Question:
Quelqu'un utilise-t-il des certificats de navigateur client?
StasM
2011-01-03 10:18:39 UTC
view on stackexchange narkive permalink

Les certificats de navigateur client semblent être un bon moyen de protéger les sites contre les intrus - il est impossible de deviner et devrait être plus difficile à voler. Bien sûr, ils ne résolvent pas tous les problèmes, mais ils ajoutent de la sécurité.

Cependant, je n'ai rencontré aucun site public les utilisant. Y a-t-il des sites qui les utilisent? Y a-t-il un défaut en eux qui empêche l'utilisation même lorsque la sécurité est importante ou une autre raison pour laquelle ils sont si peu utilisés?

StartSSL.com les utilise - au lieu de créer un nom / mot de passe, il génère un certificat client qui est utilisé pour la connexion [et doit être sauvegardé par l'utilisateur ou bien ils perdent l'accès au compte!]. Au moins dans le navigateur Chrome, ce fut une expérience étonnamment agréable. C'est le seul exemple que j'ai personnellement rencontré à ce jour.
Je fais, pour les modérateurs sur un site que j'opère.
Onze réponses:
#1
+20
nealmcb
2011-01-03 22:29:04 UTC
view on stackexchange narkive permalink

Les certifications côté client n'ont tout simplement pas eu un bon compromis coût / bénéfice. Ils sont très déroutants pour les utilisateurs, donc les coûts de support augmentent. Et ce ne sont encore que des bits et donc "quelque chose que vous connaissez" et sont vulnérables à une gamme d'attaques logicielles sur le navigateur, le schéma de distribution, le phishing, etc.

Les schémas de jetons matériels (authn à deux facteurs) sont mieux pour un bon authn. Les schémas d'authentification unique (SSO), potentiellement fédérés et potentiellement soutenus par des jetons matériels, résolvent plus de problèmes et sont plus faciles à déployer.

La gestion d'un grand nombre de certificats serait beaucoup plus compliquée pour un utilisateur que le problème épineux actuel des mots de passe multiples, et les navigateurs n'offrent pas un bon support pour sélectionner le bon certificat. Et si un utilisateur utilise un seul certificat pour de nombreux sites, il y a des problèmes de confidentialité car l'utilisation du certificat identifie l'utilisateur.

Au fil des décennies, beaucoup d'entre nous ont pensé que l'ère de la fin- L'utilisateur PK-crypto était juste au coin de la rue, en particulier ceux comme moi amoureux de la beauté de RSA. Il s'avère simplement que la façon dont il a évolué, les coûts du service d'assistance et de développement, les subtilités et les complexités et les enchevêtrements juridiques de la PKI du monde réel continuent de grignoter les avantages.

L'équipement semble plus cher que les bits, mais pas si les bits ne font pas le travail, ou si leur utilisation efficace consomme de la productivité.

Presque personne n'utilise l'authentification à 2 facteurs non plus, mais là au moins je vois la raison - la distribution de jetons physiques a des coûts. Les certificats ne coûtent rien cependant.
Certains se tournent vers l'authentification logicielle à 2 facteurs, comme la réinitialisation du mot de passe de Google envoie un OTP à votre téléphone lorsque vous essayez de vous connecter à partir d'un ordinateur qu'il ne reconnaît pas, et d'autres explorent la possibilité d'utiliser un smartphone au lieu d'un matériel. token (pour réduire les coûts).
#2
+18
AviD
2011-01-03 13:49:51 UTC
view on stackexchange narkive permalink

J'utilise des certificats de navigateur pour une poignée de sites, mais comme vous l'avez dit, la plupart des sites pas publics.

La principale difficulté des certificats côté client est de les distribuer . Autrement dit, comment puis-je vous donner en toute sécurité le certificat «tout-puissant» qui vous donnera accès à mon système, si je ne vous connais pas?
Les systèmes d'entreprise sont bien sûr plus faciles, tout comme les systèmes ouverts à un petit cercle de partenaires. Mais la distribution des clés est toujours un casse-tête difficile à résoudre. C'est beaucoup plus difficile que de simplement partager un mot de passe entre deux parties, compte tenu des aspects de la clé privée et de la protection des certificats, ....

Il existe en fait il existe des solutions à cela, bien sûr , et j'en utilise même un pour un site Web "public". (Il se trouve que c'est dans le secteur de l'identité, donc cela vaut la peine pour eux ...). Cette solution est basée sur l'authentification principale par mot de passe, et une fois que je suis entièrement authentifié, j'ai la possibilité de télécharger mon certificat - en supposant que je sache quoi en faire.
Pas beaucoup mieux, puisque le canal de mot de passe est toujours ouvert ... mais cela me donne au moins la possibilité de changer le mot de passe en quelque chose d'impossible et d'inutilisable, et de n'avoir que le CSC ....

Mais ce n'est pas anodin, et un peu complexe à mettre en œuvre correctement. La distribution dérangerait encore la plupart des utilisateurs.

Il n'est pas nécessaire qu'il soit tout-puissant - vous pouvez toujours demander un mot de passe, par exemple. Vous pouvez accorder l'accès aux zones à faible sécurité avec un mot de passe seul et à celles à haute sécurité uniquement avec cert + mot de passe. Ce n'est qu'un modèle, bien sûr.
@StasM - Eh bien, oui, mais encore une fois, cela ne fait qu'augmenter la complexité de la mise en œuvre. Et si vous faites ça, pourquoi vous embêter?
#3
+15
D.W.
2011-01-07 08:18:17 UTC
view on stackexchange narkive permalink

Si je comprends bien, l'utilisation des certificats clients dans la pratique pose de nombreux problèmes. Voici quelques-uns des problèmes que j'ai entendus:

  1. Obtenir des certificats clients. Il est difficile pour les utilisateurs d'obtenir initialement un certificat client. De toute évidence, les sites ne veulent pas créer d'obstacles inutiles que les utilisateurs doivent franchir avant même de pouvoir commencer à utiliser leur site. (Même le fait que le site génère le certificat client et le fournisse au client n'est pas une opération familière pour un utilisateur - sans compter qu'il a des problèmes de sécurité, car idéalement, seul le client devrait connaître la clé privée du client.) Navigateurs modernes fournissent des moyens de créer ou d'importer des clés privées et des certificats clients, mais l'expérience utilisateur est horrible.

  2. J'ai entendu dire que certains serveurs ne supportent apparemment pas bien les certificats clients (par exemple , http://osdir.com/ml/encryption.cryptlib/2005-09/msg00000.html).

  3. La mobilité est un problème. Malgré tous leurs problèmes, les mots de passe sont très portables; les certificats clients ne le sont pas. Même si le client parvient à générer une clé privée et à obtenir un certificat client pour cela, s'il veut commencer à utiliser un deuxième ordinateur, il devra faire une danse compliquée et déroutante pour transférer la clé privée et le certificat vers le second ordinateur. Si leur premier ordinateur meurt (ou subit une panne de disque dur) et qu'il doit réinstaller son système d'exploitation ou acheter un nouvel ordinateur, et si le client n'a pas sauvegardé sa clé privée, il n'aura aucun moyen de mettre son système d'exploitation privé clé et cert sur leur nouvel ordinateur; ils sont assez foutus. Un site peut créer une méthode d'authentification de sauvegarde afin que les utilisateurs qui ont perdu leur clé privée puissent générer et soumettre une nouvelle clé privée, mais cette méthode d'authentification de sauvegarde peut facilement devenir le maillon le plus faible de la chaîne. Peu importe la force de votre méthode d'authentification principale, si votre méthode de sauvegarde est facilement vaincue.

  4. Il n'est pas clair s'il existe une prise en charge suffisante des navigateurs pour les certificats clients. Je ne sais pas si tous les différents navigateurs (y compris les navigateurs mobiles) prennent correctement en charge les certificats clients.

  5. Le modèle PKI est de toute façon assez bien cassé. L'hypothèse était que l'autorité de certification vérifierait l'identité de l'utilisateur (par exemple, son vrai nom) avant de lui donner un certificat client, et le protocole a été conçu autour de cette hypothèse. Cependant, les autorités de certification actuelles ne vérifient pas vraiment l'identité. Cela crée un décalage entre les hypothèses de conception et la réalité.

  6. Les certificats clients créent des risques de confidentialité pour les utilisateurs. Dans certains navigateurs, ils permettent le suivi des utilisateurs sur plusieurs domaines. (Tous les navigateurs veillent à ce que les cookies se défendent soigneusement contre cette menace: seul le domaine qui a défini le cookie peut le lire. Cependant, les navigateurs n'intègrent pas de protections similaires pour les certificats de client SSL.) Je ne sais pas si les navigateurs modernes ont effectivement résolu ce problème problème, mais c'est un domaine où les certificats clients sont relativement immatures, pour autant que je sache.

  7. Il y a des problèmes techniques ennuyeux, si le client génère et signe son propre certificat client. Selon le protocole TLS, le serveur est censé demander d'abord une liste de CA qu'il est prêt à accepter; le client répond ensuite avec un certificat client émis par cette autorité de certification, si elle en a un. (Notez que cela se produit avant que le client n'ait envoyé une requête HTTP, des cookies HTTP, un nom d'utilisateur ou toute autre information d'identification.) Cela signifie que, si vous souhaitez utiliser des certificats client émis par le client (auto-signés), alors le le serveur doit connaître le nom de l'autorité de certification que le client utilise avant même que le client ne s'authentifie ou s'identifie. C'est délicat.

  8. Enfin, cerise sur le gâteau: les certificats clients ne résolvent pas le problème du phishing. Ils empêchent le vol de la clé privée du client, mais pas d'autres informations personnelles. Les méchants peuvent toujours configurer un faux site bancaire (qui supprime tous les certificats de client qui lui sont envoyés). Le site d'hameçonnage n'apprendra pas la clé privée de l'utilisateur, mais si l'utilisateur pense qu'il s'est connecté au vrai site de la banque, il peut saisir son numéro de compte bancaire, SSN, PIN, etc., révélant ces informations à l'attaquant.

Tout cela se traduit par une mauvaise utilisation et une augmentation des coûts de support (par exemple, les appels au helpdesk). En bref, vous pouvez utiliser des certificats clients, du moins en principe; c'est juste que, dans la pratique, cela n'est pas pratique pour tout le monde et la convivialité est nul.

Plus fondamentalement, il y a un problème de poule et d'oeuf: tant que de nombreux sites ne commenceront pas à utiliser des certificats clients, les fabricants de navigateurs ne le feront pas accorder une haute priorité à l'utilisation des certificats clients; et jusqu'à ce que les navigateurs rendent les certificats clients utilisables, les sites ne les adopteront pas. En d'autres termes, si nous voulons utiliser des certificats clients pour résoudre le problème général d'authentification, nous devons les deux convaincre tous les fabricants de navigateurs d'apporter des modifications majeures aux navigateurs, et convaincre les sites d'adopter de nouvelles technologies. Aucun avantage ne profite à quiconque tant que toutes ces parties n’apportent pas de changements coordonnés. C'est un énorme obstacle à l'adoption.

Il existe de meilleures solutions pour l'authentification sécurisée sur le Web, impliquant HTTPS, des cookies persistants sécurisés et une récupération par e-mail. Cependant, cela dépasse le cadre de votre question.

Dernier commentaire: Le défi fondamental de l'authentification Web sécurisée est la convivialité, la convivialité, la convivialité. Créer des systèmes qui fonctionnent bien pour les utilisateurs - et qui sont sécurisés, lorsqu'ils sont utilisés comme des utilisateurs ordinaires sont susceptibles de les utiliser - est très difficile, et c'est tout ce qui compte. La crypto n'est qu'une infime partie de ce problème.

L'élément documenté dans la spécification HTML5 (et pris en charge par de nombreux navigateurs auparavant) est un moyen assez utilisable pour générer + installer des paires de clés sécurisées sur le client. L'expérience dans Chrome était au moins assez transparente et j'espère que FF également.
L'élément est obsolète en HTML5, selon [W3C] (http://w3c.github.io/html/sec-forms.html#elementdef-keygen), [WHATWG] (https: //html.spec.whatwg.org / multipage / forms.html # the-keygen-element) et [MDN] (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen) et a été désactivédans Chrome à partir de la version 49.
#4
+7
bahamat
2011-01-03 12:24:59 UTC
view on stackexchange narkive permalink

Je pense qu'ils ne sont principalement pas utilisés parce que la personne moyenne (c'est-à-dire pas vous puisque vous posez cette question) ne peut pas comprendre leur utilisation. Il existe quelques sites commerciaux qui les utilisent mais ils sont généralement à des fins très spéciales ou pour l'automatisation. Par exemple, Oracle utilise des certificats clients pour valider les utilisateurs finaux avec des contrats de support valides pour les mises à jour de packages. Mais même avec des utilisateurs hautement techniques, obtenir le bon échange de clés peut être difficile.

Tout cela étant dit, j'utilise des certificats client pour protéger des parties de mes sites Web que je laisse ouvertes au public, et je pense qu'ils sont fantastiques.

Je vois votre point, mais tout cela peut être fait dans le navigateur ... L'utilisateur doit simplement télécharger / double-cliquer sur le fichier et c'est tout. Les extensions de navigateur sont des choses très complexes mais ont été rendues transparentes pour l'utilisateur, par exemple.
Tout cela "dans le navigateur" nécessite beaucoup de code côté serveur pour être implémenté.
#5
+6
blowdart
2011-01-05 04:10:15 UTC
view on stackexchange narkive permalink

La carte d'identité nationale estonienne est une carte à puce qui contient un certificat client intégré. Vous pouvez vous procurer des lecteurs de cartes à puce et l'utiliser à la maison pour demander des services gouvernementaux ou vous authentifier auprès des principales banques estoniennes. Tout ce que l'utilisateur voit est une invite de carte / code PIN et la prochaine chose qu'il sait qu'il est authentifié.

#6
+5
Martijn Heemels
2011-01-04 06:16:59 UTC
view on stackexchange narkive permalink

Un de nos clients utilise des certificats clients pour authentifier les systèmes de kiosques à écran tactile. Les systèmes sont distribués aux revendeurs, et chacun obtient son certificat racine CA installé ainsi qu'un certificat client unique.

Le certificat client est utilisé pour authentifier le système de kiosque auprès du serveur Web, sans que le revendeur n'ait à effectuer authentification manuelle au démarrage de l'appareil. Si un système individuel doit être exclu, il est facile pour notre client de révoquer le certificat.

Vous voyez, ici la distribution est prise en charge, c'est trivial par rapport à la livraison des kiosques ... Bien que je remette en question la sécurité de ce système, après tous les utilisateurs anonymes peuvent accéder directement au kiosque - et éventuellement "emprunter" le certificat?
C'est vrai, AviD. Bien sûr, le kiosque doit être correctement renforcé pour empêcher ce type d'accès. Si un certificat est volé, il peut être révoqué individuellement par l'autorité de certification puisque ce kiosque doit être considéré comme compromis. Dans ce cas, les informations sur le serveur Web ne sont pas suffisamment critiques pour exiger des mesures supplémentaires, de sorte que le certificat client est fondamentalement une alternative à un mot de passe.
#7
+4
Jcs
2011-01-03 22:18:25 UTC
view on stackexchange narkive permalink

Le ministre français de l'Économie a publié un site Internet public de gestion fiscale (paiement en ligne des taxes, informations sur les délais, téléchargement de formulaires ...) qui utilise un certificat SSL pour l'authentification des utilisateurs. L'enregistrement de l'utilisateur (ce rôle est attribué à une Autorité d'Enregistrement dans PKI) qui a été pointé par AviD ♦ comme étant la principale difficulté dans un tel projet, a été résolu puisque cette administration a déjà suffisamment d'informations pour identifier les contribuables.

Le problème n'est pas seulement l'identification initiale, sa distribution de certificats.
Oui, je n'étais pas clair. Je voulais dire que l'administration est en mesure de s'assurer que l'identité du demandeur de certificat (c'est-à-dire le détenteur privé) correspond à l'identité déclarée. Techniquement parlant, il y a un numéro privé unique sur le reçu de paiement d'impôt (de l'année précédente) utilisé comme secret partagé pendant le processus de génération du certificat.
Vraiment? considèrent-ils ce "numéro de paiement fiscal unique" comme un secret protégé? Humph ... Eh bien, je suppose que ce n'est pas pire que les États-Unis considèrent le SSN comme une forme d'identification sécurisée ...
#8
+1
goodguys_activate
2012-12-29 05:23:47 UTC
view on stackexchange narkive permalink

Une variante des certificats de navigateur est utilisée dans le protocole ActiveSync basé sur HTTP / S.

Plusieurs administrateurs de messagerie utilisent des certificats pour authentifier un appareil mobile afin que la messagerie mobile ne cesse soudainement de fonctionner lorsque l'utilisateur change de mot de passe.

#9
+1
Serge Ballesta
2016-04-29 14:39:04 UTC
view on stackexchange narkive permalink

Les certificats clients ont la meilleure qualité d'authentification. Mais à cause d'un problème de poule et d'œuf, les utilisateurs n'ont aucune raison d'acquérir un certificat sérieux (coûte de l'argent et du temps car la livraison doit être une opération en face à face) car peu de sites les utilisent et les administrateurs de sites n'ont aucune raison de les soutenir activement depuis leurs utilisateurs n'ont généralement pas de certificat.

Les systèmes d'entreprise sont différents car si les exigences de sécurité sont suffisamment élevées, le coût global d'une infrastructure PKI est parfaitement accessible.

Mais quand on se souvient de ce que c'est le coût total réel et la procédure pour une carte d'identité nationale (sans parler d'un passeport), l'ajout d'un certificat établi par une administration nationale n'ajouterait pas grand-chose et résoudrait joliment toutes les questions d'authentification avec des sites institutionnels comme les administrations, les banques, ... Bien sûr, je ne l'utiliserais pas pour les sites marchands ou les forums peu contrôlés

#10
  0
Totoro53
2016-04-29 14:02:29 UTC
view on stackexchange narkive permalink

Je travaille au développement d'un site qui propose une authentification par carte à puce. L'utilisateur connecte un lecteur de carte USB, se rend sur le site, et lorsqu'il veut se connecter, il insère la carte et fournit un code PIN. Le problème est que le système utilise une applet Java, et ces applets ne sont plus prises en charge par Chrome ou par MS Edge. Un nouveau middleware est en cours de développement qui n'utilise pas les applets Java, et c'est une course contre la montre car nous pouvons voir tous les principaux navigateurs empêcher les applets Java d'interagir avec le matériel de votre PC à l'avenir.

#11
  0
Archimedes Trajano
2018-03-21 22:22:39 UTC
view on stackexchange narkive permalink

Si nous développons la portée de l'OP pour aller au-delà du navigateur. Les certificats clients peuvent également être utilisés dans le contexte sans navigateur. Par exemple, Docker utilise TLS et des certificats clients pour sécuriser leurs connexions entre un client Docker distant et leurs démons.

Cela devrait encore être géré, mais il n'est pas nécessaire de passer par une autorité de certification à part entière, il peut s'agir d'une autorité de certification interne de l'entreprise pour gérer tous les certificats utilisés par les machines.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 2.0 sous laquelle il est distribué.
Loading...