Comments on Pourquoi je continue à penser du mal de HTTPS

Ni (2017-07-29T19:46:01Z)

A propos de Wireshark et de HTTPS, il y a une alternative qui est de donner la clef secrète correspondant au certificat à Wireshark. Il sait alors décoder le handshake TLS et retrouver la clef de session. Évidemment, ça ne marche pas sur les ciphersuites avec Perfect Forward Secrecy, mais ça peut quand même être utile.

Fred le marin (2017-07-29T06:19:44Z)

J'envisageai simplement sur les (128) bits à l'intérieur d'un bloc (pas des valeurs).
L'attaquant est donc déjà en difficultés, même ainsi.
Sinon, il fallait bien-sûr lire "prémices" et non "prémisses" (cf. Aristote).
Merci de ta réponse, toujours instructive.

Ruxor (2017-07-28T21:50:28Z)

@Fred le marin: Permutation de quoi ? Des (2^128) valeurs possibles des blocs ou bien des (128) bits à l'intérieur d'un bloc ? Si c'est des valeurs, on ne casse pas : un chiffrement comme AES est une permutation des 2^128 valeurs d'un bloc ; si c'est des 128 bits du bloc, ça se fait sans mal, mais il faut quand même connaître des choses sur le clair. Si le clair est un pur bruit blanc (notamment si c'est une compression complètement idéale, ce qui n'existe pas dans la pratique), sans information supplémentaire, on ne peut pas casser même le chiffrement le plus trivial. Mais en crypto, on part généralement d'hypothèses beaucoup plus fortes (c'est-à-dire favorables à l'attaquant) : typiquement, qu'il dispose de beaucoup de couples (clair,chiffré), ou même qu'il peut en générer (attaques à clair choisi, par exemple).

Fred le marin (2017-07-28T19:58:01Z)

Brain damage ("got to keep the loonies on the path…")

En vagabondant aujourd'hui même sur l'excellent site de "Chronomath"
(http://serge.mehl.free.fr/anx/geo_non_eucl.html, voir la note 3 tout en bas de page),
j'ai découvert que Cabri est aussi le nom d'un logiciel de géométrie.
Je suis troublé par ce rapprochement (temporel), lequel alimente encore un peu plus mon délire paranoïde.
Il n'y a pourtant ici ni cryptage voulu, ni même influence de la Matrice (via le port par défaut 443).
Effet Zahir, synchronicité, science-fiction, prémisses de fin du monde, ou simple coïncidence ?
Sinon, j'ai une question bête.
Casse-t-on facilement un simple "cryptage" réalisé par permutation (et après compression forte).
La permutation encodée, bien plus courte qu'un masque jetable complet, est supposée connue d'Alice et de Bob seulement.
(elle est fixe, sur des blocs de longueur fixe, par ex: 128 bits)

Ruxor (2017-07-28T19:24:01Z)

S'agissant de Wikipédia, j'aurais dû être plus clair et distinguer deux choses : le fait qu'ils *permettent* l'accès par HTTPS et le fait qu'ils *obligent* l'accès par HTTPS (le second est beaucoup plus récent que le premier). Le premier est incontestablement bien (sauf pour ce qui est de décider quelle est « la bonne » URL d'un article Wikipédia, mais le même problème se pose, par exemple, avec la version mobile du site). Le second aurait peut-être été qualifiable de réussite si la Chine avait dit « bon, on ne peut quand même pas bloquer tout Wikipédia, donc tant pis, tout sera accessible », mais comme ça ne s'est pas produit, je n'ai vraiment pas l'impression que le gain soit intéressant (les gens qui voulaient passer en HTTPS le pouvaient de toute façon déjà).

JMU (2017-07-28T18:09:49Z)

Je suis d'accord avec la majorité du billet. Par contre :

1-HTTPS ne protège pas vraiment la confidentialité des requêtes parce qu'il y a une tonne de side-channels

C'est vrai, mais c'est toujours mieux qu'en HTTP. Il est possible que l'élévation du coût de calcul de l'attaquant soit ridicule pour certains scenarii (ex. Jack Bauer doit savoir quel page WP le docteur IranianEvil est en train de visiter sinon Washington explose) mais pas pour d'autres (Jack Bauer a envie de faire la carte des visites de chaque page Wikipedia par adresse IP). Évidemment il faudrait évaluer sérieusement lesdits scenarii pour voir si ça en vaut la peine au cas par cas.

Par ailleurs, si mes requêtes Wikipedia ne sont pas un secret qui mérite d'être protégé, celles d'internautes iraniens ou chinois peuvent l'être. Le passage de WP à HTTPS obligatoire a forcé le gouvernement chinois à bloquer *tout* Wikipedia, et pas seulement les pages sur Tiananmen et compagnie (<USD: https://en.wikipedia.org/wiki/Censorship_of_Wikipedia#China >). (Alors certes, on peut se battre pour savoir si le résultat final est bon ou mauvais, mais l'important est que le HTTPS a offert une option à la WMF qu'elle n'avait pas autrement.)

2- stabilité des URL, etc.

Je suis d'accord que l'URL ne devrait pas inclure le protocole. Je pense cependant que le problème du navigateur qui "plante" (erreur de favicon, duplication d'historique etc.) n'est pas que de la faute de Firefox. J'imagine (sans preuve certes) que ça doit être trivial de régler ça dans le code, mais que ce comportement côté navigateur a été sciemment choisi au vu de sites mal fichus qui servaient des pages différentes en HTTP et HTTPS pour la même URL (hors protocole).

Bien sûr, il n'en reste pas moins que cette situation pourrie aurait pu être évitée avec une architecture plus intelligente au départ.

3- "crypto, crypto!"

HTTPS devient un point positif pour un site dès lors qu'*un* des utilisateurs peut émettre *une* requête dont la connaissance peut être considérée comme devant être secrète. Il ne faut donc pas juger la secrètitude au vu de *ton* expérience.

Cf. internautes chinois précédents : une requête française pour la page sur Tiananmen n'a pas à être secrète. Une requête chinoise pour Paris n'à pas à être secrète. Mais si elles le sont, ça camouflera la requête chinoise pour Tiananmen (qui elle, a tout intérêt à rester secrète).

Oui, si le gouvernement chinois surveille un dissident en particulier, il peut sans doute casser le secret des requêtes Wikipedia ; mais s'il veut trouver tous les internautes qui font des recherches sensibles, il doit casser toutes les requêtes Wikipedia du pays, ce qui peut être nettement plus difficile.

loqueelvientoajuarez (2017-07-27T22:22:16Z)

Un brain dump, c'est comme un brain fart mais en pire ?

sbi (2017-07-26T20:34:03Z)

As-tu entendu parler de cette crotte de ragondin-là?
https://en.wikipedia.org/wiki/Superfish#Lenovo_security_incident

J'en fus victime, et quand "Internet" a compris le problème j'ai récupéré un
message d'erreur à la con dans mon navigateur que je n'ai compris qu'après un
certain temps, en intuitant les bons mots-clés.

Admiratif (2017-07-26T15:41:25Z)

Même quand Ruxor dit qu'il n'a pas le temps de se documenter soigneusement ou de vérifier ses renseignement, il est quand même mieux informé que 99,99% des gens qui utilisent https. C'est rafraichissant de voir un article sur https qui dit quelque chose de plus subtil que "c'est bien, utilisez le partout."

Vincent Bernat (2017-07-26T11:33:17Z)

Concernant DANE/TLSA, Chrome ne l'implémente pas car cela nécessite une requête DNS supplémentaire. Firefox ne l'implémente pas pour ne pas paraître plus lent que Chrome. Ce sont les mêmes raisons pour lesquelles ont ne peut pas utiliser les champs SRV (qui apporteraient haute dispo et load balancing).

Ruxor (2017-07-26T09:09:39Z)

@Ted:

> tu aurais sans doute pu implémenter HTTPS sur ton site en moins de temps qu'il ne t'a fallu pour écrire ce billet.

Non, ça c'est évidemment faux. Avant de mettre en place HTTPS, il faut au minimum que je trouve la réponse à tous les points qui me posent problème ; avant de trouver la réponse à un point, il faut au minimum que je le formule rapidement et que je me documente à fond, et « formuler rapidement et me documenter à fond » est toujours plus long que « me documenter rapidement et formuler en quelques paragraphes » (je tape très vite, donc ce n'est vraiment pas le fait d'écrire qui est long). Donc le fait d'écrire tout ça, non seulement est une borne inférieure très grossière sur le temps qu'il me faudra pour mettre en place HTTPS, mais en plus est une première étape pour la suite (j'ai maintenant une checklist de points auxquels trouver une solution ou du moins, parce qu'il n'y aura pas de solution, une mitigation).

Mais il y a un autre point que tu négliges pour le fait de raconter tout ça en ligne plutôt que (comme tu me le suggères) juste dire « blah » quand on me demande pourquoi je ne passe pas mon site en HTTPS, c'est que si on raconte les points qui posent problèmes, des gens vous disent parfois « ce point me posait aussi problème, et je l'ai résolu comme ceci <…> » ou « ce point est un malentendu parce qu'en fait <…> » (et, petite manipulation psychologique, ça marche souvent bien mieux si on présente ça comme un problème que comme une question : arriver en disant « Linux sucks!!! it can't do <…> » permet souvent d'avoir bien plus de réponses à ses problèmes que « how do you do <…> under Linux? »).

Ted (2017-07-26T07:26:59Z)

> normalement je n'aurais pas publié tout ça parce que je n'aime pas publier des choses où je n'ai pris que très peu de temps de vérifier mes renseignements

Ça aurait vraisemblablement été une bonne idée de t'en tenir à tes principes :-)

"Je n'ai pas le temps de m'en occuper" est une raison, sinon valide, au moins compréhensible pour ne pas implémenter HTTPS. Avoir des proches qui te répètent lourdement de passer à HTTP me semble être un problème humain, pas technique. Apprends aux gens à te foutre la paix, plutôt que de tenter de convaincre l'Internet que ça a du sens de ne pas implémenter HTTPS.

Par ailleurs, tu aurais sans doute pu implémenter HTTPS sur ton site en moins de temps qu'il ne t'a fallu pour écrire ce billet.


You can post a comment using the following fields:
Name or nick (mandatory):
Web site URL (optional):
Email address (optional, will not appear):
Identifier phrase (optional, see below):
Attempt to remember the values above?
The comment itself (mandatory):

Optional message for moderator (hidden to others):

Spam protection: please enter below the following signs in reverse order: a69bb9


Recent comments