Faudrait savoir, en quoi TLSA permet de s’affranchir des CA moisies si ce n’est « implémenté nulle part » ?
J’ai dit que DANE-TA/EE n’était pas implémenté (ie sans validation de la chaîne X.509 et qui permettrait d’avoir de l’auto-signé sans erreur lors de la navigation). PKIX-TA/EE est implémenté (plugin firefox disponible) et implique la validation X.509 en plus de DANE/TLSA.
Un pin sur le certificat ne te protège pas davantage contre ce cas, celui qui a mis la main sur ta clef pourra potentiellement s’en servir tant que la signature de l’enregistrement TLSA n’aura pas expirée.
Ça protège plus que juste sur la clef. Un pin sur le certificat empèchera par exemple une interception MitM via un faux certificat généré avec la même clef. En cas de compromission de la clef, avec un pin sur le certificat, le seul moyen d’attaque reste l’interception directe pour déchiffrement a posteriori du trafic RÉEL entre un client et le serveur.
Ce cas est hardcore, on est d’accord, mais ce petit détail peut te laisser un peu plus de temps pour révoquer la clef compromise sans mettre (trop) en péril tes utilisateurs.
Ah ouais quand même. Donc c’est trop dur pour un administrateur système d’invoquer openssl req correctement, par contre tu attends d’un simple utilisateur qu’il compare lui-même, manuellement, l’empreinte du certificat telle que présentée par le navigateur avec celle qu’il sera aller chercher dans le DNS.
Je ne pourrais pas te citer les cas concrets associés pour des raisons évidentes de sécurité, mais la vérification manuelle ça a (et ça peut toujours) potentiellement sauver des vies, oui :) (Par exemple quand ton navigateur ne permet pas la validation DNSSec ou DANE/TLSA).
$ openssl req -config req.cfg -new -key $keydir/mykey.pem -outform DER -out $outdir/req.csr
[... too much snip...]
Vas-y, rigole dans ton coin. Moi ça fait déjà quelques messages que tu ne me fais plus rire.
C’est exactement ce que je dis. Hors de portée d’une personne standard.
D’ailleurs ton exemple est erroné puisque le CN devrait être identique à au moins un des SAN indiqués, généralement même le 1er.
Et il te manque aussi la gestion des paramètres d’utilisation de la clef (avec sa compatibilité Netscape).
[^] # Re: 90 jours, et alors?
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 1. Dernière modification le 22 septembre 2016 à 14:52.
J’ai dit que DANE-TA/EE n’était pas implémenté (ie sans validation de la chaîne X.509 et qui permettrait d’avoir de l’auto-signé sans erreur lors de la navigation). PKIX-TA/EE est implémenté (plugin firefox disponible) et implique la validation X.509 en plus de DANE/TLSA.
Ça protège plus que juste sur la clef. Un pin sur le certificat empèchera par exemple une interception MitM via un faux certificat généré avec la même clef. En cas de compromission de la clef, avec un pin sur le certificat, le seul moyen d’attaque reste l’interception directe pour déchiffrement a posteriori du trafic RÉEL entre un client et le serveur.
Ce cas est hardcore, on est d’accord, mais ce petit détail peut te laisser un peu plus de temps pour révoquer la clef compromise sans mettre (trop) en péril tes utilisateurs.
Je ne pourrais pas te citer les cas concrets associés pour des raisons évidentes de sécurité, mais la vérification manuelle ça a (et ça peut toujours) potentiellement sauver des vies, oui :) (Par exemple quand ton navigateur ne permet pas la validation DNSSec ou DANE/TLSA).
C’est exactement ce que je dis. Hors de portée d’une personne standard.
D’ailleurs ton exemple est erroné puisque le CN devrait être identique à au moins un des SAN indiqués, généralement même le 1er.
Et il te manque aussi la gestion des paramètres d’utilisation de la clef (avec sa compatibilité Netscape).