Qu'est-ce qui détermine exactement quelle version de SSL / TLS est utilisée lors de l'accès à un site?

Question

Si je clique sur la petite icône de verrouillage dans Chrome cela indique que le site en question utilise TLS v1. J'ai également vérifié en utilisant openssl et j'ai pu accéder au site en utilisant TLS1, SSL2 et SSL3. D'après ce que je comprends, SSL2 n'est pas sécurisé. Sur cette base, il semble que le site pourrait être visité en utilisant l'un des trois.

Qu'est-ce qui détermine la version de SSL/TLS qui sera utilisée lors de l'accès à un site sécurisé à partir d'un navigateur Web?

Tom Leek · Accepted Answer

Comme le dit @Terry, le client suggère, le serveur choisit. Il y a des détails:

Le format générique du premier message client (le ClientHello) indique la version la plus élevée prise en charge, et implicitement prétend que toutes les versions précédentes sont prises en charge - ce qui n'est pas nécessairement vrai. Par exemple, si le client prend en charge TLS 1.2, il indiquera alors "version max: 1.2". Mais le serveur peut alors choisir d'utiliser une version précédente (par exemple, TLS 1.0), que le client ne veut pas nécessairement utiliser.
Les clients modernes ont pris l'habitude d'essayer plusieurs fois. Par exemple, un client peut d'abord envoyer un ClientHello indiquant "TLS 1.2" et, si quelque chose (quoi que ce soit) échoue, il essaie à nouveau avec un ClientHello indiquant "TLS 1.0". Les clients le font car il existe des serveurs TLS non conformes et mal implémentés qui peuvent exécuter TLS 1.0 mais rejeter les messages ClientHello contenant "TLS 1.2".

Une conséquence amusante est qu'un attaquant actif pourrait forcer un client et un serveur à utiliser une version plus ancienne (par exemple TLS 1.0) même lorsqu'ils prennent tous les deux en charge une version de protocole plus récente, en fermant de force la connexion initiale. C'est ce qu'on appelle une "attaque de restauration de version". Ce n'est pas critique tant que le client et le serveur n'acceptent jamais d'utiliser une version de protocole nettement faible (et TLS 1.0 est encore raisonnablement fort). Pourtant, cela implique qu'un client et un serveur ne peuvent pas avoir la garantie qu'ils utilisent la "meilleure" version de protocole possible tant que le client met en œuvre une telle politique de "réessayer" (si le client n'a pas mis en œuvre un tel "réessayer" alors l'attaque par restauration serait empêchée, mais certains sites Web deviendraient inaccessibles).
Le message ClientHello pour SSL 2.0 a un format très distinct. Lorsqu'un client souhaite prendre en charge à la fois SSL 2.0 et une version ultérieure, il doit envoyer un ClientHello spécial qui suit le format SSL 2.0 et spécifie que "soit dit en passant, je connais également SSL 3.0 et TLS 1.0" . Ceci est décrit dans annexe E de la RFC 2246 . Les clients SSL modernes (navigateurs Web) ne font plus cela (je pense que IE 6.0 l'a toujours fait, mais pas IE 7.0).

RFC 4346 (TLS 1.1) spécifie que ces messages ClientHello au format SSLv2 seront "supprimés" à un moment donné et devraient être évités. RFC 5246 (TLS 1.2) indique plus clairement que les clients NE DEVRAIENT PAS prendre en charge SSL 2.0 et ne devraient donc avoir aucune raison d'envoyer de tels messages ClientHello. RFC 6176 maintenant interdit SSL 2.0 tout à fait.

Maintenant, un RFC n'est pas une loi: vous n'allez pas en prison parce que vous ne supportez aucun RFC particulier. Cependant, la RFC fournit toujours des conseils et illustre ainsi en quelque sorte quel sera l'état des choses dans un avenir proche (ou lointain).

En pratique:

La plupart des clients n'enverront que des messages SSLv3 + ClientHello et se connecteront avec plaisir à SSL 3.0, TLS 1.0, TLS 1.1 ou TLS 1.2, selon ce que le serveur semble prendre en charge (mais, en raison du "réessayer" "politique, un déclassement de version peut être forcé par un attaquant actif).
En fait, certains clients ne prennent pas en charge SSL 3.0 et nécessitent TLS 1.0.
De même, certains clients ne prendront pas en charge TLS 1.1 ou 1.2. Les navigateurs Web ont été mis à jour ces dernières années (à la suite de la mauvaise presse résultant de l'attaque BEAST) mais les applications sans navigateur sont rarement aussi agressivement maintenues.
De nombreux serveurs acceptent toujours un format SSLv2 ClientHello, tant que ce message ClientHello est un SSLv3 + ClientHello déguisé.
Quelques serveurs, comme le vôtre, sont toujours heureux de faire du SSL 2.0. Cela n'est pas conforme à la RFC 6176 et est mal vu (les personnes qui croient en la "classification des serveurs SSL" vous donneront un mauvais score pour cela). Cependant, ce n'est pas un problème de sécurité grave, tant que les clients ne prennent pas réellement en charge SSL 2.0. Même si un client prend en charge SSL 2.0, il doit inclure certaines astuces de prévention de restauration (décrites dans la RFC 2246), de sorte qu'une restauration vers SSL 2.0 ne devrait pas fonctionner.

Vous souhaitez toujours désactiver la prise en charge de SSL 2.0 sur votre serveur (pas nécessairement le format SSLv2 ClientHello, mais la prise en charge réelle de SSL 2.0), ne serait-ce que pour les relations publiques.

user10211 · Answer

Vous devriez lire sur le processus de prise de contact TLS.

Pour résumer brièvement, le client (qui dans ce cas est le navigateur) envoie un message ClientHello au serveur. Il contient la version TLS maximale qu'il prend en charge ainsi qu'une liste des suites de chiffrement qu'il prend en charge par ordre de préférence. Le serveur décide ensuite de la version TLS et de la suite de chiffrement qu'il souhaite utiliser pour la connexion TLS et informe le client en répondant avec un ServerHello. Idéalement, la version TLS la plus élevée et la suite de chiffrement la plus puissante doivent être sélectionnées, mais la spécification TLS ne le garantit pas. Le serveur est libre d'utiliser ce qu'il veut de la liste fournie par le client.

Paul West Jauregui · Answer

Lorsqu'un client souhaite envoyer des données à un serveur à l'aide de SSL/TLS, un client doit d'abord passer par une poignée de main pour s'authentifier auprès du serveur. Cette prise de contact commence par le "ClientHello", où le client envoie au serveur une version de SSL ou TLS qu'il prend en charge, les chiffrements pris en charge et d'autres données de session. Dans les anciennes versions de SSL (version 2), il était possible d'intercepter ce paquet d'établissement de liaison et de modifier la liste de chiffrement prise en charge pour ne contenir que des chiffrements faibles. Cela n'est plus possible car SSLv3 utilise un hachage dans la dernière partie de la poignée de main, où le client et le serveur hachent et comparent les messages envoyés et reçus.

Tous les navigateurs modernes prennent en charge SSLv3 jusqu'à TLSv1.2, mais utiliseront la version la plus élevée prise en charge par un serveur. Un intermédiaire ne peut pas modifier directement les paquets envoyés lors de la prise de contact, mais un intermédiaire peut intercepter et supprimer certains paquets. En incitant le navigateur à penser que le serveur ne prend pas en charge une version donnée de SSL/TLS, un attaquant peut rétrograder la version négociée. Vous pouvez voir comment cela se fait en visitant Praetorian's post récent: Man-in-the-Middle TLS Protocol Downgrade Attack

Pourquoi s'éloigner de SSLv3 maintenant?

Bien que SSLv3 comprenait des atténuations spéciales pour empêcher les attaques de rétrogradation de protocole, ce n'est pas nécessairement le protocole idéal à utiliser. SSLv3 présente des différences cryptographiques importantes, ce qui pourrait entraîner des faiblesses qui démontreraient davantage pourquoi TLSv1.2 devrait être la norme actuelle. Les chiffrements de chiffrement et d'authentification convenus, ainsi que les mécanismes d'échange de clés différaient considérablement dans nos tests de déclassement de protocole. Dans l'exemple ci-dessus, TLSv1.2 utilise la cryptographie à courbe elliptique (ECC) avec le mode compteur pour AES, tandis que SSLv3 utilise l'ancien chiffrement RC4 et RSA.

Certains peuvent se demander pourquoi cela est nécessaire. Dans son discours sur Black Hat en 2013, Alex Stamos a discuté de l'état actuel et futur de la cryptographie. Il a fait valoir que l'un des dangers réside dans la possibilité de briser des chiffres plus anciens ou des mécanismes d'échange clés à un moment donné dans le futur. Dans le cas de RSA, les cryptographes et les mathématiciens ont fait des progrès significatifs dans le problème de la factorisation. Diffie-Hellman (DH) s'appuie sur le problème du logarithme discret pour la sécurité cryptographique, et bien qu'aucun algorithme efficace utilisé pour calculer les journaux discrets n'existe, la durée d'exécution des algorithmes de logarithme discret a considérablement diminué au cours de l'année écoulée. Comme Stamos l'a expliqué, une fois que RSA ou DH échoue, la signature de code est interrompue et les attaques sur SSL/TLS deviendront très courantes.

En résumé, une attaque active sur une connexion peut entraîner une baisse de la sécurité cryptographique. Les clients et les serveurs peuvent empêcher cela de se produire en ne prenant en charge que les nouvelles versions de TLS. De plus, les clients doivent répondre correctement aux poignées de main ratées. Actuellement, de nombreux navigateurs optent pour l'interopérabilité plutôt que pour la sécurité, ce qui rend possible les attaques de rétrogradation de protocole. Ces changements demanderont beaucoup de temps et d'efforts. Les navigateurs devraient réimplémenter des aspects de la façon dont ils gèrent les poignées de main. La rétrocompatibilité peut se briser dans certains cas. Cependant, nous devrons éventuellement exiger l'utilisation de versions plus récentes de TLS qui prennent en charge ECC. Pourquoi ne pas pousser maintenant et empêcher de futures attaques?