Bonjour cher Journal,
Déjà meilleurs vœux à la communauté Linuxférienne, BSDéienne et
OpenSource dans son ensemble ;)
Je me demande vers où l'avenir nous amène et j'aimerais avoir votre avis à
ce sujet.
DNSSEC
Depuis déjà un petit moment les TLD incitent les registrars à pousser leurs
clients finaux à mettre en place : DNSSEC :
https://fr.wikipedia.org/wiki/Domain_Name_System_Security_Extensions
C'est déjà une très bonne idée de promouvoir DNSSEC afin que le visiteur
d'un site web soit correctement redirigé sur le ou les serveurs du domaine.
Avantages :
- Cela règle les avantages de DNS Poisoning :
https://fr.wikipedia.org/wiki/Empoisonnement_du_cache_DNS
Inconvénients :
- Cela ne règle pas le problème des DNS des FAI/Entreprises qui refusent d'être
compatibles avec cette norme.
Chrome l'avait implémenté en 2011, mais ils l'ont retiré car ce n'était pas
utilisé : https://www.imperialviolet.org/2011/06/16/dnssecchrome.html
Donc le visiteur de votre site doit faire confiance à son FAI, fournisseur
de DNS ou s'installer son propre résolveur (Ex : unbound) et il peut
installer une extension dans son navigateur pour avoir une alerte visuelle.
Par conséquent DNSSEC va connaître un déploiement long et il ne couvrira pas 100%
de nos visiteurs.
HPKP
Tout le monde sait que les certifs SSL pour être validés par nos navigateurs
doivent être signés par un CA de confiance. CA qui a son certificat dans
chacun de nos navigateurs. Sauf que si un CA est attaqué ou qu'un faux
CA est déposé dans le navigateur par un gouvernement, un employeur etc,
tous les certificats des autres CA peuvent être usurpés.
Exemple d'attaque passée :
http://www.zdnet.fr/actualites/des-certificats-ssl-frauduleux-de-comodo-autorisent-des-attaques-contre-les-webmails-39759360.htm
Du coup une nouvelle norme est sortie l'an dernier : HPKP :
https://tools.ietf.org/rfc/rfc7469.txt
Les navigateurs modernes (Chrome / Firefox) implémentent déjà cette norme :
https://developer.mozilla.org/fr/docs/Web/Security/Public_Key_Pinning
Mais pas Internet Explorer :
https://dev.windows.com/en-us/microsoft-edge/platform/status/publickeypinningextensionforhttp
Avantage :
- Si votre certificat SSL est signé par le CA XYZ et qu'un CA XXX se fait
pirater et émet un vrai/faux certificat pour votre domaine, votre client
en sera informé.
Inconvénient :
- Si votre client se fait intoxiquer à la première connexion à votre
site, alors la sécurité mise en place ne sert à rien.
Key pinning is a trust-on-first-use (TOFU) mechanism. The first time
a UA connects to a host, it lacks the information necessary to
perform Pin Validation; UAs can only apply their normal cryptographic
identity validation. (In this document, it is assumed that UAs apply
X.509 certificate chain validation in accord with [RFC5280].)
Du coup une ancienne RFC refait surface : DANE / TLSA
https://tools.ietf.org/html/rfc6698
L'idée consiste à mettre un enregistrement DNS de votre certificat. Si votre
DNS est protégé par DNSSEC cela peut être intéressant.
Actuellement je n'ai trouvé, à part des plugins, aucune trace d'intégration
en cours de cette RFC dans les navigateurs modernes.
On en revient au problème initial, le navigateur doit pouvoir se reposer sur
les DNS enregistré dans la machine. Si les DNS ne supportent pas DNSSEC c'est
inutile d'aller plus loin.
Niveau sécurité si tout est implémenté jusqu'au bout ce serait top, mais
est-ce que cela ne risque pas de ralentir un peu nos sites web, à l'heure où
on fait tout pour les rendre plus rapides (HTTP2, minifications des CSS, JS
…) ?
Les navigateurs vont devoir faire des requêtes DNS qu'ils ne font pas
actuellement.
En plus si on suit la logique nous sommes en train de demander à nos
navigateurs de vérifier les HASH (SHA256) de nos JS via la norme CSP :
https://w3c.github.io/webappsec-csp/
Donc on va solliciter encore un peu plus le CPU de nos visiteurs.
Donc cher lecteurs, que pensez-vous de la direction qui est prise ?
Vous voyez des avantages, des inconvénients que je n'ai pas listés ?
Avez-vous des pistes pour qu'on arrive à implémenter tout ça facilement et
rapidement ;)
Je trouve ce que fait Lets Encrypt génial mais avez-vous lu la critique
suivante ? :
https://blog.imirhil.fr/2015/12/12/letsencrypt-joie-deception.html
Et bonne année encore à tous.
# La vitesse des sites web
Posté par Analytical . Évalué à 10.
La plupart des sites web « modernes » chargent je ne sais combien de scripts en tout genre pour deux-trois animations et pister les utilisateurs, des images immenses en guise d'en-tête, des polices entières pour deux icônes et des milliers de lignes de CSS juste pour avoir une grille responsive et des boutons en relief. Je pense qu'il y a donc de la marge avant que les protocoles relatifs à la sécurité soient un facteur important dans la latence, la vitesse de chargement des pages et la vitesse de leur analyse par le navigateur.
# Lapsus ?
Posté par NumOpen . Évalué à 3.
"Cela règle les avantages de DNS Poisoning :" -> "Cela règle les problèmes de DNS Poisoning :"
[^] # Re: Lapsus ?
Posté par Chuck #1 . Évalué à 10.
Moi, j'ai aimé le lapsus "communauté Linuxférienne, BSDéienne". Maintenant on connait la préférence de l'auteur entre les BSDéiens et les Linux-fait-riens.
Cette signature est publiée sous licence WTFPL
[^] # Re: Lapsus ?
Posté par Régis . Évalué à 1.
Je suis mort de rire en lisant ton commentaire, bien vu ;)
[^] # Re: Lapsus ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Perso, Linuxférienne me fait penser à Lucifer, serait-ce voulu aussi ? BSDéienne peut évoquer la divinité, mais c'est un peu plus tordu. Et tout ça est très tordu aussi, quand on pense à la mascotte des BSD…
[^] # Re: Lapsus ?
Posté par eingousef . Évalué à 4.
De tout façon que ce soit BSD ou GNU c'est des vilaines bêtes à cornes et à barbiche.
Je me demande vraiment ce que tu fais là c'est un coup à te faire excommuniquer o_O
*splash!*
[^] # Re: Lapsus ?
Posté par Stéphane Aulery (site web personnel) . Évalué à -6.
Tu peux faire de l’humour mais je pense qu’on devrait tous être peinés par ces références récurrentes dans le milieu du logiciel. Croyant ou pas, le démon, c’est le prestige du mal.
On peut toujours arguer que c’est pour le côté rebelle, mais je ne vois pas qu’on puisse faire quelque bien réel en semence l’esprit de désordre, comme on ne peut rien fonder de durable sur des principes mauvais.
SA
[^] # Re: Lapsus ?
Posté par 못 옷 홋 ♨ (site web personnel) . Évalué à 9. Dernière modification le 08 janvier 2016 à 23:20.
Seulement si on prend la mythologie chrétienne comme référence, qui ne représente même pas la majorité des humains.
En réalité, le daemon, à l'origine du logo BSD à travers l'appellation "daemon" utilisée pour les services Unix, est une référence aux daimons grecs, des esprits de la nature plutôt bienveillants et en aucun cas maléfiques.
Le démon représenté sur le logo ressemble certes plus à un démon stéréotypiquement chrétien, rouge avec ses petites cornes et sa fourche (ça c'est pour le jeu de mot BSD/Beastie/beast) mais enfin il sourit, donc ce n'est pas tout à fait ça non plus.
Bref ce logo n'est qu'un mic-mac de jeux de mots et ça n'a simplement aucun sens de dire que le démon [de BSD] est "le prestige du mal". Ici c'est ton propre esprit qui est un peu trop focalisé sur ta religion et qui te joue des tours.
[^] # Re: Lapsus ?
Posté par Stéphane Aulery (site web personnel) . Évalué à -2.
Oui, biensûr il suffit d’ajouter un sourire pour le transformer en petite mascotte Kawaii.
Je n’ai pas dis que le "daemon" est "le prestige du mal", mais le "démon" […].
Le logo des BSD fait explicitement référence au Diable / démon, dans le sens chrétien comme tu le reconnais. Ce n’est pas moi qui interpole. S’ils avaient vraiment voulu représenter un daemon ils auraient utilisé une driade par exemple.
Je veux bien reconnaître que le mot daemon au sens strict pour les services n’est pas démon, mais enfin, ça joue ouvertement sur le double sens…
SA
[^] # Re: Lapsus ?
Posté par Sufflope (site web personnel) . Évalué à 8.
J'ai hâte de connaître ton avis sur les dommages corporate des noms de teub de weboob et ses modules. T'es libre le 13 ?
[^] # Re: Lapsus ?
Posté par Stéphane Aulery (site web personnel) . Évalué à -2.
Idem. Je ne sais pas quel est le statut de Besty chez OpenBSD par rapport à Puffy, qui est clean il me semble. Et que dire des daemon, de Python par exemple en hommage aux… Les références sont fréquentes.
SA
# Let’s Encrypt
Posté par gouttegd . Évalué à 10.
Je ne suis pas d’accord avec la section « Des paramètres par défaut insuffisant » — une clef RSA de 2048 bits par défaut convient très bien.
J’ai déjà dit récemment qu’une clef RSA de 4096 bits était « disproportionnée » pour un certificat valide deux ans, mais alors pour un certificat valide 90 jours, c’est carrément ridicule.
Il va falloir plus qu’un post de blog pour me convaincre qu’il y a quelque part (sur Terre, hein, pas dans une galaxie lointaine, très lointaine) un attaquant capable de casser une clef RSA de 2048 bits en moins de trois mois…
Pour info, l’ANSSI (qui selon l’auteur « déconseille officiellement » les clefs de 2048 bits) admet en réalité que cette taille de clef est toujours satisfaisante jusqu’en 2030 (p. 17, RègleFact-1).
En revanche, je suis d’accord avec le reste. Notamment, l’interaction de l’automatisation promise par Let’s Encrypt avec les autres mécanismes de sécurité (particulièrement HPKP, et DANE dans une moindre mesure) n’a pas été suffisamment pensée (je serais en fait enclin à dire que ça n’a pas été pensé du tout), de sorte qu’en effet
[^] # Re: Let’s Encrypt
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 04 janvier 2016 à 21:04.
Je crois aussi que l'article loupe le coche : en forçant le changement de certificat tous les 3 mois, Let's encrypt permet de passer très rapidement aux nouvelles technologies cryptographiques (pour les certificats). Pour moi, Let's encrypt permet justement de renforcer la sécurité générale, car elle évitera que des certificats trop faible persistent sur le web trop longtemps.
De même, le paragraphe suivant me paraît un peu douteux:
HSTS sert surtout à dire que ce site devrait être uniquement accédé par HTTPS pour les x prochains jours (dès que la première visite sur HTTPS a eu lieu). Ce n'est pas du tout lié au certificat utilisé, c'est juste un indice de redirection côté navigateur.
Je ne connais pas HPKP, mais s'il ne permet pas de changer les certificats assez aisément (donc avec une automatisation) et fréquemment, alors pour moi c'est lui qui pose problème. En effet, je ne prendrai jamais le risque de rendre mes sites inaccessibles à cause d'une erreur de manipulation d'administration système (l'erreur est humaine et fréquente). Mais je prends les remarques de cet article avec des pincettes vu les points précédents…
[^] # Re: Let’s Encrypt
Posté par gouttegd . Évalué à 6. Dernière modification le 04 janvier 2016 à 21:32.
Rien à redire là-dessus, je n’ai rien contre des certificats à validité courte. Au contraire, je préfère une réduction de leur période de validité plutôt qu’une augmentation de la taille des clefs.
Non, HPKP prévoit bel et bien le remplacement de certificat. C’est pour ça qu’il est obligatoire d’épingler (au moins) deux clefs dans l’en-tête HPKP, dont une qui ne doit pas être actuellement utilisée. Ça permet les rotations de clefs.
Il est parfaitement possible d’automatiser tout cela, mais les clients de Let’s Encrypt ne le font pas, et c’est bien là le problème. Seuls les « geeks maîtrisant X.509 et assimilés » seront en mesure de le faire eux-même, alors que Let’s Encrypt se targue de mettre le chiffrement à la portée de tous les administrateurs en herbe.
Publier des en-têtes HSTS et/ou HPKP est effectivement un risque (avec ou sans Let’s Encrypt) : ces en-têtes interdisent aux navigateurs de passer outre les erreurs de sécurité. Il ne faut les publier que si l’on est sûr que sa configuration est correcte (et correcte non seulement aujourd’hui, mais dans le futur).
[^] # Re: Let’s Encrypt
Posté par gouttegd . Évalué à 4.
Pour être honnête, la faute n’incombe pas qu’à Let’s Encrypt. HPKP est encore récent et il n’existe pas, à ma connaissance, d’outils pré-existant pour gérer ça de manière automatisée (à la manière de OpenDNSSEC pour gérer les clefs DNSSEC).
Je prédis que HPKP ne connaîtra pas un grand déploiement tant que de tels outils n’existeront pas, et on ne peut pas mettre ça sur le dos de Let’s Encrypt (même si eux seraient sans doute bien placés pour créer les outils en questions).
[^] # Re: Let’s Encrypt
Posté par Régis . Évalué à 2.
HSTS n'est pas dangereux du moment que nous sommes certain que le site sera dorénavant toujours en HTTPS.
En revanche si on veut faire marche arrière ce n'est pas possible pendant la durée de vie de l'entête HSTS.
HPKP pour moi est un vrai risque car il faut faire le pari que ton visiteur va revenir dans le laps de temps qui lui est imparti. D'ou le danger d'avoir un certificat qui a une durée de vie courte.
Je pense que l'idéal serait que DANE TLSA soit implémenté et que DNSSEC soit massivement adopté ce qui est loin d'être gagné avant plusieurs années à moins que les navigateurs décident d'implémenter leur propre résolveur (Ce qui n'est pas de leur ressort à la base).
Je suis d'accord avec Gouttegd, vu que Let's Encrypt est opensource, je ne doute pas que des outils vont venir se greffer autour de cette écosystème afin qu'il s'étoffe.
[^] # Re: Let’s Encrypt
Posté par gouttegd . Évalué à 5.
Si, le risque c’est que la moindre erreur de configuration rende le site inaccessible, parce que le navigateur n’aura pas le droit de passer outre.
Typiquement, un administrateur oublie de renouveller son certificat et le laisse expirer (un des écueils que Let’s Encrypt cherche à éviter en automatisant le plus possible, justement parce qu’on a constaté que ce genre de choses arrivaient trop souvent dans la réalité) :
Sans HSTS, ce n’est pas trop grave, le navigateur va afficher un message d’erreur mais va laisser à l’utilisateur la possibilité de passer outre (« il y a un problème avec le certificat de ce site. Voulez-vous continuer ? » — ce à quoi l’utilisateur répond « un problème avec quoi ? Évidemment que je veux continuer, je veux continuer ma visite moi. »).
Avec HSTS et si l’utilisateur a déjà visité le site préalablement, c’est mort, le navigateur qui respecte le RFC 6797 doit avorter la connexion.
C’est justement le but recherché de HSTS, qui signifie en gros « l’administrateur de ce site ne fait pas d’erreurs, si votre navigateur détecte un problème, c’est qu’il y a réellement quelque chose de louche, ce n’est pas un truc que vous pouvez ignorer en mettant ça sur le compte du laxisme de l’administrateur ».
D’où l’importance de n’utiliser HSTS que si l’on ne fait réellement pas d’erreur…
Ce n’est pas un problème, ça. Si le visiteur revient après la durée d’épinglage, on se replace juste dans le cas initial d’une première connexion. Ça n’interdit pas l’accès au site, c’est juste qu’on n’a pas, pour cette « première » connexion, la protection apportée par HPKP.
Pour info, HSTS a un comportement similaire : lui aussi a une directive "max-age" au-delà de laquelle le navigateur ne doit plus considérer que le site doit être accédé en HTTPS uniquement.
Je préférerais que les systèmes d’exploitations fournissent par défaut un résolveur DNS validant (que non seulement les navigateurs mais aussi toutes les autres applications pourront utiliser) plutôt qu’un « stub resolver ». À ma connaissance, aucun système ne fait ça à l’heure actuelle, celui qui veut un résolveur validant doit l’installer lui-même.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1.
C’est là que HPKP n’est utilisable que si tu cycles tes clefs en cohérence avec ta date de rétention HPKP. Ce qui n’est pas possible avec Let’s Encrypt.
Si tu as mis une période de rétention de X jours, tu ne dois jamais retirer une clef utilisée en même temps que son entrée HPKP, mais toujours laisser passer un temps d’au moins X jours, pour garantir que justement au moment de la rotation de clef soit le visiteur n’aura rien de préchargé soit que son délai de rétention sera expiré soit aura déjà chopé l’ancienne clef.
Le seul risque bordélique étant effectivement une compromission de la clef dans l’intervalle « changement de publication » et « changement de publication + X », d’où l’intérêt d’un X relativement petit mais pas trop (60j recommandé) mais aussi d’un faible taux de renouvellement de la clef.
Si tu désynchronises en plus le changement de clef et ta période de rétention, c’est là que tu vas avoir de sérieux problèmes effectivement…
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1.
Il n’y a pas de certificats « faibles » ou « forts ». Un certificat est binaire : il est légitime ou il ne l’est pas.
Renouveler fréquemment un certificat n’a pas d’intérêt en soi pour améliorer ta sécurité (ou alors je veux bien un pointeur vers un papier de recherche).
Si tu as trouvé le moyen de générer un certificat pour gmail.com, soit la CA s’aperçoit du trou de sécu utilisé, ferme ce trou (ce qui t’empéchera de recommencer) et révoque le certificat immédiatement (ce qui t’empéchera de l’utiliser), soit elle ne s’en aperçoit pas (et ne pourra alors ni t’empécher de l’utiliser ni de recommencer à en générer un tous les 90j).
Intérêt du renouvellement court ici ? Aucun.
Même dans le cas des certificats « faibles », comme par exemple avec le cas de SHA-1 actuel, un tel changement de norme se prépare des années à l’avance, et même malgré ça personne ne veut bouger.
Renouveler les certificats tous les 90j n’aidera pas à aller plus vite, la transition s’effectuera de toute façon toujours du côté de la CA qui n’émettra plus de l’ancien type de certificat à partir de la date décidée.
Le seul impact positif d’un renouvellement court étant qu’on se retrouve alors avec une période de transition plus courte (90j au lieu d’un an), mais c’est négligeable par rapport à la durée globale d’une telle transition (SHA-1 sunset, ça date de octobre 2014 et ça demande déjà une prolongation pour 2016…)
[^] # Re: Let’s Encrypt
Posté par gouttegd . Évalué à 5.
Ça c’est si les mécanismes de révocation fonctionnaient correctement, ce qui n’est pas le cas.
Les CRLs n’ont jamais vraiment fonctionné, et Chrome et Firefox ne les utilisent même plus.
OCSP pose au moins autant de problèmes qu’il n’en résoud (dont un joli problème de vie privée, en révélant à la CA toute connexion aux sites dont elle a signé le certificat), est souvent désactivé par défaut (notamment sur Chrome), et quand il est activé c’est toujours en mode soft-fail, de sorte qu’il suffit de bloquer la requête (ou la réponse) OCSP pour passer outre la vérification (et si on passe en mode hard-fail c’est encore plus drôle, on peut faire un déni de service sur le site visé en attaquant le serveur OCSP de sa CA).
Reste l’OCSP Stapling (j’aimerais bien des stats sur son utilisation), et les « CRLsets » de Chrome qui ne sauraient être applicables à une grande échelle.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 1.
Pas compris le lien que tu mets pour "personne ne veut bouger".
Twitter, Facebook, CloudFlare sont tous en SHA256 si ton navigateur le supporte. Avec TLS donc impossible de "forcer" à passer en SHA1 (ou corrigez-moi si je me trompe).
Ton lien arrive à la même conclusion que toi, mais en disant que ça n'enlève en fait pas de sécurité pour ceux en SHA256 tout en supportant ceux ne pouvant pas faire de SHA256 (sécurité moindre, mais mieux que pas de sécurité surtout que SHA1 n'est pas cassable en 3 secondes, faut que la personne ayant un un vieux WinXP par exemple soit intéressante pour y mettre quelques moyens)
Donc au final, ils se bougent, juste qu'ils ne sont pas d'accord pour dire "va ta faire foutre" juste parce qu'il y a une faiblesse (et pas un énorme trou béant disponible pour les script kiddies non plus) avec un algo alors que les "à jour" peuvent choisir SHA256.
Alors avant de dire "personne ne veut bouger", explique-moi en quoi supporter SHA1 pour les vieux bousins enlève de la sécurité à ceux utilisant SHA256.
Note : de la même façon, Microsoft dit "pour les OS supportant SHA256, on refusera les signatures que SHA1" et en même temps "Signez SHA1 et SHA256 comme ça les vieux bousins continueront à fonctionner tout en donnant plus de sécu aux nouveaux OS" et je ne vois pas en quoi "interdire" SHA1 apporterai plus de sécurité aux nouveaux OS (et pour les anciens, ben c'est ancien, et ils vivent avec moins de sécurité, voila tout, de toutes façon ces personnes avec de vieux bousins ne sont pas les plus intéressantes, vous imaginez vraiment Snowden avec un WinXP…)
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 4.
C’est justement là que tu te trompes. Une clef n’a pas d’existence propre, ce n’est pas parce que tu as détruit son fichier que ses effets ne peuvent pas continuer à se faire ressentir.
Dans le cas de HTTPS, si la suite de chiffrement négociée n’est pas une suite PFS (Perfect Forward Secrecy), alors la NSA ou toute autre entité du genre peut se contenter de collecter de manière passive l’ensemble de tes communications actuelles, puis espérer a posteriori (d’ici 2030 donc) déchiffrer l’intégralité de l’échange réalisé.
La durée de vie de la clef privée (le fichier au sens informatique du terme) n’a que peu d’importance par rapport à la durée de rétention possible des données échangées chiffrées avec elles (qui elles ne peuvent ni expirées ni être révoquées, cause collecte passive possible).
C’est encore plus visible avec le cas de GPG, où même une fois que ta clef a expiré ou qu’elle est révoquée, tu dois quand même la conserver à vie et protéger l’ensemble des mails envoyés avec cette clef (aussi à vie et ton correspondant de même).
Si demain l’avancée techno permet de casser du 2048 bits, alors c’est l’ensemble des mails que j’ai pu échanger avec ma vieille clef GPG de 2048 bits pourtant déjà actuellement et expirée et révoquée qui se retrouve dorénavant en clair dans la nature.
Même dans le cas de PFS, sauf dans les versions très récentes des serveurs web, les paramètres DH négociés sont calqués sur la taille de la clef privée. Donc une clef de 2048 bits donnera des paramètres DH de 2048 bits, donc fragiles par rapport à LogJam et soumis aux mêmes problèmes de cassage a posteriori (avec certes une puissance de calcul nécessaire plus importante puisqu’il faut casser chaque message indépendamment, ce qui n’est pas le cas des suites non PFS vu que le cassage de la clef permet le déchiffrement instantané de toutes les communications pour un coût nul)
Une clef de 2048 bits impose donc que tout le contenu échangé à cet instant même, avec ou sans PFS, ne possède plus aucune signification utile d’ici à 2030, ce qui est relativement encore trop « demain ». Ceci que ta clef soit regénérée toutes les 10min ou tous les 15 ans. Avec un renew à 90j, ça ne complexifiera la tache d’une écoute passif que d’un facteur 60 (60 générations de clefs de 90j = 15 ans).
Une clef de 4096 bits laisse quelques décennies supplémentaires de sécurité.
Et d’ajouter juste en dessous en recommandation qu’il faut déjà dès maintenant envisager l’usage de 3072 bits, même pour des communications n’allant pas jusqu’à 2030.
[^] # Re: Let’s Encrypt
Posté par gouttegd . Évalué à 3.
J’ai délibérément négligé ce cas-là, en effet, parce qu’à part pour supporter de très vieux navigateurs je ne vois guère de raison de continuer à offrir des suites de chiffrement sans confidentialité persistante.
Toujours pas d’accord sur le caractère fragile. Le vrai problème de LogJam n’est même pas que les serveurs utilisaient des paramètres DH de 1024 bits (même si 1024 bits est en effet un peu trop faible pour être à l’aise), mais surtout que la plupart des serveurs ont utilisé pendant des années (jusqu’à la révélation de l’attaque en fait) les mêmes paramètres DH pour tout le monde (ceux proposés par le RFC 2409), offrant ainsi à énorme jackpot aux grandes oreilles : il leur suffisait de casser un seul groupe DH pour être en mesure de déchiffrer les communications de n’importe quel serveur.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1.
Pas d’accord non plus. La réutilisation des DH n’a fait qu’empirer la criticité de LogJam, même sur des paramètres frais, on est faillible.
La factorisation reste « rapide et peu onéreuse », à cause de l’algo de « field sieving » qui peut précalculer une bonne partie de son calcul (actuellement « seulement » 1 an de calcul par p de 1024 bits puis 30 jours pour chaque DH basé sur ce p).
Voir à ce sujet la conférence du 32c3 Logjam: Diffie-Hellman, discrete logs, the NSA, and you.
[^] # Re: Let’s Encrypt
Posté par Bisaloo . Évalué à 2.
Du coup, tu es d'accord pour dire que le problème, c'est principalement l'adoption de suites PFS plus que la taille de la clé.
Et comme tu le dis toi-même, la majorité des sites supporte déjà PFS.
Ensuite, je suis pas chercheur en crypto mais je suis pas hyper convaincu par ton paragraphe sur logjam. Les chercheurs à l'origine de la découverte demandent d'abandonner les clés de 1024 bits par sécurité parce qu'il se peut que des agences à 3 lettres puissent les casser :
(https://weakdh.org/)
(https://www.eff.org/deeplinks/2015/05/logjam-internet-breaks-again)
Et encore… comme c'est marqué clairement dans le post de l'EFF, on parle là des groupes de DH par défaut, pour lesquels on peut faire une precomputation.
Après, toutes les suites PFS ne sont pas sensibles à logjam, il semble que les suites ECDH soient encore sûres.
Pour finir, si on croit le site d'openssl, il faut 100,000 heures-coeurs pour casser du 512 bits. En admettant que les certificats de let's encrypt de 2048 bits ne tiennent pas 90 jours parce que tu es confronté à un attaquant très motivé, il ne pourra tout de même casser la crypto qu'au bout d'un temps proche de l'expiration.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 05 janvier 2016 à 08:20.
Corrigez si je me trompes, la taille de la clé est indépendante de PFS.
Pour gérer les vieux bousins, on doit continuer avec des suites de chiffrement non PFS.
Donc on doit mettre du 4096 pour eux.
Et sauf si j'ai loupé un épisode, on ne peut pas dire "si PFS, tiens du 2048, sinon tiens du 4096", du coup c'est 4096 pour tous (ou 3072 si on veut rester dans les recommandations précises).
Je ne comprend pas cette phrase : on se fout de la date d'expiration, car on peut dumper et donc garder le contenu pendant 1000 ans si on veut.
Et tout le monde de fait pas du 90 jours.
Finalement, à moins que je ne vous comprenne pas bien, vous dit que 2048 ça va tout en donnant des arguments sur le fait que ça ne va pas tant que ça…
Vivement qu'on puisse passer à ECDSA (le temps que tout le monde le supporte si on veut reste le plus large possible, il y en a encore pour un moment…), mais on se battera sans doute sur 128 vs 256 vs 521 :-D
[^] # Re: Let’s Encrypt
Posté par gouttegd . Évalué à 2. Dernière modification le 05 janvier 2016 à 08:45.
Tu retardes, le futur n’est plus dans la cryptographie à base de courbes elliptiques, mais dans la cryptographie post-quantique.
La NSA (qui a longtemps été une des principales forces poussant à l’utilisation de la cryptographie ECC via sa « Suite B ») a annoncé l’année dernière qu’elle n’y croyait plus :
(Tout le monde est invité à se joindre aux spéculations sur les vraies motivations de la NSA, plus on est de fous…)
En attendant, ceux qui redoutent sérieusement que les agences en trois lettres puissent casser leurs clefs RSA et/ou leurs groupes DH de 2048 bits devraient, pour être cohérent (hé, il y a un risque que la NSA ait un ordinateur quantique d’ici 2030), se mettre tout de suite à utiliser du McEliece ou assimilé. Des clefs de plusieurs mégaoctets, voilà qui devrait les satisfaire.
[^] # Re: Let’s Encrypt
Posté par Bisaloo . Évalué à 3.
Oui, c'est indépendant. Mais on parle juste pas de la même chose. Pour moi, le problème est principalement côté serveur (et c'est ce qui nous intéresse quand on parle certificat). Avant de dire aux serveurs de passer à des clés de 4096, on ferait mieux de faire pression pour qu'ils mettent à jour leur logiciel de crypto. C'est déprimant que des navigateurs modernes conservent encore par défaut des techniques obsolètes voire dangereuses juste parce que certains serveurs ne se mettent pas à jour.
Voilà, c'est ma vision des choses. On voit pas la faute du même côté. Si quelqu'un a une page qui récapitule les suites supportées par navigateur et version, ça m'intéresse de voir et éventuellement de revoir mon opinion.
Et sur la suite de ton commentaire, à moins que ce soit moi qui ait mal compris :
Donc tu peux garder tout le contenu que tu veux, si tu as PFS, c'est inutile. Tu ne pourra déchiffrer que les communications postérieures au moment où tu casses la clé. Donc sur un certificat de 90 jours (je maintiens puisque le sujet à la base, c'était Let's Encrypt), t'as intérêt à aller très vite (plus vite que possible ? ) si tu veux que ça serve à quelque chose.
[^] # Re: Let’s Encrypt
Posté par gouttegd . Évalué à 3.
Il y a cette page maintenue par Mozilla, qui sans donner directement la récapitulation que tu cherches, indique les plus vieux navigateurs compatibles avec leurs trois configurations recommandées (« moderne / intermédiaire / vieux »).
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 1.
tu ne réponds toujours pas à la question.
Donc essayons de tourner la question autrement : en quoi conserver de vieilles techniques pour les vieux bousin impacte les gens à jour?
Tant que tu répondras pas à cette question, tu ne pourras pas convaincre que tes idées sont bonnes, car tu proposes des inconvénients (virer les gens pas à jour, comme ça) sans aucun avantage (pas plus de sécurité pour les gens à jour).
Tu n'as pas répondu à la question, donc tu n'as pas donné ta vision.
Je ne vois pas la faute, surtout. Explique!
SSLLabs de mon serveur
Tu verras ceux qui ne supportent pas ECDHE par exemple, ceux qui ont besoin de SHA1 etc.
(et oui, je continue d'avoir du 3DES, parce que je ne vois pas en quoi virer les utilisateurs WinXP qui ne veulent pas changer va changer quoi que ce soit à la sécurité de ceux étant à jour, à ma connaissance il n'est pas possible de forcer les "à jour" à basculer sur 3DES vu que SSLv3 est désactivé, cette désactivation étant elle nécessaire pour que le support des "vieux" n'impacte pas les "nouveaux").
Bref, tu ne donnes pas ta vision, tu ne réponds pas à la question, tu veux "bloquer les vieux" sans expliquer en quoi ça améliore globalement la sécurité.
[^] # Re: Let’s Encrypt
Posté par gouttegd . Évalué à 3.
Ça ouvre la porte à de possibles downgrade attacks, où un client et un serveur qui supporte tous deux une technologie moderne et résistante basculent sans raison sur une techno plus ancienne et potentiellement craquable.
Et il y a aussi le cas des technos tellement anciennes qu’elles ne sont même pas justifiées par le besoin de rester compatible avec les (très) vieux clients, mais que les serveurs supportent toujours simplement parce qu’elles sont activées par défaut et que personne n’a pris la peine de les désactiver. C’est typiquement le cas de toutes les suites EXPORT par exemple. Je pense que c’est surtout à ça que ton interlocuteur faisait référence.
À raison. Il n’y a aucune attaque praticable connue contre 3DES.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 1.
risque contre support large.
Quand SSLv3 a été jugé trop troué, il a été désactivé à ce moment-la (et pas avant).
Quel risque réel de downgrade avec TLS 1.0?
ça c'est une autre histoire, mais pareil pourquoi désactiver alors que c'est peut-être le seul moyen et qu'il vaut mieux un peu de sécu que pas du tout? Note : je ne sais pas comment sont affichés ces sites (il en existe encore?), pas avec un cadenas barré?
Peut-être.
Mais dans le lien donné par un autre, il y a une accusation de "ils ne bougent pas, ils vont contre la sécurité" pour des sites qui sont en A+ chez SSLLabs. Alors désolé, mais la c'est un peu gros et presque mensonger de dire que ces sites ne s'occupent pas de la sécurité juste parce qu'on n'est pas d'accord avec leurs choix.
Je pensais donc à ce genre de critique. Il faudrait donc préciser quelle niveau de suppression est souhaité.
Alors je vais dire que je continue d'avoir du SHA1 dans les suites de chiffrement, et SHA1 c'est troué :).
[^] # Re: Let’s Encrypt
Posté par gouttegd . Évalué à 3.
Pas d’accord. La désactivation massive de SSL 3.0 date d’il y a quelques mois (c’est POODLE qui a donné le coup de pied au cul nécessaire), et ça fait bien plus longtemps que ça qu’on savait que SSL 3.0 avait trop de failles.
Firefox et Chrome ont désactivé SSL 3.0 après POODLE non pas parce que c’était la faille de trop, mais parce que c’est avec cette faille qu’ils se sont rendus compte qu’il y avait encore trop de serveurs dans la nature qui offraient sans sourciller du SSL 3.0.
Faible a priori si client et serveur supportent le mécanisme anti-repli (mécanisme qui au passage n’aurait jamais du être nécessaire si serveurs et clients avaient respecté le protocole TLS, au lieu d’adopter le comportement du « ça passe pas en TLS n alors je me fous de la sécurité et je tente en TLS n−1, ah ben là ça passe c’est donc bien que ça devait être une erreur et pas une tentative d’attaque », mais c’est une autre histoire). Après, on n’est jamais à l’abri d’une erreur dans une implémentation (erreur à laquelle tu fermes complètement la porte en ne supportant pas le protocole plus faible en premier lieu).
Note, je ne suis pas en train de dire de ne pas supporter TLS 1.0 (même si idéalement il faudrait). Comme indiqué sur la page du wiki de Mozilla que j’ai cité par ailleurs, c’est à évaluer en fonction du public attendu.
J’aimerais vraiment que tu me trouves un client encore en service (même avec 0.00009% de part de marché) qui ne supporte rien de mieux que les suites EXPORT.
Et contrairement à d’autres technos déjà déconseillées mais contre lesquelles les attaques relèvent encore aujourd’hui de la spéculation (SHA-1 par exemple, on soupçonne fortement que créer des collisions est à la portée d’un adversaire de niveau étatique mais ça n’a pas encore été fait — de même que casser du RSA 1024 bits), il existe des attaques complètement réalistes (et à la portée de quiconque a un peu d’argent à dépenser sur Amazon EC2) contre les suites EXPORT.
Je n’ai pas d’objection à ce qu’on continue à supporter une technologie obsolète après avoir pesé les avantages et les inconvénients, si on estime qu’on peut encore avoir des clients qui en ont besoin.
Le problème, c’est de continuer à supporter une technologie obsolète sans avoir fait cette analyse, juste parce que cette technologie est activée par défaut. Il est à peu près certains que la plupart des administrateurs de sites web ne savaient même pas que leur logiciel serveur offrait par défaut des suites EXPORT (full disclosure : je ne le savais pas non plus).
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 0.
Donc la sécurité reste mieux que rien.
donc ça ne me choque pas. Comme tu dis, il faut peser. Et pas dire bourrinement "SHA1 ça craint donc c'est horrible que Facebook continue à l'accepter".
EXPORT est une autre histoire, je ne dis pas qu'il faut rien faire, mais peut-être qu'un avertissement (cadenas rouge) est suffisant plutôt que désactiver, si encore un peu d’utilisateurs (sinon désactivé, oui).
Juste que quand je lis que c'est "contre la sécu" de garder TLS1.0/SHA1, hum hum… Encore 5% de gens comme ça, ce n'est pas 0.0005%.
Bouh pas bien.
Mais oui, pas bien que la config par défaut soit encore avec EXPORT, je n'ai pas dit le contraire, ça devrait être "si l'admin sait qu'il en a besoin" depuis un certain temps.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 3.
TLS_FALLBACK_SCSV ne prévient que d’un downgrade protocolaire (TLSn vers TLSn-1 ou SSL), pas d’un downgrade chiffrement (disparition de AES pour ne laisser que 3DES ou RC4 en chiffrement supporté par exemple).
Tu peux même downgrade en DHE_EXPORT alors que le client ne le supporte même pas !
Voire Diffie-Hellman, discrete logs, the NSA, and you, page 41
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 05 janvier 2016 à 12:04.
La ligne TLS_FALLBACK_SCSV était de trop.
Ca ne change pas le reste de la demande (je n'ai pas eu de lecture sur un downgrade des suites de chiffrement, bon il y a ton lien mais j'aimerai plus : est-ce qu'il y a une proof of concept qui montre un downgrade de suite de chiffrement, je sais que je peux voir la suite choisie par le navigateur, donc je peux installer un MITM et voir quelle suite est alors choisie, donc si c'est possible si facilement que je comprend dans le lien j'imagine que ce genre de démo est disponible; bref je note le lien mais demande un peu plus de démo car je comprend l'explication comme la possibilité pour n'importe qui de passer en RSA sans PFS et SHA1 super facilement pour n'importe site vu qu'on veut encore garder ça pour les "vieux")
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 4. Dernière modification le 05 janvier 2016 à 14:08.
Oui, c’est même là-dessus qu’est basé la faille FREAK.
Les outils pour ce MitM sont dispos ici.
À l’heure actuelle, c’est uniquement le downgrade vers *-EXPORT qui est utilisé, vu que c’est uniquement les tailles de clefs très faibles associées qui permettent la 2nde partie de l’attaque (le cassage de la clef en temps réel).
On peut par contre imaginer le même principe utilisé à l’échelle de la NSA, capable de casser RC4 en temps réel.
Et ça devrait bientôt être le cas de 3DES qui n’a que 112 bits de sécurité théorique (et encore moins en pratique puisqu’il n’utilise que des tailles de blocs de 64 bits) et donc déjà largement dans la zone jaune du « ça commence à puer franchement les gars ».
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 3.
Totalement faux. Si tu supportes 3DES côté serveur, qui existe aussi pour TLS, alors un attaquant peut forcer TOUS tes utilisateurs (même ceux les plus à jour vu que Firefox supporte toujours 3DES actuellement) à utiliser 3DES au lieu de AES.
Le fait d’avoir activé 3DES pour supporter les vieux nav’ qui ne supportent que 3DES baisse la sécurité de tous les autres clients qui supportent entre autre 3DES.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 05 janvier 2016 à 11:48.
Reference needed (avec une démo de préférence).
Ce que j'ai compris est que les downgrades ne sont pas possible avec TLS (un avantage par rapport à SSLv3?), du coup j'ai énormément de mal à croire ce commentaire sur parole.
(autant pour 3DES que pour SHA1)
SSLLabs file un A+ pour des serveurs proposant 3DES malgré le fait que 3DES est 112 bits et que A+ est donné pour du 128 bits ou plus (si j'ai bien suivi).
Et SSLLabs dit "This server supports TLS_FALLBACK_SCSV to prevent protocol downgrade attacks."
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 5. Dernière modification le 05 janvier 2016 à 11:56.
Les suites de chiffrement supportées et celle choisie ne sont signées ni du client ni du serveur et peuvent donc être modifiées.
p41
Il faudra attendre TLSv1.3 pour avoir l’authentification forte du handshake et empécher les downgrades (protocolaires et chiffrement).
"This server supports TLS_FALLBACK_SCSV to prevent protocol downgrade attacks."
Protocole, pas chiffrement :)
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 05 janvier 2016 à 14:13.
A relire la chose après manger, je suis presque convaincu de la faisabilité.
Mais je reste surpris qu'après plus de 20 ans (ou plus) de SSL, personne n'ai imaginé ce genre de scénario, qui fait que le plus petit dénominateur commun peut être utilisé.
Aucun mécanisme de sécurité qui par exemple dit en sécurisé quelle a été la demande (un "écho") ou autre (par le serveur ou le navigateur)? On dépend donc toujours du plus petit dénominateur du serveur gardé pour vieille compatibilité?
Je serai vraiment curieux d'avoir un tel proof of concept en vrai, tellement c'est gros.
(parce que tout le monde n'a pas ssleuth ou calomel pour voir quel suite de chiffrement a été pris et réagir en sachant le niveau de sécurité…)
Edit : la réponse est arrivée pendant que j'écrivais, merci. Me voila moins rassuré par rapport au niveau de la sécurité, c'est malin. Parce que du coup ça veut dire qu'on ne peut pas adapter la sécurité suivant l'âge des clients, le plus vieux supporté commande les autres, snif, on ne dirait pas qu'on a plus de 20 ans de sécurité en expérience.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 2. Dernière modification le 05 janvier 2016 à 14:23.
En fait on a un vrai problème avec TLS parce que la dépendance est double :
Du coup, la seule stratégie viable est de migrer serveur et client à la fois, vers les mêmes suites de chiffrement, en même temps. Autant dire que c’est infaisable…
Et qu’on se traîne une longue traîne de trucs totalement moisi, à la fois côté serveur mais aussi côté client. Exposant à des downgrade attack l’ensemble du monde, y compris ceux à jours.
Au motif qu’on ne peut décemment pas mettre à la porte les utilisateurs de Windows XP ou IE 8…
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 1.
On ne peut pas, non, trop de monde encore. Et c'est partie de l'histoire.
Je reste bloqué sur l'idée qu'on n'a pas prévenu dans une connexion sécurisé une altération de la première trame (je sais pas, je suis peut-être complètement à côté de la plaque, mais j'imagine une première réponse avec un hash de la première trame dans une extension "reserved" du protocole ancien, du coup les vieux trucs ne sont pas dérangés et les nouveaux testent le hash, du coup vieux et nouveau sont ensemble), ça m'en bouche un coin (et j'en apprend tous les jours, je vais hésiter sur 3DES… Bon pour le moment c'est toujours pas "cassé", donc gardons, mais pour combien de temps… Surtout que SHA1 semble bien compromis aussi vu comment certains régissent pour le virer si ils peuvent)
Est-ce que je résume bien en disant que PFS c'est cool mais tant que le serveur accepte du non ECDHE (pour par exemple supporter OpenSSL 0.9.8y qui date de… 2014; Ou Java 6, ou Android 2.3, pour ne pas parler d'IE8/WinXP), PFS ne sert à rien si le client ne vérifie pas qu'il est en PFS car le MITM peut forcer à virer le PFS (et SHA1) et les navigateurs ne préviennent pas?
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 2. Dernière modification le 05 janvier 2016 à 14:49.
C’est exactement ça. La sécurité de TLS n’est garantie que si tu ne publies aucune suite faillible côté serveur, sinon un downgrade attack peut forcer le navigateur à utiliser une suite faillible qu’il supporterait lui-aussi.
Avoir du PFS et du non PFS actif côté serveur n’est fiable que si le navigateur en face ne supporte que PFS.
Avoir du PFS et du non PFS actif côté client n’est fiable que si le serveur en face ne supporte que PFS.
Donc avoir PFS et non PFS en même temps, côté client ou serveur, c’est s’exposer soi-même à un downgrade dans le cas du navigateur, et exposer l’ensemble de ses clients supportant uniquement du non PFS ou les 2 dans le cas du serveur.
La seule config qui referme l’ensemble des failles existantes et des downgrade attack possibles est donc : https://tls.imirhil.fr/https/imirhil.fr
Ça met à l’abri toute personne qui supporte TLSv1.2+ECDHE-RSA-AES (ie beaucoup de monde quand même), mais ça empêche toutes les autres d’accéder au site (mais encore trop de monde…)…
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 05 janvier 2016 à 14:59.
C'est en pratique pas gérable (Android 4.3, IE10… Bon OK, ça vient, mais quand même…), juste parce qu'on n'a pas prévu de MITM pour les suites de chiffrement…
Merci pour l'éducation.
PS : par contre, pourquoi bloquer TLS1.0? vu que si j'ai bien compris, il y a la une parade contre le downgrade.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 2. Dernière modification le 05 janvier 2016 à 15:04.
Après, tu peux être un peu moins extrémiste, comme activer TLSv1.0 et TLSv1.1 (faillible à POODLE mais mitigation possible (désactiver Javascript)) ou AES non PFS (faillible au cassage de ta clef dans XX années, mais les données récoltées seront obsolètes pour la plupart).
C’est surtout RC4 (cassé par la NSA en temps réel), 3DES (trop faible et dans la zone rouge), les suites EXPORT et SSLv3 qui sont à désactiver puisque des attaques existent déjà pour eux.
En gros tout ce qui a du rouge ou du noir ici.
Le reste est globalement (gris) à très certainement (vert et bleu) fiable.
[^] # Re: Let’s Encrypt
Posté par X345 . Évalué à 3.
Non. La sécurité de TLS est garantie pour un couple (client,serveur) seulement si l'une des deux conditions est valide:
- Le serveur ne supporte aucune suite TLS faillible
- Le client ne supporte aucune suite TLS faillible
C'est d'ailleurs la propriété ci-dessus que tu décris dans ton exemple avec PFS.
Je suis un peu ce que tu fais, et je sais pas pourquoi tu mets toute la faute sur les opérateurs de serveurs.
Les éditeurs de navigateurs sont au tout aussi responsables. Ça n'a pas de sens de parler de la "sécurité d'un domaine" (au moins en ce qui concerne la configuration des suites TLS), c'est le couple (client,serveur) qui est sécurisé ou qui ne l'est pas. Suivant ta nomenclature faudrait mettre un F à Chrome et Firefox aussi (car ils supportent du 3DES, RC4 et autres suites faillibles).
Après c'est l'éternelle triade confidentialité-intégrité-disponibilité. Difficile d'avoir les trois propriétés en même temps. Un opérateur de serveur peut améliorer la confidentialité et l'intégrité en n'activant que des suites TLS très sures, mais ça se fera au détriment de la disponibilité. Oui une banque française devrait avoir une configuration similaire à ton site (quoiqu'on peut discuter de l'utilité de PFS pour les opérations bancaires mais passons…). Pour un opérateur de service comme Google, ça revient à priver une partie de la planète de TLS.
Bref, pour conclure ça n'a pas de sens de dire que le serveur example.com n'est pas sécurisé car il supporte RC4 ou 3DES. Pour qu'il y ait un problème de sécurité, il faut aussi que le client supporte RC4.
[^] # Re: Let’s Encrypt
Posté par kantien . Évalué à 1.
Il me semble que c'est justement ce qu'il explique dans l'ensemble de son message. Du moins, c'est ce que j'en ai compris.
La partie que tu cites s'adressait peut être à zenitram, suite à la question qu'il avait posée précédemment. Je ne pense pas qu'il mettait toute la faute sur le serveur.
Zenitram a chiffré récemment son site, s'il ne supporte que du TLs non faillible alors il perd en disponibilité (comme tu le soulignes) : ce n'est pas envisageable pour lui. Je pense que c'est pour cela que le début de la réponse de Aeris se concentrait sur le côté serveur.
Et le problème est symétrique du côté des développeurs de navigateurs, ce qu'Aeris a expliqué dans ce commentaire.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 05 janvier 2016 à 21:22.
Euh… Ca doit faire 10 ans que mon site est disponible en https, rien de neuf.
"récemment", j'ai juste fait mumuse avec SSL EV et réordonné les suites de chiffrement (je pensais bêtement que ça améliorerai la sécurité même contre le MITM, bon ça ne fait que, mais c'est déjà pas mal, améliorer la sécurité contre les scans)
La sécu m’intéresse et j'ai donc mis du SSL tôt tout comme tout est en SSL quand je peux (IMAPS, SMTPS, HTTPS Everywhere, ssleuth, Calomel…), mais de toutes évidence j'ai encore à apprendre :).
En effet, il y a une différence entre faire mumuse en prod' et perdre des gens (bon, pas foule en HTTPS, mais sur le principe…)
le TLS non faillible sera pour la partie admin (la, je connais mais "utilisateurs" et leur botterai les fesses si ils n'ont pas un navigateur correct)
[^] # Re: Let’s Encrypt
Posté par kantien . Évalué à 1.
J'avais pas tout suivi à l'histoire.
Apparemment c'est là que se situe le désaccord avec Aries, sur qui doit enclencher le processus : les clients ou les serveurs. Mais j'ai du mal avec sa solution qui consiste à dire que ça doit venir des serveurs quitte à perdre des clients. Ça dépend tout de même du service que l'on rend, et je ne suis pas étonné que des entreprise comme facebook ou google aient décidé de ne pas se priver de clients.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 2. Dernière modification le 06 janvier 2016 à 01:06.
Au détriment de l’ensemble des autres utilisateurs de leur service, qui auraient peut-être aimé être en sécurité avec un navigateur à jour, eux…
Ce qui n’incite pas les nav’ a arrêter le support de RC4 et de 3DES…
Et toi, quand tu visites Facebook ou Google, tu es peut-être en train de te prendre un downgrade attack vers RC4 sans le voir, et donc tu es en train de tout balancer à la NSA, en clair, malgré ton GNU/Linux totalement à jour et ton navigateur dernier cri…
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 4.
Si le navigateur est à jour, point de problème : SSLv3 et RC4 sont désactivé (reste donc 3DES, pas connu pour être cassé, donc clients et serveurs à jour le gardent…)
Pourquoi?
Tiens, d'ailleurs, les nav' ont arrêté le support de RC4 (reste donc 3DES, bis…), donc…
Et il faut me dire en quoi un serveur accepte RC4 a la moindre non incitation sur les navigateurs, désolé mais je ne comprend pas le lien de cause à effet, qui peut le plus peut le moins, un serveur qui a RC4 (et autre chose, évidement) ou pas ne change rien du tout sur le support de RC4 par le navigateur (pas de lien! Ou démontre-le).
autant je te suis sur la partie technique, autant sur la partie philosophique j'ai beaucoup plus de mal (même je vois que ça ne le fait pas du tout), je ne suis pas convaincu par les argument sortant du ex-aequo pour les clients vs serveurs : le deux ont les mêmes possibilités de refuser une connexion non fiable.
Désolé, mais ne pas être d'accord avec toi sur une question philosophique ne veut pas dire qu'ils sont mauvais, tu as peut-être juste pas les mêmes priorités ni les mêmes réponse à une question sans réponse évidente.
Et perso, je comprend (comprendre != militer pour) l'argument qu'il vaut mieux un peu de sécurité contre les "petits cons" (pas capables de casser RC4, pas capable de faire du MITM, non tout le monde n'a pas les moyens de la NSA) que faire uniquement comme toi à leur interdire un peu de sécurité pour avoir (peut-être) plus de sécurité pour les autres.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1.
Le blem est là : beaucoup de solutions utilisées ne supportent pas mieux que RC4 ou 3DES.
Le site des impôts par exemple ?
Non, les clients doivent être compatibles avec le maximum de serveur, donc accepter plusieurs choses (a minima AES, RSA, DHE, ECHDE, SHA-1, SHA-2, TLSv1.0, TLSv1.1, TLSv1.2, actuellement aussi 3DES et RC4) et s’exposer alors toujours à un downgrade attack, alors que le serveur peut élaguer plus fortement ses suites et n’en supporter qu’une ou 2 (par exemple TLSv1.2 + ECHDE + AES only) sans perdre tant que ça d’utilisateurs (aller, à la louche moins de 1%), mettant à l’abri ses propres utilisateurs.
Dis autrement, il est aujourd’hui impossible d’avoir un navigateur TLSv1.2 + ECHDE + AES only sans se mettre à dos les ¾ de la planète et sans solution d’upgrade possible sur pas mal de serveurs (TLS hardware), alors qu’il est possible d’avoir un serveur TLSv1.2 + ECHDE + AES only sans trop galérer et en proposant une piste de mise-à-jur aux clients rejetés.
L’évolution doit/peut donc venir uniquement des serveurs, non des clients.
Les clients suivront après, une fois que la majorité des serveurs supportera autre chose que du faillible.
[^] # Re: Let’s Encrypt
Posté par X345 . Évalué à 3.
Bon, on est d'accord sur les faits techniques, mais pas sur les stratégies à adopter.
Mais non ! RC4 est désactivé dans les navigateurs récents. Je te rapelle qu'académiquement, RC4 (sur TLS) vient juste d'être cassé. Donc y'a pas de retard sur ce coup là. Le prochain à être viré des navigateurs est surement 3DES. Pour ma part, j'ai aussi désactivé 3DES dans mon navigateur et c'est rare que je tombe sur un site qui le demande (ça m'est tout de même arrivé deux ou trois fois). Je rapelle aussi que 3DES est pas complètement cassé aujourd'hui. Certes, c'est faible (Qualys le classe en WEAK), mais pas cassé comme RC4 (Qualys le classe en INSECURE).
Encore une fois pour une entreprise, perdre 1-5% de ses clients (voir 10-20%, dans d'autres pays que la France), c'est pas forcément une solution acceptable. Tout ça pour un risque de sécurité plutôt théorique (3DES est pas pété, AES sans PFS encore moins etc.)
Encore une fois, c'est un peu excessif. Avec une telle config., tu peux aller sur les GAFA, linuxfr.org, laposte.fr, Twitter, les sites du crédit agricole, Wikipedia… Je pourrais de retorquer que tu te mets à dos pas tant de sites que ça (aller, à la louche moins de 1%).
Encore une fois, tout ça est une question de compromis. Une boite (ou un site) a pas forcément envie de perdre même 1% de ses clients.
Quant au site des impôts, il devrait effectivement au moins supporter de l'AES. Si on suit la discussion que tu as eu sur Twitter avec @stephane_vesper , on voit qu'ils l'avaient désactivé à la suite des attaques CRIME et BEAST sur AES-CBC. Encore une fois en 2013 (y'a pas si longtemps hein), utiliser RC4 était la config. recommandée:
« RC4 has long been considered problematic, but until very recently there was no known way to exploit the weaknesses. After the BEAST attack was disclosed in 2011, we—grudgingly—started using RC4 in order to avoid the vulnerable CBC suites in TLS 1.0 and earlier. This caused the usage of RC4 to increase, and some say that it now accounts for about 50% of all TLS traffic » Qualys.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 06 janvier 2016 à 13:54.
On va reformuler alors :P
Dans le monde idéal des bisounours, clients et serveurs n’auraient que des suites fiables et corrigeraient immédiatement, l’ordre client ou serveur en premier n’aurait que peu d’importance.
Dans le monde idéal en pratique, il faudrait faire un choix de qui migre en premier.
Si ce sont les serveurs, on pète la compat’ avec les clients le temps pour les client de migrer.
Si ce sont les clients, on pète la compat’ avec les serveurs le temps pour les serveurs de migrer.
Mais la situation ne serait que temporaire dans les 2 cas, et la migration conduirait rapidement à avoir tout le monde à l’abri.
Ici encore, l’ordre n’aurait que peu d’importance.
Dans le monde réel, les serveurs sont migrables très difficilement, voire pas migrables du tout (serveurs old-old-old-school dépendant de vieux OS ou d’applis métiers), alors qu’à l’inverse les clients ne dépendent de rien et n’impactent pas grand chose (appli généralement isolée et indépendante de l’OS).
Alors qu’on peut envisager un monde (certainement utopiste) avec des navigateurs à jour partout (il suffit au pire de mettre une version portable de Firefox partout y compris sur Android 2.3 ou Windows XP), on n’a pas de plan d’action (ou en tout cas bien plus utopiste) permettant un monde avec des serveurs à jour partout.
On pose donc le 1er invariant : il y aura toujours des serveurs moisis dans la nature. (À noter que je ne fais aucun postulat sur l’état des navigateurs.)
De là, on en déduit que pour des raisons de compatibilité, les clients nécessiteront de supporter des suites faillibles. On a actuellement toujours plus ou moins réussi à sauver les meubles en désactivant au fur et à mesure les suites foireuses dans les clients, mais on voit bien que c’est de plus en plus difficile sans casser massivement la compat’ ou en demandant des breaking changes côté serveur.
On a donc notre 1ère règle qui s’en déduit : les clients doivent (MUST) supporter en même temps des suites faillibles et des suites sécurisées. À l’extrême limite, ils doivent (MUST) même obligatoirement supporter ALL:COMPLEMENTOFALL.
Qui dit suite faillible et suite sécurisée mixées dit downgrade attack possible vers la suite faillible.
On en déduit donc notre 2nd règle : les serveurs ne doivent (SHOULD) supporter que des suites sécurisés pour éviter tout fallback, les clients en face allant possiblement supporter des choses non sécurisées pour compat’ avec d’autres serveurs que nous.
Et on en déduit alors l’état du monde :
Si tu me trouves une situation plus optimale, je suis preneur.
On est entré dans une spirale infernale parce qu’on a voulu faire de la sécu par les 2 bouts (client et serveur), à la fois serveur et client, et qu’on se prend du coup le problème de compatibilité de plein fouet.
Il faut forcément couper un des 2 bouts (client ou serveur) pour mettre fin à la boucle et permettre une mise-à-jour de sécu sans se préoccuper de la compatibilité.
Étant donné qu’on veut de la sécurité, il faut donc couper le problème de la compatibilité, qui ne peut se régler qu’à gros coup de ALL:COMPLEMENTOFALL sur les clients.
Et à la limite revoir la notion de ALL:COMPLEMENTOFALL de temps en temps pour virer définitivement tout ce qui n’est plus utilisé du tout ou de manière très marginale.
[^] # Re: Let’s Encrypt
Posté par X345 . Évalué à 3. Dernière modification le 06 janvier 2016 à 15:04.
Bon, va falloir que j'arrive à lacher le troll on sera pas d'accord de toutes façons. Une dernière fois:
Tu donnes l'invariant qui est vrai:
(InvAeris) Il y aura toujours des serveurs moisis dans la nature.
Je donne l'invariant, qui est vrai aussi:
(InvXion345) Il y aura toujours des clients moisis dans la nature (pays émergents etc.)
Avec ces deux invariants, y'a aucune solution satisfaisante:
(Solution 1) Les serveurs n'activent que des suites récentes. Ils privent les clients moisis d'accès HTTPS.
(Solution 2) Le client n'activent que des suites récentes. Ils se privent d'accéder au serveurs mal administrés.
Tu préfères le cas (1) en argumentant que les utilisateurs peuvent toujours mettre à jour (Installer Firefox sous Windows XP, installer un autre navigateur sous Android etc., ne pas utiliser IE8-9). Je préfères le cas (2) en argumentant que les administrateurs de serveurs n'ont qu'à supporter au moins une suite correcte s'ils veulent qu'on s'y connecte (Ces histoires de LB ou SSL hardware ne sont pas convaincantes, si le hardware est ancien/mauvais on peut aussi le remplacer. C'est plus facile pour un opérateur que pour un utilisateur dans un pays pauvre, hein.)
Après oui, dans les deux cas c'est pas terrible.
Encore une fois, la solution est protocolaire (cf. FALLBACK_SCSV, TLS 1.3). Il faut un protocole qui authentifie la liste des suites. C'est devenu nécessaire. C'est pas comme si c'est la troisième fois que je te donnais cette solution…
[^] # Re: Let’s Encrypt
Posté par X345 . Évalué à 5.
D'accord pour la remarque, c'est effectivement ce qu'Aeris explique au global dans cette dicussion Je faisais aussi référence à ce qu'Aeris fait en dehors de la discussion (voir https://tls.imirhil.fr/ ) qui colle une note F à un serveur dès qu'il supporte un protocole ancien (ou des suites) faillibles même si à côté il supporte les protocoles (et suites les plus récentes).
Bon et si tu regardes son message plus bas, c'est pas si clair que ça (Aeris parle de condition nécessaire et suffisante pour le serveur, alors que c'est juste une condition suffisante bref…, je vais y répondre après).
Le problème n'est pas totalement symmétrique. Je pars du principe qu'une partie des utilisateurs ne peut pas mettre à jour: parce qu'ils ont du trop vieux matériel, parce que les logiciels ne sont pas disponibles etc. Tout le monde ne vit pas dans la 5e puissance mondiale avec un accès haut débit et du matos récent, hein. On veut quand même fournir un accès HTTPS (même si dégradé) à ces gens là. Activer uniquement les suites récentes sur un serveur, c'est priver ces utilisateurs de HTTPS. Ça peut vous paraître idiot mais c'est la stratégie choisie par Facebook ou Google.
La solution pour à la fois :
1. Offir un accès HTTPS totalement sécurisé aux gens qui ont un navigateur récent (utilisateurs dit « riches »)
2. Offir un accès HTTPS aux autres (utilisateurs dit « pauvres »)
C'est:
- Les fournisseurs de serveur mettent à jour leurs serveurs, et le configurations pour supporter des protocoles et suites récentes (donc sécurisées)
- Le navigateurs n'ont pas besoin de supporter les suites anciennes (tous les serveurs sont compatibles avec des suites récentes), ils les désactivent dans les nouvelles versions.
En gros ça donnerait ça :
Server: ECDHE-RSA-AES128-GCM-SHA256 [Suite sécurisée] RC4-MD5 [Suite pourrie]
Client « riche » (navigateur récent): ECDHE-RSA-AES128-GCM-SHA256 [Suite sécurisée] la suite pourrie est désactivée
Client « pauvre » (navigateur ancien): RC4-MD5 [Suite pourrie]
Les clients pauvres ont accès en HTTPS dégradé, les clients riches sont totalement sécurisés. Les clients n'ont pas besoin de se priver de serveurs pour être en sécurité, les serveurs n'ont pas besoin de se priver de clients.
C'est ce qui était prévu quand TLS (et SSL) ont été conçus. Le problème c'est que dans l'équation, sont venus se rajouter :
Server mal administré: RC4-MD5 [Suite pourrie]
Du coup, on peut pas désactiver la suite pourrie dans le navigateur récent.
En conclusion, le problème c'est pas les serveurs qui supportent au moins une suite faillible, c'est les serveurs qui ne supportent aucune suite sécurisée. C'est eux qui empêchent la désactivation des suites dans les clients. Et Aeris tape indistinctement sur les deux (note F pour les deux, alors que le deuxième comportement est plus problématique).
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1.
C’est en partie vrai, mais le problème a ensuite bootstrapé tout seul…
Pour gérer les serveurs tout pourris, les clients « riches » se sont mis à supporter RC4-MD5.
Ce qui a conduit à descendre la sécu de tout le monde (downgrade attack possible sur les servers) et à générer un cercle infernal.
Pour rappel quand même, en théorie le problème des clients « riches » vs les clients « pauvres » n’a pas/plus à avoir lieu : l’IETF a tranché et RC4 ne devrait plus jamais pouvoir être utilisé, nul part, ainsi que toutes les suites faillibles :
Si on applique RFC 7525 à la lettre, on trouve une config équivalente à la mienne (TLSv1.2 + ECHDE + AES only) et tous les serveurs du monde devrait être sur cette config (implémentation d’une RFC).
[^] # Re: Let’s Encrypt
Posté par X345 . Évalué à 6.
Oui effectivement, dans la situation actuelle, y'a un problème de cercle vicieux (ou d'interblocage). On peut pas changer les serveurs à cause des client, et on peut pas changer les clients à cause des serveurs…
Ok pour la RFC 7465. Le temps est surement venu d'arrêter d'utiliser RC4 (et 3DES). Je crois que les seuls utilisateurs que ça exclue sont ceux de IE 6, et ça commence à faire vraiment plus grand monde, même dans les pays « pauvres ». C'était déjà un navigateur très ancien y'a 10 ans. Et de toute façons, il ne supporte pas la moitié des sites internet (CSS, JS et compagnie).
Note que l'attaque pratique sur RC4 est assez récente (2015). Y'avait une attaque réalisable en labo depuis quelques années, mais ça nécessitait des millions de handshakes. Du coup, on est pas en retard sur ce coup.
Ça me fait un peu sourire parce qu'au moment des attaques CRIME/BEAST sur AES-CBC, la mode était de configurer son serveur en RC4 only pour les éviter. Comme quoi, faut un peu se méfier de suivre la dernière mode et attendre les RFC, à mon humble avis.
Non, elle ne dit pas ça. Elle dit que les implémentations doivent (must) supporter TLSv1.2 + ECHDE + AES mais ne recommande pas de supporter uniquement TLS v1.2 + ECDHE + AES. Par contre elle interdit (must not) SSLv3, RC4, les ciphers < 112 bits (et tout ça c'est VRAIMENT vieux). Elle deprécie (should not) les ciphers < 128 bits. Elle autorise TLS 1.0, TLS 1.1 et ne dit rien sur les ciphers sans PFS (RSA avec AES CBC etc.).
Bref, la RFC 7525 est assez modérée (elle met bien en balance sécurité-disponibilité) : elle n'exclue que peut d'utilisateurs (y compris en prenant en compte les pays « pauvres »). Supporter uniquement TLSv1.2 + ECHDE + AES c'est pousser clairement le curseur vers la sécurité au détriment de la disponibilité.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 06 janvier 2016 à 00:30.
Oui et non. En labo ça prend des millions de handshakes, mais la NSA a a priori une backdoor dessus car elle le casse en temps réel depuis 2013 : https://twitter.com/ioerror/status/398059565947699200
J’ai bien dit « équivalente » en terme de sécu. Quand tu as viré RC4 et 3DES (112 bits théorique mais certainement plus faible en réalité à cause de sa taille de bloc de 64 bits seulement), y’a plus vraiment de downgrade attack supplémentaire dispo entre ma config et 7525 :P
Sinon la diff PFS/non PFS, mais on sort du cadre des downgrades attacks (clefs incassables suffisamment vite à l’heure actuelle).
[^] # Re: Let’s Encrypt
Posté par gouttegd . Évalué à 3.
Qu’il ne faille plus utiliser RC4, certes. Mais de là à dire qu’il est cassé au point que la NSA le lit en temps réel, soit on me donne des détails soit j’achète pas, désolé.
Surtout quand juste après le même gars dit « Or to put it another way: academics have said RC4 is broken for years. Listen to them. »
Il y a une grosse marge entre « les chercheurs en cryptographie disent que c’est cassé » et « la NSA le casse en temps réel », ce n’est pas simplement « dire la même chose d’une autre façon ». La première phrase est factuelle, la seconde est pure spéculation. Et comme la première est, à elle seule, suffisante pour justifier le retrait de RC4, le recours à la seconde discrédite complètement le propos.
De manière générale, j’accorde peu de crédit aux discours alarmistes du genre « omg on va tous mourir la NSA peut [insérer ici des allégations dignes des Bruce Schneier facts] ».
Ah, et comme on ne parle que de crypto ici, je crois que c’est le bon endroit/moment pour rappeler que la crypto ne vous sauvera pas (version vidéo). Même s’il n’y a pas d’exemples relatifs à TLS, les multiples cas présentés où la cryptographie a été complètement contournée sans jamais être attaquée de front sont très intéressants.
On rapprochera ça des propos de Snowden sur l’efficacité du chiffrement :
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1.
Et effectivement, ce n’est pas dire la même chose du tout dans le cas de RC4.
Les chercheurs en crypto utilisent de la bruteforce ou des astuces mathématiques pour tenter d’accélérer la vitesse de cassage de RC4.
La NSA, elle, a une backdoor (implémentée ou trouvée) directement dans RC4 et le déchiffre donc en temps réel, via leur programme BULLRUN :
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 1.
Virer 3DES? Ca vire le dernier IE sur WinXP, donc des personnes "de pays riches" aussi (beaucoup aiment leur petit XP et gardent le navigateur par défaut).
IE6 est mort, oui, plus personne n'en parle (et avec POODLE, flingue sur la tempe de la chose car pas de support TLS), mais IE8/WinXP ne supporte pas plus que 3DES et lui reste toujours présent (et WinXP de manière générale encore plus, ils pourraient tous passer sur FF/WinXP mais non ils ne le font pas voila)
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 2.
Je retiens de la discussion que la seule solution viable à long terme est d'empécher un downgrade.
tout le reste, c'est gérer ce manque et ca ne terminera jamais (le jour oú SHA256 a un petit problème, rebelote punition pour ceux pouvant évoluer vers SHA3).
[^] # Re: Let’s Encrypt
Posté par X345 . Évalué à 3.
Oui, mille fois oui. On va un peut dans cette direction (RFC 7507), même si rien n'a été encore fait pour les suites.
Je me demande si ce serait utilisable en pratique de signer la liste des suites et des protocoles supportés (de la même manière qu'on signe la clé publique du serveur).
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 06 janvier 2016 à 10:01.
En pratique, ça pose un problème de l’œuf ou de la poule au niveau authentification.
Le serveur et le client pourraient signer leur 1er paquet (contenant les suites supportées) avec leur clef privée, mais vu qu’on est dans le handshake… cette clef n’est pas encore authentifiée !!!!
Pire, dans la très grosse majorité des cas (hors authentification par certificat en fait), la clef du client ne sera jamais authentifiée et sera générée à la volée par ton navigateur…
Pas d’authentification du paquet client de possible donc !
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 1.
question de béotien : qu'est-ce qui bloque dans l'idée que le serveur envoie le hash du premier paquet dans sa réponse une fois que le hadshake est fait, ce qui permet au client de vérifier que son premier paquet n'a pas été altéré?
Pas d'oeuf et de poule dans ce cas (les anciens clients ignorent juste l'extension).
J'avoue ne pas voir ce qui bloque, tout en n'étant pas expert (clairement!)
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1.
En soi rien.
Mais comme tout problème posant des questionnements théoriques (MAC then Encrypt ? Encrypt then MAC ? MAC and Encrypt ?) pas franchement tranchable dans ce cas précis (dans tous les cas on aura ici un bout de traitement sur des données non authentifiées), les débats à l’IETF peuvent être (très) long pour arriver à un pseudo-consensus :P
[^] # Re: Let’s Encrypt
Posté par X345 . Évalué à 3.
Le serveur pourrait signer (il me semble) la liste des suites avec sa clé privée. En utilisant la clé publique du serveur, présente dans le certificat, le client peut vérifier que la liste des suites est bien celle émise par le serveur.
Une approche alternative serait de mettre la liste des suites supportées par le serveur dans le certificat ou alors des flags (SUPPORTS_TLS_12, SUPPORTS_ECDHE). Comme ça le client qui supporte TLS 1.2 et ECDHE pourrait aller vérifier ces flags dans le certificat.
Y'a besoin d'authentifier la liste des suites du client pour assurer la sécurité. L'authentification de l'une des deux listes est suffisante (toujours le même biais de raisonnement, hein).
Cela dit, tout ça est très théorique, je ne suis pas un spécialiste des protocoles, ni de la sécurité informatique.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 2.
Les suites supportées ne peuvent pas être dans le certificat.
C’est de la conf côté serveur, et on ne pourrait pas renouveler le certificat en cas de changement à effectuer…
Ce sont 2 choses bien distinctes (chiffrement et identification) qui ne peuvent pas être mélangées
[^] # Re: Let’s Encrypt
Posté par X345 . Évalué à 2.
Aujourd'hui non évidemment… Sinon on aurait aucun problème de sécurité et serait pas en train de discuter de ce problème !
C'est justement le changement que je propose. Par contre oui, ça impose des contraintes sur le renouvellement de certificat. Sinon y'a aussi la première solution: le serveur signe la liste des suites avec sa clé privée.
Franchement… Je sais plus quoi te dire… Chiffrement et authentification sont utilisés conjointement (dans TLS, dans GPG et dans tout ce que tu veux d'autre). Sans authentification le chiffrement est vulnérable à des attaques actives (MitM).
Aujourd'hui:
- On authentifie la clé publique du serveur
- On chiffre ensuite
Je propose de passer à:
- On authentifie la clé publique du serveur
- On authentifie la liste des suites du serveur
- On chiffre ensuite
[^] # Re: Let’s Encrypt
Posté par kantien . Évalué à 1.
Effectivement à la lecture de la discussion qui a suivi, ce n'était pas si claire que cela. Il semble bien considérer que c'est aux serveurs d'enclencher le processus, quitte à sacrifier de la disponibilité pour les vieux clients, d'où son système de notation sur son site.
De ce que je comprends de son argumentation, elle serait la suivante : c'est au fournisseur de service, donc au serveur, de garantir à tous ses clients la sécurité; or le client n'étant pas spécialiste de la problématique, contrairement au fournisseur de service, l'effort doit être fourni par ce dernier.
Par contre sa solution est commercialement risquée. Quoi qu'avec html5, la transition a été initiée par les serveurs.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 0. Dernière modification le 05 janvier 2016 à 20:06.
Non, la condition nécessaire et suffisante se situe uniquement côté serveur pour un couple (client, serveur).
Si le serveur ne supporte aucune suite TLS faillible, alors même si le client en supporte une, il n’y a aucun downgrade attack de possible et la négociation TLS débouchera sur la sélection d’une suite fiable.
L’autre sens n’est pas possible, puisque pour un simple problème de compatibilité avec les autres serveurs, les clients doivent obligatoirement supporter des suites faillibles.
Par exemple sur mon site, je te garantie que tu obtiendras du TLSv1.2 + ECDHE + AES (donc fiable), même si ton navigateur est blindé de RC4 ou 3DES.
Cf la démo juste au-dessus, si les serveurs faisaient le taff, non seulement sur leurs connexions ils mettraient leurs clients à l’abri, mais en plus ça permettrait aux clients de désactiver les suites pourries non utilisées et donc de protéger au passage les connexions des autres serveurs même mal configuré (plus de downgrade attack possible puisque les suites faillibles ne sont pas supportées par le client).
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 4.
comprend pas.
Si la navigateur ne supporte que TLSv1.2 + ECDHE + AES (donc fiable), la connexion serait aussi fiable, même si le serveur est blindé de RC4 ou 3DES (un downgrade ferait échouer le navigateur qui devra refuser la connexion downgradée).
donc ex-aequo : les deux sont fautifs.
Si les navigateurs faisaient leur taf (supporter les nouveaux formats assez vite) et/ou se mettaient à jour, ça ferait longtemps que les serveurs pourraient virer le non PFS et RC4 et 3DES et même SHA1 des serveurs.
Ca me semble donc aussi ex-aequo.
Dit autrement :
- Les serveurs proposent 3DES car des vieux navigateurs sont dans la nature
- Les navigateurs proposent 3DES car des vieux serveurs sont dans la nature
symétrique.
Qu'est-ce que j'ai manqué?
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 2. Dernière modification le 05 janvier 2016 à 22:17.
Que les serveurs sont beaucoup plus facilement mettable à jour et par des personnes qui sont en plus sensées savoir de quoi il retourne.
Alors que dès que tu es côté client, tu as une inertie énorme, l’impossibilité de forcer les maj, et des personnes qui ne comprennent pas ce qui est en train de se jouer.
En plus, si tu prends la situation actuelle, tu vas laisser beaucoup moins de personnes sur le carreau à pousser du TLSv1.2 + AES + ECDHE sur ton serveur (dans 99.999% des cas ça va passer et les pouillèmes restants sont des trucs vraiment moisis dont on devrait se foutre), que de désactiver RC4 côté client (et empécher la connexion à tous les serveurs ne supportant que ça, ie un gros paquet de monde).
Il est bien plus facile que chaque admin sys fasse sa petite portion de chemin vers un monde TLSv1.2 + AES + ECHDE only, les un après les autres, que de devoir attendre que la majeure partie des serveurs supportent TLSv1.2 + AES + ECHDE pour pouvoir passer le client en TLSv1.2 + AES + ECHDE only.
D’autant plus que ça mettra au moins tes visiteurs à l’abri, quelque soit leur navigateur.
[^] # Re: Let’s Encrypt
Posté par Antoine . Évalué à 5.
C'est justement pour ça que les serveurs sont forcés de supporter les anciennes suites de chiffrement, alors qu'un client à jour peut se permettre de désactiver ces anciennes suites. À l'inverse de ce que ta logique affirme.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 0. Dernière modification le 06 janvier 2016 à 11:14.
Il ne peut pas plus. Par exemple si tu veux payer tes impôts, il te faut obligatoirement RC4 ou 3DES, et rien d’autre…
Et donc tu dois avoir RC4 d’activé sur ton client. Et donc tu te boufferas du downgrade attack potentiellement sur tous les autres serveurs qui supportent AES & RC4.
Alors que si ces derniers n’avaient supportés que AES, tu aurais pu payer tes impôts et être à l’abri ailleurs.
C’est l’intérêt d’avoir une sécu qui vient des serveurs et des clients qui supportent le max de truc : tu es en sécu partout ou les admins ont fait l’effort de te mettre en sécu, sans pour autant t’exclure des services où les admins n’ont rien fait.
En allant par là, ça ne me génerait à la limite même pas que les clients activent par défaut l’intégralité des suites de chiffrement possibles et imaginables, mais que les serveurs se limitent à uniquement quelques suites sécurisés :
Ça permettrait en plus une sécurité glissante : à la détection d’une faille de sécu, les serveurs pourraient migrer sur une autre suite de chiffrement en désactivant immédiatement l’ancienne sans avoir besoin d’attendre la mise-à-jour des clients, et la sécurité s’améliorerait progressivement au fur et à mesure de la migration des serveurs, chaque serveur qui aurait fait l’effort de migration étant lui immédiatement et totalement à l’abri.
L’inverse n’a aucun sens (client avec 1 seule suite), puisque si les serveurs devraient activer temporairement l’ancienne suite et la nouvelle suite (et donc avec une suite faillible active), le temps pour les clients de migrer progressivement de l’ancienne suite à la nouvelle suite pour ensuite se faire une seconde modification pour retirer définitivement l’ancienne suite faillible.
Bilan : la sécu vient des serveurs, point.
C’est la situation actuelle qui est bloquée, parce que personne ne veut faire d’effort et/ou perdre de la compat’. Mais en régime nominal, ça viendrait des serveurs. Vraiment.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 3.
Des serveurs désactivent --> Des navigateurs ne peuvent plus se connecter.
Des navigateurs désactivent --> Des serveurs ne peuvent plus accepter de connexion.
Désolé, la je dois être bouché, mais je ne vois toujours pas la différence que tu fais.
J'ai l'impression que tu considères qu'un admin de serveur est plus intelligent qu'un utilisateur, mais c'est un préjugé que tu as qui ne tient pas dans la réalité.
Dans ton exemple "RC4 et les impôts", FF qui désactive complètement RC4 (ok, je me suis trompé, c'est que à la fin du mois.
Note que perso j'accède à static.impots.gouv.fr en TLS_DHE_RSA_WITH_AES_128_CBC_SHA, c'est moyen (DH 1024) mais pas en RC4 donc quand FF va désactiver RC4 la sécurité sera bonne (pas de downgrade possible en RC4 sinon FF va pas aimer), donc c'est la responsabilité de FF si ma sécurité est mauvaise (ils n'ont pas désactivé RC4 avant). Je ne comprend toujours pas pourquoi ce n'est pas la faute de FF qu'ils n'aient pas désactivé RC4 (avec le même impact de perdre du monde que si le serveur le désactive).
bref, toujours pas compris pourquoi les serveurs sont plus fautifs que les navigateurs.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 06 janvier 2016 à 12:41.
C’est le cas en pratique : combien de personnes sont réellement au courant des problèmes de TLS, hors admin systèmes. Même pire, en réalité même les admins sont à la limite de l’incompétence sur TLS & X.509 (tu l’a avoué toi-même dans ce topic, malgré 20 ans d’XP, tu ne savais pas comment fonctionnait exactement HTTPS)
Raté, ils viennent de réactiver SSLv3 et DES (non non, pas 3DES, DES…).
Parce que FF ne peut pas désactiver RC4 sans exploser au passage des terrachiés de domaine qui sont protégés par du F5, du BigIP, du Fortinet ou de la config datée des années 70.
C’est exactement comme SHA-1, ça casse bien trop de truc et donc tout le monde est méga frileux à l’idée de toucher à ça directement dans les clients, alors que les serveurs et les CA soucieux de la sécurité sont déjà passé à SHA-2 (et ECDSA) depuis longtemps.
Alors qu’un admin peut parfaitement désactiver ça immédiatement dans sa conf sur une décision unilatérale et avec un peu de com’ et d’assistance à tes utilisateurs qui te sont connus et qui seront minoritaires à rencontrer des problèmes, alors que Firefox ne peut pas le faire, encore moins sans s’être mis d’accord avec les autres navigateurs pour prendre une décision collégiale, sans pouvoir communiquer avec les admins des sites mal configurés qui leur sont totalement étrangers et en devant attendre que la très grosse majorité des serveurs aient fait leur travail.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 1.
Même argument que ceux qui veulent garder RC4 dans le serveur : ne pas exploser au passage des terrachiés de gens qui ont pas mieux.
Maintenant, reste à définir "terrachiés" de chaque côté, ça manque de nombres.
gni???
Je ne connais pas mes utilisateurs (ils sont anonymes! Ca ne marche pas, ils partent et je ne les revoient jamais; et au pire, ils écrivent dans les forum que je suis pourri car ça ne marche pas chez eux et que je suis le seul à faire chier car je n'ai pas fait un choix collégial, bon la à la limite du coup je peux les contacter, un par un… Mais trop cher, donc non).
Par contre, il y a généralement de quoi contacter l'admin d'un serveur (page contact en HTTP), et il sont moins nombreux, donc plus efficace comme action, surtout que des admins sont payés donc on peut viser le chef pour se plaindre si marche pas, plus efficace non?.
Tu donnes des arguments inverses en fait.
Quand à la modif collégiale, suffit que Chrome (pour FF, c'était "avant", maintenant on s'en fout un peu, du moins c'est moins marquant) décide, et ça va vite aller…
bref, tes deux dernières lignes, ben je vois perso que c'est encore pareil (problème de collégialité etc… Tout pareil)
Désolé, mais ça me semble toujours très subjectif, parfois faux, et peu convainquant.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 06 janvier 2016 à 13:02.
Tu peux poster sur ton site que attention, à partir du XX/XX/XXXX, il faudra un navigateur à jour pour accéder à ton site. En mettant un joli lien vers Firefox. Ça règlera 99.999% des problèmes et ça améliorera la sécu de tous tes visiteurs, y compris ailleurs que chez toi.
Il ne restera que quelques rares cas particuliers (les vieux Android, et encore, pas avec ceux avec un FF à jour) qui représentera moins de 1% du trafic.
Firefox ne peut décemment pas envisager de contacter les admins des serveurs, encore moins en récupérant manuellement les données de contact un peu partout.
Pire, ils ne peuvent même pas lister lesquels posent problème sauf à scanner l’ensemble de la plage IP et à tester les ciphers suites supportées en réalité (et pour le faire, je te garanti que ça prend du temps, beaucoup de temps…).
Et même avec une telle liste, tu imagines la charge de travail juste pour faire un tel contact ? C’est du délire total ne serait-ce que de l’avoir envisager…
Et alors que tu avais des solutions à apporter à 99.99% de tes visiteur (installer Firefox ou Chromium à jour, dispo partout et sur toutes les plate-formes), Firefox ne peut pas en faire de même pour les serveurs.
Certains sont protégés par des terminaisons TLS hardware (BigIP ou F5), ou par des load balancers. Et ne pourront migrer que dans des lustres, et encore si leurs vendeurs fournis des correctifs (le support de AES dans BigIP date de quelques mois seulement par exemple).
D’autres dépendent de stack logiciel non maintenues (Java, COBOL, IIS sous Windows ME…) et ne peuvent juste pas se mettre à jour.
Bref, même en supposant une prise de contact, la plupart des serveurs ne sont pas patchables sans des travaux très lourds, en tout cas d’un niveau de difficulté bien supérieure à juste mettre à jour son Firefox ou son Chromium !
Va dire ça aux banques, et revient me voir quand tu en auras une seule qui sera passé en A suite à ta remarque… Je me bat depuis 3 ans contre elles, y’en a pas une qui a bougé, malgré une notification formelle de la part du Ministère des Finances et de l’ANSSI suite à mes travaux.
[^] # Re: Let’s Encrypt
Posté par X345 . Évalué à 3.
(Profonde fatigue) J'ai testé les banques que j'utilise:
Crédit Agricole Normandie Seine A- Qualys
ING A Qualys
Donc bon aucune banque qui obtient un A. C'est un peu fort de café.
Après, tu pourras toujours dire que sur ton outil cryptcheck, elles obtiennent un F. Sauf qu'on se tue à t'expliquer que ta manière de noter n'a pas vraiment de sens…
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1.
Ma manière de noter tient justement compte des downgrade attacks et note la pire suite dispo et non la meilleure comme dans le cas de Qualys.
Qualys peut te donner un A ou B mais le site en question peut potentiellement te downgrader en F (RC4), alors que si je donne un B, tu aurais forcément B au moins même dans le pire cas de downgrade.
[^] # Re: Let’s Encrypt
Posté par X345 . Évalué à 3.
Qualys donne pas la meilleure note, il prend en compte le meilleur et le pire des cas, pondère et donne une note en fonction. Tu prends en compte uniquement le pire des cas, et je pense que ce n'est pas la bonne manière de faire.
Exemples:
ING Direct A Qualys
Google B Qualys
Tous les deux supportent le top du top (TLS 1.2, AES, PFS). ING Direct ne supporte aucune protocole/suite faillible. Qualys le note A. Google supporte RC4 et SSLv3. Qualys lui met un B. Tu lui mets un F.
Et honnêtement, j'aime moyen les arguments d'autorité, mais on peut penser que Qualys, experte dans la sécurité, a quand même pas mal réfléchi à son schéma de notation pour qu'il soit raisonnable. Ils font référence dans ce domaine.
Encore une fois avec un Firefox récent, je peux pas me faire downgrader en SSLv3 (ou RC4 dans la prochaine version). Tu ne prends pas ça en compte. Tu colles un F dès que y'a du SSLv3, alors que ça fait un bail que les navigateurs le supportent plus. Tu prends aussi que la protection contre les attaques actives (downgrade) et pas la sécurité contre les attaques passives. Bref, tu prends en compte le pire des cas, et Qualys un mix du meilleur/pire des cas.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 0.
RC4 = downgrade attack possible, chiffrement équivalent 0 bits pour la NSA si c’est le cas = F
Et avec tout le reste ? IE6 sous XP ? OpenSSL par défaut ? curl ? wget ? Java ? Mustard ou Twidere ?
Et environ 99% des user-agent qui traînent dans le coin. Ah oups, c’est pas désactivé là bas…
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 3.
Non mais là on part dans le délire complet, d'une personne qui est complètement dans son monde.
Je poste sur mon site, et? Comme la plupart des sites, mes visiteurs sont de passage! Tu oublies tous les nouveaux (et ils sont nombreux).
Tout le monde n'a pas un site avec des amis que l'admin connait personnellement.
La, c'est du grand n'importe quoi comme explications.
Encore une fois, OK pour la technique, mais alors pour la partie humaine, c'est bien faux.
Mais les admin de serveurs peuvent contacter leurs utilisateurs foireux… Va comprendre pour l'un est OK et pas l'autre.
Comme tout le monde : top 100000 Alexa.
Bon, dès qu'on parle de "philosophie", je crois qu'il vaut mieux passer…
[^] # Re: Let’s Encrypt
Posté par kantien . Évalué à 3.
À mon avis le problème de compréhension doit venir de là. Aries ne doit pas faire de commerce, et donc de la relation client; ou alors sur un marché de niche avec des clients qui comprennent la problématique.
Si je résume la situation, telle que je l'ai comprise :
pour savoir si une attaque de type downgrade est possible, on prend le plus petit dénominateur commun des deux liste : à savoir l'intersection de LS et LC. Si cette dernière comporte une suite faillible, une attaque active par un homme du milieu est possible : la sécurité de la communication n'est pas garantie à 100 %.
La condition nécessaire et suffisante pour sécuriser la communication est donc que l'intersection ne contienne pas de suite faillible. Comme il s'agit d'une intersection, cette condition peut aussi se formuler ainsi :
Cette dernière formulation, qui est celle proposée par Xion345, est une disjonction (non exclusive) : ou bien la configuration serveur garantie la sécurisation, ou bien la configuration client garantie la sécurisation.
Le problème qui se pose pour chacune des parties est donc la suivante : comment faire pour que tous ceux à qui je m'adresse (tous les clients pour un serveur, tous les serveurs pour un client) m'assurent une intersection non vide et sans suite faillible ?
En dehors d'une coordination complète entre tous les serveurs et tous les clients, qui est impossible, un tel problème n'a pas de solution absolue.
Un serveur, qui est un fournisseur de service, cherchera avant tout à s'assurer le marché le plus large possible : son intérêt est donc de supporter le plus de suites possibles, et donc également les faillibles, afin de se garantir que l'intersection est non vide. Le critère qu'il cherchera à optimiser en priorité est le côté non vide et non l'absence de suites faillibles. Et sauf s'il est sur un marché de niche, avec des clients au fait des problèmes de sécurité, la meilleure solution pour lui est de supporter le plus de suites possibles.
Du côté du client, s'il veut s'assurer la sécurité il ne doit pas supporter de suites faillibles. Il prend le risque d'avoir des intersections vides, et de ne pas communiquer de manière sécurisée avec certains services, mais de toute façon cette sécurité n'était que de façade. Au final, c'est le service qui prend surtout le risque de perdre un client.
Dans un système commerciale de libre concurrence, la pression vient toujours du client : si une concurrent propose un service en plus que l'on ne fournit pas — ceteris paribus — alors, à terme, la clientèle ira chez lui.
Alors, certes, le client du modèle client-serveur n'est pas la même personne que le client du modèle client-service. Ce dernier ne développe pas lui-même son navigateur-client : il est également client, sur le plan commercial, du développeur-service de son navigateur. Mais quel est le rapport numérique entre le nombre de navigateurs et le nombre de service web ?
Si Chrome et Firefox, qui représente une bonne part de marché, retirent le support des vielles suites, tout en communicant visuellement dans leur interface sur les raisons de l'absence de chiffrement dans une communication lors de la connexion à un serveur mal configuré : qu'adviendra-t-il ? Les utilisateurs changeront de navigateur pour pouvoir tout de même se connecter au site, ou l'administrateur adaptera sa configuration pour ne pas perdre de client ?
Je laisse chacun apporter la réponse qu'il souhaite à cette dernière question.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Let’s Encrypt
Posté par X345 . Évalué à 3.
Tu répétes que Firefox ne peut pas désactiver RC4. Sauf que ça va être fait très bientot, et par tout le monde:
« As part of our commitment to protect the privacy of our users, Mozilla will disable the insecure RC4 cipher in Firefox in late January 2016, beginning with Firefox 44. Mozilla will be taking this action in coordination with the Chrome and IE/Edge teams » Deprecating the RC4 Cipher.
« Today, Microsoft is announcing the end-of-support of the RC4 cipher in Microsoft Edge and Internet Explorer 11. Starting in early 2016, the RC4 cipher will be disabled by-default » Ending support for the RC4 cipher in Microsoft Edge
« At this point, the use of RC4 in an HTTPS connection is falling below that bar and thus we plan to disable support for RC4 in a future Chrome release. That release is likely to reach the stable channel around January or
February 2016. » Intent to deprecate: RC4
Donc c'est pas impossible, loin de la. Dans 3 mois, Firefox, Chrome et Edge ne supporteront plus RC4. Moins d'un an après la publication d'une attaque pratique sur l'algo. Pas si mal, non ?
Donc non, c'est pas lent, y'a pas de problèmes majeurs, et la com est possible… La preuve par les faits.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 0. Dernière modification le 06 janvier 2016 à 14:01.
1- J’attend de voir la réaction des opérateurs de serveurs, et la levée de bouclier qui va en découler (les admin sys PCI-DSS compliant, je vous salue, étant donné que PCI-DSS a déprécié 3DES, vous êtes dorénavant à poil en suite de chiffrement si vous ne supportez pas AES :P). Comme SHA-1, on risque d’avoir des marches arrière sur ce sujet.
2- La fragilité de RC4 date de 2013 avec la publication du programme BULLRUN de la NSA, qui attestait du déchiffrement temps réel de cette suite. On aura donc mis 3 ans pour agir, et on a toujours cette suite de chiffrement dans la nature, même à peut-être 3 mois d’une rupture techno côté client (ça veut dire qu’il n’y a eu aucun test de compatibilité de fait et que comme on dit, ça va être « when the shit hits the fan »)
[^] # Re: Let’s Encrypt
Posté par X345 . Évalué à 3.
Rhaa. Mais tu lis un peu avant de balancer des affirmations péremptoires ?
« Measurements show that only 0.13% of HTTPS connections made by Chrome users (who have opted into statistics collection) currently use RC4. Even then, affected server operators can very likely simply tweak their configuration to enable a better cipher suite in order to ensure continued operation » Intent to deprecate: RC4
« In Firefox 36 (released in February 2015), we took the first step by making RC4 a “fallback-only” cipher. With that change, Firefox would first try to communicate with the server using secure ciphers, before “falling back” to RC4. As a result, Firefox would only use RC4 if the server didn’t support anything better. That was a major step; over the course of the following weeks, RC4 usage by Firefox dropped from around 27% of TLS transactions to less than 0.5%. »
Donc on casse moins de 1% des sites. Et dans la plupart des cas faudra rajouter une ligne dans la conf du serveur, ça permet de faire pression sur les opérateurs de serveurs mal administrés. D'ailleurs ça a justement marché pour static.impots.gouv.fr, ils supportent de l'AES maintenant alors que c'était pas le cas y'a quelques mois. Après l'admin qui a IIS sous Windows Me, y'arrive un moment, faudra peut-être éviter de mettre ça sur internet tout court hein…
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 0.
Oui, et SSLv3 et DES (pas 3DES !) au passage… ><
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 1.
Mais du coup, contrairement à ce que tu pousses ("la faute aux serveurs"), il est maintenant de la responsabilité du navigateur si il accepte une connexion SSLv3 et DES.
Plains-donc toi des navigateurs (et fait un test sur les navigateurs, pour les noter)
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à -1.
Non, puisque SSLv3 et 3DES est désactivé sur mon serveur.
C’est l’intérêt du serveur-first : tu maîtrises ce qui se passe chez toi, quelque soit ce qui se présente en face.
Et comme indiqué plus haut, je ne trouverais pas du tout anormal qu’un client se mette à supporter tout et n’importe quoi. On aurait BEAUCOUP MOINS d’emmerde pour migrer nos serveurs et plus de question à se poser si ça sera compatible ou non avec nos config. On pourra patcher nos failles de sécu sans attendre que Duchmol-browser ou Tartampion-user-agent ait activé les mêmes suites que nous…
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 06 janvier 2016 à 15:39.
Oui. Les chiffres que tu avances viennent de Firefox et de Chromium, pas des banques elles-mêmes.
Elles, elles refusent de virer RC4 et 3DES au titre qu’encore trop de leurs clients (chiffres avancés entre 1 et 4%) qui sont sur des trucs pas compatibles autre chose (vieux Android, IE6 sous Windows XP et IE8 sous Windows Vista), et aussi une grosse partie de leur infra bancaire pas compatible (typiquement les DAB sous Windows XP donc ne supportant guère plus que SSLv3 parfois).
Elles ont aussi du matos de terminaison TLS qui ne supportent pas mieux (toujours pas de PFS sur les F5 10.x par exemple ou de TLS > 1.0 sur les F5 9.X), faute de pouvoir être upgrader (problème du chiffrement hardware) ou d’avoir les moyens (il faut racheter des licences) et le temps de le faire.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 06 janvier 2016 à 15:40.
Raison de plus de laisser les serveurs comme ça (ceux qui acceptent RC4 et AES) et taper sur les navigateurs, plus faciles à mettre à jour (ton argument) en désactivant RC4.
tu argumentes à fond pour l'inverse des tes idées, bizarre…
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à -1.
Parce que les gens s’en foutent. C’est BEAUCOUP plus simple de maj un navigateur qu’un serveur et il existe au moins des recettes miracles pour y arriver (au Firefox portable), mais ce n’est pas fait régulièrement parce que les gens ne connaissent pas l’hygiène de base de l’informatique (si tu en es encore à utiliser IE6 sous XP alors que tu pourrais utiliser Firefox sécurisé sous XP…).
Donc on arrête d’attendre des maj de nav, on les laisse avec tout d’activer par défaut et on ne s’emmerde plus. Un admin qui prend soin de sa sécu pourra enfin faire les choses proprement sans se préoccuper d’activer ou non des suites faillibles pour faire plaisir à tel ou tel navigateur et pourra corriger rapidement son serveur en cas de faille de sécu sans avoir à attendre la maj divine du navigateur qui va traîner des pieds. Un admin qui ne prend pas soin de sa sécu continuera à dégeuler la vie privée de ses utilisateurs.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 06 janvier 2016 à 16:13.
Non.
(Sérieusement, il faut vraiment expliquer pourquoi des IE/XP sont toujours dans la nature?)
Ha, excuse-moi, en fait tu descends ton propre argument tout seul. Pas besoin des autres!
Ca ne te fait pas bizarre de dire une chose et son contraire dans la même phrase?
Non (perte d'utilisateurs, et les utilisateurs ont le pognon).
Tu oublies une chose (le pognon). Cet oubli inverse complètement la conclusion.
C'est délirant : tu flingues toi-même tes idées.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à -1. Dernière modification le 06 janvier 2016 à 16:25.
Parce que les utilisateurs sont justement des brelles en sécu informatique (voire en informatique tout court ?)
J’ai dis que c’était facile de mettre à jour un nav’ comparé à un serveur.
On a une porte de sortie possible pour proposer une mise-à-jour safe des navigateurs de nos visiteurs (Firefox portable), ça ne signifie pas que ça sera fait dès le lendemain de la découverte d’une faille, ni que ça sera fait tout court.
On n’a aucune porte de sortie identifiée pour les serveurs, c’est du cas par cas à chaque fois et sans recette magique possible.
Pas avec une suite ALL dans le navigateur.
[^] # Re: Let’s Encrypt
Posté par X345 . Évalué à 4.
Si je télécharge IE8 en 2010, il supporte pas ECDHE-AES, et je le mets à pas à jour. Tu configures ton serveur en ECDHE-AES only. Je peux pas me connecter sur ton serveur.
Au bout d'un moment, c'est plus de l'argumentation, c'est de la désinformation, hein.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 2.
Et on te répond que non, car ça implique le bon fonctionnement de l'interface chaise-clavier, et tout le monde sauf Aeris sait que cette interface merde un max.
Donc cet supposition n'est pas valide, donc tout tombe à l'eau (et fait même pencher la conclusion ailleurs une fois ce point changé dans la démonstration)
Le GROS problème dans ton analyse est que tu fantasmes sur "facile de mettre à jour un nav’ comparé à un serveur". Ne pas comprendre ça, j'avoue que ça me dépasse (ce n'est pas technique, c'est juste l'humanité de l'interface qu'on veut mettre dans la chaine d'évolution)
Ben si, la même chose que tu demandes aux gens derrière un navigateur. La différence est que les admins ont un problème plus gros si ils ne se bougent pas.
Donc tes arguments militent toujours pour le contraire de ta conclusion, quand on prend en compte un facteur que tu oublie (l'humain qui veut et l'humain qui a le pognon)
Tu réfléchis comme un robot qui pensent que tous les gens sont des robots logiques prêt à rejeter le dilemme du prisonnier et faire le mieux pour la société, le monde n'est pas fait de robots.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 0.
Et ça merde un max des 2 côtés.
Mais en tout cas, cliqueter sur un lien vers Firefox portable, dézipper l’archive, lancer, ça sera toujours over moins compliqué qu’aller migrer une Debian old-old-old-stable en stable ou un Windows serveur 2003 en 2010.
Je n’ai jamais dis que ça sera fait, à quelle vitesse ni avec quel pourcentage de réussite.
Mais la maj du client est possible et la procédure pour en obtenir un fiable est connu, documenté et déroulable, reproductible et généralisable, alors que celle d’un serveur, non.
Abstraction faite du pur problème humain, tu sais obtenir un Firefox à jour avec ALL d’activé avec une facilité X, alors que tu ne sais pas obtenir un serveur à jour avec ALL d’activé avec une facilité globale < X.
Peu importe le reste des arguments, le simple fait que le contrôle par le serveur fait que tu es seul responsable de la sécurité des données de tes visiteurs prime par dessus tout. Tu n’as pas et ne peux pas déléguer cette responsabilité à what-mille entités tierces.
[^] # Re: Let’s Encrypt
Posté par X345 . Évalué à 3.
Damn. La question est pas de virer RC4 ou 3DES. La question est de supporter au moins autre chose que RC4. Tu mélanges constamment ces deux notions, c'est un peu difficile de discuter.
De ce que j'ai testé toutes les banques françaises suportent au moins autre chose que RC4 ou 3DES. Et ce depuis très longtemps. Donc aucun problème de compatibilité avec les nouvelles versions de Firefox, Chrome ou Edge. Pffiou…
Encore une fois, non. Trouve moi un site de banque qui supporte uniquement RC4 et 3DES.
[^] # Re: Let’s Encrypt
Posté par Sufflope (site web personnel) . Évalué à 3.
Ouais sauf que le problème c'est que comme un attaquant peut s'assurer que vous utilisiez l'algo le plus bas possible, gérer RC4 + autre chose, dans un contexte de sécu ça revient à gérer RC4 tout court. Avant de lui répéter 50 fois qu'il comprend pas ce qu'on lui dit, faut s'assurer que ce ne soit pas l'inverse.
[^] # Re: Let’s Encrypt
Posté par Antoine . Évalué à 3. Dernière modification le 06 janvier 2016 à 18:53.
Ah ? Je n'ai pas essayé le paiement, mais je peux me connecter à :
(amusant que l'algo soit subtilement différent entre les deux, d'ailleurs)
Tout ce troll pour des infos pas à jour :-)
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1.
Ce n’était en tout cas pas le cas pour le réglement de l’impôt sur le revenu en octobre 2015. Seuls RC4 et 3DES étaient proposés.
Cf https://twitter.com/aeris22/status/684666360652247040
[^] # Re: Let’s Encrypt
Posté par X345 . Évalué à 3.
Toujours pas.
La condition (1) le serveur ne supporte aucune suite TLS faillible est suffisante
La condition (2) le client ne supporte aucune suite TLS faillible est suffidante
La condition (1 ou 2) est nécessaire (et suffisante, évidemment).
Si le client ne supporte aucune suite TLS faillible, alors même si le serveur en supporte une, il n’y a aucun downgrade attack de possible et la négociation TLS débouchera sur la sélection d’une suite fiable.
L’autre sens n’est pas possible, puisque pour un simple problème de compatibilité avec les autres clients, les serveurs doivent obligatoirement supporter des suites faillibles.
Par exemple avec ma config de Firefox, je te garantie que tu obtiendras de l'AES (donc fiable), même si ton navigateur est serveur est blindé de RC4 ou 3DES.
Pour un fournisseur de service, c'est hyper problématique de perdre des utilisateurs parce qu'ils n'ont pas un navigateur récent. C'est pour cette raison qu'ils ne les désactiveront que dans très longtemps.
La vraie bonne chose à faire ce serait que tous les serveurs du monde intégrent rapidement les protocoles (suites) récents. Ensuite les navigateurs désactivent les suites pourries dans leurs nouvelles versions. Ainsi, les sites n'ont pas besoin de se priver d'utilisateurs. Les clients n'ont pas besoin de se priver de sites non plus.
Avec la solution que tu proposes, les serveurs (donc les fournisseurs de services) doivent se priver de clients. C'est une solution acceptable pour ton site ou une banque française (quoique madame michu qui arrive plus à se connecter avec Android 2.1… Ça pourrait leur couter très cher en service client.), mais pas pour un opérateur plus international.
C'est surement ce qui était prévu quand TLS a été conçu. Il s'avère qu'au final c'est pas tellement faisable. Du coup, y'a effectivement un truc dans TLS 1.3.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 0.
Les suites faillibles ayant encore de beau jour devant elles (parce que ce sont les seuls qui passent actuellement dans du matos hard ou sur des loads balancers, etc), les navigateurs ne sont pas prêts de les retirer.
Et donc si tu veux mettre à l’abris tous tes utilisateurs, tu passes à du secure only (sinon downgrade attack) côté serveur, et tu milites fortement pour aider les quelques qui resteront à la porte à passer à quelque chose de plus à jour et sécurisé, améliorant ainsi globalement la sécu de tous tes utilisateurs sur tous les autres serveurs sécurisés qu’ils visiteront.
Ça peut être fait là maintenant tout de suite dans l’instant.
Plutôt que d’espérer voir un jour les supports pourris virés des navs (hint : quelque chose entre longtemps et jamais) et donc l’ensemble de tes visiteurs à poil en permanence sauf sur les trop rares serveurs sécurisés en attendant.
[^] # Re: Let’s Encrypt
Posté par X345 . Évalué à 4.
Je suis d'accord pour dire que la solution idéale que je décrit n'a pas vraiment lieu aujourd'hui (interblocage entre les clients et les serveurs). Et donc que les suites pourries vont encore rester un moment dans les navigateurs.
Après le jamais me semble excessif: Firefox 42 ne supporte ni SSLv3 (depuis un moment), ni RC4 Qualys, c'est quand même la preuve qu'on arrive à virer les truc vraiment craignos. En pratique ça marche pas si mal.
En fait je pense que la solution que tu proposes est aussi irréaliste: jamais les opérateurs n'accepteront de se priver d'une partie des utilisateurs (marchés émergents etc.). Ça peut être un dilemne cornélien.
Imagine que tu es Wikimedia Foundation, et que tu veux permettre à un dissident mal équipé (vieux smartphone, vieux PC) de venir documenter les exactions d'une dictature quelconque sur Wikipedia. Tu fais quoi ? Tu forces TLS 1.2 et PFS ? Tu le laisses quand même venir en TLS 1.0 et 3DES ? Ou même simplement si tu veux laisser la population d'un pays consulter des articles Wikipedia sur des sujets prohibés dans leurs pays (je pense à la Birmanie par exemple). Ou si tu es Google et que tu veux laisser les habitants du Gabon ou du Congo se connecter sur Gmail sans faire transiter leur mot de passe en clair sur le Wifi partagé (même si c'est pas ultra sécurisé, personne va aller dépenser 50000 cores/hours pour casser leur mot de passe).
Après si tu es Aeris, et qu'une partie des personnes qui visitent ton site sont potentiellement trackées par la NSA, que de toutes façons tout ceux qui le visitent ont un navigateur récent, que tu veux pas que la NSA ressorte des dossiers dans 10 ans, et donc que tu veux que tout le monde bénéficie de PFS, ta config me semble raisonnable.
Deux choses:
La situation actuelle n'est pas si mauvaise que ça. Les protocoles (suites) vraiment craignos sont retirées des navigateurs. On a plus les ciphers de 40/56 bits, plus de SSLv3, maintenant plus de RC4. Aussi faut garder à l'esprit que les attaques downgrade c'est des attaques actives, pas passives, donc pas discrètes du tout (et pas très utilisables pour de l'écoute de masse). Donc en pratique si le navigateur et le serveur supportent une suite correcte, elle sera utilisée, et offre une protection contre l'écoute passive.
Y'a pas d'un côté les "bons" admins qui ont désactivé les suites moins robustes et les "mauvais" qui les ont laissés activés. Le problème est un peu plus complexe parce que ça revient à se priver d'une partie des utilisateurs pour un risque de sécurité pas forcément hyper important. Si Google laisse SSLv3 activé, c'est pas juste parce qu'ils ont pas trouvé le fichier de config du serveur…
La seule solution qui me semble valable au niveau global c'est une solution protocolaire. Faudrait que la liste des ciphers soit authentifiée par le serveur. Ou alors pouvoir pinner une liste de ciphers dans le navigateur.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 0.
Ah oui, j’avais oublié ce truc :P
Faut que je regarde combien de sites institutionnels ne te sont donc plus accessibles…
Alors très certainement la réponse est : surtout tu ne joues pas avec ta vie, on t’envoie un OpSec via RSF sur place pour te mettre à l’abri (pas de TLS du tout + Tor + SecureDrop)
Idem, tu ne fais pas le con et tu restes bien à l’abri chez toi en attendant de savoir ce qui se passe (MitM TLS par la Birmanie qui pourrait te coûter une balle dans la tête par exemple)
Là OK, ce modèle de menace est recevable pour utiliser du 3DES ou du SSLv3.
[^] # Re: Let’s Encrypt
Posté par gouttegd . Évalué à 4.
Malheureusement si, pour les mêmes raisons qui font que le downgrade de TLS (toutes versions) à SSl 3.0 est possible.
Sauf encore une fois si le RFC 7507 (le fameux TLS_FALLBACK_SCSV) est implémenté des deux côtés.
(Une rapide recherche ne m’a pas permis de trouver à quel point le support de ce RFC était répandu parmi les navigateurs — et à partir de quelles versions — , juste qu’apparemment Microsoft ne prévoit pas de l’implémenter dans IE : « At this time we de not plan on making this change », et notez que le bug est closed.)
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1.
Non, un certificat ne protège rien. C’est la clef privée qui compte, renouveler le certificat sans renouveler la clef ne change rien vis-à-vis de PFS.
Et renouveler la clef c’est bien, mais pas trop souvent pour permettre d’autre mécanisme de sécu comme HPKP ou DANE/TLSA. Et certainement pas tous les 90j (tous les ans serait mieux).
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 0.
Et non justement, la grosse majorité supporte aussi des suites non PFS (en vert) et non pas uniquement des suites PFS (en bleu).
Et du coup sont faillibles à une downgrade attack.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 0.
Reference needed.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 06 janvier 2016 à 12:50.
Ben c’est exactement ce que fait la faille FREAK, downgrader les ciphers suites pour retomber dans quelque chose de cassable.
Actuellement ce downgrade attaque n’a de sens que vers les suites EXPORT ou RC4, parce qu’on ne sait pas déchiffrer rapidement autre chose.
Mais on peut imaginer un downgrade attack massif de la part de la NSA (il suffit de faire juste un gros sed sur le réseau) pour forcer le passage à des suites non PFS si supporté, et ainsi espérer déchiffrer l’intégralité du trafic échangé dans XX années (cassage de la clef RSA a posteriori), ce qui n’aurait pas été possible avec les suites PFS.
Une attaque théorique (pas exploitée en pratique ou en tout cas pas de manière connue) existe aussi qui permet de downgrader sur du EXPORT même si le client ne le supporte pas.
Bref, à partir du moment où tu supportes une sécu X et une sécu Y plus faible que X, un attaquant peut toujours te forcer à downgrader vers Y avec TLS actuel.
Ça peut lui servir à rien (par exemple downgrader de ECDHE-AES à DHE-AES), mais c’est toujours possible. Le cas de ECDHE-EXPORT montre aussi que c’est parfois indépendant du support réel annoncé par le client (même si le client ne supporte pas, le downgrade est possible).
Il faut attendre TLSv1.3 pour espérer contrer ce fait.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 2.
Je ne comprend pas comment le navigateur va "parler" EXPORT si il ne le supporte pas. A la réponse "EXPORT", j'imagine plutôt qu'il va rien comprendre et arrêter, donc attaque par downgrade ééchouée
Comment forcer un client à "parler" une langue non supportée?
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 06 janvier 2016 à 13:13.
La seule différence entre EXPORT et pas export au niveau protocole, c’est la taille de clef.
Donc si tu modifies la liste des ciphers du client pour dire « Eh, je cause EXPORT », le serveur, s’il supporte aussi EXPORT, te causera avec une clef de 512 bits générée exprès pour au lieu d’une de 2048 bits, tu n’as plus qu’à modifier la réponse du serveur de EXPORT à non EXPORT, et le client n’y verra que du feu (il a envoyé non EXPORT, il reçoit non EXPORT).
Et tu sais parfaitement faire du TLS côté client avec une clef RSA de 512 bits, tu auras juste l’impression que la clef du serveur est une clef de 512 bits…
Regarde la doc page 40 et 41, c’est assez compréhensible que ça va marcher tout à fait correctement.
Dans ce cas, le client n’annonce que DHE, le serveur supporte DHE & DHE-EXPORT, un downgrade est possible vers DHE-EXPORT…
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 2.
Donc le client peut voir qu'il fait du 512-bit, et donc refuser (c'est une politique de sécurité).
N'est-ce donc pas de la faute du navigateur si il accepte 512 bits? et corriger sa faille?
J'avoue ne pas comprendre le problème.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à -1.
Un client pourrait effectivement refuser la clef du serveur s’il la juge trop faible.
Mais ça ne serait alors pas trop conforme à la norme X.509.
Et on retomberait alors dans le choix cornélien : 512 bits, c’est faible ou c’est pas faible ? Et 1024 bits alors ?
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 3.
Responsabilité du navigateur.
tu dis qu'il n'est pas responsable de la sécu, mais en fait… Si.
Tout ce que tu dis s'applique indifféremment au serveur ou navigateur, mais tu accuses l'un et pas l'autre.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à -1.
Cf ma démonstration ailleurs dans le topic, mais il faut justement que la responsabilité ne soit que d’un seul côté si on veut éviter la spirale infernale sécurité = incompatibilité et incompatibilité = pas de sécurité.
Et du coup elle ne peut être que côté serveur si on veut éviter les downgrade attack tout en ayant une bonne compatibilité.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 06 janvier 2016 à 15:39.
Et du coup elle ne peut être que côté navigateur si on veut éviter les downgrade attack tout en ayant une bonne compatibilité.
Ca marche aussi (juste en inversant tes arguments)!
Tu n'as pas démontré que c'est mieux côté serveur que navigateur (et honnêtement, quand on lis ton argumentaire, on en déduit plutôt même le contraire de ta conclusion : tes arguments, une conclusion inverse complètement).
Pour ne pas répéter ce que quelqu'un d'autre à déjà dit, lien (ok, il a laissé la réponse ouverte, mais… ;-) )
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à -1.
Si, cf la démo quelque part dans ce topic.
Le matos pourri côté serveur, on ne pourra jamais s’en passer, encore moins rapidement.
Et des suites restrictives côté client, c’est remettre le problème de la compatibilité dans la boucle (tu ne maîtrise pas la configuration des serveurs autre que le tient et ne peut garantir qu’il supporte les mêmes ciphers que toi, donc un navigateur ne peut pas se limiter aux mêmes ciphers que toi non plus).
La seule config qui mettrait fin au bordel ambiant et permettrait à tous de faire les maj de sécu sans se prendre la tête de savoir qui on va dégager ou pas du parc, c’est « ALL » sur les clients et « une unique suite secure de ton choix » sur les serveurs. En cas de pépin, les admins peuvent migrer quand ils voudront, sans avoir besoin de synchroniser quoi que ce soit et en étant assuré que leurs clients continueront à voir leur site en version pourrie ou en version sécurisée par la suite. Et de ton point de vue, tu peux assurer la sécurité de tes clients dès publication de la faille de sécurité si tu en as envie.
Si tu fais l’inverse, ie des clients restrictifs, à chaque pépin de sécu, tu retombes dans le bordel de la compat. Il faut déjà prendre une décision collégial pour se mettre d’accord sur les nouvelles suites à implémenter dans tous les navigateurs. Puis attendre que suffisamment de clients se soient mis à jour pour faire la bascule côté serveur et virer l’ancienne suite (et exclure de facto tous visiteurs pas à jour).
Ou alors tu actives toutes les suites côté serveur, et une suite unique côté client. Mais alors tu ne maîtrises ni ne peut assurer la sécurité de tes propres utilisateurs, qui s’ils ne sont pas à jour, utiliseront potentiellement des suites pourries avec ton service.
Bref, dans le 1er cas, c’est toi qui est maître de la sécurité de tes visiteurs, dans le 2nd cas non.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 2.
Pareil pour les navigateurs!
Mais… En fait, pourquoi on pourrait pas? Si les serveurs perdent de l'argent faute de visiteurs, ils vont vite migrer. Ca ne tient pas!
Et des suites restrictives côté serveur, c’est remettre le problème de la compatibilité dans la boucle (tu ne maîtrise pas la configuration des navigateurs autre que le tient et ne peut garantir qu’il supporte les mêmes ciphers que toi, donc un serveur ne peut pas se limiter aux mêmes ciphers que toi non plus).
Et donc?
tu pourras répéter cet "argument" indéfiniment, ça ne convainc pas (loin de la, ça convainc en fait du contraire, car les gens derrière le navigateurs ont le pognon, et les gens derrière le serveur veulent le pognon)
Toi, tu dis à des gens voulant le pognon de virer le pognon, on s'en fout qu'ils aillent ailleurs. Tu oublies un détail… Le pognon, les mecs des serveurs le veulent.
Ca tourne en boucle (Aeris balance un truc "bizarre" pas très réaliste sur les responsabilités, c'est démonté, il le répète sans changer le contenu pour mieux convaincre donc ça doit pas bien aller, etc), je crois que le mieux est d'en rester la.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 0. Dernière modification le 06 janvier 2016 à 16:21.
Non, ils ne vont pas vite migrer. J’ai dis que c’était facile, pas que c’était rapide.
Parce qu’il y a suffisamment de lobby pour que ces modifs soient faites beaucoup trop longtemps après la bataille.
On l’a vu pour SSLv3, pour SHA-1, pour RC4, pour 3DES. Et je promet déjà une sacrée longue traîne avant l’exclusion des suites RSA au profit des suites ECC, et pire, la désactivation de TLSv1.2 après l’intégration de TLSv1.3.
Ça demande des palabres infinis pour que les navs se mettent d’accord de qui intègre quoi. Et ça ne fonctionne pas, la preuve chaque navigateur a une liste de choses supportées différente de celles des voisins…
Si justement. Je peux garantir que je n’aurais pas de problème de config en instaurant ALL sur tous les navigateurs.
Et je contrôle au moins MES données qui circulent sur MON serveur, ce que je ne peux pas faire avec un ALL côté serveur et une suite restrictive sur le client puisque je suis alors dépendant du bon vouloir de Google, Mozilla et Microsoft pour mettre à l’abri mes visiteurs.
La grosse différence est surtout là pour le choix client-first ou serveur-first : je suis légalement responsable de la sécurité de mes utilisateurs, je n’ai donc pas à subir des décisions externes (les suites dans les navigateurs) pour les mettre à l’abri.
[^] # Re: Let’s Encrypt
Posté par kantien . Évalué à 3.
C'est pour cela que l'économie de marché a inventé le concept d'assurances (qui s'assurent elles-même via des sociétés de réassurance). ;-)
Si le coût des contentieux potentiels est inférieur, grâce au système d'assurance, au gain que tu obtiens en ne te privant pas de clients suite à la configuration de ton serveur, alors tu choisis la configuration qui t'offre le plus gros marché possible. ;-)
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Let’s Encrypt
Posté par kantien . Évalué à 2.
Le lien ne serait pas ceui-là ? ;-)
Après, effectivement j'ai laissé la question ouverte, à savoir si on répond : je veux des clients ou je ne veux pas de clients. Mais cela, toi et Xion l'avez bien compris. ;-)
On en déduit effectivement la conclusion inverse, lorsque l'on rajoute à ses prémisses les lois de l'économie de marché.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à 2.
Et pourtant, le lien que tu pointes dit le contraire…
A moi que tu t'adressais.
Et je n'ai pas donné la suite, mais la réponse de l'admin a été cinglante : le lien que tu pointes.
"La taille minimale du module est de 2048 bits, pour une utilisation ne devant pas dépasser l’année 2030"
Désolé, ça fait pas très rassurant, ce minimale, ça sous-entends que c'est parce que bon, tu insistes avec ta connerie, on va écrire ça même si on aurait aimé mettre plus. Et on met une date en plus, pas lointaine (dans 15 ans, on se dit qu'on pourra casser la chose, donc si c'est dumpé… La durée de la clé ne dit rien sur la durée de l’intérêt des données)
D'ailleurs ensuite :
"Il est recommandé d’employer des modules d’au moins 3072 bits, même pour une utilisation ne devant pas dépasser 2030."
Voila, bam dans la gueule, en fait 2048 c'est pas terrible, on dit 3072, c'est recommandé. Et pour ceux qui aiment les puissances de 2, ça fait 4096, simple.
C'est un peu comme les RFC, entre MUST et SHOULD, SHOULD n'est qu'une recommandation n’empêche on espère que c'est pris en compte (pas écrit pour rien), ben la pareil, tu omets la recommandation, pourquoi?
Surtout que bon… C'est un paramètre pour l'humain, ce n'est pas comme si c'était dur à faire.
donc tu te contredis toi-même : ton "convient très bien" n'est pas compatible avec les recommandations de l'ANSSI, qui dit que ton "convient très bien" est le minimum et non pas le recommandé (et chez moi, minimum != satisfaisant, c'est plutôt "si tu insistes, fait-toi plaisir je tolérerai")
Je suis conscient que mon site ne vaut pas qu'on s'amuse à casser la clé en 2030, mais bon, c'est facile à mettre 4096, alors la question est plutôt : pourquoi pas? et ça, tu n'y as pas répondu. une petite étude sur le gain en vitesse qu'apporte le 2048 sur un site "banal"? Car finalement, la question est plutôt du côté "pourquoi pas" qu'ailleurs, et personne n'a répondu à cette question.
(à noter que les gens refusant AES-256 dans les navigateurs Chrome et FF même si le serveur n'accepte que ça, au contraire de Safari et IE qui eux l'acceptent même si AES-128 est dispo, donc des choix bien différents, ont avancé un problème de perfs, mais les gens aillant testé les perfs ont conclu que c'était quand même assez marginal donc pas un argument bien convainquant pour eux; comme quoi les arguments de perfs, ça ne convainc pas forcément tout le monde suivant la "perte" calculée)
[^] # Re: Let’s Encrypt
Posté par flan (site web personnel) . Évalué à 4.
Je ne vois pas en quoi ce n'est pas très rassurant, et je vois encore moins pourquoi ils n'auraient pas mis 3 072 ou même 4 096 s'ils avaient vraiment voulu mettre plus.
Le "minimal" est même obligatoire pour que la phrase ait un sens, et je suis sûr que tu ne te serais pas privé de la critiquer s'il n'avait pas été présent : cela signifierait qu'une clef de 3 072 ne conviendrait pas.
L'ANSSI fait des recommandations dans des cas d'usage bien précis. Si tu as des données que tu veux préserver jusqu'en 2030 (plein de données sont périssables et pourraient être dévoilées dans 15 ans sans préjudice aucun), tu peux utiliser des clefs de 2 048 bits. Si tu es du genre "ceinture et bretelles" et que tu as de l'argent à mettre dans ton CPU (oui, le SSL a un coût), c'est encore mieux de mettre du 3 072 bits, bien évidemment.
Essaie de faire les deux (2 048 et 4 096 bits), tu remarqueras une vraie différence sur le nombre de connexions qu'encaisse ton apache (j'avais fait le test il y a quelques années, c'était non négligeable même si je ne me souviens plus des chiffres).
[^] # Re: Let’s Encrypt
Posté par Zenitram (site web personnel) . Évalué à -1.
La recommandation est 3072.
Faut m'expliquer en quoi 2048 est une recommandation, c'est écrit "minimum 2048 et on recommande 3072".
Oui, la c'est un problème de français en fait : minimum contre recommandé, je comprend que tu dis que minimum = recommandé, mais tu ne dis pas comment tu traduis "recommandé" du coup.
Je traduis par "ma recommandation est 3072, mais dans certains cas et si tu es un radin, OK 2048 est tolérable".
On a vraiment un problème de français, car tu traduis "recommandé" par "ceinture et bretelles" et j'avoue ne pas te suivre du tout dans ce français.
J'attends plus de démonstration sur la partie "traduction du français", je ne suis pas convaincu : perso, je prend le mot "recommandation" comme une recommandation.
Exemple.
6x plus lent si c'est dédié au handshake.
M'en fout, mon VPS tourne à 2-3% du CPU (pas le choix, les VPS "pas cher" ne filent pas de CPU moins puissant pour moins cher, les offres moins chère n'ont pas assez de RAM ou SSD), et c'est sur le handshake le x6, le matos fait aussi d'autres choses.
Mon serveur est en 4096 et je ne vois pas de différence en pratique.
Le jour où j'aurai 1000x plus de monde, je me poserai peut-être la question, mais je regarderai aussi toute la chaine (les gens ne font pas que le handshake, ils font mouliner du PHP, du MySQL… Et donc si ça me rajoute 1% de machines en plus, faudra se poser la question radinerie contre recommandation. Je ne note quand même que les "gros" on pour le moment choisi 2048, reste à savoir si c'est de la radinerie ou si ça a vraiment un impact sur l'ensemble de leurs machines)
[^] # Re: Let’s Encrypt
Posté par Harvesterify (site web personnel) . Évalué à 1.
https://istlsfastyet.com/
Le coût n'e'st pas si élevé comme ça, surtout quand tu as un trafic assez limité. Et si tu as un site qui ne dépend pas d'autres sous domaines, SPDY ou HTTP2 est une bonne idée pour réduire encore plus l'impact sur les perfs.
Mes messages engagent qui je veux.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1.
Ils souffrent de la même erreur que Let’s Encrypt : s’asseoir sur tout le reste de la stack X.509/TLS et se contenter de tenir compte uniquement du certificat…
https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0000.html
[^] # Re: Let’s Encrypt
Posté par Harvesterify (site web personnel) . Évalué à 0.
D'où ma remarque :
Mes messages engagent qui je veux.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . Évalué à 1.
Même si tu n’as pas d’autre sous-domaine…
Tu peux te retrouver avec des problèmes avec des CDN et des certificats wildcard déployés un peu trop à l’arrache qui pourrait être aussi valide pour ton domaine et qui pointe sur ton adresse IP, mais avec des paramètres TLS négociés bien plus faibles et un cross-accès à une resource critique… :D
# Juste pour compléter la liste
Posté par Kaane . Évalué à 2.
Tous les TLD n'ont pas un top level signé liste TLD ce qui oblige à passer par des DLV DNSSEC Lookaside Validationqui va créer des trusts anchor à droite à gauche - au cas ou.
Du fait du truc précédent, il redevient possible de faire du DNS poisonning (c'est un poil plus compliqué certes)
Il faut parfois deux mois pour renouveler/changer une clef et la remonter vers les DLV et les racines TLD. Et il n'existe pas de façon simple de révoquer une clef. Très cool si un admin sys un peu escroc sur les bords par en claquant la porte.
Si votre clef est corrompue sur le disque et/ou en mémoire - ben plouf. J'espère que vous avez un backup de la clef et une bonne connaissance des adresses IP des serveurs autoritaires, sinon vous prenez le risque de passer un poil pour un guignol.
De base DNSSEC permet assez facilement de récupérer l'ensemble de votre zone, il y a des "bricolages" qui permettent de protéger vos fichiers zones (Universal DNSSEC, Online signing, NSEC3) mais bon ils ont tous des inconvénients et sont des degrés de protection variable (Universal DNSSEC n'est pas formalisé, Online signing oblige à laisser trainer les clefs privées sur tous les resolveurs et NSEC3 est déjà cassé)
[^] # Re: Juste pour compléter la liste
Posté par Sufflope (site web personnel) . Évalué à 3.
J'ai jamais compris cet argument. Y en a qui nomment leurs serveurs avec leurs numéros de CB ? La sécurité du backoffice repose sur le postulat que personne ne tapera lebackoffice.maboite.com ?
[^] # Re: Juste pour compléter la liste
Posté par Kerro . Évalué à 3.
Ça limite les choses.
Par exemple je gère des VPN pour mes clients. Leurs sites sont généralement nommés nom-du-site.vpn.societe.fr
Ou pour des serveurs qui n'ont pas à être utilisés directement par les utilisateurs, par exemple un serveur de bases de données.
En cas d'attaque ciblée, l'attaquant sait quelles sont les autres cibles. En plus le nom DNS est souvent évocateur, ce qui lui fait encore gagner du temps.
S'il ne peut pas avoir la zone DNS alors il va lui falloir bien plus de temps pour trouver toutes les ramifications. Et il ne trouvera jamais certaines autres machines.
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . Évalué à 1.
Étant donné qu’il est très simple et très rapide de scanner toute la plage IP (cf ZMap et son utilisation la plus efficace, Shodan), avoir un DNS obscurci ne sert à rien : on trouvera facilement quel serveur (= IP) héberge un VPN, au mieux on aura scanné toute ta plage de port, au pire tout l’Internet :P
[^] # Re: Juste pour compléter la liste
Posté par Kaane . Évalué à 0.
Étant donné qu’il est très simple et très rapide de scanner toute la plage IP (cf ZMap et son utilisation la plus efficace, Shodan), avoir un DNS obscurci ne sert à rien : on trouvera facilement quel serveur (= IP) héberge un VPN, au mieux on aura scanné toute ta plage de port, au pire tout l’Internet :P
Ben vas-y scanne tout internet, fait un reverse lookup de toutes les IP et fait la corrélation. Je ne pense pas qu'il existe de machine capable de faire ce que tu proposes. Surtout qu'en plus il n'y a qu'un seul reverse par IP alors qu'il peut y avoir plusieurs noms de domaine.
Si tu fais un reverse sur tout internet tu vas tomber sur pas mal de CDN par exemple, mais bonne chance pour savoir lesquels sont utilisé par tel ou tel domaine (et donc lesquels tu dois cibler si tu veux faire un DDoS)
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . Évalué à 3. Dernière modification le 10 janvier 2016 à 17:29.
C’est exactement ce que permet ZMap. Et la plage IPv4 est scannée intégralement chaque jour, par exemple pour mesurer les handshakes TLS, les bannières SMTP, POP3, IMAPS, les noms inclus dans les certificats, les réponses AXFR DNS, les reverses DNS associés, le tout qui reboucle sur lui-même pour faire un reverse DNS sur l’intégralité de toutes les IP ou noms de domaine qui auraient pu être trouvé (Project Sonar includes a regular DNS lookup for all names gathered from the other scan types, such as HTTP data, SSL Certificate names, reverse DNS records, etc).
Benjamin Sonntag a réussi à construire une liste contenant le tiers des noms de domaine en .fr en se basant sur des outils de ce type.
Donc en gros, ta protection par l’obscurité, t’as un taux de perte de 33% de base avec des outils débiles. En étant plus intelligent, on doit pouvoir monter au minimum à 50%.
[^] # Re: Juste pour compléter la liste
Posté par Kaane . Évalué à 3.
C’est exactement ce que permet ZMap.
Non.
A moins d'essayer en force brute toutes les possibilités d'entrées DNS, ZMAP n'a aucune chance de tomber sur abcdefghijkl123.mondomaine.com si celui ci n'est pas référencé ailleurs que sur les DNS. Si aucun autre site ne le mentionne, et si son reverse est différent (voire sur un autre domaine) alors c'est grillé.
Ensuite L'immense majorité des entrées DNS sont publiques. C'est clair que si je scanne toutes les adresses du monde et que je regarde pour chaque adresse son reverse, je vais tomber un paquet de noms de domaines (honnêtement je suis même surpris que ce ne soit "que" 33%) - mais ça n'apporte pas vraiment grand chose au débat. La on parle d'un frontal avec une entrée DNS "connue" qui discute avec pleins de serveurs back-end via des entrées DNS qui ne sont normalement pas connues du public et qui ont des reverses qui divergent des noms utilisés par les serveurs frontaux.
Ensuite il ne s'agit pas de sécurité par l'obscurité, la sécurité par l'obscurité consiste à ne pas dévoiler la méthode utilisée - de peur que par l'analyse de la méthode on puisse casser la méthode elle-même et donc rendre nulle la sécurité. La non divulgation, qui consiste non pas à masquer la méthode, mais à ne pas dévoiler l'ensemble des éléments utilisés par l'implémentation spécifique de la méthode est parfaitement normale. Au hasard je dirais, par exemple, que si tu veux utiliser un chiffrement asymétrique RSA, tu ne vas pas divulguer ta clef. Ce n'est pas de la sécurité par l'obscurité, c'est du bon sens.
Ben dans le cas présent c'est la même chose - la méthode est exposée clairement (le reverse est différent des noms utilisés par les serveurs frontaux, les serveurs frontaux sont les seuls (ou presque) à utiliser certains nom de domaines.)
[^] # Re: Juste pour compléter la liste
Posté par gouttegd . Évalué à 1.
Est-ce que la sécurité de ton installation dépend du fait que personne ne connaît ou ne peux trouver le nom abcdefghijkl123.mondomaine.com ?
[^] # Re: Juste pour compléter la liste
Posté par Kaane . Évalué à 2.
Est-ce que la sécurité de ton installation dépend du fait que personne ne connaît ou ne peux trouver le nom abcdefghijkl123.mondomaine.com ?
Non, la sécurité de l'installation ne varie pas. La qualité de service ainsi que la résistance à certaines attaques de type déni de service est améliorée par contre.
Pour être clair, ça n'a aucun impact sur la sécurité des données, la sécurisation des systèmes d'authentification et les injections/corruptions/poisoning - par contre ça empêche de faire de la mitigation. Donc un attaquant qui n'aurait pas les moyens de faire un DDoS sur dix serveurs simultanément, pourrait par contre en choisir trois et les noyer (ce qui aurait un beaucoup plus gros impact sur la qualité du service ressenti).
A noter cependant qu'il ne s'agit pas de "mon" installation. Si je devais faire du DNSSEC, je le ferai très probablement via CloudFlare aujourd'hui. Principalement parce qu’ils ont réussi a encaisser de grosses attaques sur DNSSEC sans s'effondrer.
Je conseille vivement la lecture de ceci https://www.cloudflare.com/dnssec/ecdsa-and-dnssec/ et de cela https://www.cloudflare.com/dnssec//dnssec-complexities-and-considerations/ pour bien comprendre que le couple DNSSEC RSA + pleins de sous domaines = DDoS gratos pour un assaillant.
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . Évalué à 0. Dernière modification le 11 janvier 2016 à 17:43.
Faux.
Si ce domaine héberge un VPN, il devrait obligatoirement présenté un certificat contenant abcdefghijkl123.mondomaine.com, sous peine de casser l’authentification côté client.
Et donc se fera dégommer par ZMap.
Si ce domaine héberge du HTTPS, bien que ça ne soit pas obligatoire, il y a de forte chance d’y trouver aussi un certificat avec le nom réel de la machine en SubjectName et la liste de tous les domaines servis en SubjectAltName, ne serait-ce que pour éviter une erreur flippante si un client se connecte directement dessus. C’est par exemple le cas chez CloudFlare.
SubjectName = CN=ssl277212.cloudflaressl.com
SubjectAltName =
DNS:ssl277212.cloudflaressl.com, DNS:.anglospizza.com, DNS:.bouncyballs.org, DNS:.bursleyburslem.com, DNS:.businessownersideacafe.com, DNS:.coordinatescollection.com.au, DNS:.daanindianfoodonline.com, DNS:.delhi2go-online.co.uk, DNS:.elearnapp.com, DNS:.ellieclothing.com, DNS:.flamesnewcastle.co.uk, DNS:.indianatakeaway.com, DNS:.korben.info, DNS:.lighthousebanff.com, DNS:.mamamia-crewe.com, DNS:.marinosonline.co.uk, DNS:.no1chinesetakeawaykirkcaldy.co.uk, DNS:.p2pchange.is, DNS:.pizza-parlour.co.uk, DNS:.pizzaworld-basingstoke.com, DNS:.predictableprofits.com, DNS:.ricekungfuonline.co.uk, DNS:.rootofspice.com, DNS:.seriesblog.tv, DNS:.thegreenroomjazzcafeonline.co.uk, DNS:.tulipwokonline.com, DNS:.warungbumbuonline.co.uk, DNS:anglospizza.com, DNS:bouncyballs.org, DNS:bursleyburslem.com, DNS:businessownersideacafe.com, DNS:coordinatescollection.com.au, DNS:daanindianfoodonline.com, DNS:delhi2go-online.co.uk, DNS:elearnapp.com, DNS:ellieclothing.com, DNS:flamesnewcastle.co.uk, DNS:indianatakeaway.com, DNS:korben.info, DNS:lighthousebanff.com, DNS:mamamia-crewe.com, DNS:marinosonline.co.uk, DNS:no1chinesetakeawaykirkcaldy.co.uk, DNS:p2pchange.is, DNS:pizza-parlour.co.uk, DNS:pizzaworld-basingstoke.com, DNS:predictableprofits.com, DNS:ricekungfuonline.co.uk, DNS:rootofspice.com, DNS:seriesblog.tv, DNS:thegreenroomjazzcafeonline.co.uk, DNS:tulipwokonline.com, DNS:warungbumbuonline.co.uk
Non, ils indiquent juste qu’effectivement avec de la puissance de frappe on peut énumérer les domaines d’un serveur, et que ECDSA permettrait de minimiser la taille des réponses donc les facteurs d’amplification si ton résolveur DNS sert de vecteur d’attaque DDOS (et non s’il est la cible finale).
Donc ça sera strictement la même chose si tu avais ton propre serveur DNSSec autorité (qui plus est non résolveur pour ne pas pouvoir servir de vecteur d’attaque).
[^] # Re: Juste pour compléter la liste
Posté par Kerro . Évalué à 2.
Les VPN « corrects » ne font pas de reverse, ou du moins pas obligatoirement. Pour la bonne raison que, justement, les reverse ne sont pas souvent disponibles (volontairement ou non).
Et aussi pour la bonne raison que ça amène moins de sécurité que celle du certificat. Cela dit dans certains cas ça peut être un plus, en particulier si utilisation d'un certificat émanant d'une autorité officielle (donc de qualité discutable).
Par exemple OpenVPN ne s'occupe pas de faire un reverse. Ni les VPN présents dans la plupart des appliances (dernièrement j'ai vu du Peplink, du Ubiquiti, et du D-Link).
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . Évalué à 2.
Je ne te parle pas du reverse (DNS) mais du fait que le certificat (X.509) que va présenter le serveur VPN doit obligatoirement correspondre au domaine que le client a saisi dans son client VPN.
Sinon le certificat présenté est invalide et sera rejeté par le client (OpenVPN par exemple).
Et donc le certificat servit par le serveur X.X.X.X doit forcément contenir le nom de domaine private.example.org si c’est celui-ci qui est utilisé par les clients, que X.X.X.X ait pour reverse DNS private.example.org ou duchmol.foo.bar.
Et donc quand zmap va zmapiser tout IPv4, il tombera sur X.X.X.X, lui demandera bien gentiment son certificat en simulant une connexion OpenVPN, regardera le contenu du champ SubjectName ou SubjectAlternativeName et en déduira que c’est un VPN pour la boîte possédant le domaine example.org ainsi que la présence du champ DNS private.example.org, qui ne sera donc plus du tout privé..
[^] # Re: Juste pour compléter la liste
Posté par Kerro . Évalué à 2.
Ah ok, compris.
Je n'ai pas du tout cela avec OpenVPN. Comment as-tu ce problème ?
À moins que le client ne connaisse pas à l'avance la clef publique du serveur (on à alors la même « sécurité » que le cadenas d'un site web : modifier le DNS permet de tout contrôler).
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . Évalué à 0.
Tu as ce problème avec OpenVPN, puisque tu fournis côté serveur une CA (pour valider le client), une clef privée et un certificat, et au client une CA (pour valider le serveur), une clef privée et un certificat.
Le client ne connaît pas à l’avance la clef publique du serveur, c’est même pour ça qu’on lui renseigne une CA qui permettra de garantir que l’émetteur du certificat est bien une personne de confiance.
[^] # Re: Juste pour compléter la liste
Posté par Kerro . Évalué à 2.
Soit tu n'as jamais utilisé OpenVPN, soit tu mélanges les concepts.
Ben non, je n'ai pas ce problème, c'est du sûr et certain à 100% vu que les certificats que JE génère n'ont pas le début de commencement d'un nom de domaine à l'intérieur.
[^] # Re: Juste pour compléter la liste
Posté par Kaane . Évalué à 3.
GNI ??? Déjà de quel type de VPN tu parles ? OpenVPN ? IPSec (et lequel ?) L2TP ? PPTP ? Parce que ces différents systèmes VPN ne nécessitent pas franchement de certificats avec correspondances des noms - en fait ils ne nécessitent même pas de nom résolus au niveau DNS - en IP pure ça passe. Du moment que tu valider le certificat…
En VPN 999 fois sur 1000 le nom de domaine ne sert qu'à simplifier l'installation ou la migration du service vis à vis des collaborateurs.
CloudFlare c'est du frontal, c'est à dire un truc sur lequel le client est supposé se connecter directement - donc je ne comprend pas trop ta remarque. Bien entendu sur un serveur frontal il faut que le SSL contienne tous les alt name. On parle de serveurs back-end là
GNIIII ????
Ce qu'ils disent c'est que c'est casse pied d'avoir tout ses noms de domaines accessibles sur simple requête - que la parade est de passer par de la signature dynamique (au lieu de renvoyer un fichier générique statique - on signe une réponse qui correspond exactement à la demande) - sauf que bien sur la signature dynamique oblige à avoir les clefs privées sur tous les résolveurs (perso je suis pas fan) et qu'en plus l'algo par défaut pour la signature est RSA (c'est d'ailleurs le seul algo obligatoire) - sauf que RSA ça bouffe du CPU comme un goret, et que du coup si tu te prends une attaque - ton résolveur va exploser.
Donc ils demandent à ce que la signature par défaut passe par de l’elliptique qui va quand même 10 fois plus vite - ce qui permet de rester serein un peu plus longtemps quand on se prend une attaque par réflexion.
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . Évalué à 1.
OpenVPN et IPSec, c’est basé sur X.509, donc ça contient forcément un Subject(Alt)Name dans le certificat sauf à ce que les clients s’y connectent via l’IP directement dans leur client VPN. Si le subject(alt)name ne matche pas le TEXTE saisi par le client (et non pas sa résolution ni même son existence DNS ou reverse), alors le certificat est invalide (on peut aussi insérer des IP:X.X.X.X dans le certificat, mais c’est assez très rare).
L2TP et PPTP, je connais moins, mais en tout cas L2TP utilise aussi apparament X.509.
[^] # Re: Juste pour compléter la liste
Posté par Kaane . Évalué à 3.
Il faut en effet que les DN/CN coté client correspondent à ceux coté serveurs. A aucun moment on est obligé de déranger un DNS pour ça. (Généralement d'ailleurs, on fait sans.)
Je ne vois toujours pas en quoi ça permettrait à ZMAP de trouver des reverses alternatifs sur mon serveur VPN…
[^] # Re: Juste pour compléter la liste
Posté par Sufflope (site web personnel) . Évalué à 2.
Je ne sais pas comment fonctionnent les VPN mais votre dialogue de sourd me désole alors je tente. S'il n'y a pas de mécanisme type SNI et si c'est bien, comme HTTPS, du XYZ encapsulé dans du TLS (pas comme STARTTLS donc) la connexion chiffrée doit être établie avant que le serveur puisse savoir vers quel VPN hébergé le client veut se connecter. Il faut donc qu'il ait (comme à une époque avec HTTPS) un seul certif fourre-tout à présenter quand on se connecte en causant VPN sur le port en question. Je ne sais pas si c'est comme ça que ça marche, mais vos réponses à côté de la plaque au lieu de comprendre ce qu'il essaie d'expliquer ne me donnent pas confiance concernant vos autres réponses (dommage j'étais presque convaincu par les histoires de mitigation d'attaques ciblées).
[^] # Re: Juste pour compléter la liste
Posté par Kaane . Évalué à 2.
Très rapidement, on peut effectivement envisager de faire fonctionner un VPN comme ça - mais je n'ai jamais vu ce type de config être faite.
De façon générale, le serveur de VPN est directement devant le réseau ciblé - on pourrait s'amuser à faire du routage/vlan via des réseaux tiers, mais ça serait un peu aller contre le principe même du VPN.
Le plus souvent un VPN va fonctionner soit avec échange direct des clefs (IE la société qui fournit le VPN paramètre aussi la machine et du coup en profite pour faire l'échange de certificat/clef publiques à ce moment là) - soit on pousse le client à créer sa propre paire clef publique/clef privée et on ajoute lui demande de transmettre la clef publique par mail/site web/ftp - Ou alors on se contente de filer bêtement un couple login/mot de passe, par exemple par téléphone.
Il est rarissime qu'un service VPN utilise un tiers de confiance (type verisign) et des certificats contre signés - Ça arrive parfois en bancaire, sur certaines plateformes de trading - généralement sur des réseaux dédiés (IE non routés sur internet).
Tout ça pour dire que mon serveur peut avoir comme reverse truc.chose.tld, comme nom de domaine accédé par le client waouh.super.net, comme domaine cible (IE une fois la connexion VPN établie) un.deux.test et avoir un certificat avec comme DN : CN=tutu, CN=titi, DC=pipo, DC=root - du moment que le certificat est reconnu par le client comme valide pour le domaine cible ça va passer.
En ce qui concerne la mitigation d'attaque - tu n'es pas obligé de me croire sur parole (encore heureux) - mais je t'invite à lire les docs que j'ai linké chez CloudFlare qui sont raisonnablement accessibles (Oui parce que les docs sur les systèmes de cryptographie ça devient vite pénible pour le non initié).
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . Évalué à 0. Dernière modification le 11 janvier 2016 à 23:54.
Non justement.
Si ton client se connecte au serveur VPN via waouh.super.net (qui résout via le DNS en X.X.X.X et X.X.X.X qui reverse en truc.muche.org), il faut obligatoirement que le certificat soit valide pour ce nom, donc :
Tout aute valeur de CN ou de SubjectAltName ne validerait pas la connexion.
(/CN=X.X.X.X ne serait pas valide puisque le matching est fait en comparant strictement avec le nom saisi par l’utilisateur, ici waouh.super.net)
La plupart du temps/sur les configs VPN classiques, c’est /CN=waouh.super.net (moins couramment avec en plus SubjectAltName=DNS:waouh.super.net), et donc le domaine waouh.super.net ne peut pas rester caché (même avec un reverse IP qui donne autre chose) et sera détecté par ZMap (scan de la plage IP, passage sur X.X.X.X, récupération du certificat présenté, obtention du CN ou SubjectAltName).
À noter que la CA émmettrice n’a aucun impact ici, ZMap ne cherchera pas à vérifier la validité réelle du certificat et donc en auto-signé, en signé par une root CA connue ou par une root CA interne, le domaine de connexion du VPN leakera dans tous les cas.
[^] # Re: Juste pour compléter la liste
Posté par Kaane . Évalué à 2.
Non.
Tu te connecte à ce que tu veux - la validation du VPN ce fait après. Tu confonds avec SSL.
La plupart des systèmes VPN utilisent un certificat X509 - mais il est rarissime qu'il y ait une architecture PKI derrière. De toutes façons la première étape de quasiment tous les VPN est de créer un tunnel puis de faire la validation par ce tunnel.
Tout ce qui se passe dans le tunnel est déjà privé. J'ai des VPN vers des domaines locaux, à savoir tu te connectes au VPN par IP ou par un DN classique, mais une fois le VPN monté ta carte virtuelle est sur mondomaine.local. Le certificat signe mondomaine.local et c'est le seul certif que le client valide.
Donc ZMAP ne peut rien faire.
Non plus, ils parlent aussi (brièvement) des cas d'amplification d'attaque (auquels ils ne participent pas grâce à différentes techniques qu'ils aimeraient bien voir se rependre) - mais ils se focalisent surtout sur les signatures dynamiques avec ECDSA qui permettent d'éviter les énumérations de domaine.
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . Évalué à 0.
La validation du VPN se fait à l’établissement de la connexion.
Tu ne peux pas te connecter à un VPN qui présenterait un certificat invalide pour le domaine auquel tu te connectes.
T’as pas besoin d’une PKI au sens littéral du terme, mais tu as a minima besoin d’une CA qui puisse émettre les certificats clients et serveurs, que l’un et l’autre puisse
Totalement faux. Ça serait même du délire au niveau sécurité, puisque tu pourrais te prendre un bon gros MitM dans la tronche sans rien pouvoir détecter.
Si tu veux être en sécurité, tu dois valider AVANT l’établissement du tunnel sécurisé que tu discutes avec la bonne personne.
Non, pas si tu n’as pas validé AVANT l’établissement du tunnel que tu discutais avec la bonne personne et qu’il n’y avait pas un attaquant sur ta ligne qui pourrait alors lire l’intégralité de tes communications.
Si ton certificat contient mondomaine.local, alors mondomaine.local ne sera pas privé et sera détecté par ZMap.
Cf démonstration précédente, ce certificat leakera bien gentillement au passage de ZMap.
[^] # Re: Juste pour compléter la liste
Posté par Kerro . Évalué à 2.
Sur mon OpenVPN perso j'ai CN="cn" et chez la plupart de mes clients j'ai CN="" (le but est de limiter la fuite d'informations).
Les VPN de chez D-Link et autres, on les dirige vers une IP fixe et basta. Ou vers un nom de domaine géré par un DNS dynamique, ça fonctionne aussi. Jamais dans la configuration du D-Link « serveur » on indique qu'il doit génèrer un certificat avec tel ou tel nom.
Tu as peut-être forcé la vérification de concordance entre le CN et l'adresse ?
Par exemple avec OpenVPN c'est un script de vérification qu'il faut créer soi-même, indiqué par l'option auth-user-cn-verify.
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . Évalué à 1.
Encore une fois, la doc de CloudFlare n’est pas de la mitigation d’attaque, mais de la diminution d’amplification d’attaque.
Ce n’est pas CloudFlare qui est visé directement par le DDOS, mais CloudFlare qui génère le DDOS.
Un attaquant Y souhaitant massacrer un serveur X va envoyer des tonnes de requêtes DNS (via UDP donc) avec un spoof de l’IP source en X.
Si le domaine est signé par DNSSec, alors la requête DNS faite par l’attaquant à un serveur DNSSec de CloudFlare est très courte (par exemple pour le NSEC3 q0da90gqv16l28ro6i5s6ce4ogqe0cp4.imirhil.fr, la question est
Type50? q0da90gqv16l28ro6i5s6ce4ogqe0cp4.imirhil.fr. (72)= 58 octets) mais la réponse est TRÈS longue (je vous passe les détails, mais elle fait 1074 octets).L’IP source étant spoofée (merci UDP), cette réponse ne va pas retournée chez l’attaquant, mais chez l’attaqué !
Du coup, on a un traffic de 58Mbps entre l’attaquant et CloudFlare (une simple ligne fibre classique suffit), mais un trafic entre CloudFlare et l’attaqué de 1.074Gbps (facteur d’amplification de 18) !
Si en plus l’attaquant a le bon goût de contrôler un petit botnet d’une centaine de machines, c’est 100×50Mbps = 5Gbps de traffic qui se transforme en 100×1Gbps = 100Gbps chez l’attaqué… Rideau…
Là je n’ai que ×18 d’amplification, mais on peut monter à ×4000 sans soucis avec les bonnes requêtes DNS qui vont bien et des serveurs résolveurs mal configurés (genre avec le AXFR actif, qui vont transformer « AXFR? imirhil.fr » (17 octets) en le dump intégral de ma zone DNSSec (69885 octets, soit amplification ×4110)) .
Si en plus CloudFlare a le bon goût d’avoir voulu protégé ses propres clients d’un listing de domaine via DNSSec, ce qui impose de resigner à la volée les zones, alors CloudFlare va aussi s’écrouler, puisque les millions de requêtes DNSSec qui vont lui être faites vont littéralement lui faire exploser tous ses CPU, et se faire DDOS par elle-même.
De simple vecteurs d’attaque, CloudFlare devient une victime collatérale du DDOS.
La position de CloudFlare est donc la suivante : si ECDSA était utilisé dans DNSSec, ça diminuerait déjà de beaucoup les amplifications DNS possibles (une signature ECDSA est beaucoup plus courte que RSA), mais en plus si CloudFlare était quand même vecteur malencontreux d’un DDOS, elle ne se DDOSerait pas elle-même à coup de CPU-burn (ECDSA beaucoup plus léger en calcul que RSA).
Ce que CloudFlare dénonce, c’est donc valable pour tout les serveurs DNSSec faisant autorité qui peuvent se retrouver par mégarde vecteur d’amplification d’un DDOS, et tomber eux-même s’ils ont activé les protections contre le domaine listing.
CloudFlare n’est pas plus sécurisé que les autres, puisque ECDSA n’est actuellement pas déployable dans DNSSec, c’est d’ailleurs ce qu’ils aimeraient voir adopter bien plus vite que ce qui n’est actuellement le cas.
[^] # Re: Juste pour compléter la liste
Posté par Kerro . Évalué à 2.
En gros tu peux voir un VPN comme du SSH avec connexion automatique.
Aucun besoin d'avoir un nom de domaine ou quoi que ce soit.
[^] # Re: Juste pour compléter la liste
Posté par Kerro . Évalué à 2.
Scanner toute les IP ne te permet pas de savoir par qui elles sont utilisées.
Sauf si tu fais volontairement en sorte que le reverse-lookup donne l'information, ce qui n'est utile que pour les machines « publiques » pour lesquelles on a déjà l'information.
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . Évalué à 1.
Ben si, tu le sais.
Si ça répond un truc, c’est que c’est utilisé.
Si ça te donne des certificats qui sont tenus à jour, c’est que c’est utilisé.
Et avec les noms contenus dans les certificats, tu sais parfaitement qui utilise telle IP.
C’est encore plus flagrant avec le VPN, qui à l’inverse de HTTPS ne supporte pas de SNI donc possède nécessairement une info utile sur le nom de domaine dans le certificat X.509 présenté (si tu scannes X.X.X.X et que tu tombes sur un VPN, tu regardes le nom de domaine du certificat présenté, tu en déduis le nom de domaine utilisé par les clients pour se connecter, 99% de chance que ça soit un nom de domaine parlant et sur un sous-domaine du client final).
[^] # Re: Juste pour compléter la liste
Posté par Kaane . Évalué à 3.
J'ai jamais compris cet argument. Y en a qui nomment leurs serveurs avec leurs numéros de CB ? La sécurité du backoffice repose sur le postulat que personne ne tapera lebackoffice.maboite.com ?
Il y a plusieurs cas ou tu n'as vraiment pas envie d'exposer tous les noms DNS possibles et imaginables.
Par exemple si tu as un cluster de serveur derrière un load balancer. Pour tout un tas de raisons tu peux vouloir que les clients passent par ton load balancer (server.mondomaine.tld) , mais avoir besoin d'exposer tes machines directement pour la maintenance (srv1.mondomaine.tld, srv2.mondomaine.tld etc.)
Autre exemple, en cas de migration de serveur ou de montée de version - tu peux vouloir que les clients passent par un autre serveur (par exemple un serveur de maintenance) sans pour autant que le dit serveur soit normalement visible.
Pour finir quand tu donnes la liste des serveurs accessibles depuis l'extérieur via DNS, tu files au passage les IP desdits serveurs - ça peut permettre à des personnes mal intentionnées de voir chez qui tu es hébergé, ou sont tes peerings, quelles sont les parties les moins redondées de ton réseaux (SPOF entre autres) et ça simplifie grandement les attaques.
# Implémentation de DANE TLSA dans nos navigateurs ?
Posté par Régis . Évalué à 1.
À votre avis est-ce que nous allons bientôt avoir une implémentation de DANE dans nos navigateurs ?
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities
Car vu que cela a été retiré de chrome et que la page chez Mozilla n'a pas été mise à jour depuis 2011 :
https://wiki.mozilla.org/Security/DNSSEC-TLS-details
Nous pouvons légitimement penser que ce projet est mort-né. Pourtant il aurait grandement amélioré la sécurité et empêché l'utilisation de vrais-faux certificats pour les gouvernements et les faux certificats par les entreprises.
Ne devrions-nous pas lancer une pétition afin que Mozilla et Chrome le supporte ?
[^] # Re: Implémentation de DANE TLSA dans nos navigateurs ?
Posté par Zenitram (site web personnel) . Évalué à -3.
Est-ce que DANE protège de paypa1.com ? (bien regarder le nom)
Si non, problème de fishing, donc inutile.
J'ai cru comprendre que c'est pour ce genre de raison que DANE n'a été que peu valorisé par les navigateur (qu'en gros, on veut que quelqu'un vérifie contre le fishing, même si c'est qu'un peu, que de faire confiance aux sites seuls).
donc avant de faire une pétition, peut-être regarder pourquoi Mozilla et Google ont jugé la chose "pas intéressante" et préparer un contre-argumentaire. Tu es prêt à le faire?
[^] # Re:Implémentationde DANE TLSA dans nos navigateurs ?
Posté par Juke (site web personnel) . Évalué à 9.
et les CA ?
[^] # Re: Implémentation de DANE TLSA dans nos navigateurs ?
Posté par Régis . Évalué à 1.
Tu as des sources sur le sujet ?
Est-ce que ce ne serait pas le rôle des CA de faire ce job ? Actuellement ils signent tout et n'importe quoi.
Sans tomber dans la paranoïa, si ce protocole est implémenté cela nuirait à beaucoup de monde (Les vrais faux-certificats des êtats, les faux certificats des employeurs) voire même une profonde remise en question de l'intérêt même des CA.
Toi même tu reconnais dans un autre journal, la connerie des CA :
http://linuxfr.org/users/zenitram/journaux/ssl-ev-etendue-oui-validation-euh
[^] # Re: Implémentation de DANE TLSA dans nos navigateurs ?
Posté par Zenitram (site web personnel) . Évalué à 1.
J'ai lu, je ne sais plus où.
Edit : ha si, lien dans le journal.
https://www.imperialviolet.org/2011/06/16/dnssecchrome.html
Faut lire les liens ;-).
Est-ce vraiment la raison?
encore une fois, vaut mieux avoir des contre-arguments costaux, le coup de "ha ça fait chier les CA donc ils bloquent", ça va convaincre les conspirationnistes mais à part ça…
Remplacer du "marche pas bien" par du "encore pire" n'est pas la conclusion du journal.
[^] # Re: Implémentation de DANE TLSA dans nos navigateurs ?
Posté par Sufflope (site web personnel) . Évalué à 7.
Je suppose que t'as viré les airbags de ta voiture qui sont inutiles puisqu'ils ne te sauveront pas si tu te fous à la flotte.
[^] # Re: Implémentation de DANE TLSA dans nos navigateurs ?
Posté par gouttegd . Évalué à 2.
À mon avis ? Non, en tout cas pas une implémentation « native » (intégrée par défaut de base dans le navigateur). Je ne sais pas pour Firefox, mais les devs de Chrome ont clairement fait savoir que ce n’était pas au programme.
En attendant, il y a toujours ce plugin que je ressors à chaque discussion sur le sujet. Et (attention, auto-promotion éhontée) ma propre implémentation pour Uzbl.
[^] # Re: Implémentation de DANE TLSA dans nos navigateurs ?
Posté par gouttegd . Évalué à 3.
À noter tout de même le travail de Viktor Dukhovni (a.k.a « Monsieur DANE », auteur ou co-auteur d’à peu près tous les RFCs sur DANE, et auteur de l’implémentation correspondante dans Postfix) pour implémenter DANE directement dans OpenSSL, où ça aura un bien plus grand impact (pouvant bénéficier à une tripotée d’applications) que dans un seul navigateur.
# Contre DNSSEC
Posté par Mildred (site web personnel) . Évalué à -3.
http://sockpuppet.org/blog/2015/01/15/against-dnssec/
[^] # Re: Contre DNSSEC
Posté par Aeris (site web personnel) . Évalué à 1.
Mais rien que pour DANE/TLSA, ça permet de fixer en partie le gros problème de la confiance en les CA, et rien que ça ça a le mérite d’exister et d’être promu !
[^] # Re: Contre DNSSEC
Posté par Antoine . Évalué à 4.
Plutôt que de fixer le problème, ne vaudrait-il mieux pas le résoudre ?
[^] # Re: Contre DNSSEC
Posté par Misc (site web personnel) . Évalué à 2.
Je ne suis pas d'accord sur "coute à utiliser et à déployer". Si tu fait les choses à la main, ouais. Mais entre temps, on a des trucs qui existent et qui font ça pour toi. Exemple, j'utilise freeipa, et ça le fait sans souci, cf howto
https://www.freeipa.org/page/Howto/DNSSEC
(ça fait aussi vachement la CA interne quand il faut, avec renouvellement, etc).
Et dire que c'est une architecture de sécurité contrôlé par le gouvernement, c'est sur l'internet publique. Tu peux avoir ton réseau interne aussi si tes contraintes de sécurité le requiert.
[^] # Re: Contre DNSSEC
Posté par claudex . Évalué à 6.
Non, c'est d'ailleurs pour ça que les navigateurs ne mettent pas une erreur franche quand il y a un problème de certificat et qu'ils permettent de la contourner.
Bien moins que les CA actuelles, tu peux d'ailleurs prendre un .cn et être à l'abri des US.
Oui, TLS aussi.
Pour une clef qui est changé très régulièrement. Si tu as des infos comme quoi tu casse le RSA 1024bits en temps réel, tu as la gloire assurée
Non, il faut relire les RFC
Pour ceux qui ne configure pas correctement. Mais c'est déjà le cas actuellement.
Je n'ai rien compris à ce paragraphe
C'est navrant de dire que ce n'est pas incontournable sans donner d'alternative.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.