reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] TLS handshake failure

I haven't been following this discussion from the start, but it is ringing really loud bells for me. Some time ago we had a rather similar discussion on this list in which the following snippet appeared:
Cullen Jennings wrote: 
On 10/22/04 5:51 PM, "Bob Bramwell" <bob@xxxxxxxxxx> wrote:



This note is part reality check and part change proposal.  Your constructive
feedback will be most welcome.

I am trying to set things up to allow TLS connections to do client
authentication.  There are a number of things, notably in the Security class,
that will need to change to accomodate this.

At present a Security object has two public certificates associated with it:
its publicCert and its publicIdentityCert.  The former is used as the 
certificate
presented to a TLS client when it connects to a TlsConnection created in
server mode.  The latter only appears to be used for signing stuff 
(computeIdentity
and checkIdentity functions).  No provision is made for a client side 
certificate
per se.
uhmm the PublicCert would be used for this
I remain convinced that there *are* scenarios where distinct client and server certificates have to be presented. IMO there ought to be provision for this. Presenting the server cert if no client cert were specified seems to be a reasonable default position to take. 

Hope that helps,
        Bob.

Sandeep Sharma wrote:

I do not think it was doing the correct thing. For a TlsTransport that
was created with a domain, it was not presenting the right certificate
when acting as a client.

I changed some code in there so that the certificate and key are 'used'
for a client and my TLS handshake issues are solved now. 
By the way, once resip establishes a TLS connection to a remote side,
1) How long is the connection kept around?
2) Under what conditions does resip disconnect?
3) Is it like: "Connect, Send SIP message, Disconnect" ?

Thanks


On Wed, 2005-05-04 at 09:16 -0700, Cullen Jennings wrote:


This is a part that may need some refactoring. Most clients that are phones
or softphones won't have a cert and won't do mutual TLS. However, some will
and proxy to proxy connection will often do mutual TLS and have one proxy
acting as the client.

The design idea was that when you create a TlsTransport, you say if it has a
certificate or not. If it does, then it should use it when acting as client
or server. If it does not, then it can only act as a client.

Not sure if the code does this or not.



On 5/4/05 8:55 AM, "Sandeep Sharma" <ssharma@xxxxxxxxxx> wrote:



I noticed that in TlsConnection.cxx there is code such as:

  if ( mServer )
  {
     assert( mSecurity );

     X509* cert =
mSecurity->getDomainCert(mDomain); //mDomainCerts[mDomain];
     if (!cert)
     {
        ErrLog(<< "Don't have certificate for domain " << mDomain );
     }

     if( !SSL_use_certificate(mSsl, cert) )
     {
        throw Security::Exception("SSL_use_certificate failed",
                                  __FILE__,__LINE__);
     }

     EVP_PKEY* pKey =
mSecurity->getDomainKey(mDomain); //mDomainPrivateKeys[mDomain];
     if (!pKey)
     {
        ErrLog(<< "Don't have private key for domain " << mDomain );
     }
     if ( !SSL_use_PrivateKey(mSsl, pKey) )
     {
        throw Security::Exception("SSL_use_PrivateKey failed.",
                                  __FILE__,__LINE__);
     }
  }

Why are SSL_use_certificate and SSL_use_PrivateKey only called for
server? I think they should be called regardless. (even if we are acting
as client).

Thoughts?



On Tue, 2005-05-03 at 15:06 -0600, Sandeep Sharma wrote:


Thanks for the information.

The code for a resip client verifying the server cert is in the function
computePeerName that is called after the SSL_do_handshake. My
application is failing in SSL_connect itself, so I think it is a issue
of not being able to find the cert issuer in the trusted list. This
statement is based on the fact that when I run openssl s_client I am
able to connect successfully (but I do see errors related to cert
verification - errors are in my initial post).

So I am trying to understand how the verification works. My machine has
a file called /usr/share/ssl/cert.pem that has 61 (CA) certs in it. 13
of these are from Verisign. I created 13 files with prefix root_cert_
under my application directory and the logs indicate that the preload
function is loading these certificates now.

I connect to the server and the server presents this certificate. (some
portions have been replaced with XXXX or ....)

Certificate:
   Data:
       Version: 3 (0x2)
       Serial Number:
           XXXX
       Signature Algorithm: sha1WithRSAEncryption
       Issuer: O=VeriSign Trust Network, OU=VeriSign, Inc., OU=VeriSign
International Server CA - Class 3, OU=www.verisign.com/CPS Incorp.by
Ref. LIABILITY LTD.(c)97 VeriSign
       Validity
           Not Before: Dec  6 00:00:00 2004 GMT
           Not After : Dec  6 23:59:59 2006 GMT
       Subject: C=US, ST=Virginia, L=XXXX, O=XXXX, OU=XXXX, OU=Terms of
use at www.verisign.com/rpa (c)00, CN=XXXX
       Subject Public Key Info:
           Public Key Algorithm: rsaEncryption
           RSA Public Key: (2048 bit)
               Modulus (2048 bit):
                   ....:
                   ....:
....: ....: 
               Exponent: 65537 (0x10001)
       X509v3 extensions:
           X509v3 Basic Constraints:
               CA:FALSE
           X509v3 Key Usage:
               Digital Signature, Key Encipherment
           X509v3 CRL Distribution Points:

URI:http://crl.verisign.com/Class3InternationalServer.crl

           X509v3 Certificate Policies:
               Policy: 2.16.840.1.113733.1.7.23.3
                 CPS: https://www.verisign.com/rpa

           X509v3 Extended Key Usage:
               Netscape Server Gated Crypto, TLS Web Server
Authentication, TLS Web Client Authentication
           Authority Information Access:
               OCSP - URI:http://ocsp.verisign.com

           1.3.6.1.5.5.7.1.12:
               0_.].[0Y0W0U..image/gif0!
0.0...+..............k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif
   Signature Algorithm: sha1WithRSAEncryption
....:
....:
....:
....:

What happens during verification? I am guessing something in this cert
should match one of the root certs for verification to succeed? What is
that bit? 
I even tried adding this to Security.cxx but it did not help.
SSL_CTX_set_options(mSslCtx, SSL_OP_ALL);

Another thing I noticed is that resip uses calls to X509_STORE*. I
looked at another SSL based app and it uses stuff like this:
SSL_CTX_set_client_CA_list();
SSL_CTX_load_verify_locations()

Are both of these approaches basically doing the same thing behind the
scenes? 
If anyone has successfully tested a scenario similar to what I described
above, please let me know.

FWIW, the other side is able to successfully establish a TLS connection
with my application and send in SIP messages. It is just not working
from me to them.

I am at my wit's end here. Any help, pointers are welcome.

Thanks
Sandeep



On Mon, 2005-05-02 at 17:22 -0700, Cullen Jennings wrote:


Try and answer a few of your questions here - there should be better
documentation on all of this ...

the root_cert* files are the certs for CA that you trust - so you would need
to copy the versign cert to one of these.

The domain_cert are the things that are used for TLS  - so this would be
your certificate for the serer.

The user_cers are only used for S/MIME and don't have anything to do with
TLS 
Some of the code on a Resip client verifying the server cert has been
changing and I'm a not up to date on it. It should be checking the
SubjectAltName of the cert and that the date of the cert is valid. It is not
checking CRL stuff.


On 5/2/05 4:57 PM, "Sandeep Sharma" <ssharma@xxxxxxxxxx> wrote:



Hello,

I am looking for some help on how resiprocate validates/verifies server
certificates presented as part of TLS handshake.

The client is my application linked with resiprocate. The server is
another application that uses openssl.

The client tries to establish a TLS connection to server. On the client
(resip) side, following errors are seen..

TlsConnection.cxx:176 | TLS connection failed ok=-1 err=5
error:00000005:lib(0):func(0):DH lib
TlsConnection.cxx:196 |  (SSL Error want syscall)
TlsConnection.cxx:197 | Error may be because trying ssl connection to
tls server
TlsConnection.cxx:228 | Couldn't TLS connect
Write failed on socket: 18, closing connection

On server side, they report errors like this:
SSL3_GET_CLIENT_CERTIFICATE: peer did not return a certificate.

I CAN establish a connection using openssl s_client using -ssl2, so I
know that the server is SSL2 (not TLS). In my application, I am using
SSLv23 as the method. This also proves that the server has been
provisioned with my (client's) self signed cert.

I read that openssl s_client does server certificate verification but
still continues if the verification fails. But looks like resip stops if
the verification fails.

I looked back into the logs from openssl s_client and sure enough, there
were messages related to server certificate verification failure.

openssl s_client -connect server:port -verify 10 -cert cert.pem -key
key.pem -showcerts -debug -nbio_test -state -crlf -ssl2

verify error:num=20:unable to get local issuer certificate
verify return:1
verify error:num=27:certificate not trusted
verify return:1
verify error:num=21:unable to verify the first certificate
verify return:1

The server cert is issued by Verisign and the CN matches the machine
name that I am trying to connect to.

When I copy the server certificate on to my box and run openssl verify
on that cert, I get similar (not exactly same) errors.

I looked in resip code and found that there is some processing done with
files with prefix domain_cert_, user_cert_ and root_cert_ but did not
really understand what needs to be done.

So my specific questions are:

1) How does resip verify server certs presented as part of TLS
handshake? Where does it look for trusted issuers?

2) What is the difference between domain_cert_*.pem, user_cert_*.pem and
root_cert_*.pem? How are they used?

Any feedback, answers, suggestions and questions are welcome.

Thanks



--
Bob Bramwell            Jasomi Networks (Canada) | This space
Ph: 403 269 2938 x155   #310 602 11th Ave SW     | intentionally
FX: 403 269 2993        Calgary, AB, T2R 1J8     | left blank.