Sto cercando un modo semplice per sapere se un server utilizza l'estensione SSL Indicazione nome server per il suo certificato HTTPS su un sito Web. Un metodo che utilizza un browser o la riga di comando Unix va bene.
Grazie!
Sto cercando un modo semplice per sapere se un server utilizza l'estensione SSL Indicazione nome server per il suo certificato HTTPS su un sito Web. Un metodo che utilizza un browser o la riga di comando Unix va bene.
Grazie!
Risposte:
SNI viene avviato dal client, quindi è necessario un client che lo supporti. A meno che tu non sia su Windows XP, il tuo browser lo farà. Se il tuo client ti consente di eseguire correttamente il debug delle connessioni SSL (purtroppo, anche i comandi CLI gnutls / openssl non lo fanno), puoi vedere se il server rispedisce un campo nome_server nel ciao esteso. Si noti che l'assenza di questo campo significa solo che il server non ha utilizzato il nome_server nel ciao del client per aiutare a scegliere un certificato, non che non lo supporti.
Quindi, in pratica, il test più semplice è semplicemente provare a connettersi. Per questo è necessario conoscere due nomi che si risolvono nello stesso IP, a cui è possibile stabilire una connessione ssl. https è più semplice in quanto puoi semplicemente passare a entrambi i nomi e vedere se ti viene presentato il certificato corretto.
Ci sono tre risultati:
Un test leggermente più complicato che produrrà più informazioni è di aprire e catturare i fili durante la navigazione. È quindi possibile trovare i pacchetti pertinenti filtrando per ssl.handshake. Le schermate seguenti sono un esempio di una coppia hello client / ciao server in cui è supportato SNI:
Anche in questo caso, ovviamente l'assenza di un campo nome_server nel ciao server non indica che SNI non è supportato. Solo che il nome_server fornito dal client non è stato usato per decidere quale certificato usare.
L'unico liner che probabilmente stai cercando per rilevare la presenza di un'intestazione di estensione di indicazione del nome server SSL / TLS è:
openssl s_client -servername www.SERVERNAME.com -tlsextdebug -connect www.YOURSERVER.com:443 2>/dev/null | grep "server name"
dove si www.SERVERNAME.com
trova il valore SNI che stai testando ed www.YOURSERVER.com
è il nome di dominio o l'indirizzo IP del server TLS che stai testando.
La riga di comando usa openssl
's s_client
(vedi s_client (1) ) per connettersi al server www.YOURSERVER.com
sulla porta 443
. L' -tlsextdebug
opzione attiva l'output di debug dell'estensione TLS. L' -servername
opzione indica al s_client
programma di passare www.SERVERNAME.com
come valore del campo SNI nel pacchetto ClientHello durante l'handshake TLS.
Infine, 2>/dev/null
nasconde semplicemente l'output di stderr (che può essere rumoroso) e la | grep "server name"
pipeline filtra stdout per visualizzare l'estensione TLS denominata "nome server" s_client
nell'output di debug dell'estensione TLS.
Se vedi una linea di output come
TLS server extension "server name" (id=0), len=0
quindi il server restituisce le informazioni dell'intestazione SNI nella sua risposta ServerHello. In caso contrario, è possibile che il server non supporti SNI o che non sia stato configurato per restituire informazioni SNI dato il nome richiesto. In questo caso, ricontrolla che stai utilizzando un nome di dominio -servername
nell'opzione su cui il server dovrebbe rispondere con le informazioni SNI su.
-servername
o meno. -servername sdfsdlkfjsdf23.somedomain.somewhere -connect realhost.somedomain.somewhere
= TLS server extension "server name" (id=0), len=0
(E lo stesso output se corrispondono.) Come si verifica che non corrisponda a un host sul server dall'output?
-msg
oltre ai parametri sopra e grep per "Alert". Se -servername
è sbagliato otterrai qualcosa di simile TLS 1.2 Alert ... warning unrecognized_name
dal server. @Meitar Penso che se lo aggiungi alla risposta sarà utile per altre persone.
-msg
switch aggiunge semplicemente un hexdump di messaggi del protocollo TLS. Non è necessario osservare un errore di handshake TLS, quindi sarebbe errato aggiungere a questa risposta. Inoltre, errori di handshake TLS come questo vengono stampati su STDOUT, il che significherebbe che 2>/dev/null
sarebbe necessario rimuoverli dalla risposta per poter essere elaborati grep
in primo luogo. Ciò che @bshea sta effettivamente chiedendo è "Come posso rilevare gli errori TLS?" che è una domanda completamente diversa dalla domanda "Questo server utilizza la funzionalità SNI del protocollo TLS?" che è l'argomento qui.
STDERR
a un file di testo, non visualizzo quell'errore lì. Senza non -msg
avrei potuto trovare un'altra opzione che mostra i messaggi di handshake. (usando openssl 1.0.2q). Finché la rilevanza per la risposta potresti avere ragione.
È possibile utilizzare openssl
per recuperare e interrogare il certificato.
openssl s_client -connect
openssl x509
grep
per trovare le informazioni "DNS:"openssl s_client -connect alice.sni.velox.ch:443 | openssl x509 -noout -text | grep DNS:
% openssl s_client -connect alice.sni.velox.ch:443 | openssl x509 -noout -text | grep DNS:
depth=2 C = BM, O = QuoVadis Limited, CN = QuoVadis Root CA 2
verify return:1
depth=1 C = BM, O = QuoVadis Limited, CN = QuoVadis Global SSL ICA G2
verify return:1
depth=0 C = CH, ST = Zuerich, L = Zuerich, O = Kaspar Brand, CN = alice.sni.velox.ch
verify return:1
DNS:alice.sni.velox.ch, DNS:carol.sni.velox.ch
L'ultima riga mostra tutte le voci SNI presenti nel certificato:
DNS:alice.sni.velox.ch, DNS:carol.sni.velox.ch
DNS:...
voci sull'ultima riga mostrano tutti i nomi SNI validi nel certificato.
openssl
. Sono disponibili alcuni dettagli:openssl s_client -servername alice.sni.velox.ch -tlsextdebug -msg -connect alice.sni.velox.ch:443
durante il test SSL Qualys vengono fornite alcune indicazioni sull'utilizzo di SNI .