Pour sécuriser les échanges, il faut bien améliorer l'identification des parties qui échangent.
Tout dépend ce qu'on entend par :
- "sécuriser"
- "échange"
Je crois qu'il faut faire quelques rappels élèmentaires :
La sécurité qu'apporte la connexion sécurisée par TLS, donc HTTPS par rapport à HTTP, tient à ces points :
(1)
définition des extrémités :
(1si) identification et authentification du nom du serveur : l'autorité nommée dans l'URL est bien l'extrémité de la connexion sécurisée
(1cp) définition du client
(1ci) identification et authentification du client (très rare)
(2)
intégrité : les données ne sont pas altérées en route
(3)
confidentialité : un espion n'apprend rien de plus sur la charge utile que la quantité (nombre de messages, sens des messages (client->serveur ou serveur->client) et taille de chaque message)
Définition des extrémitésJ'ai mis "authentification du serveur" en (1) parce que c'est cette propriété de base qui donne le sens des autres.
L'identité vérifiée par (1si) est définie par "le.nom.du.serveur" dans
https://le.nom.du.serveur/données/envoyées/au/serveur
Le serveur TLS devra prouver qu'il est autorisé pour parler pour "le.nom.du.serveur" (il peut être autorisé pour plusieurs autres noms).
La sécurité de ce point est relative au contenu de l'URL. Si l'URL est quelconque,
si l'utilisateur ne choisit pas l'URL et qu'il n'est pas capable de la vérifier, alors le (1) est une garantie vide.(1c) est le symétrique de (1s) au niveau TLS.
Par définition, le client est "actif" (il appelle, il compose un numéro de téléphone) alors que le serveur est "passif" (il est appelé, il décroche son téléphone), donc le nom du client n'est pas comparé au contenu d'une URL bien sûr. En l'absence de certificat TLS client, le client n'a pas de nom.
(1ci) correspond à l'identification du nom du client dans un registre.
Même quand le client n'est pas identifié par un certificat, le serveur sait qu'il a en face de lui un client donné, qu'il peut associer à un "pseudonyme" (d'où le "p"); seule, cette remarque n'a aucun sens.
- (1si) tout seul ne garantit pas grand chose : se connecter à un serveur HTTPS démontre juste que le serveur en question existe, qu'il accepte les connexions (donc que l'URL nomme bien un serveur HTTPS, qu'elle est valide jusqu'au "/")
- (1cp) tout seul ne garantit rien du tout : recevoir une connexion HTTPS démontre juste qu'il existe un internaute, quelque part.
Intégrité (2) se définit par rapport au (1) : l'intégrité est garantie jusqu'à l'autre extrémité, qui est authentifiée.
On ne peut pas parler d'intégrité si on ne définit pas entre qui et qui.(2) donne une consistance (un effet tangible) à (1) :
(2s) le client sait que la conversation (séquence des messages envoyées et reçus) a été vue identiquement par le serveur nommé
(2c) le serveur sait que la conversation (séquence des messages envoyées et reçus) a été vue identiquement par un client, désigné par un pseudonyme.
C'est là que la remarque sur le pseudonyme du client prend un sens.
On peut faire une pause à ce point là : les garanties offertes sont effectives, elles sont déjà utiles. Par exemple, un gestionnaire de MàJ peut demander à un serveur "quelle est la version la plus récente d'un paquetage". Il a la garantie que
la réponse qu'il reçoit vient du serveur et qu'elle est consécutive à sa demande, donc qu'elle n'est pas moins récente que sa demande. [On voit donc que TLS offre déjà plus que DNSSEC dans l'utilisation habituelle (RR signé), qui garantit que la réponse vient du serveur et qu'elle est la réponse à la question, mais pas qu'elle est consécutive à la question (on pourrait en théorie avoir la même garantie en générant une question nouvelle à chaque fois).] On remarque que la confidentialité n'est pas essentielle dans cette utilisation.
Avec (1)+(2) on peut faire des choses utiles, parce que (1si)+(2s) offre une vraie garantie. (Par symétrie, (1ci)+(2c) aussi.)
En revanche, (2c) qui est l'intégrité du point de vue du serveur est sans consistance : (2c) n'offre aucune garantie réelle (point de vue du serveur) en l'absence d'identification du client (1ci).
Confidentialité (3) se définit par rapport au (1) : la confidentialité est garantie jusqu'à l'autre extrémité, qui est authentifiée.
On ne peut pas parler de confidentialité si on ne définit pas entre qui et qui.(3) garantit que seuls le C et S connaissent les données secrètes échangées, dont notamment :
- les secrets permanents (validité indéfinie) comme un mdp
- les secrets temporaires (validité courte) comme un identifiant de session (stocké dans un cookie p.ex.)
Le (3) donne une consistance (un effet tangible) à (2c), puisque le serveur peut déduire de la connaissance par le client C d'un secret (comme mdp(i) ou sid(i)) le fait que le pseudonyme p de C est associé à l'identité i. C'est (3) qui donne une consistance à un pseudonyme client.
(1)+(2)+(3) permet de s'identifier sur lafibre et de poster un contenu, de façon sûre. C'est (3) qui garantit qu'un message posté sur lafibre vient bien d'un utilisateur :
la confidentialité sert à maintenir l'intégrité au niveau supérieur.
Protocoles réseaux sécurisés (https)