[Sipp-devel] TLS initialization in SIPP.cpp

[Mahesh N. <mah...@mg...>]

Hello SIPp Developers.

I was trying to make a SIP call over TLS using SIPp. However I see that 
the TLS mutual authentication does not happen during the TLS handshake.

On further investigation over the source code,  it seems that the TLS 
initialization is not done properly.

I have quoted the code below (from sipp.cpp) along with my (Mash) comments:

*File: sipp.cpp Function:  static ssl_init_status FI_init_ssl_context (void)

*  /*  Load the trusted CA's */
  SSL_CTX_load_verify_locations(sip_trp_ssl_ctx, tls_cert_name, NULL);
  SSL_CTX_load_verify_locations(sip_trp_ssl_ctx_client, tls_cert_name, 
NULL);
 
  /*  CRL load from application specified only if specified on the 
command line */
*  if (strlen(tls_crl_name) != 0) { *
    if(sip_tls_load_crls(sip_trp_ssl_ctx,tls_crl_name) == -1) {
      ERROR("FI_init_ssl_context: Unable to load CRL file (%s)", 
tls_crl_name);
      return SSL_INIT_ERROR;
    }
 
    if(sip_tls_load_crls(sip_trp_ssl_ctx_client,tls_crl_name) == -1) {
      ERROR("FI_init_ssl_context: Unable to load CRL (client) file 
(%s)", tls_crl_name);
      return SSL_INIT_ERROR;
    }
     *// }  Mash: According to me, the module should have ended here for 
the condition **if (strlen(tls_crl_name) != 0).  And the following 
initialization should have been outside the above condition to have SSL 
initialization with mutual authentication in place.  There is not 
connection between CRLs and the SSL initialization. This is a bug which 
should be rectified asap in my opinion for SIPP to be inter-operable 
with other SSL products. Without the fix, the TLS would be performed 
only with server authentication and Mutual authentication negotiations 
would fail.

*   * /* The following call forces to process the certificates with the */
    /* initialised SSL_CTX *                                           */
    SSL_CTX_set_verify(sip_trp_ssl_ctx,
                       SSL_VERIFY_PEER |
                       SSL_VERIFY_FAIL_IF_NO_PEER_CERT,
                       sip_tls_verify_callback);

    SSL_CTX_set_verify(sip_trp_ssl_ctx_client,
                       SSL_VERIFY_PEER |
                       SSL_VERIFY_FAIL_IF_NO_PEER_CERT,
                       sip_tls_verify_callback);
*  }*


  /* Selection Cipher suits - load the application specified ciphers */
  SSL_CTX_set_default_passwd_cb_userdata(sip_trp_ssl_ctx,
                                             (void *)CALL_BACK_USER_DATA );
  SSL_CTX_set_default_passwd_cb_userdata(sip_trp_ssl_ctx_client,
                                             (void *)CALL_BACK_USER_DATA );
  SSL_CTX_set_default_passwd_cb( sip_trp_ssl_ctx,
                                             passwd_call_back_routine );
  SSL_CTX_set_default_passwd_cb( sip_trp_ssl_ctx_client,
                                             passwd_call_back_routine );
================================================================================================================

Let me know if my comments above make sense and whether the fix for the 
bug can be checked in.

In my local checked out code, I have further modified the code to have 
an option during runtime for mutual authentication:
1. with-tls-ma = enabled or disabled. Enabled - with mutual 
authentication. Disabled - with server authentication only.

If you think what I have explained is valid, I can checkin the code for 
the same and you can cross verify it.

Cheers,
Mahesh.
Tehcnical Lead,
Mascon Global Limited.





EMAIL DISCLAIMER : This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised distribution or copying is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of Mascon shall be understood to be neither given nor endorsed by Mascon. Any information contained in this email, when addressed to Mascon clients is subject to the terms and conditions in governing client contract.

Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we can not guarantee that any email or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Mascon grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused.