#99 TLS Initilization bug in sipp.cpp

future
open-accepted
Rob Day
Transport (9)
5
2013-04-14
2008-06-04
Mahesh Nayak
No

Hello SIPp Developers.

I was trying to make a SIP call over TLS using SIPp.

There are two kinds of authentication and certification validation that can happen during TLS negotiation. They aer:
1. Server authentication - where the server authenticates the client certificate.
2. Mutual Authentication - where the client can send attribute "Server request certificate" and the server would have to send its Certificate(s) to the Client for validation and integrity authentication.

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 at the right place.

I have quoted the code below (from sipp.cpp) along with my 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;
}
// } Mahesh says: 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.

Discussion

  • Rob Day
    Rob Day
    2012-12-15

    Thanks - I'm looking at porting SIPp to use GnuTLS in version 3.4, so will look at this then.

     
  • Rob Day
    Rob Day
    2012-12-15

    • status: open --> open-accepted
    • assigned_to: Rob Day
    • milestone: --> v3.4
     
  • Rob Day
    Rob Day
    2013-04-14

    • Group: v3.4 --> future