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). 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. To see exactly what the iPad sends, down to the last byte, use tcpdump or one of these nifty graphical wrappers like Wireshark. Some (buggy) servers instead refuse the connection when they see extensions that they do not support. In SSL/TLS, the ClientHello message can contain extensions, which servers are supposed to skip when they don't understand them. This tool can also be used to see what the server supports.Īnother possibility is the use of extensions. 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. Http-192.168.1.55-8443-1, handling exception: : no cipher suites in common RandomCookie: GMT: 1360933724 bytes = Ĭipher Suites: Update: Enabling SSL logging in java (logging server side), I get this, so I really thing this is cipher related: Allow unsafe renegotiation: false What may be the problem? How can I better investigate it? The latest try is this one (the complete handshake is in the above link). As you may see iPad client try three times using different client_versions and ciphers, but the server always reply handshake_failure. I sniffed what happens but I am unable to understand what is going on. When connecting with Safari on iPad, the SSL handshake fails. When connecting with all desktop browser everything work right. I do have a tomcat server that listen on an SSL socket with TLS protocol.
0 kommentar(er)
