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.
"3DES is considered weak and must be avoided, using it cap your score to "C"."
Alors que la RFC 7525 qui te sert de référence dit le contraire :
3DES a un autre biais, sa taille de bloc, qui n’est que de 64 bits, soit bien trop faible.
L’ANSSI déconseille aussi ce cipher (cf http://www.ssi.gouv.fr/uploads/2015/01/RGS_v-2-0_B1.pdf page 10 & 11) et recommande au moins du 128 bits (en taille de clef & en taille de bloc).
Je me pose des questions car ce "perfect" bloque plein d'utilisateurs considérés encore comme sûrs, c'est "perfect" vis à vis de quoi?
C’est « perfect » au sens qu’on n’a aucun des warning/erreurs précédents.
il est imparfait si il bloque des utilisateurs sans raison de sécurité au moment du test
Faux.
Le fait d’avoir du 3DES actif côté serveur suffit à pouvoir tomber dessus en cas de mauvaise configuration (ordre des suites côté client) ou en cas d’attaque (downgrade attack).
On n’est donc pas à l’abris d’une merde dès que 3DES est dispo quelque part.
On a aussi vu que le non support de PFS exposait violamment à la NSA (par exemple via Heartbleed) en cas de compromission de la clef privée dans le futur.
Idem, sauf à utiliser uniquement des suites PFS (puisque la présence d’une non PFS rendrait la connexion potentiellement non fiable), on est à poil.
Du coup, un serveur du monde réel qui ne veut pas se couper de gens sans raison de sécurité en 2015 se tape un "C" sur cryptcheck la où il obtient un "A+" sur SSLLabs…
Ne pas se couper des gens à l’heure actuelle, c’est exploser en plein vol à la prochaine grosse faille de sécu sur ces protocoles. TLSv1.0 & TLSv1.1 sont dorénavant faillibles à du Poodle, et une escalade de cette faille rendrait vulnérables tous les utilisateurs de ces protocoles.
La note « A » est donc la seule configuration valable actuellement qui résistera dans le temps et évitera d’avoir à patcher à l’arrache (ou non, cf RC4 & MD5 qui persistent malgré les risques…).
Tant qu’on ne fait pas mal à l’utilisateur, la sécu ne s’améliore pas. La preuve, même les CA ne savent pas commencer à bosser avant d’être plus que le dos au mur (voire même plutôt déjà encastrées dedans), cf https://cabforum.org/pipermail/public/2015-September/005935.html
Postfix permet d'éviter cela en vérifiant à la place que le certificat utilisé couvre bien le nom de domaine destinataire
C’est plus compliqué que ça.
En pratique, il ne faut pas vérifier le nom de domaine du certificat, car à l’inverse de HTTPS, SMTP+STARTTLS ne permet pas SNI, ie. de sélectionner un certificat pour chaque domaine de destination, sauf à sous-entendre que 1 domaine = 1 serveur SMTP & 1 IP.
C’est par exemple particulièrement vrai pour les fournisseurs mutualisés, comme OVH, Google ou Microsoft, qui n’ont qu’un seul MX pour l’ensemble des domaines servis.
Au mieux on pourrait seulement vérifier que domaine du certificat = domaine du MX (ou de son reverse), mais en aucun cas la vérification domaine du certificat = domaine du récepteur n’est possible. Une usurpation du DNS ne pourra donc pas être détectée par ce moyen.
De plus, les RFC mentionnent aussi qu’il faut considérer que les serveurs SMTP émetteurs n’ont pas les compétences nécessaires pour vérifier la chaîne de validité, par exemple pas de liste de CA valides (cf https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13#section-3.1.3).
Un MitM serait dans tous les cas facilement faisables, via un simple certificat auto-signé usurpant le domaine visé…
En clair, le mail est non sécurisable parce que personne ne l’a envisagé comme ça quand il a été définit au début du monde, et toutes les couches de sécu actuelles sont des hacks plus ou moins ignobles et (in)efficaces pour corriger le tir.
Le problème de la notation pour le mail, c’est que c’est beaucoup plus compliqué que pour HTTPS, SMTP étant un protocole asynchrone. En particulier, il vaut mieux utiliser un protocole totalement moisi comme SSLv3, DES ou MD5 que d’émettre le message en clair, ce qui est le cas si les 2 serveurs n’arrivent pas à se mettre d’accord sur une suite de chiffrement.
Un serveur noté « F » n’est donc pas complètement anormal tant qu’on aura pas améliorer l’ensemble des serveurs du monde.
À noter aussi que la présence (ou l’absence) de STARTTLS n’est pas authentifiée comme dans le cas de HTTPS, et donc qu’un attaquant dans le réseau n’a qu’à simplement droper le petit paquet réseau contenant la chaîne « STARTTLS » dans les échanges SMTP pour que le serveur émetteur considère que le destinataire ne supporte pas le chiffrement et envoie alors le message en clair.
C’est à la portée de n’importe qui, y compris d’un pixel sur le parvis de la Défense avec un routeur TP-Link à $20… Je vous laisse le soin de comprendre ce qu’une agence gouvernementale est capable de faire sur le sujet :)
Les 2 cumulés, sauf à avoir de sérieuses preuves scientifiques que leur système a fait mieux sur ces 2 domaines, c’est juste un no-go.
Et en prime, vouloir faire du mail « sécurisé », quand on sait ce que leak comme méta-données ce protocole, c’est plus ou moins du suicide aussi.
Pour finir, la même question qu’on devrait toujours se poser avant de parler de sécurité : c’est quoi le modèle de menace ?
Whiteout annonce même clairement qu’ils n’en ont pas et que c’est à l’utilisateur de bâtir le sien et de savoir s’il peut utiliser ce service : https://whiteout.io/security.html « So it's best to decide which threat model applies to you. »
Sans plus d’infos techniques à disposition de l’utilisateur pour qu’il puisse réellement faire cette réflexion, inutilisable aussi.
Allez, encore un petit effort pour le A+ sur SSLLabs :D
Il y a encore du RC4 qui traîne et quelques navigateurs sans Forward Secrecy.
Et il manque aussi le support de HSTS.
Les configs qui vont bien : http://www.iletaitunefoisinternet.fr/ssltls-benjamin-sonntag/
Les sources des bannières étant publiques, tu pouvais très bien supprimer ces boutons.
Et même héberger chez toi ces pages pour éviter le tracking.
C'est ce qui a été fait sur le site de l'April (avec en prime la traduction en Français).
Quitte à défendre une cause, autant commencer par se l'appliquer à soi-même :)
Et la « norme » est totalement incomplète, avec des gros passages de type « pour cette fonction super utile, cf spec privée non publique d'une techno privatrice qu'on gardera bien pour nous »
L'objectif est de faire quoi ? Juste de gérer tes propres certificats ?
Ou de vraiment mettre en place une vraie PKI au sens large, avec livraison des certificats aux clients de manière sécurisée, gestion de la révocation, OSCP et le reste ?
Dans le 1er cas, EJBCA et OpenCA me paraissent juste overkill, XCA est bien plus simple pour une utilisation personnelle.
[^] # 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.
[^] # Re: Outil de test + STARTTLS
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 1. Dernière modification le 13 octobre 2015 à 10:19.
3DES a un autre biais, sa taille de bloc, qui n’est que de 64 bits, soit bien trop faible.
L’ANSSI déconseille aussi ce cipher (cf http://www.ssi.gouv.fr/uploads/2015/01/RGS_v-2-0_B1.pdf page 10 & 11) et recommande au moins du 128 bits (en taille de clef & en taille de bloc).
C’est « perfect » au sens qu’on n’a aucun des warning/erreurs précédents.
Faux.
Le fait d’avoir du 3DES actif côté serveur suffit à pouvoir tomber dessus en cas de mauvaise configuration (ordre des suites côté client) ou en cas d’attaque (downgrade attack).
On n’est donc pas à l’abris d’une merde dès que 3DES est dispo quelque part.
On a aussi vu que le non support de PFS exposait violamment à la NSA (par exemple via Heartbleed) en cas de compromission de la clef privée dans le futur.
Idem, sauf à utiliser uniquement des suites PFS (puisque la présence d’une non PFS rendrait la connexion potentiellement non fiable), on est à poil.
Ne pas se couper des gens à l’heure actuelle, c’est exploser en plein vol à la prochaine grosse faille de sécu sur ces protocoles. TLSv1.0 & TLSv1.1 sont dorénavant faillibles à du Poodle, et une escalade de cette faille rendrait vulnérables tous les utilisateurs de ces protocoles.
La note « A » est donc la seule configuration valable actuellement qui résistera dans le temps et évitera d’avoir à patcher à l’arrache (ou non, cf RC4 & MD5 qui persistent malgré les risques…).
Tant qu’on ne fait pas mal à l’utilisateur, la sécu ne s’améliore pas. La preuve, même les CA ne savent pas commencer à bosser avant d’être plus que le dos au mur (voire même plutôt déjà encastrées dedans), cf https://cabforum.org/pipermail/public/2015-September/005935.html
[^] # Vérif du certificat
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 4.
C’est plus compliqué que ça.
En pratique, il ne faut pas vérifier le nom de domaine du certificat, car à l’inverse de HTTPS, SMTP+STARTTLS ne permet pas SNI, ie. de sélectionner un certificat pour chaque domaine de destination, sauf à sous-entendre que 1 domaine = 1 serveur SMTP & 1 IP.
C’est par exemple particulièrement vrai pour les fournisseurs mutualisés, comme OVH, Google ou Microsoft, qui n’ont qu’un seul MX pour l’ensemble des domaines servis.
Au mieux on pourrait seulement vérifier que domaine du certificat = domaine du MX (ou de son reverse), mais en aucun cas la vérification domaine du certificat = domaine du récepteur n’est possible. Une usurpation du DNS ne pourra donc pas être détectée par ce moyen.
De plus, les RFC mentionnent aussi qu’il faut considérer que les serveurs SMTP émetteurs n’ont pas les compétences nécessaires pour vérifier la chaîne de validité, par exemple pas de liste de CA valides (cf https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13#section-3.1.3).
Un MitM serait dans tous les cas facilement faisables, via un simple certificat auto-signé usurpant le domaine visé…
En clair, le mail est non sécurisable parce que personne ne l’a envisagé comme ça quand il a été définit au début du monde, et toutes les couches de sécu actuelles sont des hacks plus ou moins ignobles et (in)efficaces pour corriger le tir.
# Outil de test + STARTTLS
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 4.
Il y a l’outil que j’ai développé : https://tls.imirhil.fr/
Sources dispo ici : https://github.com/aeris/cryptcheck
Le problème de la notation pour le mail, c’est que c’est beaucoup plus compliqué que pour HTTPS, SMTP étant un protocole asynchrone. En particulier, il vaut mieux utiliser un protocole totalement moisi comme SSLv3, DES ou MD5 que d’émettre le message en clair, ce qui est le cas si les 2 serveurs n’arrivent pas à se mettre d’accord sur une suite de chiffrement.
Un serveur noté « F » n’est donc pas complètement anormal tant qu’on aura pas améliorer l’ensemble des serveurs du monde.
À noter aussi que la présence (ou l’absence) de STARTTLS n’est pas authentifiée comme dans le cas de HTTPS, et donc qu’un attaquant dans le réseau n’a qu’à simplement droper le petit paquet réseau contenant la chaîne « STARTTLS » dans les échanges SMTP pour que le serveur émetteur considère que le destinataire ne supporte pas le chiffrement et envoie alors le message en clair.
C’est à la portée de n’importe qui, y compris d’un pixel sur le parvis de la Défense avec un routeur TP-Link à $20… Je vous laisse le soin de comprendre ce qu’une agence gouvernementale est capable de faire sur le sujet :)
# Crypto & Javascript ? Seriously ?
Posté par Aeris (site web personnel) . En réponse à la dépêche Whiteout, chiffrement de bout en bout des courriels, convivial et OpenSource. Évalué à 10.
On ne peut pas faire de crypto « propre » dans le navigateur, via Javascript.
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
http://blog.kotowicz.net/2014/07/js-crypto-goto-fail.html
Mettre sa clef privée sur iOS ou sur Androïd, faut aussi être maso.
Coucou la puce baseband : https://www.fsf.org/blogs/community/replicant-developers-find-and-close-samsung-galaxy-backdoor
Les 2 cumulés, sauf à avoir de sérieuses preuves scientifiques que leur système a fait mieux sur ces 2 domaines, c’est juste un no-go.
Et en prime, vouloir faire du mail « sécurisé », quand on sait ce que leak comme méta-données ce protocole, c’est plus ou moins du suicide aussi.
Pour finir, la même question qu’on devrait toujours se poser avant de parler de sécurité : c’est quoi le modèle de menace ?
Whiteout annonce même clairement qu’ils n’en ont pas et que c’est à l’utilisateur de bâtir le sien et de savoir s’il peut utiliser ce service :
https://whiteout.io/security.html « So it's best to decide which threat model applies to you. »
Sans plus d’infos techniques à disposition de l’utilisateur pour qu’il puisse réellement faire cette réflexion, inutilisable aussi.
[^] # Re: HTTPS
Posté par Aeris (site web personnel) . En réponse à la dépêche Sortie de R.A.S. v0.5, alias RandoAmisSecours. Évalué à 6.
Normalement tu peux avoir A+ avec la conf à Benjamin en délaissant juste IE6/XP et IE8/XP. Ça ne doit plus concerner grand monde :D
# HTTPS
Posté par Aeris (site web personnel) . En réponse à la dépêche Sortie de R.A.S. v0.5, alias RandoAmisSecours. Évalué à 5.
Allez, encore un petit effort pour le A+ sur SSLLabs :D
Il y a encore du RC4 qui traîne et quelques navigateurs sans Forward Secrecy.
Et il manque aussi le support de HSTS.
Les configs qui vont bien : http://www.iletaitunefoisinternet.fr/ssltls-benjamin-sonntag/
[^] # Re: Cohérence
Posté par Aeris (site web personnel) . En réponse à la dépêche Le jour de la riposte (« The Day We Fight Back ») contre la surveillance généralisée. Évalué à 3.
Les sources des bannières étant publiques, tu pouvais très bien supprimer ces boutons.
Et même héberger chez toi ces pages pour éviter le tracking.
C'est ce qui a été fait sur le site de l'April (avec en prime la traduction en Français).
Quitte à défendre une cause, autant commencer par se l'appliquer à soi-même :)
[^] # Re: En résumé
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je suis passé de LibreOffice à une suite propriétaire.... Évalué à 10.
Et la « norme » est totalement incomplète, avec des gros passages de type « pour cette fonction super utile, cf spec privée non publique d'une techno privatrice qu'on gardera bien pour nous »
# Utilisation personnelle simple ou PKI full features ?
Posté par Aeris (site web personnel) . En réponse au journal PKI open source: retours d'experience ?. Évalué à 2.
L'objectif est de faire quoi ? Juste de gérer tes propres certificats ?
Ou de vraiment mettre en place une vraie PKI au sens large, avec livraison des certificats aux clients de manière sécurisée, gestion de la révocation, OSCP et le reste ?
Dans le 1er cas, EJBCA et OpenCA me paraissent juste overkill, XCA est bien plus simple pour une utilisation personnelle.