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 X345 . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. É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.