为什么SSL握手在iPad中失败？
我确实有一个tomcat服务器可以监听带有TLS协议的SSL套接字。当与所有桌面浏览器连接时，一切都正常工作。在iPad上与Safari连接时，SSL握手失败。
我嗅到了发生了什么，但我无法理解到底发生了什么。这是ssldump输出。正如您可能看到的，iPad客户机使用不同的client_versions和密码尝试了三次，但是服务器总是响应handshake_failure。
最新的尝试是这个(完整的握手在上面的链接中)。
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可能出了什么问题？我怎么才能更好地调查它呢？
我非常感谢你
Update:在java (日志服务器端)中启用SSL日志，我得到了这个，所以我真正了解这是与密码相关的：
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)回答 2
Security用户
发布于 2013-02-15 11:44:25
您应该尝试使用ssldump来查看从浏览器成功连接的结果，特别是客户端宣布了哪些密码，以及服务器选择了哪个密码。这个工具也可以用来查看服务器支持什么。
另一种可能是使用扩展。在SSL/TLS中，ClientHello消息可以包含扩展，当服务器不理解这些扩展时，应该跳过这些扩展。当一些服务器看到它们不支持的扩展时，它们会拒绝连接。
要查看iPad到底发送了什么，直到最后一个字节，请使用tcpdump或这些漂亮的图形包装工具之一，如Wireshark。然后，您可以制作一个小程序，该程序打开到服务器的TCP连接，写入ClientHello，并查看服务器是否使用警报消息或ServerHello进行响应。通过尝试变体，您应该能够准确地确定是什么使服务器对iPad发送的内容不满意(诊断不能治愈，但这是朝着正确方向迈出的一步)。您可以使用TestSSLServer的源代码作为此程序的基础。
Security用户
发布于 2013-02-20 04:26:14
为了让TLS在一个IP地址上实现多个https站点，协议必须重新协商连接。尝试启用不安全的重新协商服务器端。
托马斯提到了上面的“一些错误服务器”，这里有一个指向苹果技术报告"iOS 5和TLS 1.2互操作性问题“的链接。
https://security.stackexchange.com/questions/30958
复制相似问题
腾讯云开发者
