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é STARTTLS
est "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 ClientHello
message).
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 STARTTLS
mode. Certaines personnes semblent avoir compris cela comme STARTTLS
= TLS, mais ce n'est pas le cas. Le mot clé STARTTLS
est "START", pas TLS. Pourquoi cela n'a pas été appelé STARTSSL
ou STARTSSLORTLS
parce 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 CONNECT
commande HTTP et, à condition que la réponse réussisse, lance la négociation SSL / TLS en envoyant unClientHello
message. 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 STARTTLS
commande 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.)