pourquoi une authentification client n'est pas couramment effectuée dans le protocole TLS?
Y a-t-il une autre raison à cela que la gestion des clés/certificats côté client?
Qu'est-ce que l'authentification? Cela garantit que celui qui se trouve à l'autre bout du tunnel est qui vous croyez. Cela dépend vraiment du type de identité que vous souhaitez utiliser.
Pour la plupart des sites Web, la notion intéressante est continuité. Ils ne se soucient pas vraiment de qui est connecté; en effet, l'intérêt d'un site Web est d'être lisible par tout le monde. Le type d'authenticité qu'un site Web souhaite obtenir est de s'assurer que deux demandes successives proviennent bien du même client (quel qu'il soit). En effet, l'expérience du site Web est celle d'une succession logique de pages, entraînée par les actions de l'utilisateur (les liens sur lesquels il clique), et l'ingérence avec ce cadre de type film est ce que l'attaquant recherche. L'utilisateur et les concepteurs du site Web pensent en termes de sessions et l'attaquant veut détourner la session.
Cette authenticité est obtenue par plusieurs mécanismes:
- Les requêtes HTTP successives du même client passent par la même connexion (avec la fonction "keep-alive").
- SSL propose un mécanisme de reprise de session, qui réutilise la clé partagée négociée (c'est la "poignée de main abrégée" décrite dans la section 7.3 de la norme SSL/TLS ).
- La requête HTTP peut inclure un cookie que le serveur choisit; typiquement, une valeur aléatoire spécifique à l'utilisateur est envoyée sous forme de cookie à l'utilisateur et, en la voyant revenir dans les requêtes suivantes, le serveur est convaincu que les requêtes proviennent du même utilisateur.
Le cookie est suffisant pour assurer la continuité.
Quelle valeur supplémentaire ajouteraient les certificats clients? Eh bien, pas grand-chose. Certificats sont un moyen de distribuer les liaisons clé/nom. Il existe principalement trois scénarios où les certificats clients (dans un contexte Web) sont pertinents:
Le serveur Web a besoin d'une notion étendue d'identité de l'utilisateur, qui est définie par quelqu'un d'autre. Par exemple, imaginez un service gouvernemental accessible aux citoyens, mais uniquement après une authentification appropriée, par ex. un système électoral en ligne. Ce qui fait que le citoyen, avec son nom et sa date de naissance précis, est géré par l'État dans son ensemble, mais pas la même partie que celui qui gère le service. Les certificats clients sont alors un moyen de transporter l'authentification de l'ICP qui a délivré le certificat au citoyen, vers le système électoral en ligne qui n'a pas du tout le droit de dire qui est nommé quoi, mais doit néanmoins conserver des enregistrements clairs de qui se connecte.
Le concepteur de système a peu confiance dans la robustesse des navigateurs Web existants. Si le navigateur d'un utilisateur est piraté, le cookie secret peut être volé et l'utilisateur a essentiellement perdu, pour toujours. D'un autre côté, si l'utilisateur possède une carte à puce et que la carte à puce ça stocke une clé privée (qui est utilisée en combinaison avec un certificat client), un piratage complet du navigateur est toujours un gros problème, mais c'est plus contenu: puisque la carte à puce commettra un honorable seppuku au lieu de laisser la précieuse clé privée révélée, la situation peut être récupérée. Une fois le formatage et la réinstallation obligatoires effectués, les choses sont à nouveau sécurisées.
Le site Web ne souhaite pas seulement l'authenticité, il souhaite également obtenir la non-répudiation . La non-répudiation est un concept juridique qui nécessite un certain soutien des parties techniques du système, et ce soutien est signatures numériques . Nous sommes en dehors de ce que SSL/TLS fournit ici. En aucun cas, une authentification client SSL/TLS ne peut être une preuve qui pourrait être utilisée pour résoudre un conflit juridique entre l'utilisateur et le serveur lui-même (un serveur bancaire ne peut pas afficher la transcription de la connexion et dire "voyez, cet utilisateur vraiment m'a demandé d'acheter ces actions à ce prix ", car la banque aurait pu facilement fabriquer l'intégralité de la transcription). Pour de telles choses, il faut des certificats client et du code côté client qui utilise le certificat pour signer les données réelles. Cependant, une fois que le dur travail de délivrance des certificats aux clients a été effectué, il est logique de simplement les utiliser pour HTTPS.
Dans le cas courant d'un serveur Web, aucun de ces scénarios ne s'applique. Les certificats clients ne sont donc pas utilisés, car ils soulèveraient des problèmes pratiques sans ajouter de valeur supplémentaire. Ce serait une solution à la recherche d'un problème.
La principale raison est que 95% des utilisateurs d'Internet n'ont aucune idée de ce qu'est un certificat côté client, et encore moins comment l'utiliser. Certains utilisateurs parviennent à peine à utiliser des noms d'utilisateur et des mots de passe, et la plupart ne se soucient toujours pas de l'authentification à deux facteurs. Il est également difficile d'installer un certificat client sur des appareils distincts (ordinateur de bureau, ordinateur portable, tablette, smartphone, etc.) pour l'authentification à un seul service.
Donc, pour une liste rapide:
- Ignorance. Les gens ne savent tout simplement pas ce qu'ils sont ni pourquoi ils sont utiles.
- Commodité. Les gens ne peuvent pas être gênés de configurer leur appareil pour utiliser des certificats clients.
- Support. Si les gens doivent encore téléphoner au support technique lorsqu'ils oublient leur mot de passe ou ne peuvent pas se connecter, pouvez-vous imaginer combien d'appels de support supplémentaires seront nécessaires s'ils doivent installer un certificat client ? Ce problème est encore multiplié par la baisse de part de marché d'Internet Explorer, donc le personnel doit être formé pour guider les utilisateurs à travers l'installation sur IE, Firefox, Chrome, Opera, Safari, etc. ainsi que divers appareils mobiles.
- Complexité. Un code côté serveur supplémentaire est requis pour valider le certificat par rapport à un compte d'utilisateur.
- Prévalence. Aucun site majeur ne les utilise en masse pour le moment, donc personne d'autre ne le fera. Je me rends compte que c'est un catch-22, mais l'adoption de la technologie l'est souvent.
- Complaisance. La plupart des fournisseurs supposent que les mots de passe (ou 2FA) sont assez forts pour leurs besoins, même lorsque ces fournisseurs protègent très sensibles/informations critiques telles que les données financières.
Donc, même s'il serait agréable de voir des certificats côté client à grande échelle, je ne le vois vraiment pas se produire à moins qu'un événement sérieux ne pousse les fournisseurs à le faire.
Le client tente d'atteindre un serveur spécifique, identifié dans l'URL. Le client doit donc authentifier le serveur.
D'un autre côté, dans la plupart des utilisations de HTTPS, tout client peut contacter le serveur. Le serveur n'a aucune connaissance préalable du client. Il n'y a donc rien pour que le serveur authentifie le client. Le serveur veut authentifier l'utilisateur, pas la machine cliente.
Dans un environnement Internet, le client peut se trouver derrière un proxy, sur une adresse IP dynamique, etc. Il n'y a rien que le serveur puisse vouloir vérifier. Le seul point d'authentification du client serait d'enregistrer son identité pour de futures utilisations, soit à des fins médico-légales, soit pour suivre les clients sur plusieurs connexions. Étant donné que les utilisateurs peuvent se connecter à partir de plusieurs machines, il est inutile de suivre les machines clientes. L'enregistrement des identités des clients n'est que très marginalement utile pour identifier les clients ou utilisateurs malveillants après coup (l'attaquant est susceptible d'avoir généré un certificat qui ne fournit aucune information utile), cela ne vaut pas la peine de faire des efforts.
Dans un paramètre intranet, où seuls les clients connus doivent se connecter au serveur, l'authentification client est utile et utilisée.