Implications fonctionnelles des différences entre SSL et TLS

Je sais que TLS est essentiellement une version plus récente de SSL et qu'il prend généralement en charge la transition d'une connexion non sécurisée à sécurisée (généralement via une commande STARTTLS).

Ce que je ne comprends pas, c'est pourquoi TLS est important pour un professionnel de l'informatique et pourquoi, étant donné le choix, je choisirais l'un plutôt que l'autre. TLS est-il vraiment juste une version plus récente, et si c'est le cas, est-ce un protocole compatible?

En tant que professionnel de l'informatique: quand dois-je utiliser lequel? Quand est-ce que je n'utilise pas lequel?

Réponse courte:

SSL est le précurseur de TLS. SSL était un protocole propriétaire développé par Netscape Communications, normalisé plus tard au sein de l'IETF et renommé TLS. En bref, les versions vont dans cet ordre: SSLv2, SSLv3, TLSv1.0, TLSv1.1 et TLSv1.2.

Contrairement à une croyance relativement répandue, il ne s'agit pas du tout d'exécuter un service sur un port distinct avec SSL et de pouvoir le faire sur le même port que la variante en texte brut avec TLS. SSL et TLS peuvent être utilisés pour les deux approches. Il s'agit de la différence entre SSL / TLS lors de la connexion (parfois appelé "SSL / TLS implicite") et SSL / TLS après qu'une commande a été émise au niveau du protocole, généralement STARTTLS(parfois appelé "SSL / TLS explicite") . Le mot clé STARTTLSest "START", pas TLS. C'est un message, au niveau du protocole d'application, pour indiquer qu'il doit y avoir un basculement vers SSL / TLS, s'il n'a pas été initié avant tout échange de protocole d'application.

L'utilisation de l'un ou l'autre des modes doit être équivalente, à condition que le client soit configuré pour attendre SSL / TLS d'une manière ou d'une autre, afin de ne pas être rétrogradé vers une connexion en texte brut.

Réponse plus longue:

SSL vs TLS

Pour autant que je sache, SSLv1 n'a jamais quitté les laboratoires. SSLv2 et SSLv3 étaient des protocoles développés par Netscape. SSLv2 est considéré comme non sécurisé depuis un certain temps, car il est susceptible de déclasser les attaques. SSLv3 utilise en interne (3,0)comme numéro de version (dans le ClientHellomessage).

TLS est le résultat de la standardisation en tant que protocole plus ouvert au sein de l'IETF. (Je pense avoir lu quelque part, peut-être dans le livre de E. Rescorla, que le nom avait été choisi de telle manière que tous les participants étaient également mécontents de celui-ci, afin de ne pas favoriser une entreprise particulière: c'est une pratique assez courante dans les normes ). Les personnes intéressées par la façon dont la transition a été effectuée peuvent lire la FAQ SSL-Talk List ; il existe plusieurs exemplaires de ce document, mais la plupart des liens (vers ) sont obsolètes.netscape.com

TLS utilise des messages très similaires (suffisamment différents pour rendre les protocoles incompatibles, bien qu'il soit possible de négocier une version commune ). Les TLS 1.0 , 1.1 et 1.2 ClientHello messages utilisent (3,1), (3,2), (3,3)pour indiquer le numéro de version, ce qui montre clairement la poursuite de SSL.

Il y a plus de détails sur les différences de protocole dans cette réponse .

Quand dois-je utiliser quoi? Quand est-ce que je n'utilise pas lequel?

Utilisez la version la plus élevée possible si possible. En pratique, en tant que fournisseur de services, cela nécessitera que vos utilisateurs aient des clients qui prennent en charge ces versions. Comme d'habitude, il s'agit toujours d'un exercice d'évaluation des risques (de préférence accompagné d'une analyse de rentabilisation, le cas échéant). Cela étant dit, coupez tout de même SSLv2.

De plus, notez que la sécurité fournie par SSL / TLS ne concerne pas seulement la version que vous utilisez, mais aussi la configuration appropriée: il est certainement préférable d'utiliser SSLv3 avec une suite de chiffrement forte que TLSv1.0 avec une avec une faible (ou suite de chiffrement anonyme / à chiffrement nul). Certaines suites de chiffrement, jugées trop faibles, ont été explicitement interdites par les nouvelles versions de TLS. Les tableaux du fournisseur Java 7 SunJSSE (et leurs notes de bas de page) peuvent être intéressants si vous souhaitez plus de détails.

Il serait préférable d'utiliser TLS 1.1 au moins, mais tous les clients ne les prennent pas encore en charge malheureusement (par exemple Java 6). Lorsque vous utilisez une version sous 1.1, cela vaut certainement la peine de chercher à atténuer la vulnérabilité BEAST .

Je recommanderais généralement le livre d'Eric Rescorla - SSL and TLS: Designing and Building Secure Systems, Addison-Wesley, 2001 ISBN 0-201-61598-3 aux personnes qui veulent vraiment plus de détails.

SSL / TLS implicite et explicite

Il y a un mythe qui dit que TLS vous permet d'utiliser le même port alors que SSL ne le peut pas. Ce n'est tout simplement pas vrai (et je laisserai l' unification des ports pour cette discussion). Malheureusement, ce mythe semble avoir été propagé aux utilisateurs par le fait que certaines applications comme MS Outlook offrent parfois un choix entre SSL et TLS dans leurs options de configuration alors qu'elles signifient en fait un choix entre SSL / TLS implicite et explicite. (Il existe des experts SSL / TLS chez Microsoft, mais il semble qu'ils n'étaient pas impliqués dans l'interface utilisateur d'Outlook.)

Je pense que la raison pour laquelle cette confusion se produit est à cause du STARTTLSmode. Certaines personnes semblent avoir compris cela comme STARTTLS= TLS, mais ce n'est pas le cas. Le mot clé STARTTLSest "START", pas TLS. Pourquoi cela n'a pas été appelé STARTSSLou STARTSSLORTLSparce que ces extensions ont été spécifiées dans l'IETF, qui n'utilisait que des noms utilisés dans ses spécifications (en supposant que le nom TLS serait finalement le seul permanent, je suppose).

• SSL sur le même port que le service de texte brut: proxy HTTPS.

De nos jours, la plupart des serveurs HTTPS peuvent gérer TLS, mais il y a quelques années, la plupart des gens utilisaient SSLv3 pour HTTPS. HTTPS (à proprement parler, normalisé en HTTP sur TLS ) établit normalement la connexion SSL / TLS lors de la connexion TCP, puis échange le message HTTP sur la couche SSL / TLS. Il existe une exception à cela lors de l'utilisation d'un proxy HTTP entre les deux. Dans ce cas, le client se connecte au proxy HTTP en clair (généralement sur le port 3128), puis émet la CONNECTcommande HTTP et, à condition que la réponse réussisse, lance la négociation SSL / TLS en envoyant unClientHellomessage. Tout cela se passe sur le même port en ce qui concerne la connexion entre navigateur et proxy (évidemment pas entre proxy et serveur cible: ce n'est même pas la même machine). Cela fonctionne très bien avec SSLv3. Beaucoup d'entre nous dans des situations derrière un proxy l'auront utilisé contre des serveurs qui ne supportaient pas au moins TLS 1.0.

• SSL sur le même port que le service de texte brut: e-mail.

Celui-ci est clairement hors spécifications, mais en pratique, il fonctionne souvent. À proprement parler, les spécifications parlent de passer à TLS (pas SSL) après avoir utilisé la commande STARTTLS. En pratique, SSL fonctionne souvent aussi (tout comme la spécification "HTTP sur TLS" comprend également l'utilisation de SSL au lieu de TLS). Vous pouvez l'essayer par vous-même. En supposant que vous disposez d'un serveur SMTP ou IMAP qui prend en charge STARTTLS, utilisez Thunderbird, accédez aux préférences, aux options avancées, à l'éditeur de configuration et désactivez-le security.enable_tls. De nombreux serveurs accepteront toujours la connexion, simplement parce que leurs implémentations délèguent la couche SSL / TLS à une bibliothèque SSL / TLS qui sera généralement en mesure de gérer SSL et TLS de la même manière, sauf si configuré pour ne pas le faire. Comme le dit la FAQ OpenLDAP , "Bien que le mécanisme soit conçu pour être utilisé avec TLSv1, la plupart des implémentations se replieront sur SSLv3 (et SSLv2) si nécessaire. ". Si vous n'êtes pas sûr, vérifiez avec un outil comme Wireshark.

• TLS sur un port distinct.

De nombreux clients peuvent utiliser TLS 1.0 (au moins) pour les protocoles où la variante sécurisée se trouve sur un port différent. De toute évidence, il existe un certain nombre de navigateurs et de serveurs Web qui prennent en charge TLS 1.0 (ou supérieur) pour HTTPS. De même, SMTPS, IMAPS, POPS et LDAPS peuvent également utiliser TLS. Ils ne sont pas limités à SSL.

Quand dois-je utiliser quoi? Quand est-ce que je n'utilise pas lequel?

Entre SSL / TLS explicite et implicite, cela n'a pas vraiment d'importance. Ce qui importe, c'est que votre client sache à quoi s'attendre et qu'il soit configuré de manière appropriée pour le faire. Plus important encore, il doit être configuré pour rejeter les connexions en texte brut lorsqu'il attend une connexion SSL / TLS, qu'elle soit implicite ou explicite .

La principale différence entre SSL / TLS explicite et implicite réside dans la clarté des paramètres de configuration.

Par exemple, pour LDAP, si le client est un serveur Apache Httpd ( mod_ldap- sa documentation indique également la différence entre SSL et TLS, malheureusement), vous pouvez utiliser SSL / TLS implicite en utilisant une ldaps://URL (par exemple AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one) ou utiliser SSL / explicite TLS en utilisant un paramètre supplémentaire (par exemple AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one TLS).

Il est peut - être en général un risque légèrement moindre lors de la spécification du protocole de sécurité dans le système d'URL ( https, ldaps, ...) que lorsque le client attend de configurer un paramètre supplémentaire pour activer le protocole SSL / TLS, car ils peuvent oublier. C'est discutable. Il peut également y avoir des problèmes dans l'exactitude de l'implémentation de l'un par rapport à l'autre (par exemple, je pense que le client Java LDAP ne prend pas en charge la vérification du nom d'hôte lors de l'utilisation ldaps://, quand il le devrait, alors qu'il est pris en charge avec ldap://+ StartTLS).

Dans le doute, et pour être compatible avec plus de clients si possible, il ne semble pas faire de mal d'offrir les deux services lorsque le serveur le prend en charge (votre serveur écoutera simplement sur deux ports en même temps). De nombreuses implémentations de serveur pour les protocoles pouvant être utilisés avec les deux modes prendront en charge les deux.

Il est de la responsabilité du client de ne pas se laisser rétrograder vers une connexion en texte brut. En tant qu'administrateur de serveur, vous ne pouvez techniquement rien faire de votre côté pour empêcher les attaques de rétrogradation (à part peut-être exiger un certificat client). Le client doit vérifier que SSL / TLS est activé, que ce soit lors de la connexion ou après une STARTTLScommande de type. De la même manière qu'un navigateur ne doit pas se laisser rediriger de https://vers http://, un client pour un protocole qui prend en charge STARTTLS doit s'assurer que la réponse est positive et que la connexion SSL / TLS est activée avant de continuer. Un attaquant MITM actif pourrait sinon facilement rétrograder l'une ou l'autre des connexions.

Par exemple, les anciennes versions de Thunderbird avaient une mauvaise option pour cela appelée "Utiliser TLS, si disponible" , ce qui impliquait essentiellement que si un attaquant MITM était capable de modifier les messages du serveur afin qu'il n'annonce pas la prise en charge de STARTTLS, le client se laisserait silencieusement rétrograder vers une connexion en texte brut. (Cette option non sécurisée n'est plus disponible dans Thunderbird.)

TLS est un protocole plus récent que SSL (mais AFAIK, il est compatible avec SSL v3). Habituellement, vous ne devez vous soucier que d'une seule différence:

Un protocole SSL a généralement un port séparé - par exemple, 80 pour HTTP et 443 pour HTTPS (HTTP / SSL). Lorsque vous vous connectez au port SSL, la session entière est cryptée.

TLS est plus récent que SSL, et il ne nécessite pas de port séparé - à la place, il doit être négocié par le client. Par exemple, vous pouvez exécuter IMAP sur le port 143, et si le serveur de messagerie et le client prennent en charge TLS, le client enverra une STARTTLScommande et activera le cryptage uniquement. De cette façon, vous n'avez pas besoin d'un port SSL uniquement séparé, tout en restant compatible avec les applications sans SSL.

Résumé:
SSL : légèrement plus ancien. Ports séparés pour les connexions simples et cryptées. Tout le trafic sur le port SSL est toujours crypté.
TLS : port unique pour les connexions simples et cryptées. Le cryptage n'est activé qu'après que le client a émis une STARTTLScommande.

TLS est simplement une version plus récente de SSL. Utilisez TLS lorsque vous en avez la possibilité. Plus, comme d'habitude, sur Wikipédia .

De cet article de la base de connaissances de l'Université de l'Indiana :

SSL signifie Secure Sockets Layer. Netscape a initialement développé ce protocole pour transmettre des informations en privé, garantir l'intégrité des messages et garantir l'identité du serveur. SSL fonctionne principalement en utilisant le chiffrement par clé publique / privée sur les données. Il est couramment utilisé sur les navigateurs Web, mais SSL peut également être utilisé avec des serveurs de messagerie ou tout type de transaction client-serveur. Par exemple, certains serveurs de messagerie instantanée utilisent SSL pour protéger les conversations.

TLS signifie Transport Layer Security. L'Internet Engineering Task Force (IETF) a créé TLS en tant que successeur de SSL. Il est le plus souvent utilisé comme paramètre dans les programmes de messagerie, mais, comme SSL, TLS peut jouer un rôle dans toute transaction client-serveur.

Les différences entre les deux protocoles sont très mineures et très techniques, mais ce sont des normes différentes. TLS utilise des algorithmes de cryptage plus puissants et a la capacité de travailler sur différents ports. De plus, TLS version 1.0 n'interagit pas avec SSL version 3.0.

TLS est une version plus récente de SSL. Bien que dans certains endroits, ces mots puissent signifier autre chose que des protocoles, veuillez clarifier votre question.