debugging perché TLS ha esito negativo tra openssl e alcuni siti SSL

Question

debugging perché TLS ha esito negativo tra openssl e alcuni siti SSL

#1 da (2 voti)

0

Ho un vecchio sistema CentOS 5.11 con OpenSSL 0.9.8e. Sono in grado di connettere la maggior parte dei siti SSL senza problemi. Tuttavia, con alcuni siti come www.looklinux.com, se provo a connettermi, ottengo questo errore:

openssl s_client -connect www.looklinux.com:443  
CONNECTED(00000003)  
27080:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert 
handshake failure:s23_clnt.c:586:

Ora, da fare

openssl s_client -connect www.google.com:443 | grep -i "protocol"

Vedo Protocol : TLSv1 nell'output. E dal link link
So che www.looklinux.com supporta TLS 1.0, 1.1 e 1.2. Quindi sembra che il client e il server condividano almeno un protocollo compatibile (TLS v1) e non è questo il problema. Ho ragione finora?

Allora, cosa sta andando male e come posso risolverlo?

Quando lo eseguo con il flag -debug ottengo:

openssl s_client -connect www.looklinux.com:443 -debug
CONNECTED(00000003)
write to 0x872a198 [0x87665b8] (88 bytes => 88 (0x58))
0000 - 16 03 01 00 53 01 00 00-4f 03 01 5b 05 ff fc 97   ....S...O..[....
0010 - 78 87 a5 97 77 11 57 60-1b e0 ae 9f 81 8c c6 c6   x...w.W'........
0020 - 15 3c fb 0b ef 3e d7 20-8a 83 3b 00 00 28 00 39   .<...>. ..;..(.9
0030 - 00 38 00 35 00 16 00 13-00 0a 00 33 00 32 00 2f   .8.5.......3.2./
0040 - 00 05 00 04 00 15 00 12-00 09 00 14 00 11 00 08   ................
0050 - 00 06 00 03 00 ff 01                              .......
0058 - <SPACES/NULS>
read from 0x872a198 [0x876bb18] (7 bytes => 7 (0x7))
0000 - 15 03 01 00 02 02 28                              ......(
1678:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:586:

Questo post: link
suggerisce che a volte una versione precedente di OpenSSL non sia semplicemente compatibile. È facile spiegare che cosa non può fare il vecchio OpenSSL? E non c'è davvero nessuna soluzione? Sono cauto nel "aggiornarlo" costruendo OpenSSL dal sorgente, perché le istruzioni per compilare dalla fonte di solito hanno errori o omissioni, in cui un lettore esperto sa quali sono le istruzioni supposte da dire, ma io seguo le direzioni esattamente e ottenere hosed. Quindi spero di poter risolvere questo problema semplicemente installando un certificato extra, o qualcosa del genere.

openssl

posta Bennett 24.05.2018 - 01:10

fonte

1 risposta

Leggi altre domande sui tag openssl

Email priva di metadati: in che modo SENDER può inviare direttamente, in modo anonimo e in sicurezza, il provider di posta del RECIPIENT per fornire un'e-mail priva di metadati? Come viene generato il nonce di WordPress?

score 2 · Accepted Answer

Questo problema non è correlato ai certificati in alcun modo e non può essere risolto da un certificato.

Il rapporto SSLLabs mostra che il server supporta solo suite che utilizzano lo scambio di chiavi ECDHE_ECDSA, ad esempio Crittografia delle curve ellittiche . Upstream OpenSSL 0.9.8 ha implementato ECC, ma disabilitato per impostazione predefinita e si doveva leggere il codice sorgente per trovare la parola magica ECCdraft per abilitarlo. Tuttavia, RedHat e quindi CentOS rimosso (tutto) ECC dai pacchetti creati prima di circa due anni fa, quindi probabilmente non funzionerà per voi. Puoi facilmente vedere che l'elenco di suite offerte nel tuo ClientHello (offset esadecimale da 2E a 56) non contiene alcuna coppia di byte nell'intervallo C0xx in cui sono presenti tutte le suite ECC.

Inoltre, come indicato nel rapporto SSLLabs, "Questo sito funziona solo con i browser con supporto SNI." e OpenSSL non invia SNI per impostazione predefinita; devi specificare l'opzione -servername $hostname - che funziona in 0.9.8.

Tuttavia, il mio 0.9.8zg con ECCdraft e -servername ottiene ancora l'avviso 40. L'unica differenza che posso trovare tra quello e 1.0.0s (con -servername ) che funziona è che 1.0.0 invia le estensioni pointformats (0xB) e curve (0xA) e la 0.9.8 no - ma secondo rfc4492 dovrebbero essere facoltative. Quindi, anche se avessi un 0.9.8 non nobilitato potresti essere sfortunato.

Non ho mai avuto problemi a creare OpenSSL stesso dal sorgente su qualsiasi Unix decente; è in realtà uno dei pacchetti più semplici da costruire che abbia mai visto. Tuttavia, dovresti anche ricostruire tutto sul tuo sistema per utilizzare l'OpenSSL aggiornato e, a seconda di quali sono queste cose, potrebbe essere molto più difficile, specialmente dove sono richieste modifiche di origine, poiché in alcuni casi sono passati da 0.9.8 a 1.0.x (e molto di più da 1.0.x a 1.1.0 se si voleva andare avanti così radicalmente).

A seconda di ciò che stai facendo, potresti essere in grado di indirizzare il tuo traffico attraverso un proxy SSL / TLS esterno, come squid + bump, che accetta il vecchio TLS sbiadito (o anche SSL) puoi fare e trasmettere i tuoi dati da e verso altri sistemi usando il nuovissimo TLS scintillante e scintillante.