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