Perché l'handshake SSL non funziona con iPad? [chiuso]

3

Ho un server tomcat che ascolta su un socket SSL con protocollo TLS. Quando ci si connette a tutti i browser desktop, tutto funziona correttamente. Quando ci si connette a Safari su iPad, l'handshake SSL fallisce.

Ho annusato cosa succede ma non riesco a capire cosa sta succedendo. Questo è l'output ssldump. Come puoi vedere, il client di iPad prova tre volte utilizzando diverse versioni_ client e cipher, ma il server risponde sempre handshake_failure.

L'ultima prova è questa (l'handshake completo si trova nel link sopra).

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

Quale potrebbe essere il problema? Come posso indagare meglio?

Ti ringrazio molto

Aggiornamento : abilitando la registrazione SSL in java (lato server di registrazione), ottengo questo, quindi sono davvero correlato al cipher:

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)
    
posta eppesuig 15.02.2013 - 11:47
fonte

2 risposte

1

Dovresti provare un ssldump per vedere cosa succede per una connessione riuscita da un browser, in particolare quali cifrari sono stati annunciati dal client e quale è stato scelto dal server. Questo strumento può anche essere usato per vedere cosa supporta il server.

Un'altra possibilità è l'uso di estensioni. In SSL / TLS , il messaggio ClientHello può contenere estensioni, che i server devono saltare quando non capiscono loro. Alcuni server (buggy) rifiutano la connessione quando vedono le estensioni che non supportano.

Per vedere esattamente ciò che l'iPad invia, fino all'ultimo byte, usa tcpdump o uno di questi eleganti wrapper grafici come Wireshark . Quindi puoi creare un piccolo programma che apre una connessione TCP al server, scrive un ClientHello e verifica se il server risponde con un messaggio di avviso o un ServerHello . Provando le varianti, dovresti essere in grado di individuare ciò che rende il server infelice con ciò che l'iPad invia (la diagnosi non sta guarendo, ma è un passo nella giusta direzione). È possibile utilizzare il codice sorgente di TestSSLServer come base per questo programma.

    
risposta data 15.02.2013 - 12:44
fonte
1

Affinché TLS possa implementare più siti https su un singolo indirizzo IP, il protocollo deve rinegoziare la connessione. Prova a abilitare quel lato del server di rinegoziazione non sicuro.

Thomas ha menzionato sopra "alcuni server bacati" sopra, ecco un link a una nota tecnica Apple intitolata " Problemi di interoperabilità di iOS 5 e TLS 1.2 ".

    
risposta data 20.02.2013 - 05:26
fonte

Leggi altre domande sui tag