Non, la condition nécessaire et suffisante se situe uniquement côté serveur pour un couple (client, serveur).
Toujours pas.
La condition (1) le serveur ne supporte aucune suite TLS faillible est suffisante
La condition (2) le client ne supporte aucune suite TLS faillible est suffidante
La condition (1 ou 2) est nécessaire (et suffisante, évidemment).
Si le client ne supporte aucune suite TLS faillible, alors même si le serveur 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 clients, les serveurs doivent obligatoirement supporter des suites faillibles.
Par exemple avec ma config de Firefox, je te garantie que tu obtiendras de l'AES (donc fiable), même si ton navigateur est serveur est blindé de RC4 ou 3DES.
Pour un fournisseur de service, c'est hyper problématique de perdre des utilisateurs parce qu'ils n'ont pas un navigateur récent. C'est pour cette raison qu'ils ne les désactiveront que dans très longtemps.
La vraie bonne chose à faire ce serait que tous les serveurs du monde intégrent rapidement les protocoles (suites) récents. Ensuite les navigateurs désactivent les suites pourries dans leurs nouvelles versions. Ainsi, les sites n'ont pas besoin de se priver d'utilisateurs. Les clients n'ont pas besoin de se priver de sites non plus.
Avec la solution que tu proposes, les serveurs (donc les fournisseurs de services) doivent se priver de clients. C'est une solution acceptable pour ton site ou une banque française (quoique madame michu qui arrive plus à se connecter avec Android 2.1... Ça pourrait leur couter très cher en service client.), mais pas pour un opérateur plus international.
C'est surement ce qui était prévu quand TLS a été conçu. Il s'avère qu'au final c'est pas tellement faisable. Du coup, y'a effectivement un truc dans TLS 1.3.
[^] # 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é à 3.
Toujours pas.
La condition (1) le serveur ne supporte aucune suite TLS faillible est suffisante
La condition (2) le client ne supporte aucune suite TLS faillible est suffidante
La condition (1 ou 2) est nécessaire (et suffisante, évidemment).
Si le client ne supporte aucune suite TLS faillible, alors même si le serveur 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 clients, les serveurs doivent obligatoirement supporter des suites faillibles.
Par exemple avec ma config de Firefox, je te garantie que tu obtiendras de l'AES (donc fiable), même si ton navigateur est serveur est blindé de RC4 ou 3DES.
Pour un fournisseur de service, c'est hyper problématique de perdre des utilisateurs parce qu'ils n'ont pas un navigateur récent. C'est pour cette raison qu'ils ne les désactiveront que dans très longtemps.
La vraie bonne chose à faire ce serait que tous les serveurs du monde intégrent rapidement les protocoles (suites) récents. Ensuite les navigateurs désactivent les suites pourries dans leurs nouvelles versions. Ainsi, les sites n'ont pas besoin de se priver d'utilisateurs. Les clients n'ont pas besoin de se priver de sites non plus.
Avec la solution que tu proposes, les serveurs (donc les fournisseurs de services) doivent se priver de clients. C'est une solution acceptable pour ton site ou une banque française (quoique madame michu qui arrive plus à se connecter avec Android 2.1... Ça pourrait leur couter très cher en service client.), mais pas pour un opérateur plus international.
C'est surement ce qui était prévu quand TLS a été conçu. Il s'avère qu'au final c'est pas tellement faisable. Du coup, y'a effectivement un truc dans TLS 1.3.