Bon, on est d'accord sur les faits techniques, mais pas sur les stratégies à adopter.
On va reformuler alors :P
Dans le monde idéal des bisounours, clients et serveurs n’auraient que des suites fiables et corrigeraient immédiatement, l’ordre client ou serveur en premier n’aurait que peu d’importance.
Dans le monde idéal en pratique, il faudrait faire un choix de qui migre en premier.
Si ce sont les serveurs, on pète la compat’ avec les clients le temps pour les client de migrer.
Si ce sont les clients, on pète la compat’ avec les serveurs le temps pour les serveurs de migrer.
Mais la situation ne serait que temporaire dans les 2 cas, et la migration conduirait rapidement à avoir tout le monde à l’abri.
Ici encore, l’ordre n’aurait que peu d’importance.
Dans le monde réel, les serveurs sont migrables très difficilement, voire pas migrables du tout (serveurs old-old-old-school dépendant de vieux OS ou d’applis métiers), alors qu’à l’inverse les clients ne dépendent de rien et n’impactent pas grand chose (appli généralement isolée et indépendante de l’OS).
Alors qu’on peut envisager un monde (certainement utopiste) avec des navigateurs à jour partout (il suffit au pire de mettre une version portable de Firefox partout y compris sur Android 2.3 ou Windows XP), on n’a pas de plan d’action (ou en tout cas bien plus utopiste) permettant un monde avec des serveurs à jour partout.
On pose donc le 1er invariant : il y aura toujours des serveurs moisis dans la nature. (À noter que je ne fais aucun postulat sur l’état des navigateurs.)
De là, on en déduit que pour des raisons de compatibilité, les clients nécessiteront de supporter des suites faillibles. On a actuellement toujours plus ou moins réussi à sauver les meubles en désactivant au fur et à mesure les suites foireuses dans les clients, mais on voit bien que c’est de plus en plus difficile sans casser massivement la compat’ ou en demandant des breaking changes côté serveur.
On a donc notre 1ère règle qui s’en déduit : les clients doivent (MUST) supporter en même temps des suites faillibles et des suites sécurisées. À l’extrême limite, ils doivent (MUST) même obligatoirement supporter ALL:COMPLEMENTOFALL.
Qui dit suite faillible et suite sécurisée mixées dit downgrade attack possible vers la suite faillible.
On en déduit donc notre 2nd règle : les serveurs ne doivent (SHOULD) supporter que des suites sécurisés pour éviter tout fallback, les clients en face allant possiblement supporter des choses non sécurisées pour compat’ avec d’autres serveurs que nous.
Et on en déduit alors l’état du monde :
des serveurs moisis qui seront accessibles par tous, non sécurisés pour tous (mais difficile de faire mieux :P), mais qui peuvent devenir sécurisés pour tous un peu plus tard sans aucun problème de compatibilité à envisager
des serveurs sécurisés qui seront accessibles par tous et sécurisés pour tous
des navigateurs qui seront compatibles avec tout serveur existant
Si tu me trouves une situation plus optimale, je suis preneur.
On est entré dans une spirale infernale parce qu’on a voulu faire de la sécu par les 2 bouts (client et serveur), à la fois serveur et client, et qu’on se prend du coup le problème de compatibilité de plein fouet.
Il faut forcément couper un des 2 bouts (client ou serveur) pour mettre fin à la boucle et permettre une mise-à-jour de sécu sans se préoccuper de la compatibilité.
Étant donné qu’on veut de la sécurité, il faut donc couper le problème de la compatibilité, qui ne peut se régler qu’à gros coup de ALL:COMPLEMENTOFALL sur les clients.
Et à la limite revoir la notion de ALL:COMPLEMENTOFALL de temps en temps pour virer définitivement tout ce qui n’est plus utilisé du tout ou de manière très marginale.
[^] # 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é à 1. Dernière modification le 06 janvier 2016 à 13:54.
On va reformuler alors :P
Dans le monde idéal des bisounours, clients et serveurs n’auraient que des suites fiables et corrigeraient immédiatement, l’ordre client ou serveur en premier n’aurait que peu d’importance.
Dans le monde idéal en pratique, il faudrait faire un choix de qui migre en premier.
Si ce sont les serveurs, on pète la compat’ avec les clients le temps pour les client de migrer.
Si ce sont les clients, on pète la compat’ avec les serveurs le temps pour les serveurs de migrer.
Mais la situation ne serait que temporaire dans les 2 cas, et la migration conduirait rapidement à avoir tout le monde à l’abri.
Ici encore, l’ordre n’aurait que peu d’importance.
Dans le monde réel, les serveurs sont migrables très difficilement, voire pas migrables du tout (serveurs old-old-old-school dépendant de vieux OS ou d’applis métiers), alors qu’à l’inverse les clients ne dépendent de rien et n’impactent pas grand chose (appli généralement isolée et indépendante de l’OS).
Alors qu’on peut envisager un monde (certainement utopiste) avec des navigateurs à jour partout (il suffit au pire de mettre une version portable de Firefox partout y compris sur Android 2.3 ou Windows XP), on n’a pas de plan d’action (ou en tout cas bien plus utopiste) permettant un monde avec des serveurs à jour partout.
On pose donc le 1er invariant : il y aura toujours des serveurs moisis dans la nature. (À noter que je ne fais aucun postulat sur l’état des navigateurs.)
De là, on en déduit que pour des raisons de compatibilité, les clients nécessiteront de supporter des suites faillibles. On a actuellement toujours plus ou moins réussi à sauver les meubles en désactivant au fur et à mesure les suites foireuses dans les clients, mais on voit bien que c’est de plus en plus difficile sans casser massivement la compat’ ou en demandant des breaking changes côté serveur.
On a donc notre 1ère règle qui s’en déduit : les clients doivent (MUST) supporter en même temps des suites faillibles et des suites sécurisées. À l’extrême limite, ils doivent (MUST) même obligatoirement supporter ALL:COMPLEMENTOFALL.
Qui dit suite faillible et suite sécurisée mixées dit downgrade attack possible vers la suite faillible.
On en déduit donc notre 2nd règle : les serveurs ne doivent (SHOULD) supporter que des suites sécurisés pour éviter tout fallback, les clients en face allant possiblement supporter des choses non sécurisées pour compat’ avec d’autres serveurs que nous.
Et on en déduit alors l’état du monde :
Si tu me trouves une situation plus optimale, je suis preneur.
On est entré dans une spirale infernale parce qu’on a voulu faire de la sécu par les 2 bouts (client et serveur), à la fois serveur et client, et qu’on se prend du coup le problème de compatibilité de plein fouet.
Il faut forcément couper un des 2 bouts (client ou serveur) pour mettre fin à la boucle et permettre une mise-à-jour de sécu sans se préoccuper de la compatibilité.
Étant donné qu’on veut de la sécurité, il faut donc couper le problème de la compatibilité, qui ne peut se régler qu’à gros coup de ALL:COMPLEMENTOFALL sur les clients.
Et à la limite revoir la notion de ALL:COMPLEMENTOFALL de temps en temps pour virer définitivement tout ce qui n’est plus utilisé du tout ou de manière très marginale.