Cours : Les principaux protocoles applicatifs
L'authentification HTTP
Hier, vous avez vu les codes de réponse 401 (utilisateur non authentifié) et 403 (accès refusé). Ces codes renvoient à un mécanisme fondamental du web moderne : l'authentification applicative, c'est-à-dire la façon dont on prouve notre identité à un serveur via HTTP.
Deux méthodes sont très courantes sur le Web : Basic Auth et Bearer Token / JWT. Voyons comment elles fonctionnent.
Basic Auth
Le Basic Auth est la méthode d'authentification la plus simple qui existe en HTTP. Le principe est straightforward : on envoie nos identifiants (nom d'utilisateur + mot de passe) à chaque requête, dans un en-tête appelé Authorization.
Comment ça marche ?
Quand le serveur détecte qu'une ressource est protégée (il renvoie un 401 Unauthorized), le client doit renvoyer les identifiants encodés ainsi :
Où <credentials> est la chaîne username:password encodée en Base64.
Par exemple, avec l'utilisateur mari et le mot de passe secret42:
La chaîne brute est :
mari:secret42Encodée en Base64, ça donne :
bWFyaTpzZWNyZXQ0Mg==Donc l'en-tête devient :
Authorization: Basic bWFyaTpzZWNyZXQ0Mg==
Un exemple de Basic Auth
Avec curl, on peut tester le Basic Auth comme ceci :
curl se charge automatiquement de créer l'en-tête Authorization: Basic ... pour vous.
Dans un navigateur, quand vous accédez à une URL protégée par Basic Auth, c'est le navigateur qui affiche la pop-up classique "Identification requise". Vous entrez vos identifiants, et c'est le navigateur qui gère l'en-tête automatiquement.
À retenir sur le Basic Auth
C'est simple à mettre en œuvre, mais fragile sans HTTPS
Les identifiants sont envoyés à chaque requête (pas de session comme on pourrait penser)
Très utilisé dans les APIs simples, les outils en ligne de commande, et certains services internes
Bearer Token / JWT
Le Basic Auth a un gros défaut : à chaque fois que vous faites une requête, vous envoyez votre mot de passe (encodé). C'est risqué, surtout si le serveur est compromis.
La solution moderne : au lieu d'envoyer nos identifiants à chaque fois, on les envoie une seule fois pour obtenir un jeton (token). Ensuite, c'est ce jeton qu'on présente à la place du mot de passe.
Le cycle Bearer Token
Demande d'authentification: le client envoie ses identifiants au serveur via une requête POST (souvent sur un endpoint
/loginou/auth).Réponse avec token: le serveur vérifie les identifiants et renvoie un jeton (token) dans sa réponse.
Utilisation du token: pour toutes les requêtes suivantes, le client envoie ce jeton dans l'en-tête
Authorization:
Le mot "Bearer" signifie "porteur", celui qui détient le jeton (bearer) est considéré comme authentifié.
Les JWT (JSON Web Tokens)
Un type très courant de token est le JWT. C'est un jeton structuré en trois parties séparées par des points .:
Partie | Rôle |
|---|---|
Header | Quel algorithme de signature est utilisé ? |
Payload | Les données (qui suis-je ? quels droits ai-je ?) |
Signature | Permet au serveur de vérifier que le jeton n'a pas été falsifié |
Un exemple d'authentification avec Bearer Token format JWT
À retenir sur les Bearer Tokens / JWT
On envoie nos identifiants une seule fois (au login), pas à chaque requête
Le jeton peut avoir une durée de vie limitée (expiration)
C'est le standard moderne pour les APIs, les applications mobiles et les SPA (Single Page Applications)
HTTP et HTTPS
HTTP
Pour HTTP, vous l'avez vu plus en détails hier, si vous voulez l'observer en action la technique la plus simple est de faire tourner votre TP en observant ce qui se passe dans l'onglet Network/Réseau de la console de développement de votre navigateur :
HTTPS
Le HTTPS (HyperText Transfer Protocole Secure) c'est le HTTP combiné à un mode de chiffrement appelé TLS (Transport Layer Security) et/ou de son prédécesseur SSL (Secure Sockets Layer). On parle souvent de SSL/TLS pour désigner les deux en même temps.
Le principe est assez simple : le serveur a un certificat d'authenticité, décerné par une autorité de certification qui met à disposition des listes de clés publiques.
Le processus SSL/TLS :
Le client demande au serveur une connexion sécurisé (en pratique souvent une URL qui commence par https://)
Le serveur envoie au client son certificat et sa signature numérique
Le client tente de vérifier la véracité de la signature auprès des autorités de certification
Si cette signature est vérifiée le client génère une clé de chiffrement pour la durée de la session, qu'il chiffre avec la clé publique reçue dans le certificat
Le serveur utilise sa propre clé privée pour déchiffrer la clé de session
On considère que la connexion sécurisée est établie entre le client et le serveur
Observer comment fonctionne une requête HTTPS
Pour observer une requête HTTPS, vous pouvez également utiliser votre console de développement sur le navigateur (Chrome sur les images de démonstration, mais disponible sur les autres).
Dans l'onglet réseau (ici, je demande la page https://kornog.bzh) :
Dans l'onglet sécurité :
Et quand vous affichez le certificat pour pourez voir la clé publique :
Le DNS
Le DNS (Domain Name System) est un service distribué qui associé un nom de domaine (tralala.fr) avec une adresse IP donnée (188.114.97.2).
Lorsqu'un client, par exemple votre navigateur veut accéder à une adresse URL (tralala.fr par exemple) il ne sait pas où aller chercher cette information, il va donc chercher à plusieurs endroits :
dans son cache, s'il a déjà visité cette URL, il a peut-être gardé l'adresse IP en cache
demander à un serveur DNS
Il existe deux types de serveurs DNS, ceux qui font la recherche, qu'on appelle les résolveurs (parfois appelés à tort serveurs récursifs, ils agissent de façon itérative), et les serveurs ayant autorité.
Les serveurs résolveurs se renvoient mutuellement la balle jusqu'à ce que l'un d'entre eux ait soit en cache la réponse à la question, soit qu'il renvoie vers un serveur ayant autorité pour ce nom de domaine.
Lorsque vous faites migrer un site, c'est généralement cette mise à jour de l'information parmi tous les caches de serveur résolveurs qui a un délai de propagation (généralement 24 à 72 heures).
Observer vous-même les DNS
En utilisant une commande comme :
Vous allez pouvoir observer la réponse reçue :
Ici, on devine que la réponse a été obtenue via le cache d'un serveur résolveur, car on ne nous déclare pas d'autorité directe pour la réponse (non-authoritative answer).
Les protocoles pour les mails
SMTP
SMTP (Simple Mail Transfer Protocol) est le principal protocole utilisé pour transférer les mails vers les serveurs de messageries électroniques.
Il repose sur un échange d'information assez simple :
établir une connexion au serveur
lui dire bonjour (plus exactement
EHLO)lui dire de qui vient le mail (
MAIL FROM)lui dire à qui il doit aller (
RCPT TO)les informations du mail (
DATA)un
.final pour indiquer la fin de la communicationon ferme la connexion (
QUIT)
Un exemple communication en texte brut
Comment tester le SMTP soi-même ?
Vous allez avoir besoin de deux composants : un faux serveur SMTP (nous allons utiliser MailPit), et un client permettant de l'interroger (telnet sur Windows, netcat sur MacOS et Linux).
Vous trouverez les explications sur l'installation de MailPit (et Telnet sous Windows) ici.
Dans le gif ci-dessous, vous avez sur le terminal de gauche, un faux serveur SMTP (Mailpit) qui tourne, dans le terminal de gauche on utilise netcat pour se connecter à ce serveur et lui envoyer des informations.
Enfin en bas de l'écran vous voyez une petite interface web de MailPit qui vous montre l'activité du serveur (l'arrivée du mail).
IMAP / POP3
IMAP (Internet Message Access Protocol) et POP3 sont les deux principaux protocoles pour interroger un serveur de messagerie pour pouvoir recevoir des messages.
Historiquement POP (Post Office Protocol) récupérait les messages et les téléchargeait en local dans un logiciel spécialisé en les enlevant du serveur.
IMAP les lui laissaient systématiquement en ligne.
Aujourd'hui l'un comme l'autre peuvent à la fois les laisser en ligne ou les télécharger selon la configuration dans laquelle on les utilise.
FTP et FTPS
FTP
Le FTP (File Transfer Protocol) est un protocole de communication destiné au partage de fichiers entre deux ordinateurs du même réseau.
Ce protocole permet d'ajouter, modifier ou supprimer des fichiers sur un ordinateur distant, c'est pourquoi il est fréquemment utilisé pour alimenter des petits (sinon il n'est pas le plus efficace) sites internets hébergés sur des serveurs tiers.
En pratique le client (votre ordinateur) va établir une connexion avec l'ordinateur distant (le serveur) qui fait tourner un binaire, appellé Serveur FTP qui implémente le protocole.
L'interface graphique la plus connue qui permet de manipuler du FTP est FileZilla.
FTPS
Le FTPS (File Transfer Protocol Secure) est une combinaison du FTP avec un chiffrement TLS/SSL.
De la même façon que le serveur web répond à une demande HTTPS en envoyant son certificat, ils va répondre à une demande FTPS en envoyant ce même certificat qui pourra servir de clé de chiffrement pour les échanges de fichiers.
Tester le FTP soi-même
Si vous n'avez pas de serveur distant qui accepte le FTP à votre disposition vous pouvez en faire tourner un en local avec une image docker pour ensuite tester la connexion via FileZilla ou le terminal.
Utilisez le docker-compose.yaml suivant :
Et voici les informations de connexion à votre serveur :
Vous pourrez faire une connexion, lister vos fichiers, mais ce serveur local est strict ne vous permettra pas d'uploader des fichiers.
La meilleure option est de tester sur un serveur web à votre disposition.
SSH
SSH (Secure SHell) est un protocole de communication sécurisé. Il repose sur un échange de clé au début de l'échange. Ces clés permettent d'abord d'authentifier les interlocuteurs puis de chiffrer les communications. Elle ne peuvent donc pas être interceptées par un tiers (sniffer par exemple).
Comment fonctionne le SSH ?
Côté client, vous créez un couple de clé SSH (avec ssh-keygen) : votre clé privée qui sera conservée sur votre ordinateur et une clé publique.
Sur les différents serveurs auxquels vous voulez pouvoir accéder en SSH un administrateur va devoir ajouter votre clé publique dans la liste des clés autorisées.
Lorsque vous voudrez vous connecter au serveur, il fera le lien entre la clé contenue sur votre ordinateur et celle publique dans la liste de ses accès autorisés.
À quoi sert le SSH ?
Il peut servir à échanger des fichiers, mais un de ses principaux usages, c'est qu'il vous permet de vous connecter à distance à un ordinateur et donc d'accéder à toutes les fonctionnalités du terminal auquel votre utilisateur a droit et ceci à distance.
Cela peut vous permettre d'installer des binaires, de faire des commandes git, de configurer votre serveur, et plein d'autres choses le tout depuis votre terminal.
Les WebSockets
WebSocket est un protocole réseau qui permet d'ouvrir un canal de communication bidirectionnel entre un client (le navigateur web) et un serveur web.
L'intérêt principal de ce protocole pour le web, c'est que contrairement aux autres où le serveur réagit toujours à une demande du client, ici une fois la connexion établie, le serveur peut de lui-même envoyer des informations au client (on appelle ça push) c'est ce protocole qui permet les notifications en temps réel.
Cas d'usage : Forum versus Chat
Sur un protocole de communication habituel, la communication fonctionne comme sur un forum, vous vous connectez, vous vérifiez s'il existe des nouveaux messages dans les conversations que vous suivez, vous postez ou non un message et vous repartez.
En pratique à chaque fois que vous rafraichissez, c'est le client qui demande au serveur "quoi de neuf ?" et le serveur répond.
Avec les websockets ça ressemble plus à un chat : même si vous ne demandez pas toutes les 5 minutes à rafraichir la conversation, si quelqu'un poste quelque chose pour vous c'est le serveur lui-même qui va envoyer l'info à votre navigateur sans qu'il l'ait demandée (et si le navigateur est sympa il vous met une notification ou actualise directement la conversation).