Tu n'as pas démontré que c'est mieux côté serveur que navigateur (et honnêtement, quand on lis ton argumentaire, on en déduit plutôt même le contraire de ta conclusion : tes arguments, une conclusion inverse complètement).
Si, cf la démo quelque part dans ce topic.
Le matos pourri côté serveur, on ne pourra jamais s’en passer, encore moins rapidement.
Et des suites restrictives côté client, c’est remettre le problème de la compatibilité dans la boucle (tu ne maîtrise pas la configuration des serveurs autre que le tient et ne peut garantir qu’il supporte les mêmes ciphers que toi, donc un navigateur ne peut pas se limiter aux mêmes ciphers que toi non plus).
La seule config qui mettrait fin au bordel ambiant et permettrait à tous de faire les maj de sécu sans se prendre la tête de savoir qui on va dégager ou pas du parc, c’est « ALL » sur les clients et « une unique suite secure de ton choix » sur les serveurs. En cas de pépin, les admins peuvent migrer quand ils voudront, sans avoir besoin de synchroniser quoi que ce soit et en étant assuré que leurs clients continueront à voir leur site en version pourrie ou en version sécurisée par la suite. Et de ton point de vue, tu peux assurer la sécurité de tes clients dès publication de la faille de sécurité si tu en as envie.
Si tu fais l’inverse, ie des clients restrictifs, à chaque pépin de sécu, tu retombes dans le bordel de la compat. Il faut déjà prendre une décision collégial pour se mettre d’accord sur les nouvelles suites à implémenter dans tous les navigateurs. Puis attendre que suffisamment de clients se soient mis à jour pour faire la bascule côté serveur et virer l’ancienne suite (et exclure de facto tous visiteurs pas à jour).
Ou alors tu actives toutes les suites côté serveur, et une suite unique côté client. Mais alors tu ne maîtrises ni ne peut assurer la sécurité de tes propres utilisateurs, qui s’ils ne sont pas à jour, utiliseront potentiellement des suites pourries avec ton service.
Bref, dans le 1er cas, c’est toi qui est maître de la sécurité de tes visiteurs, dans le 2nd cas non.
[^] # 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.
Si, cf la démo quelque part dans ce topic.
Le matos pourri côté serveur, on ne pourra jamais s’en passer, encore moins rapidement.
Et des suites restrictives côté client, c’est remettre le problème de la compatibilité dans la boucle (tu ne maîtrise pas la configuration des serveurs autre que le tient et ne peut garantir qu’il supporte les mêmes ciphers que toi, donc un navigateur ne peut pas se limiter aux mêmes ciphers que toi non plus).
La seule config qui mettrait fin au bordel ambiant et permettrait à tous de faire les maj de sécu sans se prendre la tête de savoir qui on va dégager ou pas du parc, c’est « ALL » sur les clients et « une unique suite secure de ton choix » sur les serveurs. En cas de pépin, les admins peuvent migrer quand ils voudront, sans avoir besoin de synchroniser quoi que ce soit et en étant assuré que leurs clients continueront à voir leur site en version pourrie ou en version sécurisée par la suite. Et de ton point de vue, tu peux assurer la sécurité de tes clients dès publication de la faille de sécurité si tu en as envie.
Si tu fais l’inverse, ie des clients restrictifs, à chaque pépin de sécu, tu retombes dans le bordel de la compat. Il faut déjà prendre une décision collégial pour se mettre d’accord sur les nouvelles suites à implémenter dans tous les navigateurs. Puis attendre que suffisamment de clients se soient mis à jour pour faire la bascule côté serveur et virer l’ancienne suite (et exclure de facto tous visiteurs pas à jour).
Ou alors tu actives toutes les suites côté serveur, et une suite unique côté client. Mais alors tu ne maîtrises ni ne peut assurer la sécurité de tes propres utilisateurs, qui s’ils ne sont pas à jour, utiliseront potentiellement des suites pourries avec ton service.
Bref, dans le 1er cas, c’est toi qui est maître de la sécurité de tes visiteurs, dans le 2nd cas non.