Mais... En fait, pourquoi on pourrait pas? Si les serveurs perdent de l'argent faute de visiteurs, ils vont vite migrer. Ca ne tient pas!
Non, ils ne vont pas vite migrer. J’ai dis que c’était facile, pas que c’était rapide.
Parce qu’il y a suffisamment de lobby pour que ces modifs soient faites beaucoup trop longtemps après la bataille.
On l’a vu pour SSLv3, pour SHA-1, pour RC4, pour 3DES. Et je promet déjà une sacrée longue traîne avant l’exclusion des suites RSA au profit des suites ECC, et pire, la désactivation de TLSv1.2 après l’intégration de TLSv1.3.
Ça demande des palabres infinis pour que les navs se mettent d’accord de qui intègre quoi. Et ça ne fonctionne pas, la preuve chaque navigateur a une liste de choses supportées différente de celles des voisins...
Et des suites restrictives côté serveur, c’est remettre le problème de la compatibilité dans la boucle (tu ne maîtrise pas la configuration des navigateurs autre que le tient et ne peut garantir qu’il supporte les mêmes ciphers que toi, donc un serveur ne peut pas se limiter aux mêmes ciphers que toi non plus).
Si justement. Je peux garantir que je n’aurais pas de problème de config en instaurant ALL sur tous les navigateurs.
Et je contrôle au moins MES données qui circulent sur MON serveur, ce que je ne peux pas faire avec un ALL côté serveur et une suite restrictive sur le client puisque je suis alors dépendant du bon vouloir de Google, Mozilla et Microsoft pour mettre à l’abri mes visiteurs.
La grosse différence est surtout là pour le choix client-first ou serveur-first : je suis légalement responsable de la sécurité de mes utilisateurs, je n’ai donc pas à subir des décisions externes (les suites dans les navigateurs) pour les mettre à l’abri.
[^] # 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. Dernière modification le 06 janvier 2016 à 16:21.
Non, ils ne vont pas vite migrer. J’ai dis que c’était facile, pas que c’était rapide.
Parce qu’il y a suffisamment de lobby pour que ces modifs soient faites beaucoup trop longtemps après la bataille.
On l’a vu pour SSLv3, pour SHA-1, pour RC4, pour 3DES. Et je promet déjà une sacrée longue traîne avant l’exclusion des suites RSA au profit des suites ECC, et pire, la désactivation de TLSv1.2 après l’intégration de TLSv1.3.
Ça demande des palabres infinis pour que les navs se mettent d’accord de qui intègre quoi. Et ça ne fonctionne pas, la preuve chaque navigateur a une liste de choses supportées différente de celles des voisins...
Si justement. Je peux garantir que je n’aurais pas de problème de config en instaurant ALL sur tous les navigateurs.
Et je contrôle au moins MES données qui circulent sur MON serveur, ce que je ne peux pas faire avec un ALL côté serveur et une suite restrictive sur le client puisque je suis alors dépendant du bon vouloir de Google, Mozilla et Microsoft pour mettre à l’abri mes visiteurs.
La grosse différence est surtout là pour le choix client-first ou serveur-first : je suis légalement responsable de la sécurité de mes utilisateurs, je n’ai donc pas à subir des décisions externes (les suites dans les navigateurs) pour les mettre à l’abri.