Hello,

On 3/12/13 8:46 AM, Olle E. Johansson wrote:

11 mar 2013 kl. 19:02 skrev Jirka Jirout jirka.jirout@mac.com:

...

Hello,

I have a very strange issue - we are running kamailio 3.3.2 as a part of Sip Provider CE and some of our clients have issues with TLS connectivity.

1. some clients such as Jitsi on Mac OS X and Bria or idoubs on iOS can always connect
2. imsdroid on Android can sometimes connect and works (about 10 % of attempts)

When I run tcpudmp on the server during the unsuccessfull attempts, I see something like this:

...

1 1 0.0347 (0.0347) C>S SSLv2 compatible client hello Version 3.1 cipher suites TLS_RSA_WITH_AES_128_CBC_SHA 1 2 0.0360 (0.0013) S>C Handshake ServerHello Version 3.1 session_id[0]= cipherSuite TLS_RSA_WITH_AES_128_CBC_SHA compressionMethod NULL 1 3 0.0361 (0.0001) S>C Handshake Certificate 1 4 0.0361 (0.0000) S>C Handshake ServerHelloDone 1 5 0.0782 (0.0420) C>S Alert level fatal value unexpected_message 1 0.0785 (0.0002) S>C TCP FIN 1 6 0.1092 (0.0307) C>S Handshake ClientKeyExchange 1 7 0.1092 (0.0000) C>S ChangeCipherSpec 1 8 0.1092 (0.0000) C>S Handshake

What I find particularly strange is that the client sends fatal alert and then attempts to continue with handshake. What exactly does this "unexpected_message" mean? Is the client letting the server know the last message was unexpected? Or is this telling me the server had not expected the message? It cannot be a certificate problem, can it?

Considering other clients were fine, I blamed our code at first, but I am no longer sure that is the (only) reason for this behavior. I decided to start from scratch and wrote an extremely simple application in plain C, that connects to the TLS port using openssl (which imsdroid also uses), sends some query and then prints response. It works fine on https sites, even on the same server kamailio is running and with the same certificates (our certificates come from Verisign CA G3). When I run ssldump, I can see handshake is fine, socket opened, the client is sending application data. I can see data coming in on the server using tcpdump. However, the data never reaches Kamailio - no sign of the packets in the log and no answer whatsoever (I use a fake REGISTER message so I would expect to get something like "Unauthorized" back).

The same happens, when I try to use openssl s_client to connect to the site and send "register" message (because R at the start of packet triggers renegotiation in s_client, uff).

My TLS settings in Kamailio are pretty much default, only using my own key and certificate.

Just for the record, I noticed similar issues with some clients at SIPit, using an older version of Kamailio for the TLS tests. I haven't had time to dig deeper into it, but it feels very similar to what you see here.

If the client side is doing renegotiation, then set this module parameter:

- http://kamailio.org/docs/modules/stable/modules/tls.html#renegotiation

Beware that it exposes some security risks (if you google, you'll find more about this generic ssl issue).

Let us know if it works.

Cheers, Daniel

Hello,

I have enabled re-negotiation, which does not do too much good I am afraid. However, the connection attempts do get thru to kamailio now, although I am afraid it does not help either.

Mar 12 09:16:23 crypto2 /usr/sbin/kamailio[404]: ERROR: tls [tls_server.c:1190]: TLS accept:error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected message Mar 12 09:16:23 crypto2 /usr/sbin/kamailio[404]: ERROR: <core> [tcp_read.c:1127]: ERROR: tcp_read_req: error reading

I went thru our client code and it does the following:

SSL_CTX_new(SSLv23_client_method()) or SSL_CTX_new(SSLv23_server_method())))

SSL_CTX_set_mode(transport->tls.ctx_client, SSL_MODE_AUTO_RETRY) SSL_CTX_set_mode(transport->tls.ctx_server, SSL_MODE_AUTO_RETRY) SSL_CTX_set_verify(transport->tls.ctx, SSL_VERIFY_NONE, null)

SSL_CTX_set_cipher_list(transport->tls.ctx, "AES256-SHA")

SSL_new(ssl_ctx) SSL_set_fd(ssl, fd)

SSL_connect(ssl)

and then of course SSL_write() and SSL_read()

regards, jj