À l'aide de la commande openssl, comment savoir si elle utilise TLS 1.0?
En raison d'une analyse de sécurité, on m'a dit de ne pas utiliser TLS1.0. J'ai trouvé n lien qui m'a donné des commandes à utiliser pour vérifier si un protocole spécifique est utilisé/activé. La commande que j'ai exécutée (avec sortie est)
(Sortie de TLS1.0 désactivée)
$ openssl s_client -connect localhost:8443 -tls1
CONNECTED(00000003)
139874418423624:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1275:SSL alert number 40
139874418423624:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1505770082
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
Le lien dit que si le protocole est activé, il dira "Connecté", sinon "échec de la prise de contact". Cependant, comme vous pouvez le voir ci-dessus, il dit les deux même si j'ai configuré Tomcat pour utiliser TLS1.2.
Ma configuration dans le fichier server.xml:
<Connector port="8443" protocol="HTTP/1.1"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
keystoreFile="/glide/bigdata/bdapi/keys/bdapi_keystore.jks"
keystorePass="bdapi123" clientAuth="false" sslProtocol="TLSv1.2"
sslEnabledProtocols="TLSv1.2"/>
Si j'autorise Tomcat à utiliser TLS1.0, je vois toujours CONNECTED mais je vois également les informations du certificat.
(Sortie de TLS1.0 activée)
openssl s_client -connect localhost:8443 -tls1
CONNECTED(00000003)
<snip snip>
<snip snip>
(certificate info)
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
<snip snip>
<snip snip>
(certificate info)
---
Server certificate
-----BEGIN CERTIFICATE-----
<snip snip>
<snip snip>
(public key)
-----END CERTIFICATE-----
<snip snip>
<snip snip>
(certificate info)
---
No client certificate CA names sent
Server Temp Key: ECDH, secp521r1, 521 bits
---
SSL handshake has read 2121 bytes and written 357 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 59C0448146B0A18DE52D99C630C896E12BA9861702AB2582C2AA0658E6458B04
Session-ID-ctx:
Master-Key: <some random key>
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1505772673
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
read:errno=0
Comment interpréter la sortie d'OpenSL? Ai-je réussi à désactiver TLS1.0 avec la configuration ci-dessus ou comme il dit "CONNECTED" dans les deux sorties, je ne l'ai pas désactivé et je vais échouer à nouveau l'analyse de sécurité?
TL; TR: Il est loin d'être trivial de vérifier auprès du client qu'un serveur ne prend pas en charge TLS 1.0. Vous pouvez être sûr que le serveur prend en charge TLS 1.0 si vous obtenez une connexion réussie avec TLS 1.0. Mais vous ne pouvez pas être sûr que le serveur ne prend pas en charge TLS 1.0 si cette tentative échoue.
Comme vous l'avez déjà réalisé, les informations fournies dans le lien que vous citez sont au moins en partie fausses. De plus, ils sont incomplets. Vérifier si un serveur a vraiment TLS 1.0 désactivé n'est pas si simple. Pour comprendre ce qui doit être vérifié pour être vraiment sûr, il est préférable d'avoir au moins une compréhension de base du fonctionnement de la prise de contact TLS. Notez que la plupart de ce que je dis ici est également vrai pour SSL, qui est principalement le nom antérieur de la même famille de protocoles maintenant connue sous le nom de TLS.
Initialement, le client doit créer une connexion TCP au serveur. Cela n'a encore rien à voir avec TLS lui-même. Et déjà si la connexion TCP vous réussit) obtiendra CONNECTED(00000003). Si vous n'obtenez pas ce CONNECTED alors le serveur peut être en panne ou peut ne pas être accessible depuis votre site, par exemple parce qu'un pare-feu bloque l'accès. Ainsi, ne pas obtenir le CONNECTED ne dit rien sur la capacité du serveur à prendre en charge TLS 1.0 .
Après la création de la connexion TCP TCP, la partie TLS commence. Dans le cas le plus simple, le client envoie au début de la prise de contact TLS dans le message ClientHello la meilleure version TLS possible et les chiffres qu'il prend en charge. Le serveur répond avec le meilleur protocole SSL/TLS qu'il prend en charge, qui est égal ou inférieur à la version de protocole offerte par le client. Et le serveur choisit le chiffrement commun en fonction de ce que le client offre et de ce qui est configuré pour être acceptable pour le serveur . Dans votre cas spécifique, le client propose TLS 1.0 comme meilleur protocole (en raison du -tls1 option) et le jeu de chiffrement par défaut. La prise de contact échouera si le serveur ne prend pas en charge TLS 1.0 ou inférieur OR si le serveur ne prend en charge aucun des chiffrements proposés par le client. En raison de la dernière partie il est possible que le serveur tombe en panne avec votre client spécifique même si TLS 1.0 est activé parce que le serveur n'aime pas les chiffres proposés par le client .
Et cela devient plus complexe. Il est courant que les serveurs prennent en charge plusieurs certificats sur la même adresse IP aujourd'hui. Cela se fait en incluant le nom d'hôte cible à l'aide de extension SNI TLS dans ClientHello au début de la prise de contact TLS. S'il n'y a pas d'extension SNI ou si l'extension ne correspond à aucun nom d'hôte configuré, le serveur envoie généralement un certificat par défaut ou abandonne la prise de contact. En raison de la dernière partie , il est possible que le serveur tombe en panne avec votre client spécifique même si TLS 1.0 est activé sur le serveur car aucune extension SNI n'a été utilisée ou a été utilisée avec le mauvais nom d'hôte . openssl s_client n'utilisera pas SNI par défaut, donc votre tentative pourrait simplement avoir échoué à cause d'une extension SNI manquante. Vous devez utiliser le -servername option pour cela et bien sûr vous devez utiliser un nom d'hôte correctement configuré sur le serveur avec cette option.
Et jusqu'à présent, nous ne nous occupions que de piles TLS saines et d'une connexion directe au serveur. Si la pile TLS est cassée ou s'il y a un boîtier de médiation cassé entre les deux (comme les équilibreurs de charge, les pare-feu, etc.), cela pourrait faire échouer la prise de contact accidentellement ou volontairement même si le serveur prend en charge TLS 1.0. Et si vous avez une terminaison SSL devant votre serveur (certains pare-feu, équilibreurs de charge ou un CDN), vous ne testerez même pas les propriétés du serveur mais du système en face de lui.
En d'autres termes: si vous obtenez une connexion TLS 1.0 réussie au serveur, vous pouvez être sûr que le serveur ou un terminateur SSL en face de lui prend en charge TLS 1.0. Si la connexion TLS 1.0 échoue à la place, cela ne signifie pas pour sûr que le serveur ne prend pas en charge TLS 1.0.
Bien que ces outils ne répondent pas directement à votre question spécifique, ils peuvent fournir les résultats que vous recherchez. Si vous disposez d'une connexion Internet, essayez-en quelques-unes:
Si aucune connexion Internet n'essaye:
Oui, ce site Web est erroné; CONNECTED signifie que la connexion TCP a réussi mais ne dit rien sur la négociation TLS (ou, espérons-le, pas SSL). Si vous n'êtes pas CONNECTÉ mais que quelques lignes se terminent par connect: errno=$n (Même si le nombre est 0!), Cela signifie que nous n'avons même pas pu tenter une poignée de main et que nous n'avons donc aucune information dans les deux cas. le serveur prend en charge.
Bien que vous puissiez apprendre à lire les messages d'erreur et autres informations publiées par openssl, l'indicateur clé est la ligne commençant New, Au début du dernier bloc de sortie (après le --- quelques lignes avant SSL-Session:); s'il montre une vraie version de protocole et chiffre la prise de contact réussie, s'il a (NONE) la prise de contact a échoué - comme le vôtre.
Notez que la prise de contact peut échouer pour des raisons autres que la version du protocole. Si ce test réussit pour 1.0, vous pouvez être sûr que le serveur prend en charge 1.0, mais si ce test échoue, cela ne prouve pas définitivement que le serveur ne fonctionne pas prend en charge 1.0. Vous devrez en fait en savoir plus sur TLS pour les distinguer. Comme Steffen l'a publié plus longuement pendant que j'écrivais ceci - mais j'ai décidé que mes paras 2 et 4 pourraient toujours aider.
FWIW note également que les tests pour SSLv2 en utilisant uniquement s_client -ssl2 Ne sont pas valides sur les versions 1.0.0 ou la liste de chiffrement par défaut empêche la connexion SSLv2 même sur les serveurs qui prennent en charge SSLv2. Cependant, quiconque s'inquiète encore aujourd'hui de SSLv2 sur un vrai serveur (pas de laboratoire de test ou de musée) est en grande difficulté.