Bon, va falloir que j'arrive à lacher le troll on sera pas d'accord de toutes façons. Une dernière fois:
Tu donnes l'invariant qui est vrai:
(InvAeris) Il y aura toujours des serveurs moisis dans la nature.
Je donne l'invariant, qui est vrai aussi:
(InvXion345) Il y aura toujours des clients moisis dans la nature (pays émergents etc.)
Avec ces deux invariants, y'a aucune solution satisfaisante:
(Solution 1) Les serveurs n'activent que des suites récentes. Ils privent les clients moisis d'accès HTTPS.
(Solution 2) Le client n'activent que des suites récentes. Ils se privent d'accéder au serveurs mal administrés.
Tu préfères le cas (1) en argumentant que les utilisateurs peuvent toujours mettre à jour (Installer Firefox sous Windows XP, installer un autre navigateur sous Android etc., ne pas utiliser IE8-9). Je préfères le cas (2) en argumentant que les administrateurs de serveurs n'ont qu'à supporter au moins une suite correcte s'ils veulent qu'on s'y connecte (Ces histoires de LB ou SSL hardware ne sont pas convaincantes, si le hardware est ancien/mauvais on peut aussi le remplacer. C'est plus facile pour un opérateur que pour un utilisateur dans un pays pauvre, hein.)
Après oui, dans les deux cas c'est pas terrible.
Si tu me trouves une situation plus optimale, je suis preneur.
Encore une fois, la solution est protocolaire (cf. FALLBACK_SCSV, TLS 1.3). Il faut un protocole qui authentifie la liste des suites. C'est devenu nécessaire. C'est pas comme si c'est la troisième fois que je te donnais cette solution...
[^] # 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. Dernière modification le 06 janvier 2016 à 15:04.
Bon, va falloir que j'arrive à lacher le troll on sera pas d'accord de toutes façons. Une dernière fois:
Tu donnes l'invariant qui est vrai:
(InvAeris) Il y aura toujours des serveurs moisis dans la nature.
Je donne l'invariant, qui est vrai aussi:
(InvXion345) Il y aura toujours des clients moisis dans la nature (pays émergents etc.)
Avec ces deux invariants, y'a aucune solution satisfaisante:
(Solution 1) Les serveurs n'activent que des suites récentes. Ils privent les clients moisis d'accès HTTPS.
(Solution 2) Le client n'activent que des suites récentes. Ils se privent d'accéder au serveurs mal administrés.
Tu préfères le cas (1) en argumentant que les utilisateurs peuvent toujours mettre à jour (Installer Firefox sous Windows XP, installer un autre navigateur sous Android etc., ne pas utiliser IE8-9). Je préfères le cas (2) en argumentant que les administrateurs de serveurs n'ont qu'à supporter au moins une suite correcte s'ils veulent qu'on s'y connecte (Ces histoires de LB ou SSL hardware ne sont pas convaincantes, si le hardware est ancien/mauvais on peut aussi le remplacer. C'est plus facile pour un opérateur que pour un utilisateur dans un pays pauvre, hein.)
Après oui, dans les deux cas c'est pas terrible.
Encore une fois, la solution est protocolaire (cf. FALLBACK_SCSV, TLS 1.3). Il faut un protocole qui authentifie la liste des suites. C'est devenu nécessaire. C'est pas comme si c'est la troisième fois que je te donnais cette solution...