Cet article d’introduction explique le rôle et le fonctionnement global de HTTPS, les articles spécifiques se focalisent plus en profondeur sur un point précis.

1. De SSL à TLS 1.3
2. Le certificat PKIX (parution à venir)
3. Les suites cryptographiques (parution à venir)
4. À double tour (parution à venir)

En raison de la diversité des hébergeurs, serveurs, autorités de certification et besoins de compatibilité avec des clients web plus ou moins anciens, ces articles ne sont toutefois que des guides et non des tutoriels pour configurer un logiciel particulier.

Bien au-delà du cadenas

Pour le grand public HTTPS est souvent associé à la présence rassurante du petit cadenas verrouillé à proximité de la barre d’URL et malheureusement également à quelques clics rapides sur des boutons OK lorsqu’une alerte relative à un problème de certificat surgit.

Le S qui signifie sécurisé dans HTTPS provient de TLS —Transport Layer Security— qui est un protocole supplémentaire et indépendant qui se positionne entre TCP et HTTP qui demeurent pratiquement inchangés.
La sécurisation de la connexion répond à trois besoins principaux : authentifier le serveur, garantir la confidentialité et l’intégrité des données échangées.
Cela ne concerne donc que les données en transit et n’améliore que marginalement la sécurisation du serveur lui-même, mais rendre bien plus difficile la récupération de cookies ou d’identifiants de connexion peut éviter quelques mauvaises surprises.

L’annonce de Google de signaler, dès le début 2017, comme non sécurisée toute page web qui propose un formulaire de saisie de mot de passe ou de carte bancaire hors HTTPS devrait encore accélérer le mouvement de migration de HTTP vers HTTPS, de nombreux sites ayant déjà fait le saut suite aux révélations d’Edward Snowden en 2013.
Par ailleurs HTTP/2 (ou h2), la nouvelle version de HTTP, nécessite en pratique la présence de TLS. Pour mettre en place HTTP/2 et bénéficier de ses accélérations une étape préliminaire est donc de passer intégralement en HTTPS.
Il y a toujours plus de raisons techniques d’utiliser HTTPS, comme accéder à l’API de géolocalisation avec les navigateurs modernes, mais la première raison devrait être le respect de l’utilisateur et de ses données.

Premier contact

Voici comment se déroule typiquement l’établissement d’une connexion HTTPS lors d’une première visite d’un site.
Le client a tout d’abord besoin de déterminer l’adresse IP associée au nom de domaine du site web, si cette information n’est pas disponible dans une mémoire cache locale (suite à une requête antérieure) une demande de résolution est émise vers un serveur DNS.

Malheureusement les données locales du client pourraient avoir été altérées, le résolveur DNS pourrait avoir été empoisonné par des informations erronées ou tout simplement mentir et, pour finir, un élément actif du réseau pourrait intercepter la demande et retourner une réponse falsifiée… Cela tromperait le client et l’orienterait en direction d’un serveur probablement malveillant, d’où la nécessité pour un serveur HTTPS légitime de pouvoir s’authentifier en prouvant qu’il a été préalablement reconnu par un tiers de confiance comme étant bien celui attendu.

Une fois en possession de l’IP du serveur le client peut le contacter avec le protocole HTTP sur le port 80. Dans le cas présent le client demande simplement l’élément du site situé à sa racine, celle-ci est symbolisée par un simple caractère /.

Le serveur ne renvoie pas au client les données qu’il attendait mais lui indique avec une redirection HTTP 301 que ce qu’il cherche est désormais disponible à un autre emplacement accessible en HTTPS (techniquement parlant le protocole fait partie de l’URL, la redirection correspond donc à un déplacement de site). Le site HTTP ne sert donc plus qu’à rediriger automatiquement ses visiteurs vers la version HTTPS. Ceci constitue également une bonne pratique SEO pour éviter que les moteurs de recherche ne détectent du contenu dupliqué et donc dévalorisé.

Le client délaisse temporairement le protocole HTTP car il a en premier lieu besoin d’établir la connexion sécurisée. Pour ce faire il s’adresse au port 443, qui est communément dédié à TLS, il énumère alors tout un inventaire de ses capacités relatives à ce protocole (algorithmes de signature acceptés, courbes elliptiques connues, suites cryptographiques préférées…).

En fonction des desiderata du client le serveur va retourner un certificat contenant une clé publique qui permettront de l’authentifier, il indique également quelle suite cryptographique il a retenu pour chiffrer les données. Celle-ci va déterminer le mécanisme d’échange de la clé de chiffrement, ainsi que l’algorithme de chiffrement symétrique et la méthode de vérification d’intégrité qui seront mis en œuvre par la suite.

Une fois le client en possession du certificat il va s’assurer de sa conformité en vérifiant plusieurs points dont les principaux sont :

• la présence du nom du domaine visité parmi ceux présents sur le certificat
• la période de validité
• la signature apposée par l’AC —Autorité de Certification— qui a émis le certificat
• la possibilité de remonter la chaîne de confiance d’AC en AC jusqu’à une AC racine reconnue
• l’absence de publication sur des listes de révocation de type CRL et/ou OCSP.

Les raisons pour déclencher une alerte de sécurité relative au certificat sont donc nombreuses et parfois obscures. Le grand public ayant tendance à vouloir passer outre, les navigateurs ont commencé à modifier la présentation des alertes pour rendre l’accès au contournement moins facile, de plus certains en-têtes HTTP peuvent désormais inhiber cette possibilité.

Une fois l’échange (ou construction) de la clé de chiffrement symétrique réalisé, un canal de communication chiffré est établi, le client et le serveur ne communiqueront désormais plus qu’à travers celui-ci, rendant de ce fait leurs échanges inintelligibles au reste du monde.

Le client transmet alors une nouvelle requête HTTP GET mais en passant cette fois par le canal chiffré, le serveur lui répond désormais pleinement par cette même voie, couramment le serveur précise via un en-tête HTTP STS —Strict Transport Security— qu’il exige d’être contacté en HTTPS à l’avenir.

Il est parfaitement possible de capturer et décortiquer ces premiers échanges avec un analyseur de paquets réseau comme Wireshark, une fois la connexion chiffrée le résultat est bien sûr un peu plus opaque…

En l’absence de connexion sécurisée le contenu des échanges peut être consulté et même modifié en tout point du réseau, cependant les points d’accès WiFi gratuits sont particulièrement sensibles, car n’importe qui peut en monter un et il est très facile de les écouter.

La NSA —National Security Agency— (et très probablement d’autres agences gouvernementales tout autour de la planète) collecte massivement et sans distinction toutes sortes de données sur le net. Certains des documents divulgués par Edward Snowden ont été mis en relation avec des recherches universitaires qui laissent peu de doutes quant aux capacités dont dispose la NSA pour casser le chiffrement d’une partie du trafic Internet mal protégé, en particulier en raison de l’utilisation de clés asymétriques trop petites ou basées sur des primitives trop communes. Il est donc devenu crucial de veiller sur ces points car ce qui aujourd’hui encore n’est qu’à la portée d’agences gouvernementales pourrait devenir le business quotidien d’organisations criminelles d’ici quelques années.

2016 année de transition

Extérieurement on pourrait croire que rien n’a changé en 20 ans, en fait c’est en partie vrai, avec des certificats régulièrement renouvelés un serveur correctement configuré à la fin des années 90 aurait pu fonctionner sans problème visible jusqu’en novembre 2014… c’est-à-dire jusqu’au moment où les navigateurs ont commencé à désactiver SSLv3 en leur sein pour contrer l’attaque POODLE. En pratique depuis 2011 et plus encore suite aux révélations d’Edward Snowden en 2013 le petit monde de la crypto sur le web est en ébullition et tente de rattraper des années de retard et d’immobilisme.

2016 est clairement une année charnière, Let’s Encrypt a distribué de manière automatisée plus de 10 millions de « certificats SSL » gratuits depuis son lancement fin 2015, ce qui contribue très concrètement à l’adoption généralisée de HTTPS. Cela permet à un nombre croissant d’hébergeurs de proposer HTTPS au même coût qu’un hébergement classique et sans nécessairement avoir besoin d’une IP en propre pour chaque domaine grâce au support de l’extension TLS nommée SNI —Server Name Indication— qui est très largement répandue, ce qui tombe à pic avec la pénurie d’IPv4 qui est devenue une réalité.

Depuis le 1er janvier 2016 les autorités de certifications n’ont plus le droit d’émettre de certificats dont la signature repose sur un condensat SHA-1, SHA-256 s’est donc largement généralisé et les navigateurs vont commencer à rejeter les vieux certificats encore en SHA-1 début 2017.

Depuis le début de l’année la méthode de chiffrement RC4 (le fleuron des années 90) est progressivement retirée des navigateurs modernes et à la place Chrome, Firefox et Opera acceptent désormais ChaCha20 ; de son côté le chiffrement AES est couramment accéléré matériellement y compris sur les processeurs d’entrée de gamme chez Intel et AMD.

HTTP/2 qui impose de nombreuses restrictions quant à la configuration TLS sous-jacente est désormais activable avec Apache 2.4.17, Nginx 1.10.0 et IIS 10 sur Windows Server 2016.

Les spécifications finales de TLS 1.3 devraient être publiées d’ici quelques mois, mais il faudra de toute façons de longues années avant que cette version ne devienne prédominante (pour autant une importante part du trafic web mondial devrait en bénéficier très rapidement du fait de son adoption quasiment acquise sur les serveurs de Google et Cloudflare d’une part et dans Chrome et Firefox de l’autre). Mais on peut d’ores et déjà s’inspirer de TLS 1.3 pour mieux configurer TLS 1.2.

De plus la large diffusion d’OpenSSL 1.0.2 au sein des dernières distributions GNU/Linux et l’ancrage de LibreSSL à sa place dans certains systèmes *BSD devraient également faciliter l’obtention de configurations TLS correctes, sans parler d’OpenSSL 1.1.0 qui vient de faire ses premiers pas avec quelques nouveautés très intéressantes.

HTTPS partout, sécurité NULL(part)

HTTPS partout c’est bien, mais avec un S de qualité c’est encore mieux. Les navigateurs affichent toujours le même cadenas (parfois affublé d’un petit complément pour signaler un soucis comme du contenu mixte) mais il faut bien comprendre que les différents mécanismes en œuvre pour établir la liaison sécurisée vont produire une connexion plus ou moins robuste en fonction des capacités respectives du client et du serveur. Il est possible d’avoir une estimation de cette robustesse avec des extensions comme Calomel SSL Validation ou SSleuth pour Firefox, le premier est quelque peu plus simple d’accès avec un simple code couleur visible dans un premier temps et des indications plus détaillées disponibles au besoin, je vous conseille de l’installer car il permet d’accéder rapidement à des informations précieuses pendant la phase de configuration et plus généralement au quotidien voir du jaune ou du rouge à son niveau devrait vous alerter.

Sur cette page du site de test badssl.com on voit que le blason est bleu alors que c’est la couleur verte qui est associée aux meilleures notes, ici la note globale n’est que de 89%.

Les navigateurs peuvent éventuellement indiquer les paramètres TLS en cours d’utilisations mais ces informations ne sont pas toujours accessibles facilement et souvent incomplètes.

Google Chrome donne les informations les plus détaillées et qualifie individuellement le protocole, l’échange de clé ainsi que la méthode de chiffrement soit de robuste soit d’obsolète. Sur la même page de test on voit que Chrome considère le chiffrement AES 256 bits en mode CBC avec un HMAC SHA-1 comme étant obsolète… Il y a de quoi froncer un sourcil car AES 256 bits est considéré comme étant ce qui se fait de mieux en matière de chiffrement, mais comme souvent en sécurité le diable est dans les détails et pour Chrome ce sont le mode CBC et le HMAC SHA-1 qui posent problème. Pour autant le cadenas est tout ce qu’il y a de plus normal et en apparence tout va bien, mais il n’est pas inenvisageable que d’ici 3 ou 4 ans certains navigateurs refusent de se connecter sur un site configuré de la sorte car techniquement on peut d’ores et déjà faire mieux et à l’avenir l’usage du mode CBC pourrait être découragé.
Les phrases précédentes contiennent quelques acronymes qui ne sont pas détaillés dans cette introduction. Il y a beaucoup d’acronymes en cryptographie, ce qui ne facilite pas vraiment la compréhension du sujet lorsqu’on l’aborde en néophyte. Il y a une vingtaine d’années Netscape 4 proposait à ses utilisateurs d’activer ou non certaines suites cryptographiques (y compris une sans chiffrement, également connue sous le nom de chiffrement NULL), le grand public était alors directement exposé à de tels acronymes.

Aujourd’hui Safari ne restitue strictement aucune information concernant le protocole ou la suite cryptographique en service, on voit le cadenas et on peut consulter le certificat c’est tout. Toute la « culture » cryptographique est occultée, a posteriori on sait que la majorité des utilisateurs de Netscape et leurs descendants n’ont retenu que deux vagues notions : SSL ça crypte (sic) et plus il y a de bits mieux c’est crypté (sic), traumatisme très certainement lié à la première « crypto war » et ses restrictions à l’export hors US.
Les articles spécifiques font le tour d’une bonne partie des concepts et des acronymes liés à cette culture cryptographique bien au-delà du cadenas donc, leur parution devrait avoir lieu progressivement dans les prochains mois. En attendant si vous souhaitez commencer à creuser le sujet et décortiquer la configuration SSL/TLS d’un site déjà existant l’incontournable SSL Labs devrait se révéler très précieux.