Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I do have a tomcat server that listen on an SSL socket with TLS protocol. When connecting with all desktop browser everything work right. When connecting with Safari on iPad, the SSL handshake fails.

I sniffed what happens but I am unable to understand what is going on. This is the ssldump output. As you may see iPad client try three times using different client_versions and ciphers, but the server always reply handshake_failure.

The latest try is this one (the complete handshake is in the above link).

New TCP connection #3: host35-105-static.24-87-b.business.telecomitalia.it(59123) <-> 192.168.1.55(8443)
3 1  0.0898 (0.0898)  C>S  Handshake
  ClientHello
    Version 3.0
    cipher suites
    Unknown value 0xff
    Unknown value 0x3d
    Unknown value 0x3c
    SSL_RSA_WITH_AES_128_CBC_SHA
    SSL_RSA_WITH_RC4_128_SHA
    SSL_RSA_WITH_RC4_128_MD5
    SSL_RSA_WITH_AES_256_CBC_SHA
    SSL_RSA_WITH_3DES_EDE_CBC_SHA
    SSL_DHE_DSS_WITH_NULL_SHA
    Unknown value 0x6b
    SSL_DHE_RSA_WITH_AES_128_CBC_SHA
    SSL_DHE_RSA_WITH_AES_256_CBC_SHA
    SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
    Unknown value 0x3b
    SSL_RSA_WITH_NULL_SHA
    SSL_RSA_WITH_NULL_MD5
    compression methods
              NULL
3 2  0.0906 (0.0008)  S>C  Alert
  level           fatal
  value           handshake_failure
3    0.0907 (0.0000)  S>C  TCP FIN
3    0.1772 (0.0865)  C>S  TCP FIN

What may be the problem? How can I better investigate it?

I thank you very much

Update: Enabling SSL logging in java (logging server side), I get this, so I really thing this is cipher related:

Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
http-192.168.1.55-8443-1, setSoTimeout(60000) called
[Raw read]: length = 5
0000: 16 03 00 00 4B                                     ....K
[Raw read]: length = 75
0000: 01 00 00 47 03 00 51 1E   33 5C CB 56 A8 58 4B 4D  ...G..Q.3\.V.XKM
0010: 34 86 04 4C CC 4E 00 A0   A8 7B 60 4E 6A 17 28 2F  4..L.N....`Nj.(/
0020: DB 51 1C 17 AE 9C 00 00   20 00 FF 00 3D 00 3C 00  .Q...... ...=.<.
0030: 2F 00 05 00 04 00 35 00   0A 00 67 00 6B 00 33 00  /.....5...g.k.3.
0040: 39 00 16 00 3B 00 02 00   01 01 00                 9...;......
http-192.168.1.55-8443-1, READ: SSLv3 Handshake, length = 75
*** ClientHello, SSLv3
RandomCookie:  GMT: 1360933724 bytes = { 203, 86, 168, 88, 75, 77, 52, 134, 4, 76, 204, 78, 0, 160, 168, 123, 96, 78, 106, 23, 40, 47, 219, 81, 28, 23, 174,  156 }
Session ID:  {}
Cipher Suites: [TLS_EMPTY_RENEGOTIATION_INFO_SCSV, Unknown 0x0:0x3d, Unknown 0x0:0x3c, TLS_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, Unknown 0x0:0x67, Unknown 0x0:0x6b, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, Unknown 0x0:0x3b, SSL_RSA_WITH_NULL_SHA, SSL_RSA_WITH_NULL_MD5]
Compression Methods:  { 0 }
***
[read] MD5 and SHA1 hashes:  len = 75
0000: 01 00 00 47 03 00 51 1E   33 5C CB 56 A8 58 4B 4D  ...G..Q.3\.V.XKM
0010: 34 86 04 4C CC 4E 00 A0   A8 7B 60 4E 6A 17 28 2F  4..L.N....`Nj.(/
0020: DB 51 1C 17 AE 9C 00 00   20 00 FF 00 3D 00 3C 00  .Q...... ...=.<.
0030: 2F 00 05 00 04 00 35 00   0A 00 67 00 6B 00 33 00  /.....5...g.k.3.
0040: 39 00 16 00 3B 00 02 00   01 01 00                 9...;......
http-192.168.1.55-8443-1, SEND SSLv3 ALERT:  fatal, description = handshake_failure
http-192.168.1.55-8443-1, WRITE: SSLv3 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 00 00 02 02 28                               ......(
http-192.168.1.55-8443-1, called closeSocket()
http-192.168.1.55-8443-1, handling exception: javax.net.ssl.SSLHandshakeException: no cipher suites in common
http-192.168.1.55-8443-1, called close()
http-192.168.1.55-8443-1, called closeInternal(true)
Finalizer, called close()
Finalizer, called closeInternal(true)
Finalizer, called close()
Finalizer, called closeInternal(true)
Finalizer, called close()
Finalizer, called closeInternal(true)
share|improve this question

closed as too localized by tylerl, Iszi, Gilles, Scott Pack, Rory Alsop Feb 20 '13 at 16:24

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

2 Answers 2

In order for TLS to implement multiple https sites on a single IP address, the protocol has to renegotiate the connection. Try enabling that unsafe renegotiation server side.

Thomas mentioned "some buggy servers" above, here is a link to an Apple tech note entitled "iOS 5 and TLS 1.2 Interoperability Issues".

share|improve this answer
    
Thanks for this comment. I just read that Apple note, and also the information related to the Allow unsafe renegotiation available here. I am more inclined in thinking this is a cipher error, but I am going to test it with the unsafe negotiation. I'll report here my findings. –  eppesuig Feb 20 '13 at 9:02

You should try a ssldump to see what happens for a successful connection from a browser, in particular what ciphers were announced by the client and which one was chosen by the server. This tool can also be used to see what the server supports.

Another possibility is the use of extensions. In SSL/TLS, the ClientHello message can contain extensions, which servers are supposed to skip when they don't understand them. Some (buggy) servers instead refuse the connection when they see extensions that they do not support.

To see exactly what the iPad sends, down to the last byte, use tcpdump or one of these nifty graphical wrappers like Wireshark. Then you may make a small program which opens a TCP connection to the server, writes a ClientHello, and see if the server responds with an alert message or a ServerHello. By trying variants, you should be able to pinpoint what exactly makes the server unhappy with what the iPad sends (diagnosis is not healing, but that's a step in the right direction). You could use TestSSLServer's source code as basis for this program.

share|improve this answer
    
Thanks for your suggestions. I have collected a bunch of ssldumpS from many other browsers. I even connected without problems from the same iPad with a different browser (Chrome). I then tried to reproduce the client configuration connecting with openssl s_client -connect host:port with various options but I never managed to reproduce the problem. Now I activate the complete SSL logging in java and I am waiting for a connection from iPad. I'll be back here with more information later on. –  eppesuig Feb 15 '13 at 11:54

Not the answer you're looking for? Browse other questions tagged or ask your own question.