Tu oublies un détail : si tu n'es pas capable d'assurer que tu parles à la bonne personne, alors tu n'es pas capable d'assurer que seule la bonne personne entend.
Tu oublies un détail, tu ne parles pas à une personne, mais à une machine.
Si tu autorises les MITM (en refusant d'authentifier la personne), alors tu ne garantis pas que seul le destinataire lit ce que ton trafic.
Tu ne garantie pas non plus qu'une seule personne lise le message déchiffré, tu garanties seulement que seule une clé appartenant à une seule personne déchiffre. Ce qu'il y a après tu n'en sais rien, ça peut être PRISM.
Quand je fais ssh monserveur, si la clé change, je suis au courant qu'elle a changé. Que cette clé soit signée par toi ou par une tierce personne ne change pas ce fait. Tu pourras rétorquer qu'il faut alors faire confiance lors de la poignée de main initiale, mais ça vaut aussi pour la tierce personne.
Système sans tiers :
___________________________________________________________________________
[ système clé à molette ]
[ _________________________________________________________ ]
[ [ système informatique ] ]
[ [ _________________ _____________ ___________________ ] ]
[ [ [ ordinateur ][ réseau ][ ordinateur ] ] ]
[ [ [ ][ ][ ] ] ]
[ alice → [ [ → chiffrement → ][ transport → ][ → déchiffrement → ] ] → bob ]
[ ¤ [ [ ¤ ø ][ ø ][ ø ¤ ] ] ¤ ]
[ [ [_________________][_____________][___________________] ] ]
[ [_________________________________________________________] ]
[___________________________________________________________________________]
Légende si pas de tiers :
¤ MITM possible
ø MITM possible lors de la première poignée de main
Système avec tiers :
___________________________________________________________________________
[ système clé à molette ]
[ _________________________________________________________ ]
[ [ système informatique ] ]
[ [ _________________ _____________ ___________________ ] ]
[ [ [ ordinateur ][ réseau ][ ordinateur ] ] ]
[ [ [ ][ ][ ] ] ]
[ alice → [ [ → chiffrement → ][ transport → ][ → déchiffrement → ] ] → bob ]
[ ¤ [ [ ¤ ø ][ ø ][ ø ¤ ] ] ¤ ]
[ [ [_________________][_____________][___________________] ] ]
[ [_________________________________________________________] ]
[ ↑ ↑ ]
[ joséphine → signature → signature ]
[___________________________________________________________________________]
Légende si pas confiance dans le tiers :
¤ MITM possible
ø MITM possible lors de la première poignée de main
Légende si confiance dans le tiers :
¤ MITM possible
ø MITM pas possible
Ne rien faire du tout sous prétexte que ce n'est pas optimal n'est jamais une bonne idée. On peut reprendre l'exemple de ssh et de telnet. Je préfère un ssh avec un doute à la poignée de main initiale que faire un login via telnet.
On peut voir le chiffrage comme le niveau 1 du service : personne ne peut savoir entre deux point (mais il peut y avoir plusieurs paires chaînées, d'où la possibilité du MITM).
On peut voir la signature comme le niveau 2 du service : si un tiers n'est pas compromis, seul deux savent.
Quand j'accepte le certificat de LinuxFr ou de Facebook ou de monvoisin.net, qu'il soit signé par CaCert ou par Verisign, ou qu'il soit autosigné, je fais confiance à LinuxFr ou Facebook ou à mon voisin pour que le serveur ne soit pas compromis.
D'où l'idée de la clé à molette... aucun système n'est parfait, alors ne soyons pas « tout ou rien ».
Cas d'usage IRL, personellement j'aimerai pouvoir facilement donner un accès https à un ami ou quelqu'un de ma famille que j'héberge pour qu'il puisse mettre à jour son site et l'administrer via le web sans devoir expliquer comment contourner les batons de FireFox. En général, pour la majorité des gens, la solutions c'est le tout http, ce qui est pire.
Et puis il y a des cas où l'on s'en moque complètement du correspondant. Si je surf par TOR ou que je suis un relai BitMessage, je me moque complètement d'authentifier mes relais, ce qui compte c'est que je trouve ce que je désire.
surtout surtout surtout, la navigation sur le web n'exige pas d'être soi-même authentifié par le site, ce qui signifie qu'il n'est pas nécessaire d'authentifier le site, tout simplement.
On peut imaginer le cas où une personne consulte des documents sur un site servi https, le site n'authentifie pas son lecteur, le lecteur n'authentifie pas le site.
On peut savoir qu'un site sert tel document (c'est public servi en https), mais on peut ne pas savoir à qui appartient le site et qui sert les documents. Et surtout, on ne sait pas à qui ces documents sont servis et lequel d'entre eux, et le lecteur a son document.
Note: le document peut être signé par l'auteur, le serveur n'est pas nécessairement l'auteur.
Cas d'usage fictif :
l'église publie un commentaire biblique et le signe ;
un serveur le partage au milieu de nombre de documents de sujet divers qui sont servis en https ;
un chrétien qui cache sa foi dans un village tenu par des rebelles islamistes qui ont massacrés tous ses coreligionnaires visite anonymement le serveur et télécharge le commentaire biblique et vérifie la signature de l'église et le lit.
Analyse :
L'église ne sait pas qui a lu le commentaire biblique ;
le serveur ne sait pas qui a téléchargé le commentaire biblique ;
le chrétien ne sait pas qui lui a fourni le commentaire biblique mais sait que c'est celui de l'église ;
le rebelle islamiste ne sait pas que quelqu'un a téléchargé un commentaire biblique.
Pourquoi authentifier dans ce cas là ?
Pourquoi tout ou rien ? Pourquoi si pas authentification, pas chiffrage ?
Pourquoi faire du ssh même quand on n'a pas signé sa clé ssh chez Thawte ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: le vrai et le faux
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Scandale de la NSA et cryptographie, le vrai du faux. Évalué à 10.
Tu oublies un détail, tu ne parles pas à une personne, mais à une machine.
Tu ne garantie pas non plus qu'une seule personne lise le message déchiffré, tu garanties seulement que seule une clé appartenant à une seule personne déchiffre. Ce qu'il y a après tu n'en sais rien, ça peut être PRISM.
Quand je fais
ssh monserveur, si la clé change, je suis au courant qu'elle a changé. Que cette clé soit signée par toi ou par une tierce personne ne change pas ce fait. Tu pourras rétorquer qu'il faut alors faire confiance lors de la poignée de main initiale, mais ça vaut aussi pour la tierce personne.Système sans tiers :
Système avec tiers :
Système avec PRISM :
Il n'y a pas de système optimal.
Ne rien faire du tout sous prétexte que ce n'est pas optimal n'est jamais une bonne idée. On peut reprendre l'exemple de ssh et de telnet. Je préfère un ssh avec un doute à la poignée de main initiale que faire un login via telnet.
On peut voir le chiffrage comme le niveau 1 du service : personne ne peut savoir entre deux point (mais il peut y avoir plusieurs paires chaînées, d'où la possibilité du MITM).
On peut voir la signature comme le niveau 2 du service : si un tiers n'est pas compromis, seul deux savent.
Quand j'accepte le certificat de LinuxFr ou de Facebook ou de monvoisin.net, qu'il soit signé par CaCert ou par Verisign, ou qu'il soit autosigné, je fais confiance à LinuxFr ou Facebook ou à mon voisin pour que le serveur ne soit pas compromis.
D'où l'idée de la clé à molette... aucun système n'est parfait, alors ne soyons pas « tout ou rien ».
Cas d'usage IRL, personellement j'aimerai pouvoir facilement donner un accès https à un ami ou quelqu'un de ma famille que j'héberge pour qu'il puisse mettre à jour son site et l'administrer via le web sans devoir expliquer comment contourner les batons de FireFox. En général, pour la majorité des gens, la solutions c'est le tout http, ce qui est pire.
Et puis il y a des cas où l'on s'en moque complètement du correspondant. Si je surf par TOR ou que je suis un relai BitMessage, je me moque complètement d'authentifier mes relais, ce qui compte c'est que je trouve ce que je désire.
surtout surtout surtout, la navigation sur le web n'exige pas d'être soi-même authentifié par le site, ce qui signifie qu'il n'est pas nécessaire d'authentifier le site, tout simplement.
On peut imaginer le cas où une personne consulte des documents sur un site servi https, le site n'authentifie pas son lecteur, le lecteur n'authentifie pas le site.
On peut savoir qu'un site sert tel document (c'est public servi en https), mais on peut ne pas savoir à qui appartient le site et qui sert les documents. Et surtout, on ne sait pas à qui ces documents sont servis et lequel d'entre eux, et le lecteur a son document.
Note: le document peut être signé par l'auteur, le serveur n'est pas nécessairement l'auteur.
Cas d'usage fictif :
Analyse :
Pourquoi authentifier dans ce cas là ?
Pourquoi tout ou rien ? Pourquoi si pas authentification, pas chiffrage ?
Pourquoi faire du ssh même quand on n'a pas signé sa clé ssh chez Thawte ?
ce commentaire est sous licence cc by 4 et précédentes