Le terme approprié est TLS ou Transport Layer Security, qui est le protocole de sécurisation des échanges réseaux qui succède à SSL (Secure Sockets Layer), et est utilisé notamment dans HTTPS (HTTP over TLS) ; mais SSL reste utilisé comme terme parapluie pour désigner toute connexion TCP sécurisée (par SSL ou TLS). Je me concentrerai sur HTTPS dans cet article, mais SSL est utilisé également pour les mails (SMTP, POP3 et IMAP), les annuaires (LDAP), les messageries instantanées (XMPP), les bases de données, etc.

Une connexion sécurisée apporte trois garanties : confidentialité, authenticité et intégrité.

  • Confidentialité : la connexion est chiffrée, dissimulant les URLs, les cookies et toutes les données et métadonnées sensibles. Les seules informations publiques sont l’adresse IP, le port, et le nom de domaine du site Web.
  • Authenticité : le visiteur communique avec le “vrai” site Web, pas avec un imposteur ou à travers un “homme du milieu” (“man-in-the-middle”, MitM)
  • Intégrité : les données envoyées entre le visiteur et le site Web n’ont pas été falsifiées ou modifiées.

La confidentialité est garante du respect de la vie privée. L’authenticité et l’intégrité sont gages de sécurité.

# Comment ça marche ?

Revenons rapidement aux débuts de la cryptologie moderne, lors de la Seconde Guerre Mondiale, avec les premières machines de chiffrement (Enigma, machine de Lorenz), Bletchley Park et Alan Turing : les personnes devaient se rencontrer en personne pour échanger leurs clés de chiffrement (pour faire simple, les paramètres des algorithmes de chiffrements). Si une clé était violée, elles devaient se rencontrer à nouveau, mais vous ne pouviez jamais savoir si votre clé avait été violée. Avec une telle lourdeur opérationnelle, seuls les États-Nations pouvaient se permettre de chiffrer ainsi leurs communications.

Plus tard, PGP (et son implémentation GPG) introduit la notion de “toile de confiance” (“web of trust”) : les personnes peuvent signer (cryptographiquement) leurs clés les uns les autres (de préférence lors d’une rencontre physique) et peuvent ainsi donner leur confiance à des inconnus si elles font confiance aux intermédiaires dans la toile (si Alice a confiance en Bernard, et Bernard a confiance en Carole, alors Alice peut vraisemblablement faire confiance à Carole). Opérationnellement moins lourd que les échanges en main propre, mais bien trop difficile à utiliser, PGP est réservé aux experts (et même les experts s’y perdent, Snowden ne fait pas exception).

Plus récemment, des applications comme Signal utilisent une approche Trust on First Use (TOFU) : on part du principe que la première fois qu’on communique avec une personne (et donc qu’on échange les clés de chiffrement), on n’est pas victime d’une attaque (encore une fois, mieux vaut une rencontre en personne). Si les clés changent, les utilisateurs en sont avertis ; et les clés peuvent s’échanger hors de l’application (les utilisateurs sont alors maître de leur sécurité lors de cet échange). Toute personne avisée peut ainsi chiffrer ses communications !

Mais ça ne fonctionne pas pour HTTPS : HTTPS doit être totalement transparent pour les utilisateurs lambda, les erreurs et avertissements doivent être aussi exceptionnels que possible, on ne peut pas mises sur un Trust on First Use pour chaque site Web (le risque est trop grand) : les noms de domaines changent de main, les clés changent, etc. On veut que tout un chacun puisse chiffrer ses communications sans effort.

C’est ainsi qu’il existe quelques organisations (les autorités de certifications) autorisées à délivrer des certificats, et éventuellement déléguer la délivrance de certificats à des autorités intermédiaires, créant ainsi des chaînes de confiances. Les systèmes d’exploitations et/ou les navigateurs font confiance à un certain nombre de certificats racines ; si un site Web utilise un certificat signé par une autorité de confiance, alors la communication est jugée sécurisée. Les autorités de certification doivent vérifier que le propriétaire des clés de chiffrement contrôle le site Web, mais techniquement elles peuvent délivrer n’importe quel certificat à n’importe qui. Les clés de chiffrement peuvent ainsi changer librement, à partir du moment où elles sont signées par une autorité de certification de confiance. C’est ce qu’on appelle l’infrastructure à clés publiques (PKI), et ça permet réellement à tout le monde de chiffrer ses communications.

En d’autres termes, la PKI, ce sont des sociétés (éditeurs de navigateurs et/ou systèmes d’exploitations) qui font confiance à d’autres sociétés et gouvernements (les autorités de certifications) à votre place.

# SSL n’est pas sans problème

  • Les autorités de certifications sont généralement à but commercial et vendent les certificats.
  • Techniquement, elles peuvent délivrer n’importe quel certificat à n’importe qui ; et on a vu en 2013 une autorité de certification (DigiNotar) délivrer un certificat pour *.google.com, et votre navigateur lui aurait fait confiance ! (le certificat a été utilisé pour surveiller et hacker les comptes GMail de citoyens Iraniens)
  • Les autorités de certifications sont les pierres angulaires du système, et donc des cibles de choix pour les cyber-attaques.
  • Qui décide qui peut devenir autorité de certification racine ? Qui définit les règles ?
  • Les grosses autorités de certifications peuvent être jugées “too big to fail”, avec le risque de ne pas être punies pour un mauvais comportement(comme certaines institutions financières lors de la crise des subprimes en 2007–2008).

…mais c’est aussi la seule méthode de chiffrement déployée à grande échelle qui semble fonctionner.

Heureusement, des solutions existent ou se mettent en place pour contrecarrer ces problèmes.

Plusieurs autorités de certifications commencent à délivrer des certificats gratuitement, et l’une d’entre elles (Let’s Encrypt) a mis au point un protocole de délivrance totalement automatisé (après acceptation des conditions d’utilisation). Let’s Encrypt délivre donc des certificats à durée de validité très courte (90 jours aujourd’hui, mais ils envisagent de la réduire dans le futur), à n’importe qui en fait la demande, à partir du moment où il peut prouver qu’il possède/contrôle le nom de domaine. En installant une extension sur un serveur HTTP, celui-ci peut ainsi totalement automatiser les demandes (initiale et de renouvellement) des certificats pour les noms de domaine qu’ils sert, sans aucune intervention manuelle de l’administrateur. Ce protocole de délivrance (Automated Certificate Management Environment, ACME) étant ouvert et standardisé à l’IETF, nulle doute que d’autres autorités de certifications suivront (pas nécessairement gratuitement, mais elles devront alors se distinguer par des services complémentaires ; finalement un peu comme dans la téléphonie et les accès à Internet avec les offres low-cost).

La Certificate Transparency, une initiative de Google (suite à l’incident DigiNotar) en cours de standardisation IETF, vise à éviter les mauvaises délivrances de certificats (comme ça a été le cas pour google.com, cf. ci-dessus) en mettant en place un registre public de toutes les délivrances à des fins de monitoring et d’audit. Google a d’ores et déjà annoncé qu’à partir d’octobre 2017, Chrome n’aura plus confiance qu’en les certificats (délivrés après cette date) conformes à la Certificate Transparency ; c’est en fait déjà le cas depuis 2015 pour les certificats EV (pour afficher le cartouche vert dans la barre d’adresse du navigateur, mais la connexion n’est pour le moment pas refusée en absence de Certificate Transparency), et depuis juin 2016 pour les certificats de Symantec (avec refus de connexion cette fois).

Du côté des administrateurs de sites Web, un entête HTTP (Strict-Transport-Security) permet d’indiquer aux navigateurs que le site doit être visité exclusivement en HTTPS (pendant une durée définie) : si vous essayez d’aller sur ce blog avec son adresse http://, votre navigateur devrait récrire l’URL en https:// sans même faire de requête non sécurisée. Un autre entête (Public-Key-Pins) permet de se prémunir des attaques par DNS Rebinding et des certificats frauduleux, en indiquant des empreintes de certificats de confiance : si une visite ultérieure au site Web utilise un certificat qui n’est pas dans cette liste blanche, le navigateur refusera la connexion. Cet entête est vraiment réservé aux sites critiques (tels que des paiements en ligne, des données de santé, etc.) car il est facile de se tirer un balle dans le pied et totalement bloquer l’accès à son site. Dans le même ordre d’idée, mais moins contraignant, une entrée DNS (Certificate Authority Authorization, CAA) pour le nom de domaine peut lister la ou les autorités de certifications autorisées à émettre des certificats pour ce domaine ; un navigateur sera ainsi en mesure de détecter un certificat frauduleux (mais pas une attaque par DNS Rebinding).

Le CA/Browser Forum, consortium regroupant des éditeurs et les autorités de certifications, définit des règles que tous doivent suivre. Récemment, le Forum a ainsi décidé de réduire la durée maximale des certificats de 39 mois à 825 jours (environ 27 mois), et d’obliger à partir de septembre 2017 la vérification des entrées DNS CAA. Google, Apple et Mozilla ont également révoqué leur confiance en WoSign et StartCom en ce début d’année, parce que ces autorités de certification n’avaient pas respecté les exigences établies par le CA/Browser Forum. Google est également en bras de fer avec Symantec (et ses marques Verisign, Thawte, et GeoTrust) suite à de nombreuses erreurs et fautes (la liste maintenu par Mozilla est longue), mais jugé “too big to fail” par beaucoup, l’avenir le dira…

Enfin, au niveau technique, avant l’établissement de la connexion, un navigateur doit faire une requête DNS, qui la plupart du temps n’est pas sécurisée non plus (DNSSEC, déjà très peu utilisé, ne garantit que l’intégrité des réponses, mais pas la confidentialité des échanges). Il existe un standard DNS over TLS mais il est relativement récent donc pas encore largement déployé. Affaire à suivre…

# SSL n’est plus une option

HTTPS n’était prévu au départ que pour les mots de passe et les cartes bancaires ; mais à l’heure où la donnée se monnaie, tout devrait désormais être chiffré. Sans chiffrement, n’importe qui sur le même réseau que vous peut suivre votre navigation. On l’a vu dès 2010 avec FireSheep, qui récupère les cookies utilisés pour maintenir les sessions utilisateurs, et vous permet de vous connecter aux sites tels Facebook ou GMail en leur nom, en utilisant leur session. Mais sans chiffrement, votre navigation peut aussi être manipulée ! Ça peut être anodin, tel que rickroller les utilisateurs de Spotify sur Android en remplaçant les premières secondes des morceaux streamés. Mais certains fournisseurs d’accès (notamment sur les points d’accès Wi-Fi publics dans les gares, les restaurants, les avions) injectent des messages dans les sites Web que vous visitez (pour vous informer que votre forfait data est bientôt épuisé, ou vous indiquer la durée restante de votre vol) ; et en 2015 le gouvernement Chinois a conduit une attaque par déni de service distribuée (DDoS) sur GitHub (entre autres) par le biais de son Grand Canon, en injectant des instructions dans les scripts d’analyse de fréquentation de Baidu (équivalent de Google Analytics en Chine) pour que les navigateurs des internautes (c’est à dire, vous) fassent des appels répétés à GitHub à votre insu. Et il n’y aucune raison pour que quiconque (les fournisseurs d’accès notamment, principalement de hotspots) n’injecte pas non plus de la publicité, ou détourne la publicité des sites vers leurs propres agences publicitaires (privant ainsi les sites Web d’une partie de leur revenus). Quand il ne s’agit pas d’injecter des scripts malveillants voire des malware.

Très récemment, les États-Unis ont autorisé les fournisseurs d’accès à monnayer votre historique de navigation (et je ne parle pas du Snoopers’ Charter du Royaume Uni et des Data Retention laws d’Australie). Sans chiffrement, ils savent tout ; sinon ils connaissent uniquement les sites que vous avez contacté, mais pas ce que vous y avez regardé et/ou écrit.

(WebMD, utilisé dans cet exemple, est plus ou moins un équivalent américain de Doctissimo ; on notera d’ailleurs que Doctissimo n’utilise pas HTTPS non plus)

D’un point de vue bien plus pragmatique, toutes les nouvelles possibilités des navigateurs, qui reposent sur la confiance que l’utilisateur a dans le site qu’il visite (notifications, ajout à l’écran d’accueil, mode déconnecté, etc.), ou qui pourrait être mises à mal par des intermédiaires (HTTP/2 qui permet de bien meilleures performances, algorithme de compression Brotli), ne sont activées que sur les sites sécurisés. L’API de géolocalisation a même été changée pour n’être plus disponible que sur les pages sécurisées dans Chrome depuis avril 2016 et dans Safari depuis septembre 2016, pour des raisons évidentes de respect de la vie privée ; Firefox suivra à partir d’août 2017 (aucun signe du côté de Microsoft par contre).

# SSL n’est pas la panacée

Pour autant, SSL ne vous protège pas de tout : la seule chose sécurisée est la connexion avec le site. Ce site peut être malveillant et servir des malwares ou faire du phishing. Le conseil généralement donné dans les medias de vérifier si “le site affiche un cadenas” ou “commence par https://” est donc loin d’être suffisant. Le site peut aussi avoir des failles de sécurité et permettre des attaques en tout genre (XSS, CSRF, SQLi, etc.) Rien ne garantit non plus que vous ne parlez pas simplement à un proxy, qui relaierait les requêtes vers un site non sécurisé (Cloudflare est souvent décrié pour proposer ce genre de services, gratuitement qui plus est) ; ou que la machine ne soit pas correctement configurée et sécurisée (les récents ransomware sur les bases de données MongoDB et ElasticSearch notamment en sont un exemple ; sans parler des autres fuites de données en tous genre, comme les comptes d’Ashley Madison ou de Yahoo! à l’été 2016) ; ou que les mots de passe ne soient pas traités et stockés de façon sécurisée ; ou tout simplement que le mot de passe de l’administrateur soit facile à deviner (et donc le site facile à vandaliser, voire pire). Tout reste une affaire de confiance.

# Conclusion

En conclusion, il n’y a plus aucune raison de ne pas utiliser SSL sur son site Web, et toutes les raisons de le faire au plus vite. Cerise sur le gâteau, avec Let’s Encrypt, ça ne coûte rien. Et comme toutes les configurations SSL ne se valent pas, veillez à avoir une bonne note sur l’outil d’audit SSL Labs (test à renouveler régulièrement !)

Chez Atol, les démos et prototypes hébergés sur un sous-domaine d’atolcd.com sont en HTTPS par défaut ; et nous invitons nos clients à utiliser HTTPS également. Agrilocal, Atrium et Ozwillo ne sont par exemple accessible qu’en HTTPS. Nous avons également, pour aller plus loin, commencé des travaux pour sécuriser les connexions au sein même de notre réseau privé.

À noter : cet article est largement inspiré d’une présentation d’Eric Mill, avec son aimable autorisation.

Tweetez
Partagez
Partagez41
0 Partages