Différence entre SSL et TLS

Selon wikipedia: http://en.wikipedia.org/wiki/Transport_Layer_Security

On dirait que TLS remplace SSL, mais la plupart des sites Web utilisent toujours SSL?

En bref, TLSv1.0 est plus ou moins SSLv3.1. Vous pouvez trouver plus de détails dans cette question sur ServerFault .

La plupart des sites Web prennent en charge au moins SSLv3 et TLSv1.0, comme l' indique cette étude (article de Lee, Malkin et Nahum: Cryptographic Strength of SSL / TLS Servers: Current and Recent Practices , IMC 2007) (lien obtenu à partir de la liste IETF TLS ). Plus de 98% prennent en charge TLSv1 +.

Je pense que la raison pour laquelle SSLv3 est toujours utilisé était pour le support hérité (bien que la plupart des navigateurs prennent en charge TLSv1 et certains TLSv1.1 ou même TLSv1.2 de nos jours). Jusqu'à il n'y a pas si longtemps, certaines distributions avaient toujours SSLv2 (considéré comme non sécurisé) activé par défaut avec les autres.

(Vous pouvez également trouver cette question intéressante, bien qu'elle concerne le modèle d'utilisation de TLS plutôt que SSL vs TLS (vous pourriez en fait avoir le même modèle avec SSL). Cela ne s'applique pas à HTTPS de toute façon, car HTTPS utilise SSL / TLS depuis le début de la connexion.)

De http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/

Au début des années 90, à l'aube du World Wide Web, certains ingénieurs de Netscape ont développé un protocole pour effectuer des requêtes HTTP sécurisées, et ce qu'ils ont proposé s'appelait SSL. Étant donné le corpus de connaissances relativement limité sur les protocoles sécurisés à l'époque, ainsi que la pression intense sous laquelle tout le monde chez Netscape travaillait, leurs efforts ne peuvent être considérés que comme incroyablement héroïques. C'est incroyable que SSL ait duré aussi longtemps qu'il l'a fait, contrairement à un certain nombre d'autres protocoles du même millésime. Nous avons certainement beaucoup appris depuis lors, mais le problème avec les protocoles et les API, c'est qu'il y a très peu de retours en arrière.

Il y a eu deux mises à jour majeures du protocole SSL, SSL 2 (1995) et SSL 3 (1996). Celles-ci ont été soigneusement conçues pour être rétrocompatibles, pour faciliter l'adoption. Cependant, la rétrocompatibilité est une contrainte pour un protocole de sécurité pour lequel elle peut signifier une vulnérabilité vers l'arrière.

Ainsi, il a été décidé de rompre la compatibilité descendante, et le nouveau protocole nommé TLS 1.0 (1999). (Avec le recul, il aurait peut-être été plus clair de l'appeler TLS 4)

Les différences entre ce protocole et SSL 3.0 ne sont pas dramatiques, mais elles sont suffisamment importantes pour que TLS 1.0 et SSL 3.0 n'interagissent pas.

TLS a été révisé deux fois, TLS 1.1 (2006) et TLS 1.2 (2008).

À partir de 2015, toutes les versions SSL sont cassées et non sécurisées (l'attaque POODLE) et les navigateurs suppriment le support. TLS 1.0 est omniprésent, mais seulement 60% des sites prennent en charge TLS 1.1 et 1.2 , un triste état de choses.

Si vous êtes intéressé par ce genre de choses, je recommande la discussion intelligente et amusante de Moxie Marlinspike à https://www.youtube.com/watch?v=Z7Wl2FW2TcA

tls1.0 signifie sslv3.1

tls1.1 signifie sslv3.2

tls1.2 signifie sslv3.3

le rfc vient de changer le nom, vous pouvez trouver le code hexadécimal de tls1.0 est 0x0301, ce qui signifie sslv3.1

TLS maintient la compatibilité descendante avec SSL et, par conséquent, le protocole de communication est presque identique dans l'une des versions mentionnées ici. Les deux différences importantes entre SSL v.3, TLS 1.0 et TLS 1.2 sont la fonction pseudo-aléatoire (PRF) et la fonction de hachage HMAC (SHA, MD5, handshake), qui est utilisée pour construire un bloc de clés symétriques pour Cryptage des données d'application (clés serveur + clés client + IV). La principale différence entre TLS 1.1 et TLS 1.2 est que la version 1.2 nécessite l'utilisation de IV "explicite" pour se protéger contre les attaques CBC, bien qu'il n'y ait pas de changements au PRF ou au protocole nécessaires pour cela. TLS 1.2 PRF est spécifique à la suite de chiffrement, ce qui signifie que le PRF peut être négocié pendant l'établissement de liaison. SSL a été développé à l'origine par Netscape Communications (historique), puis maintenu par Internet Engineering Task Force (IETF, actuel). TLS est géré par le groupe de travail du réseau. Voici la différence entre les fonctions PRF HMAC dans TLS:

TLS 1.0 et 1.1

PRF (secret, étiquette, graine) = P_MD5 (S1, étiquette + graine) XOR P_SHA-1 (S2, étiquette + graine);

TLS 1.2

PRF (secret, étiquette, graine) = P_hash (secret, étiquette + graine)

"Si ce n'est pas cassé, ne le touchez pas". SSL3 fonctionne correctement dans la plupart des scénarios (il y avait une faille fondamentale trouvée dans le protocole SSL / TLS en octobre, mais c'est une faille des applications plus que celle d'un procol lui-même), donc les développeurs ne se pressent pas de mettre à niveau leurs modules SSL. TLS apporte un certain nombre d'extensions et d'algorithmes de sécurité utiles, mais ils sont un ajout pratique et non indispensable. Donc TLS sur la plupart des serveurs reste une option. Si le serveur et le client le prennent en charge, il sera utilisé.

Mise à jour: dans '2016, SSL 3, et même TLS jusqu'à 1.2, s'avèrent vulnérables à diverses attaques et la migration vers TLS 1.2 est recommandée. Il existe également des attaques contre les implémentations de TLS 1.2, bien qu'elles soient dépendantes du serveur. TLS 1.3 est actuellement en développement. Et maintenant TLS 1.2 est un must.

https://hpbn.co/transport-layer-security-tls/ est une bonne introduction

Le protocole SSL a été développé à l'origine chez Netscape pour activer la sécurité des transactions de commerce électronique sur le Web, ce qui nécessitait un cryptage pour protéger les données personnelles des clients, ainsi que des garanties d'authentification et d'intégrité pour assurer une transaction sûre. Pour ce faire, le protocole SSL a été implémenté au niveau de la couche application, directement au-dessus de TCP (Figure 4-1), permettant aux protocoles au-dessus (HTTP, e-mail, messagerie instantanée et bien d'autres) de fonctionner inchangé tout en assurant la sécurité des communications lorsque communiquer sur le réseau.

Lorsque SSL est utilisé correctement, un observateur tiers ne peut déduire que les points de terminaison de connexion, le type de cryptage, ainsi que la fréquence et une quantité approximative de données envoyées, mais ne peut ni lire ni modifier aucune des données réelles.

SSL 2.0 a été la première version publique du protocole, mais il a été rapidement remplacé par SSL 3.0 en raison d'un certain nombre de failles de sécurité découvertes. Comme le protocole SSL était la propriété de Netscape, l'IETF s'est efforcé de normaliser le protocole, ce qui a abouti à la RFC 2246, publiée en janvier 1999 et connue sous le nom de TLS 1.0. Depuis lors, l'IETF a continué à itérer sur le protocole pour corriger les failles de sécurité, ainsi que pour étendre ses capacités: TLS 1.1 (RFC 2246) a été publié en avril 2006, TLS 1.2 (RFC 5246) en août 2008, et le travail est maintenant en cours pour définir TLS 1.3.