<foo> simply produces <foo>in the text).
<URL: http://somewhere.tld/ >,
and it will be automatically made into a link.
(Do not try any other way or it might count as an attempt to spam.)mailto: URI,
e.g. mailto:my.email@somewhere.tld,
if you do not have a genuine Web site).
Ruxor (2017-10-30T21:41:01Z)
@Xavier Combelle: Je sais tout ça, mais je ne vois pas en quoi ça répond à mes objections.
Par ailleurs, l'affirmation « censors must choose between blocking the entire site and allowing access to all articles » est trompeuse ou fausse : le Dictatoristan peut très facilement créer un site miroir de Wikipédia, accessible en HTTP (ou en HTTPS, d'ailleurs), qui reproduit exactement le contenu de Wikipédia sauf tout ce qui parle des frasques du président à vie du Dictatoristan, et ensuite bloquer totalement l'accès à Wikipédia sur son site normal. Certes, ils ne peuvent pas faire apparaître un lien vers wikipedia-dictatoristan.org depuis wikipedia.org, mais ils peuvent le faire apparaître à toutes sortes d'autres endroits, et ce lien sera vite connu si c'est la seule façon de consulter Wikipédia au Dictatoristan (surtout s'ils font la même procédure pour Google et insèrent leurs résultats ou modifient les réponses quand ça les arrange sur les pages de réponse de Google). La Chine a les moyens d'aller encore plus loin et de refaire complètement Wikipédia à leur sauce, ce qu'ils sont en train de faire, mais simplement mettre en place un miroir officiel demande très peu de moyens humains.
Je crois que c'est ce que je ferais de façon systématique, moi, si je voulais mener une censure de ce genre à l'échelle d'un pays : bloquer complètement le HTTPS en sortie du pays (aucune exception), mais avoir un site du gouvernement qui permet d'y accéder en réécrivant les URL de façon simple https://example.tld → https://bigbrother.truc/example.tld (et le moteur va ensuite réécrire toutes les URL intérieures). Les gens apprendraient rapidement comment il faut faire, ça ne les emmerderait qu'un petit peu, et ça n'aura absolument rien fait pour protéger qui que ce soit.
Xavier Combelle (2017-10-30T21:06:43Z)
Les raisons pour les quelle wikipedia est passée en https complet
- rendre beaucoup plus difficile la surveillance ciblée d'une communication.
- rendre impraticable l'espionnage de l'ensemble d'une population sur la communication chiffrée.
- rendre la censure spécifique de certains articles de wikipedia quasiment inopérante.
C'est des raisons similaires qui poussent les protecteurs des droits numériques à l'adoption massive des techniques de chiffrement (et non pas l'inviolabilité absolue des techniques de chiffrement)
Pour citer la source dans la langue de shakespeare:
"The HTTPS protocol creates an encrypted connection between your computer and Wikimedia sites to ensure the security and integrity of data you transmit. Encryption makes it more difficult for governments and other third parties to monitor your traffic. It also makes it harder for Internet Service Providers (ISPs) to censor access to specific Wikipedia articles and other information."
https://blog.wikimedia.org/2015/06/12/securing-wikimedia-sites-with-https/
Concernant l'efficacité de l'utilisation de HTTPS comme arme anticensure, l'abstract de cette étude est très éclairante
https://cyber.harvard.edu/publications/2017/04/WikipediaCensorship
Abstract:
This study, conducted by the Internet Monitor project at the Berkman Klein Center for Internet & Society,
analyzes the scope of government-sponsored censorship of Wikimedia sites around the world. The study
finds that, as of June 2016, China was likely censoring the Chinese language Wikipedia project, and Thailand
and Uzbekistan were likely interfering intermittently with specific language projects of Wikipedia as well.
However, considering the widespread use of filtering technologies and the vast coverage of Wikipedia, our
study finds that, as of June 2016, there was relatively little censorship of Wikipedia globally. In fact, our study
finds there was less censorship in June 2016 than before Wikipedia’s transition to HTTPS-only content
delivery in June 2015. HTTPS prevents censors from seeing which page a user is viewing, which means
censors must choose between blocking the entire site and allowing access to all articles. This finding
suggests that the shift to HTTPS has been a good one in terms of ensuring accessibility to knowledge.
The study identifies and documents the blocking of Wikipedia content using two complementary data
collection and analysis strategies: a client-side system that collects data from the perspective of users around
the globe and a server-side tool to analyze traffic coming in to Wikipedia servers. Both client- and server-side
methods detected events that we consider likely related to censorship, in addition to a large number of
suspicious events that remain unexplained. The report features results of our data analysis and insights into
the state of access to Wikipedia content in 15 select countries.
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.