Hello,
On 3/12/13 8:46 AM, Olle E. Johansson wrote:
11 mar 2013 kl. 19:02 skrev Jirka Jirout <jirka.jir...@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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
- http://conference.kamailio.com -
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
