• [^] # Re: Let’s Encrypt

    Posté par (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.

    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...)...