Pourquoi RFC4255 (SSHFP) n'est-il pas utilisé pour HTTPS?
J'ai eu cette idée il y a quelques heures, mais bien sûr, il existe déjà et il y a même n RFC ...
Pourquoi ne publions-nous pas l'empreinte digitale pour le certificat SSL/TLS via DNS? Nous avons besoin de DNSSEC pour vous assurer que la réponse est légitime et nous devons nous assurer que les serveurs de noms sont dans un environnement sécurisé, mais en plus que je ne vois aucun problème que SSL/TLS n'a pas déjà.
Ce changement déplacerait l'autorité pour sécuriser tout notre trafic crypté des autorités de certification (CAS) aux noms de noms DNS. Cela pourrait être un problème car dans ce cas, tous les fournisseurs DNS (qui ont DNSSEC) devraient devenir des environnements très élevés de sécurité tels que CAS. Mais tous les serveurs de noms ne devraient-ils pas déjà être? La majorité des sites Web utilisent le HTTP uni pour le trafic sensible et la plupart des gens ne remarqueraient pas s'il n'y a pas de cadenas lors de la connexion à Google. Je dirais qu'ils ont déjà une énorme responsabilité.
Si nous ne faisons pas confiance aux noms de noms du domaine, nous pourrions inclure des empreintes digitales dans des serveurs root, mais je ne suis pas sûr de la charge supplémentaire qui serait.
Un autre problème est que la DNSSEC n'est pas aussi largement mise en œuvre. Mais la raison de mes questions est parce que l'IETF envisage de prendre en charge le cryptage dans HTTP/2.0 sans exiger la vérification du certificat "pour faciliter le déploiement".
À mon avis, la sécurité devrait soit être faite correctement, soit pas du tout. Ne donnez pas aux gens un faux sentiment de sécurité. Mais si nous allons modifier les protocoles de toute façon (mettre à niveau tous les serveurs Web), nous pourrions également implémenter DNSSEC et faire cette voie droite (authentifiée).
Les problèmes/changements en bref:
- nous devons faire confiance aux noms de noms (root?) au lieu d'une tonne de CAS;
- nous devons ajouter un type d'enregistrement DNS ou étendre l'utilisation de l'enregistrement SSHFP; et
- nous devons prendre en charge la DNSSEC plus largement.
Je manque quelque chose? Pourquoi payons-nous des certificats Top Dollar pour SSL/TLS lorsque tout ce que nous avons à faire est de publier l'empreinte digitale du certificat sur un canal authentifié?
Le point de cryptage non authentifié dans http 2.0 est d'encourager l'activer sans avoir à modifier d'autres configs. Je suis contre cela parce que c'est inutilement lent (une autre ronde pour l'échange de clé, qui est particulièrement mauvaise à l'étranger ou avec une perte de paquets) et ajoute à peine une sécurité. Cela pourrait même fournir un faux sentiment de sécurité. Sur le bon côté, il obscurcisse la circulation.
Cette proposition d'utilisation DNS le rend quelque peu plus de travail à implémenter le cryptage sur les serveurs Web, mais le rend (au moins presque) aussi sûr que SSL/TLS normal tout en gardant une disponibilité généralisée de cryptage très élevé (je ne m'attends pas à ce qu'ils vont garder Les prix ridiculement élevés pour un serveur de noms de noms à compter de la SSHFP/HTTPFP/TLSFP comme ils le font avec des certificats). Le cryptage non authentifié pourrait toujours être un dernier recours lorsque toutes les autres options (SIGN SIGN SIGT; CERT stocké; Empreinte digitale en toute sécurité) ne sont pas disponibles (bien qu'il ne soit pas indiqué à l'utilisateur, car il fournit un sens total de sécurité), mais je suis Pas sûr que ça vaut même la peine de ralentissement.
S'il n'est pas possible d'utiliser les serveurs racine pour cela, nous pourrions également utiliser les serveurs de noms du domaine comme "envionnements raisonnablement sécurisés" (cadenas normal) et utiliser un certificat signé par CA (barre verte). Dites ensuite aux gens de rechercher le barreau de la barre de la banque en ligne. Les serveurs de noms ont déjà une responsabilité assez grosse afin que cela puisse être suffisamment sûr, même si nous ne pouvons pas nous attendre à ce qu'ils soient aussi secs qu'une ca. Au moins, ce serait un système beaucoup plus flexible; Je suis restreint à mon domaine et à un sous-domaine pour tout certificat à prix raisonnable (et le sous-domaine est déjà occupé par "www").
ma question à nouveau en bref: Y a-t-il une raison pour laquelle nous n'utilisons pas de système de type SSHFP pour HTTPS, si DNSSEC a été largement disponible?
Il existe - c'est ce qu'on appelle Dane - - http://tools.ietf.org/html/rfc6698 (le certificat RFC n'a pas vu d'avoir eu une traction, je ne sais pas pourquoi).
Pour générer les enregistrements, vous pouvez utiliser ceci:
https://github.com/pieterlexis/wede
Ce plug-in Firefox peut les valider:
malheureusement, ce n'est pas complet.
L'équipe de patrouille de certificat a un plugin mis à jour:
https://labs.nic.cz/page/1207/dane-patrol/
mais il ne semble pas fonctionner non plus :(
Il ne semble pas y avoir d'autre support pour d'autres navigateurs, chrome dispose d'un support écrit mais non publié, voir ce blog Publier (si TLSA est important pour vous, peut-être envoyé par courrier électronique Adam?):
https://www.imperialviolet.org/2012/10/20/dane-staplé-certificates.html
Notez que TLSA ne vous laissez pas simplement valider un certificat, il permet également à un propriétaire du site affirmer que le certificat utilisé sur leur site ne sera signé que par une autorité de certification particulière, qui va un moyen de poser les problèmes de CA rogue/piraté de du repos.
N'oubliez pas que tout ca (ou affilié d'une CA, ou une filiale d'une CA, etc.) peut signer un certificat pour n'importe quel domaine. Pour que l'écosystème CA soit sécurisé , chaque a pour être sécurisé!