Le « S » dans HTTPS ne signifie pas SSL
Il est naturel de supposer que lorsque nous voyons une icône de cadenas dans nos navigateurs, cela signifie que le site utilise SSL pour sécuriser nos communications. Il s’agit apparemment également d’un signal envoyé aux consommateurs indiquant que le site est, en fait, sécurisé . À tel point que, selon l’enquête de confiance des consommateurs de 2015 du Conseil de sécurité de Californie, « seuls trois pour cent d’entre eux seraient prêts à communiquer leurs informations de carte de crédit à des sites sans l’icône de cadenas ».
L’impact ne se limite pas aux consommateurs. Les personnes interrogées dans le cadre de notre dernière enquête sur l'état de la distribution des application qui avaient déjà mis en œuvre ou prévoyaient de mettre en œuvre « SSL Everywhere » avaient une plus grande confiance (3 ou plus sur une échelle de 1 à 5) dans la capacité de leur organisation à résister à une attaque au niveau de la couche application .
La vérité est que la plupart des gens ne peuvent pas vous dire ce que signifie SSL, et encore moins décrire comment cela fonctionne. Ce qu'ils savent cependant, c'est qu'il s'agit d'un mécanisme permettant de garantir la sécurité des transactions (et donc des informations confidentielles) lors de l'interaction avec une application ou un site Web.
C'est en partie notre faute (comme celle du marché). Nous avons utilisé SSL comme description du protocole ( RFC 6101 ) ainsi que comme moyen générique de décrire une connexion sécurisée. SSL est le pansement de la sécurité, le Google des moteurs de recherche, le Kleenex des mouchoirs.
La réalité est que HTTPS ne nécessite pas réellement SSL. Le « S » dans « HTTPS » signifie sécurisé et nécessite simplement une méthode de sécurisation des connexions entre deux points de terminaison, comme un navigateur et un site Web. En augmentant, cela signifie en fait HTTP sur TLS, pas SSL.
C’est une différence importante car même s’ils partagent des racines, TLS n’est pas SSL n’est pas TLS. Il s’agit de protocoles différents, chacun comportant ses propres défis, problèmes et impacts. Les deux sécurisent les connexions de la même manière (elles utilisent des certificats pour l’authentification et des paires de clés publiques/privées pour le chiffrement), mais les différences d’implémentation demeurent.
Pourquoi devriez-vous vous en soucier ? Vous devriez vous en soucier car les derniers protocoles application Web (et peut-être les meilleurs, cela reste à voir) (HTTP/2 et SPDY) ne prennent pas en charge SSL. Ils prennent en charge TLS. Ils ne l’exigent pas en soi, mais les implémentations de navigateur prenant en charge les deux n’offrent une prise en charge que via TLS. Pas SSL.
Certes, aujourd’hui, il n’y a pas un nombre significatif de sites utilisant HTTP/2 ou SPDY, mais ce chiffre est en croissance. Considérez que 7,5 % des 1 000 premiers sites proposent désormais du contenu via HTTP/2 :
Extrait de W3CTech (juillet 2015) :
La nouvelle norme HTTP/2 , dont la version finale a été publiée en mai 2015, est désormais utilisée par 0,4% de tous les sites Web (contre 0,24% au début du mois), et par 7,5% des 1 000 premiers sites .
Maintenant, considérez que nous ne parlons pas seulement de navigateurs et de serveurs. Nous devons également considérer ce que cela signifie pour l’intégration – pour l’utilisation d’API provenant de certains de ces 1000 premiers sites (comme Google) qui peuvent forcer l’utilisation non seulement de HTTP/2 ou de SPDY, mais également de TLS. Tous les services publics de Google proposant un cryptage utilisent TLS. Si vous intégrez certaines fonctionnalités de Google, vous pourriez être intéressé par le fait qu’ils utilisent TLS au lieu de SSL. Parce que ça fait la différence sous le capot.
Il faut également noter qu’il existe des répercussions commerciales. Conformément à la norme PCI, SSL ne peut plus être utilisé après le 30 juin 2016. Après ce point, TLS est explicitement requis. Cela implique quelques changements pour rester en conformité avec la norme PCI. Et bien sûr, vous devez le faire, car si vous n'êtes pas en conformité, les conséquences sont nombreuses. Cela pourrait, par exemple, entraîner des frais de compte marchand plus élevés et des amendes de la part des émetteurs de cartes de crédit, voire la révocation pure et simple de votre capacité à traiter les paiements et les transactions. En cas de violation, votre entreprise s'exposera à un risque plus élevé de poursuites judiciaires et d'amendes en raison de votre manquement à faire preuve de diligence raisonnable en matière de sécurité.
Enfin, il existe cette RFC ( RFC 7568 ) très fortement formulée qui explique pourquoi vous devriez vraiment passer à TLS :
3. N'utilisez pas la version 3.0 de SSL
Il n’est pas réaliste de supposer que vous allez manquer de ressources et passer de SSL à TLS immédiatement. Après tout, bien que TLS soit basé sur SSL v3, il n'est pas 100% rétrocompatible avec son prédécesseur et il faut quelques modifications de configuration pour désactiver SSL et forcer l'utilisation de TLS. Modifications de configuration qui nécessitent généralement un redémarrage. Dans un environnement de grande envergure, ce processus est, bien entendu, perturbateur et prend du temps.
Mais il est temps de commencer à réfléchir sérieusement à la durée pendant laquelle vous souhaitez prendre en charge SSL et au moment où vous souhaitez passer à TLS pur.