Selon Wikipédia : http://en.wikipedia.org/wiki/Transport_Layer_Security
Il semble que le TLS remplace le SSL, mais la plupart des sites web utilisent encore le SSL ?
Selon Wikipédia : http://en.wikipedia.org/wiki/Transport_Layer_Security
Il semble que le TLS remplace le SSL, mais la plupart des sites web utilisent encore le 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 à la fois SSLv3 et TLSv1.0 au moins, comme le montre cette étude (article de Lee, Malkin et Nahum : Force cryptographique des serveurs SSL/TLS : pratiques actuelles et récentes, 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 encore utilisé est pour le support hérité (bien que la plupart des navigateurs prennent en charge TLSv1 et certains TLSv1.1 voire même TLSv1.2 de nos jours). Jusqu'à il n'y a pas si longtemps, certaines distributions avaient encore SSLv2 (considéré comme insecure) activé par défaut avec les autres.
(Vous pourriez également trouver cette question intéressante, même s'il s'agit du modèle d'utilisation de TLS plutôt que de SSL vs. TLS (en fait, vous pourriez avoir le même modèle avec SSL). Cela ne s'applique de toute façon pas à HTTPS, puisque HTTPS utilise SSL/TLS dès 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, quelques ingénieurs de Netscape ont développé un protocole pour effectuer des requêtes HTTP sécurisées, et ce qu'ils ont créé s'appelait SSL. Étant donné le corps de connaissances relativement peu nombreux sur les protocoles sécurisés à l'époque, ainsi que la pression intense sous laquelle travaillait tout le monde chez Netscape, leurs efforts ne peuvent être vus que comme incroyablement héroïques. Il est étonnant que SSL ait perduré aussi longtemps qu'il l'a fait, contrairement à un certain nombre d'autres protocoles de la même époque. Nous avons certainement beaucoup appris depuis, mais la chose à retenir à propos des protocoles et des API est qu'il n'y a pratiquement pas de retour 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 réalisées pour être rétrocompatibles, afin de faciliter l'adoption. Cependant, la rétrocompatibilité est une contrainte pour un protocole de sécurité pour lequel cela peut signifier une rétrovulnérabilité.
Il a donc été décidé de rompre la rétrocompatibilité, et le nouveau protocole a été nommé TLS 1.0 (1999). (Avec le recul, il aurait peut-être été plus clair de le nommer TLS 4)
Les différences entre ce protocole et SSL 3.0 ne sont pas dramatiques, mais elles sont suffisamment significatives pour que TLS 1.0 et SSL 3.0 ne soient pas compatibles entre eux.
Le TLS a été révisé deux fois, TLS 1.1 (2006) et TLS 1.2 (2008).
En 2015, toutes les versions du SSL sont obsolètes et non sécurisées (attaque POODLE) et les navigateurs suppriment leur support. TLS 1.0 est omniprésent, mais seulement 60% des sites prennent en charge TLS 1.1 et 1.2, une situation déplorable.
Si cela vous intéresse, je recommande la conférence astucieuse et amusante de Moxie Marlinspike à https://www.youtube.com/watch?v=Z7Wl2FW2TcA
TLS maintient la compatibilité descendante avec SSL et donc le protocole de communication est presque identique dans chacune 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, poignée de main), qui est utilisée pour construire un bloc de clés symétriques pour le chiffrement des données d'application (clés serveur + clés client + IV). La différence majeure entre TLS 1.1 et TLS 1.2 est que 1.2 exige l'utilisation d'un IV "explicite" pour se protéger contre les attaques CBC, bien qu'aucun changement de PRF ou de protocole ne soit nécessaire pour cela. Le PRF de TLS 1.2 est spécifique au cipher-suite, ce qui signifie que le PRF peut être négocié pendant la poignée de main. SSL a été initialement développé par Netscape Communications (historique) et ensuite maintenu par Internet Engineering Task Force (IETF, actuel). TLS est maintenu par le groupe de travail sur les réseaux. Voici les différences entre les fonctions HMAC PRF dans TLS :
TLS 1.0 et 1.1
PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed);
TLS 1.2
PRF(secret, label, seed) = P_hash(secret, label + seed)
"Si ce n'est pas cassé, ne le touchez pas". SSL3 fonctionne bien dans la plupart des scénarios (une faille fondamentale a été découverte dans le protocole SSL/TLS en octobre, mais il s'agit plus d'une faille des applications que du protocole lui-même), donc les développeurs ne se précipitent pas pour mettre à jour leurs modules SSL. TLS apporte un certain nombre d'extensions utiles et d'algorithmes de sécurité, mais ce sont des ajouts pratiques et non pas une obligation. Ainsi, TLS reste une option sur la plupart des serveurs. S'ils sont supportés à la fois par le serveur et le client, TLS sera utilisé.
Mise à jour : en 2016, SSL 3 et même TLS jusqu'à 1.2 se sont révélés vulnérables à diverses attaques et la migration vers TLS 1.2 est recommandée. Des attaques existent également sur les implémentations de TLS 1.2, bien qu'elles dépendent du serveur. TLS 1.3 est actuellement en développement. Et maintenant, TLS 1.2 est une nécessité.
Non, il s'agit d'une faille de protocole, et les développeurs devraient mettre à jour leurs piles SSL. Cela étant dit, il existe des directives pour l'utilisation de l'extension de renégociation dans RFC 5746 pour SSLv3, en plus de celles pour TLS.
Si vous tuez quelqu'un avec le couteau, ce n'est pas la faute du couteau, mais celle de votre cerveau. Même chose ici. Si le protocole était utilisé d'une manière pour laquelle il n'était pas conçu, ce n'est pas une faille du protocole.
Le protocole a été conçu de telle manière que l'application qui l'utilise le considère autant que possible comme un socket normal. Le problème de renégociation, sans la nouvelle extension, oblige la couche d'application (par exemple HTTP) à être consciente. Il y a un fil de discussion intéressant sur ce sujet sur la liste de diffusion TLS de l'IETF : ietf.org/mail-archive/web/tls/current/msg04000.html
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
4 votes
"La plupart des sites web utilisent encore SSL". Voici une bonne enquête sur le support des protocoles trustworthyinternet.org/ssl-pulse/#chart-protocol-support
0 votes
Question plus populaire similaire: security.stackexchange.com/questions/5126/…