Re: [reSIProcate-users] SSL not working with reSIProcate 1.4.1
- From: "Srivastava, Rajeev Kumar (Rajeev)" <srivastava@xxxxxxxxx>
- Date: Wed, 22 Apr 2009 23:09:14 +0530
Now I am getting a weird problem with
TLS/SSL.
My application is having 5 UAs & each UA has its
own DUM & SipStack.
Each UAs are using different UDP port but same TCP
& TLS port.
When I enabled TLS the INVITE sent to different UAs are
being delivered to one particular UA's onNewSession virtual
function.
e.g. UA1's onNewSession is being called for INVITE on
any of the 5 UAs.
And this selection of particular UA too is random. Not
for a particular guy each time I restart my
application.
If TLS is not being used, everything works
fine.
Corresponding UA's onNewSession function is being
called for respective INVITEs & not always for a particular UA's
onNewSession.
Is this recommended to have different DUM &
SipStack for each UA or do they share these?
What could be the problem here?
Thanks,
~
Rajeev
From: slgodin@xxxxxxxxx
[mailto:slgodin@xxxxxxxxx] On Behalf Of Scott Godin
Sent:
Sunday, April 19, 2009 12:29 AM
To: Srivastava, Rajeev Kumar
(Rajeev)
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re:
[reSIProcate-users] SSL not working with reSIProcate 1.4.1
Hi Srivastava,
Thanks for this. It has already been fixed in SVN revision 8296 and
8348.
Regards,
Scott
On Sat, Apr 18, 2009 at 10:18 AM, Srivastava, Rajeev
Kumar (Rajeev)
<srivastava@xxxxxxxxx>
wrote:
Scott, Thanks
for your inputs. SSL is working fine now after generating new certificated
with correct hosname information.
However, There
is one problem I found in resip\stack\ssl\TlsConnection.cxx
TlsConnection::read function.
<snip>
int bytesRead =
SSL_read(mSsl,buf,count);
StackLog(<< "SSL_read returned
" << bytesRead << " bytes [" << Data(Data::Borrow, buf,
bytesRead) << "]");
if (bytesRead > 0
&& SSL_pending(mSsl))
{
int restBytes =
SSL_pending(mSsl);
char* buffer =
getWriteBufferForExtraBytes(restBytes);
StackLog(<< "reading remaining buffered
bytes");
restBytes = SSL_read(mSsl, buffer,
SSL_pending(mSsl));
StackLog(<<
"SSL_read returned " << restBytes << " bytes [" <<
Data(Data::Borrow, buffer, restBytes) << "]");
if
(restBytes>0)
{
bytesRead +=
restBytes;
}
else
{
bytesRead =
restBytes;
}
}
</snip>
My Client application was
returning -1 for SSL_read(mSsl,buf,count) function call with error
code 2.
After that it was crashing at
following line :-
StackLog(<< "SSL_read
returned " << bytesRead << " bytes [" << Data(Data::Borrow,
buf, bytesRead) << "]");
when it was trying to write
<< Data(Data::Borrow, buf, bytesRead) .
The correct location for this log
message should be inside if (bytesRead > 0 &&
SSL_pending(mSsl)) block.
The correct code should be
:
<snip>
int bytesRead =
SSL_read(mSsl,buf,count);
if (bytesRead > 0
&& SSL_pending(mSsl))
{
StackLog(<< "SSL_read returned " << bytesRead << " bytes ["
<< Data(Data::Borrow, buf, bytesRead) <<
"]");
int restBytes =
SSL_pending(mSsl);
char* buffer =
getWriteBufferForExtraBytes(restBytes);
StackLog(<< "reading remaining buffered
bytes");
restBytes = SSL_read(mSsl, buffer,
SSL_pending(mSsl));
StackLog(<<
"SSL_read returned " << restBytes << " bytes [" <<
Data(Data::Borrow, buffer, restBytes) << "]");
if
(restBytes>0)
{
bytesRead +=
restBytes;
}
else
{
bytesRead =
restBytes;
}
}
</snip>
Thanks,
~ Rajeev
Sent: Thursday, April 09, 2009 6:57
PM
The problem is that the post TLS handshake hostname validation
check is failing. When a TLS client connects to a server - it must check
that the certificate presented by the server to the client identifies the
server that it is trying to contact. In SIP this means the hostname in
the request URI of the SIP request you are sending must match either the
certificate subject common name, or one of the SubjectAltNames (DNS or URI
entries). The following line in the logs indicate this error:
<<RESIP:TRANSPORT-ERROR>> Certificate name mismatch: trying
to connect to <148.147.174.64> remote cert domain(s) are <Converged
Communication Server 2.1>
There are two problems in your setup. You are using an IP address
to contact the server. When using TLS you should always use hostnames or
SRV records to connect to the TLS server. Your certificate does not
contain a valid hostname in the Subject CommonName field.
Hope this helps.
Scott
On Thu, Apr 9, 2009 at 6:51 AM, Srivastava, Rajeev
Kumar (Rajeev)
<srivastava@xxxxxxxxx> wrote:
Hello
Scott,
Yes, my
reSIProcate Application is TLS Client.
I am not sure
what changes need to be done while generating Certificate to pass this host
validation check.
Is this (the
problem I am facing) because of wrong certificate or do I need to change my
code to work with new version of reSIProcate?
As I am not
very much knowledgeable in SSL stuff, I am attaching the reSIProcate logs
along with the certificates I am using for further help on
this.
Thanks,
~ Rajeev
Is resiprocate the TLS client or server in these traces?
Are there any relevant errors in the resiprocate log files?
Assuming your resiprocate application is the TLS client, it is tearing
down the TLS connection after the handshake. Usually this is because
the post handshake host validation check failed. The code surrounding
hostname validation has changed since release 1.1. The resip logs
should contain some useful information if this is the case.
Scott
On Tue, Apr 7, 2009 at 5:58 AM, Srivastava, Rajeev
Kumar (Rajeev)
<srivastava@xxxxxxxxx> wrote:
Hi,
I recently upgraded
resiprocate library to 1.4.1 form 1.1 for one of my projects(Windows
only).
After that TLS is not getting
enabled.
<code
snip>
Security* pSecurity = new Security ( "..\etc"
);
SipStack* pSipStack = new SipStack (
pSecurity );
StackThread* pStackThread =
new StackThread ( *pSipStack );
pSipStack->addTransport (
TLS,
nTlsPort,
V4,
StunDisabled,
Data::Empty,
Data::from
( strDomain ) );
pSipStack->addTransport ( TCP, nTcpPort);
pSipStack->addTransport ( TCP, nUdpPort);
pStackThread->run ();
</snip>
This same piece of code is
working fine with the same certificate with reSIProcate
1.1.
But it is not working with
reSIProcate 1.4.1
I am attaching WireShark logs
for reference.
Is there any change in SSL
implementation and do I need to use it in a different manner
now?
Do let me know if you need any
more information for helping out.
Thanks,
~
Rajeev
_______________________________________________
resiprocate-users
mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/