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).
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.
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
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.
Je suis un peu ce que tu fais, et je sais pas pourquoi tu mets toute la faute sur les opérateurs de serveurs.
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).
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
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.
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?
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…)…
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.
En fait on a un vrai problème avec TLS parce que la dépendance est double :
On pourrait mettre à jour tous nos serveurs pour ne supporter que du TLSv1.2 + ECHDHE + AES-GCM, mais du coup on exclurait tous les anciens navs’ qui ne supportent pas AES ou pas TLSv1.2, ou pas ECHDHE…
On pourrait mettre à jour tous nos navigateurs pour ne supporter que du TLSv1.2 + ECHDHE + AES-GCM, mais du coup on exclurait tous les anciens serveurs qui ne supportent pas TLSv1.2.
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…
Est-ce qu'il y a une proof of concept qui montre un downgrade de suite de chiffrement
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 ».
Faible a priori si client et serveur supportent le mécanisme anti-repli
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).
(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").
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.
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.
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).
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
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.
Et comme tu le dis toi-même, la majorité des sites supporte déjà PFS.
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.
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.
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.
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…)
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.
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.
J0 : publication de K1 (utilisée) et K2 (backup)
J1 ≥ J0+X : K1 est compromise, on peut immédiatement basculer sur K2 et publier K2 (U) et K3 (B), les visiteurs antérieurs à J0 sont expirés, les postérieurs possèdent bien K2
J2 ≥ J1+X : on décide de changer volontairement K2, on bascule immédiatement sur K3 et on publie K3 (U) et K4 (B), les visiteurs antérieurs à J1 sont expirés, les postérieurs possèdent bien K3
etc
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…
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…
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é.
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).
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.
Après cela dépend si vous avez prévenu le client ou pas
Même quand on prévient longtemps à l’avance, les correctifs ne sont jamais fait avant d’avoir plus que dépassé la ligne rouge…
Même les root CA à la base de la base de la sécurité de HTTPS se réveillent 3 moins avant une dead-line annoncée depuis 3 ans déjà et annoncent qu’elles dépasseront cette dead-line d’au moins 1 an…
Windows XP est toujours en vie et non patchable alors qu’il ne supporte pas autre chose que SSLv3, idem pour les distributeurs de billet…
La dette technique est tellement monstrueuse sur le sujet que personne ne souhaite faire d’effort parce que ça lui coûterait trop (en matériel, en développement, en perte de client, de chiffre d’affaire ou de part de marché).
Les seules évolutions notables sur le sujet sont toujours venus des navigateurs, et en imposant une décision unilatérale violente (SHA-1, RC4, SSLv3, désactivation des plugins…)
La vérification de la validité du certificat ne DOIT pas être faite et est de toute façon très difficile à faire.
Les RFC l’indiquent clairement, on ne peut faire la supposition que les valideurs potentiels auront une stack de CA correctes à disposition, en plus d’avoir des problèmes de détermination du domaine à valider (une vérif du domaine de destination est impossible par manque de SNI sur SMTP et le domaine du MX est faillible par l’attaque que tu annonces).
Les serveurs de soumission, ce sont tes propres clients qui les utilisent, tu as donc la main dessus et tu peux imposer de la crypto correcte et obligatoire dessus.
Les MX, tout le monde peut les utiliser, et donc tu ne maîtrises pas du tout la configuration TLS minimale qu’ils vont supporter ou non. Il faut donc être le plus laxiste dessus.
Donc sur du submission (587), TLS (natif, pas STARTTLS) imposé avec config draconienne (les MUA thunderbird/outlook/kontact/claws-mail supportent une crypto correcte), sur du smtp (25), STARTTLS facultatif avec le maximum de ciphers actives (mauvais support de la crypto par la plupart des MTA, dont les scripts PHP moisis de mailing et autre).
Ils veulent ne plus avoir à toucher à leur config d’ici 2020. Ça signifie que tout le reste sera désactivé à plus ou moins court terme, et de force dans les prochaines versions de leur navigateur (ça a commencé avec RC4, ça sera SHA-1 au 1er janvier 2016, puis 3DES et TLS < 1.2).
Sauf que dans ton exemple c'est pas un utilisateur lambda. C'est un CA
Oui, mais je pars du principe que si une CA a 3 ans de retard en terme de mise-à-jour, un utilisateur lambda doit en être à 10 ou 15 ans :P
Et les CA n’ont pas fait la migration justement pour la bonne raison « qu’on ne veut pas perdre nos utilisateurs sous WinXP ou qu’on ne veut pas migrer nos applis inmaintenables ». Idem pour la sécu des banques : « on ne veut pas voir notre support exploser ni perdre 1% de chiffre d’affaire ».
Poule, œuf, tout ça tout ça…
Si on veut améliorer la sécu, ça va « forcément » passer par une décision unilatérale et violente des navigateurs et autres, qui va laisser beaucoup de monde sur le carreau.
Cf par exemple la position de Google sur le sujet qui est encore plus extrémiste que moi : https://googleonlinesecurity.blogspot.sg/2015/09/disabling-sslv3-and-rc4.html.
TLS 1.2 avec du AES-GCM (ça ça pique vraiment vu le très mauvais support actuel) et du ECDSA P-256 (idem, ça pique beaucoup), c’est actuellement bien indiqué comme « la configuration pérène jusqu’en 2020 qui ne nécessitera pas de revoir sa configuration tous les 6 mois ».
Pourquoi Noos aurait-il la note M et Orange la note F alors que Noos est capable du meilleur (TLS 1.2, PFS) comme du pire (anonymous, SSL2). Orange ne proposant TLSv1 (avec PFS), SSLv3
« M » = certificat mismatch. C’est-à-dire qu’un utilisateur se taperait une alerte de sécurité puisque le certificat ne correspond pas au domaine à protéger.
À la lecture des différentes commentaires qui appuient bien sur la grosse dette historique de SMTP, on ne peut pas utiliser les mêmes critères de jugement.
Tout à fait. Mettre un « A » en place sur SMTP, c’est forcer 90% (au doigt mouillé) du trafic SMTP à passer en clair puisque le serveur en face n’arrivera pas à négocier une suite de chiffrement.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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 Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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 Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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 Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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 Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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 Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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 Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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 Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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 Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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 Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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 Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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 Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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 Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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 Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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: Outil de test + STARTTLS
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 3. Dernière modification le 13 octobre 2015 à 15:44.
Même quand on prévient longtemps à l’avance, les correctifs ne sont jamais fait avant d’avoir plus que dépassé la ligne rouge…
Même les root CA à la base de la base de la sécurité de HTTPS se réveillent 3 moins avant une dead-line annoncée depuis 3 ans déjà et annoncent qu’elles dépasseront cette dead-line d’au moins 1 an…
Windows XP est toujours en vie et non patchable alors qu’il ne supporte pas autre chose que SSLv3, idem pour les distributeurs de billet…
La dette technique est tellement monstrueuse sur le sujet que personne ne souhaite faire d’effort parce que ça lui coûterait trop (en matériel, en développement, en perte de client, de chiffre d’affaire ou de part de marché).
Les seules évolutions notables sur le sujet sont toujours venus des navigateurs, et en imposant une décision unilatérale violente (SHA-1, RC4, SSLv3, désactivation des plugins…)
[^] # Re: Chiffrement opportuniste
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 3.
Cf plus bas.
La vérification de la validité du certificat ne DOIT pas être faite et est de toute façon très difficile à faire.
Les RFC l’indiquent clairement, on ne peut faire la supposition que les valideurs potentiels auront une stack de CA correctes à disposition, en plus d’avoir des problèmes de détermination du domaine à valider (une vérif du domaine de destination est impossible par manque de SNI sur SMTP et le domaine du MX est faillible par l’attaque que tu annonces).
[^] # Re: Outil de test + STARTTLS
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 3.
Non, c’est bien l’inverse.
Les serveurs de soumission, ce sont tes propres clients qui les utilisent, tu as donc la main dessus et tu peux imposer de la crypto correcte et obligatoire dessus.
Les MX, tout le monde peut les utiliser, et donc tu ne maîtrises pas du tout la configuration TLS minimale qu’ils vont supporter ou non. Il faut donc être le plus laxiste dessus.
Donc sur du submission (587), TLS (natif, pas STARTTLS) imposé avec config draconienne (les MUA thunderbird/outlook/kontact/claws-mail supportent une crypto correcte), sur du smtp (25), STARTTLS facultatif avec le maximum de ciphers actives (mauvais support de la crypto par la plupart des MTA, dont les scripts PHP moisis de mailing et autre).
[^] # Re: Outil de test + STARTTLS
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 1.
Point à noter aussi. La NSA vient de dropper le support de AES-128 (AES-256 recommandé) ainsi que de SHA-256 (SHA-384 minimum).
https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml
Des failles existantes qu’elle connaîtrait et pas nous ? :D
[^] # Re: Outil de test + STARTTLS
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 2.
Faut savoir lire entre les lignes :D
Ils veulent ne plus avoir à toucher à leur config d’ici 2020. Ça signifie que tout le reste sera désactivé à plus ou moins court terme, et de force dans les prochaines versions de leur navigateur (ça a commencé avec RC4, ça sera SHA-1 au 1er janvier 2016, puis 3DES et TLS < 1.2).
[^] # Re: Outil de test + STARTTLS
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 1.
Oui, mais je pars du principe que si une CA a 3 ans de retard en terme de mise-à-jour, un utilisateur lambda doit en être à 10 ou 15 ans :P
Et les CA n’ont pas fait la migration justement pour la bonne raison « qu’on ne veut pas perdre nos utilisateurs sous WinXP ou qu’on ne veut pas migrer nos applis inmaintenables ». Idem pour la sécu des banques : « on ne veut pas voir notre support exploser ni perdre 1% de chiffre d’affaire ».
Poule, œuf, tout ça tout ça…
Si on veut améliorer la sécu, ça va « forcément » passer par une décision unilatérale et violente des navigateurs et autres, qui va laisser beaucoup de monde sur le carreau.
Cf par exemple la position de Google sur le sujet qui est encore plus extrémiste que moi : https://googleonlinesecurity.blogspot.sg/2015/09/disabling-sslv3-and-rc4.html.
TLS 1.2 avec du AES-GCM (ça ça pique vraiment vu le très mauvais support actuel) et du ECDSA P-256 (idem, ça pique beaucoup), c’est actuellement bien indiqué comme « la configuration pérène jusqu’en 2020 qui ne nécessitera pas de revoir sa configuration tous les 6 mois ».
[^] # Re: Outil de test + STARTTLS
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 1.
« M » = certificat mismatch. C’est-à-dire qu’un utilisateur se taperait une alerte de sécurité puisque le certificat ne correspond pas au domaine à protéger.
Tout à fait. Mettre un « A » en place sur SMTP, c’est forcer 90% (au doigt mouillé) du trafic SMTP à passer en clair puisque le serveur en face n’arrivera pas à négocier une suite de chiffrement.