- Les communications sur Internet reposent sur une structure où les paquets sont traités par plusieurs couches, et grâce aux protocoles en couches, les développeurs n’ont pas à gérer eux-mêmes les détails d’implémentation du transport, du routage ou de la sécurité
- Une requête HTTP suit un flux par étapes qui commence par la création du message par le navigateur, puis passe par la résolution DNS, le 3-way handshake TCP, les routeurs, et enfin la réponse du serveur
- En HTTP de base, les en-têtes et le corps circulent en clair, ce qui le rend vulnérable à l’écoute clandestine et à l’usurpation de serveur ; une couche de sécurité a été ajoutée pour combler cette limite
- HTTPS est une forme de HTTP à laquelle s’ajoutent le chiffrement et la vérification TLS ; le TLS handshake est le processus qui aligne version, cipher suite, certificat et informations d’échange de clés afin de créer une clé de session symétrique
- TLS 1.3 exclut RSA ainsi que les cipher suites et paramètres vulnérables, et réduit les choix possibles afin de constituer un handshake plus simple, plus rapide et plus sûr que les approches précédentes
Modèle en couches pour comprendre les communications Internet
- Internet est un réseau de réseaux informatiques interconnectés, et « Internet » signifie littéralement « entre les réseaux »
- Il fonctionne comme un réseau maillé à commutation de paquets, avec une structure de best-effort delivery qui ne garantit ni la livraison des paquets ni leur heure d’arrivée
- Internet semble fonctionner de manière fluide parce que des traitements comme les réessais, la garantie de l’ordre, la suppression des doublons et la sécurité sont pris en charge en arrière-plan par plusieurs couches d’abstraction
- Chaque couche fournit une fonction précise, et différents protocoles peuvent implémenter cette fonction
- Grâce à cette modularité, changer le protocole d’une couche peut ne pas affecter les protocoles des autres couches
Rôle de chaque couche réseau
- Application layer traite la logique propre à chaque application ; l’unité de communication est le message, et HTTP en est un exemple représentatif
- Security layer fournit le chiffrement et l’authentification ; l’unité de communication est le record, et TLS en est un exemple
- Transport layer est responsable de la transmission fiable des données ; elle utilise des TCP segments ou des UDP datagrams, identifiés par des numéros de port
- Network layer route les paquets à travers Internet et utilise les adresses IP comme identifiants
- Link layer gère les communications proches du support physique ; elle utilise des frames et identifie les équipements par adresse MAC
- Physical layer transmet physiquement les bits entre appareils ; la fibre optique ou l’Ethernet cable en sont des exemples
Flux d’une requête HTTP
Comment les paquets atteignent le serveur
- Lorsque le client envoie une requête, les paquets de données ne vont pas directement au serveur : ils traversent plusieurs équipements réseau et routeurs pour trouver un chemin jusqu’à la passerelle du réseau du serveur
- La Link layer prend ensuite en charge la transmission sur le segment local
-
Étapes par lesquelles le texte traverse Internet
- L’appareil client encapsule les données de la requête HTTP dans un TCP segment, puis les enveloppe dans un IP packet
- Pour une connexion filaire, elles sont encore encapsulées dans une Link layer frame, comme une Ethernet frame
- La frame est transmise via le réseau local au routeur du client
- Le routeur local reçoit la frame, retire le Link layer header, puis traite l’IP packet
- Le routeur examine l’adresse IP de destination et décide du prochain hop
- Le paquet est transmis vers le réseau suivant en passant par un ou plusieurs routeurs intermédiaires, chacun répétant le processus de détermination du prochain hop et de transmission
- Le paquet finit par atteindre un routeur situé sur le même réseau que le serveur de destination
- Ce routeur prend la décision de routage finale et envoie le paquet à l’appareil local correspondant au serveur
- Le routeur du serveur transmet le paquet au serveur via le segment de réseau local
- La Link layer veille à ce que la frame soit correctement livrée à l’interface réseau du serveur
- Le serveur reçoit la frame, extrait l’IP packet, puis traite le TCP segment encapsulé afin de reconstruire la requête HTTP d’origine
- Le processus de la Network layer qui envoie les paquets à travers Internet est également utilisé dans les étapes précédentes, comme la résolution du nom de domaine ou le TCP handshake
Réponse du serveur et rendu par le navigateur
- Le serveur traite la requête HTTP, puis renvoie une réponse HTTP au client
- La réponse comprend la version HTTP utilisée, un code d’état comme
200 ou 404, les en-têtes de réponse et un corps comme le HTML de la page demandée ou des données JSON
HTTP/1.1 200 OK
Date: Sat, 26 May 2023 10:00:00 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Type: text/html
Content-Length: 3456
Example Page
Hello, world!
- Le client reçoit et traite la réponse HTTP
- Le navigateur interprète le HTML et affiche le contenu à l’écran
- Si la réponse contient des ressources supplémentaires comme des images, du CSS ou du JavaScript, le navigateur envoie d’autres requêtes HTTP en suivant le même processus
Problèmes de sécurité de HTTP et HTTPS
- HTTP de base n’offre aucune sécurité
- Toute personne à l’écoute de la connexion peut voir 100 % des données échangées
- Si quelqu’un se fait passer pour le serveur, le client peut envoyer des informations sensibles au mauvais destinataire
- HTTPS est une forme de HTTP à laquelle s’ajoutent le chiffrement et la vérification
- Il existe plusieurs façons de sécuriser les communications HTTP, mais l’implémentation généralement utilisée aujourd’hui est TLS
- TLS permet au client et au serveur de vérifier leur identité mutuelle et de chiffrer le payload de manière à ce que les deux parties puissent le déchiffrer
- Le flux d’une requête HTTPS est identique au flux HTTP présenté plus haut, mais une Security layer est ajoutée entre l’Application layer et la Transport layer
- Le TLS handshake utilise généralement TCP
Ce que négocie le TLS handshake
- Le TLS handshake est le processus par lequel le client et le serveur s’accordent sur plusieurs éléments à utiliser pour communiquer
- Les éléments négociés incluent un ensemble d’algorithmes utilisés pour la vérification des messages, la compression et le chiffrement
- Cet ensemble d’algorithmes est appelé cipher suite
- À strictement parler, la cipher suite exclut l’algorithme de compression, mais dans cet article, l’ensemble complet est appelé cipher suite
- Voici quelques composants possibles
- Compression algorithm : méthode de compression des données sur le wire ; Gzip et Brotli en sont des exemples, et Brotli est principalement utilisé aujourd’hui
- Key exchange algorithm : méthode permettant d’échanger en toute sécurité des clés de chiffrement sur un canal public ; ECDHE-RSA et ECDHE-ECDSA en sont des exemples, et ECDHE est principalement utilisé aujourd’hui
- Authentication algorithm : méthode d’authentification de l’identité des parties pendant le handshake ; RSA et ECDSA en sont des exemples, RSA est largement utilisé et ECDSA gagne également en popularité
- Symmetric encryption algorithm : méthode de chiffrement des données entre le client et le serveur ; AES-128-GCM et AES-256-GCM en sont des exemples, et AES-GCM offre une sécurité forte avec une bonne efficacité
- MAC algorithm : méthode garantissant l’intégrité et l’authenticité des messages ; HMAC-SHA256 et HMAC-SHA384 en sont des exemples, et HMAC-SHA256 ainsi que le mode GCM des cipher suites modernes sont utilisés
- Le client et le serveur s’accordent sur une cipher suite, puis échangent des seeds aléatoires et les informations du SSL certificate afin de créer une clé symétrique utilisée pour chiffrer et vérifier les messages
- La source des informations sur le TLS handshake est Cloudflare
Étapes du TLS handshake classique
-
Client Hello
- Le client envoie au serveur un message TCP contenant les cipher suites prises en charge, la TLS version prise en charge et un nombre aléatoire appelé Client Random
-
Server Hello
- Le serveur répond avec un message TCP contenant la TLS version choisie, les algorithmes de la cipher suite sélectionnée et le Server Random
-
Certificate Verification
- Le client vérifie le SSL certificate du serveur via une Certificate Authority et récupère la public key du serveur
-
Premaster Secret Generation
- Le client crée un premaster secret, le chiffre avec la public key du serveur et l’envoie au serveur
-
Decryption
- Le serveur utilise sa private key pour déchiffrer le premaster secret
-
Session Key Creation
- Le client et le serveur utilisent le Client Random, le Server Random et le premaster secret pour créer une session key
-
Client Ready
- Le client envoie un message
finished chiffré avec la session key
-
Server Ready
- Le serveur envoie un message
finished chiffré avec la session key
-
Secure HTTP Communication
- Les deux parties communiquent ensuite avec un chiffrement symétrique sécurisé utilisant la session key
Ce qui change avec TLS 1.3
- Le TLS handshake décrit plus haut correspond aux anciennes versions de TLS et est obsolète au regard de TLS 1.3, la version récente
- TLS 1.3 et les versions ultérieures ne prennent pas en charge RSA ni plusieurs cipher suites pour des raisons de sécurité
- La version récente réduit fortement les choix possibles, ce qui la rend plus simple, plus sûre et plus rapide
- Les concepts clés restent valables dans TLS 1.3
- Le handshake sert à s’accorder sur la méthode de compression, l’authentification du serveur et l’échange de clés
- Il génère une clé de chiffrement symétrique afin de protéger les données des paquets échangés via TCP
- TLS 1.3 ne prend pas en charge les cipher suites et paramètres vulnérables aux attaques, et raccourcit le handshake pour le rendre plus rapide et plus sûr
-
Étapes de base du handshake TLS 1.3
- Client hello : le client envoie la version du protocole, le Client Random et la liste des cipher suites
- Dans TLS 1.3, la prise en charge des cipher suites non sûres a été supprimée, ce qui réduit fortement le nombre de cipher suites possibles
- Le Client hello contient aussi les paramètres qui serviront à calculer le premaster secret
- Le client suppose connaître la key exchange method préférée du serveur, ce qui est plus probable grâce à la liste réduite de cipher suites
- Cette structure réduit la longueur totale par rapport aux handshakes TLS 1.0, 1.1 et 1.2
- Server generates master secret : le serveur a reçu le Client Random, les paramètres du client et la cipher suite, et peut générer lui-même le Server Random afin de créer le master secret
- Server hello and
Finished : le Server hello contient le certificate du serveur, la digital signature, le Server Random et la cipher suite choisie
- Comme le serveur possède déjà le master secret, il envoie aussi le message
Finished
- Final steps and client
Finished : le client vérifie la signature et le certificate, génère le master secret, puis envoie le message Finished
- Secure symmetric encryption achieved : un chiffrement symétrique sécurisé est ensuite établi
1 commentaires
Commentaires sur Hacker News
En tant que non-spécialiste, je me demande pourquoi il est si difficile de savoir à quel niveau la panne s’est produite quand on n’arrive pas à accéder à un site web précis ou à Internet en général
Il est souvent difficile de déterminer s’il s’agit d’une erreur de configuration réseau sur ma machine locale, d’un problème de connexion Wi‑Fi jusqu’au routeur, d’un problème de câble entre le routeur et le FAI, d’une panne majeure chez le FAI, ou d’une panne du site web que j’essaie de joindre
J’ai entendu l’explication vague selon laquelle les requêtes sont routées par des chemins non déterministes, mais elle ne me convainc pas vraiment. Je me demande pourquoi, si un lien casse quelque part sur le trajet, le dernier lien encore fonctionnel ne pourrait pas renvoyer un message du type « ton message est arrivé jusque-là, mais l’envoi vers l’étape suivante a échoué »
Les configurations varient énormément, on ne sait pas quelle configuration était réellement voulue, et il est risqué de partir d’hypothèses basées sur les causes fréquentes si cela conduit à une réponse totalement erronée
Par exemple, si le serveur DNS ne répond pas et que l’hôte cible ne répond pas non plus, on pourrait conclure à une erreur de configuration du routeur ou à une panne du FAI, alors que la vraie cause peut être un client VPN qui a modifié la table de routage locale et les serveurs DNS puis n’a pas restauré ces changements à la fermeture. Le problème est de savoir comment un outil de diagnostic pourrait distinguer un changement temporaire d’une configuration permanente
L’application ne voit pas les messages ICMP si le socket n’est pas configuré explicitement pour cela. Ce type d’erreur est considéré comme « temporaire » et, sous Linux, cela se règle avec l’option de socket
IP_RECVERRQuand on travaille à la couche 7, il n’y a pas beaucoup d’intérêt à collecter les erreurs de cette couche. Les erreurs Destination Unreachable qui remontent déjà s’intégreront à la logique de gestion d’échec que vous aurez de toute façon, et dans ce cas les autres couches réessaieront face à une destination injoignable, ce qui finira probablement par se manifester comme un time-out
Pour comprendre comment la couche TCP traite les erreurs ICMP, ces RFC sont utiles : https://www.rfc-editor.org/rfc/rfc1122#page-103
La section 4.2.3.9 indique que les messages Unreachable sont des soft errors, donc TCP ne doit pas interrompre la connexion, mais doit fournir l’information à l’application. TCP peut soit la remonter à la couche applicative via la routine ERROR_REPORT, soit enregistrer le message et ne le signaler à l’application que lorsque la connexion TCP finit par expirer
Il existe aussi un document qui traite plus en détail de l’interaction entre les piles dans le cadre de l’étude d’ICMP comme vecteur d’attaque contre TCP : https://www.rfc-editor.org/rfc/rfc5927
Si le serveur DNS lui-même est injoignable, alors il s’agit d’une erreur réseau quelque part entre l’utilisateur et ce serveur. En pratique, on diagnostique souvent en déroulant les étapes à la main : vérifier si le serveur DNS répond au ping, s’il peut résoudre l’hôte demandé, et ce que donnent d’autres serveurs DNS. Il peut aussi y avoir des noms exclus à cause de politiques d’entreprise
Si vous voulez aller plus loin, des outils en ligne de commande comme
ping,tracerouteetdigsont utilesMTR ressemble à un mélange de ping et de traceroute qui tourne en continu en temps réel, avec chaque saut affiché séparément
Quand je remarquais pour la première fois qu’un nœud était tombé sur le réseau Xfinity, c’était cohérent parce que le même MTR me montrait au moins que tout allait bien depuis mon réseau jusqu’au modem. Je connais peu d’outils qui montrent aussi bien qu’MTR une hausse de latence de plusieurs centaines de ms sur un saut situé au-delà du FAI
Cela ne résout pas tous les problèmes, mais comme il fournit la latence saut par saut, cela vaut la peine de vérifier
Pour dire « le problème est ici », il faut faire des hypothèses sur la manière dont le système d’exploitation, le matériel et le réseau sont configurés
Quand on accède à un site web, il faut d’abord obtenir via DNS l’adresse IP du serveur web, mais rien que la façon dont le navigateur obtient l’IP du DNS est déjà complexe. On peut la configurer dans le navigateur, le système d’exploitation, le routeur ou le modem, et si elle n’est pas définie, elle peut venir du serveur DHCP auquel le routeur est connecté. Cela peut être le serveur DHCP du FAI, ou celui d’un autre routeur interne à l’organisation
Si DNS semble en cause, il est facile de voir que l’IP est erronée, mais difficile de dire d’où elle vient. Avec SSL aussi, le certificat du serveur peut être incorrect, ou bien ce peut être le certificat sur mon propre ordinateur qui est erroné
C’est peut-être lié, mais il existe aussi des exemples interactifs détaillés octet par octet pour TLSv1.2 et TLSv1.3
Ce sont des ressources que j’aime beaucoup et que je recommande vivement si vous voulez mieux comprendre TLS
[0]: https://tls12.xargs.org/
[1]: https://tls13.xargs.org/
Je me demande s’il existe d’autres articles écrits sous cet angle. J’aime bien les textes qui expliquent les choses « comme à un ingénieur moyen », quel que soit le niveau d’expérience.
C’est généralement très utile, car on peut y apprendre à nouveau des morceaux qui n’étaient pas totalement clairs, ou y trouver d’autres exemples à réutiliser pour expliquer à quelqu’un d’autre.
Exemples :
https://www.cloudflare.com/learning/dns/what-is-dns/
https://www.cloudflare.com/learning/ssl/transport-layer-secu...
https://www.cloudflare.com/learning/performance/what-is-http...
L’explication selon laquelle « le client génère un premaster secret, le chiffre avec la clé publique du serveur, puis l’envoie au serveur » n’est déjà plus vraie depuis longtemps.
Il est ajouté que le processus qui vient d’être décrit correspond aux premières versions de TLS, aujourd’hui anciennes, si on le compare au TLS 1.3 moderne.
Dire que « les versions actuelles de TLS (>1.3) ne prennent pas en charge RSA ni plusieurs suites cryptographiques pour des raisons de sécurité » est correct pour la partie échange de clés. C’est parce que RSA n’offre pas la forward secrecy.
RSA reste utilisé pour les signatures, et c’est probablement encore le type le plus répandu dans les certificats x509.
Il me semble aussi que Safari a relevé il n’y a pas longtemps l’exigence à 2048 bits pour les clés des signatures RSA.
Cet article se lit comme si une vraie explication de HTTPS avait été résumée par une IA. Les termes apparaissent sans contexte.
Il ne dit pas ce qu’est un certificat ni comment fonctionne la chaîne de confiance, et suppose que le lecteur connaît déjà la cryptographie à clé publique. Il décrit 6 des 7 couches de l’OSI sans jamais employer ce terme, et en omettant la couche de présentation.
Bon, cela dit, le titre dit bien mediocre.
L’écriture n’est pas mon point fort, donc je reçois volontiers la critique. Le fait que mon texte soit passé de « mauvais » à « c’est écrit par une IA ? » reste un progrès.
Je me suis demandé où arrêter l’explication, et la cryptographie à clé publique me semblait une bonne frontière, car elle peut être mieux expliquée ailleurs. Même chose pour plusieurs couches de l’OSI.
En revanche, je reconnais que j’aurais dû couvrir les certificats et peut-être toute la chaîne de confiance.
Je n’arrive pas à trouver de code montrant la vérification de signature de
SHA256(client_hello_random + server_hello_random + curve_info + public_key).Je connais la théorie, mais dès que j’essaie de l’implémenter, quelque chose coince. Un lien vers un petit programme jouet montrant concrètement comment faire serait utile.
J’espère vraiment qu’il n’est pas écrit des choses du genre « la clé privée se trouve dans le certificat SSL du serveur ». Bon, cela dit, le titre dit bien “Mediocre Engineer”.
Même TLS <1.3 ne fonctionne pas comme l’article le décrit, et pourtant il essaie d’y mêler des éléments plus récents de la 1.3. La partie DNS décrit un résolveur récursif, alors qu’un client ne procède généralement pas ainsi ; il parlera plutôt à un résolveur stub.
Les erreurs s’enchaînent : « Internet Layer », l’idée implicite que brotli serait un algorithme largement utilisé pour la compression TLS ou dans les suites cryptographiques, ou encore « les versions actuelles de TLS (>1.3) ne prennent pas en charge RSA ».
À cause de ce genre de spam de blog, j’aimerais parfois qu’il y ait un bouton downvote. Ce n’est pas assez gênant pour être signalé comme publicité, mais le niveau est faible. Je devrais peut-être écrire un article moins mediocre et essayer de le faire arriver en première page de HN. Si je gagnais 300 k$ de salaire, j’aurais peut-être plus de temps.
Le contenu de l’article est dans l’ensemble un peu daté. De nos jours, 30 % des requêtes web passent par HTTP/3, et il y a aussi CORS, mais aucune date de publication n’est indiquée.
Moi, je développe surtout des systèmes SaaS déployés dans des réseaux d’entreprise internes, et les requêtes CORS sont proches de 0 %. Même chose pour HTTP/3.