Usando il comando openssl, come posso sapere se sta usando TLS 1.0?

TL; TR: È tutt'altro che banale verificare dal client che un server non supporta TLS 1.0. Si può essere sicuri che il server supporti TLS 1.0 se si ottiene una connessione riuscita con TLS 1.0. Ma non puoi essere sicuro che il server non supporti TLS 1.0 se questo tentativo fallisce.

Come già sapevi, le informazioni fornite nel link che citi sono almeno parzialmente errate. Inoltre, sono incompleti. Controllare se un server ha realmente TLS 1.0 disabilitato non è così semplice. Per capire cosa è necessario verificare per essere veramente sicuri è meglio avere almeno una conoscenza di base di come funziona TLS-Handshake. Nota che la maggior parte di ciò che dico qui vale anche per SSL, che è principalmente il nome precedente per la stessa famiglia di protocolli ora nota come TLS.

Inizialmente, il client deve creare una connessione TCP al server. Questo non ha ancora niente a che fare con TLS stesso. E già se la connessione TCP ha esito positivo otterrai CONNECTED(00000003) . Se non si ottiene questo CONNECTED, il server potrebbe essere inattivo o non essere raggiungibile dal sito, ad esempio perché un firewall sta bloccando l'accesso. Pertanto, non ottiene CONNECTED non dice nulla sulla capacità del server di supportare TLS 1.0 .

Dopo aver creato la connessione TCP inizia la parte TLS. Nel caso più semplice, il client invia all'inizio dell'handshake TLS all'interno del messaggio ClientHello la migliore versione di TLS che può e le cifre supportate. Il server risponde con il miglior protocollo SSL / TLS supportato che sia uguale o inferiore alla versione del protocollo offerta dal client. E il server sceglie il codice comune in base a ciò che offre il client e a cosa è configurato per essere accettabile per il server. Nel tuo caso specifico, il client offre TLS 1.0 come protocollo migliore (a causa dell'opzione -tls1 ) e il set di crittografia predefinito. L'handshake avrà esito negativo se il server non supporta TLS 1.0 o inferiore OR se il server non supporta nessuno dei codici offerti dal client. A causa dell'ultima parte è possibile che il server non riesca con il tuo client specifico anche se il server ha abilitato TLS 1.0 perché al server non piacciono le cifre offerte dal client .

E diventa più complesso. È normale che i server supportino più certificati sullo stesso indirizzo IP oggi. Ciò avviene includendo il nome host di destinazione utilizzando l'estensione SNI TLS all'interno di ClientHello all'inizio dell'handshake TLS. Se non è presente un'estensione SNI o se l'estensione non corrisponde ad alcun hostname configurato, il server invierà solitamente un certificato predefinito o interromperà l'handshake. A causa dell'ultima parte è possibile che il server non riesca con il tuo client specifico anche se il server ha abilitato TLS 1.0 perché non è stata utilizzata alcuna estensione SNI o è stata utilizzata con il nome host errato . openssl s_client non utilizzerà SNI per impostazione predefinita, quindi il tuo tentativo potrebbe semplicemente fallire solo a causa di un'estensione SNI mancante. Devi usare l'opzione -servername per questo e ovviamente devi usare un nome host correttamente configurato sul server con questa opzione.

E fino ad ora ci siamo occupati solo di stack TLS sani e di una connessione diretta al server. Se lo stack TLS è interrotto o se c'è qualche intermediario in mezzo (come bilanciamento del carico, firewall, ecc.) potrebbero far fallire accidentalmente o di proposito l'handshake anche se il server supporta TLS 1.0. E se hai una terminazione SSL davanti al tuo server (alcuni firewall, load balancer o un CDN) non testerai nemmeno le proprietà del server ma del sistema di fronte ad esso.

In altre parole: se si ottiene una connessione TLS 1.0 di successo con il server, si può essere sicuri che il server o un terminatore SSL di fronte supportino TLS 1.0. Se la connessione TLS 1.0 non funziona, non significa che il server non supporti TLS 1.0.

Sebbene questi strumenti non rispondano direttamente alla tua domanda specifica, possono fornire i risultati che stai cercando. Se disponi di una connessione Internet, prova alcuni di questi:

• link
• link
• link

Se nessuna connessione Internet tenta:

• link
• link

Sì, quel sito web è sbagliato ; CONNECTED significa che la connessione TCP è riuscita, ma non dice nulla sull'handshake TLS (o si spera non su SSL). Se non si ottiene CONNECTED ma si ottengono alcune righe che terminano con connect: errno=$n (anche se il numero è 0!) Significa che non siamo nemmeno riusciti a tentare una stretta di mano e quindi non abbiamo informazioni in alcun modo su ciò che il server supporta.

Sebbene tu possa imparare a leggere i messaggi di errore e altre informazioni openssl , l'indicatore chiave è la linea che inizia con New, all'inizio dell'ultimo blocco di output (dopo --- poche righe prima %codice%); se mostra una versione e un codice di protocollo reali, l'handshake ha avuto successo, se ha SSL-Session: l'handshake non è riuscito - come fa il tuo.

Nota: l'handshake può fallire per ragioni diverse dalla versione del protocollo. Se questo test ha esito positivo per 1.0, puoi essere sicuro che il server supporta 1.0, ma se questo test fallisce, non dimostra che il server non supporta 1.0. Avrai bisogno di conoscere effettivamente TLS per distinguerli. Come Steffen ha postato a un livello molto più lungo mentre stavo scrivendo questo - ma ho deciso che i miei paras 2 e 4 potrebbero ancora aiutare.

FWIW nota anche che il testing per SSLv2 utilizzando solo (NONE) non è valido nelle versioni 1.0.0 su dove la lista di cifratura predefinita impedisce la connessione SSLv2 anche sui server che supportano SSLv2. Tuttavia, qualcuno che ancora oggi si preoccupa di SSLv2 su un server reale (non in laboratorio o in laboratorio) è in pericolo.