Chapitre 31 Cacher le contenu des communications : la cryptographie asymétrique
Dans le premier tome de ce guide, nous avons vu que la piste la plus sérieuse pour protéger des données des regards indiscrets est le chiffrement : il permet de les rendre illisibles pour toute personne qui n’a pas la clé secrète.
31.1 Limites du chiffrement symétrique
Dans le cadre du chiffrement symétrique, c’est une même clé secrète qui permet à la fois d’effectuer le chiffrement et le déchiffrement.
Le chiffrement symétrique est tout à fait adapté pour chiffrer une clé USB ou un autre support de stockage.
Lorsqu’on souhaite chiffrer une communication, c’est plus délicat : la personne qui devra déchiffrer les données n’est pas la même que celle qui les a chiffrées.
Si la clé secrète était la même pour toutes les personnes avec qui l’on communique, alors chacune de ces personnes pourrait déchiffrer des messages qui ne lui sont pas destinés. Il faut donc autant de clés secrètes que de personnes avec qui on communique ; et il faut trouver le moyen de s’échanger ces clés secrètes de façon confidentielle.
31.2 Une solution : la cryptographie asymétrique
Dans les années 1970, des cryptographes ont trouvé une solution aux problèmes posés par le chiffrement symétrique en créant le chiffrement asymétrique.
Avec le chiffrement asymétrique, chaque personne qui communique possède une paire de clés : une clé publique pour qu’on puisse lui écrire des messages chiffrés, et une clé privée pour qu’elle puisse les déchiffrer et les lire.
À chaque échange, il faut imaginer que les communications voyagent dans une boîte munie d’un verrou spécial.
La clé publique permet de verrouiller la boîte au moment de l’envoi du message. Par contre, elle ne permet en aucun cas de la déverrouiller.
L’autre clé, la clé privée, permet uniquement de déverrouiller la boîte et donc d’accéder à son contenu.
La clé publique peut être distribuée à n’importe qui. Elle peut même être mise en ligne, puisqu’elle ne sert qu’à verrouiller la boîte. La clé privée, elle, ne se partage jamais.
Ana possède une paire de clés.
Bea possède aussi une paire de clés.
Les messages destinés à Ana seront placés dans une boîte qui sera verrouillée avec sa clé publique.
Bea récupère la clé publique d’Ana.
Bea dépose un message dans la boîte d’Ana puis la verrouille avec la clé publique d’Ana.
Ana utilise sa clé privée pour déverrouiller la boîte et récupérer le message. Seule sa clé privée permet de déverrouiller cette boîte.
Dans notre exemple illustré, le chiffrement a lieu dans l’ordinateur de Bea et le déchiffrement dans celui d’Ana.
31.3 Chiffrement de bout en bout
Lorsque seules les personnes qui communiquent peuvent lire les messages échangés, on parle de chiffrement de bout en bout. En principe, cela empêche l’écoute électronique, y compris par les fournisseurs de télécommunications, par les fournisseurs d’accès Internet et même par le fournisseur du service de communication. Avec le chiffrement de bout en bout, personne n’est en mesure d’intercepter les clés cryptographiques nécessaires pour déchiffrer la conversation.
Les systèmes de chiffrement de bout en bout sont conçus pour résister à toute tentative de surveillance ou de falsification, car aucun tiers ne peut déchiffrer les données communiquées ou stockées. En particulier, les services qui offrent du chiffrement de bout en bout sont incapables de remettre une version déchiffrée des messages de leurs utilisatrices aux autorités389.
31.3.1 Une affaire de nombres premiers…
Dans la réalité, la clé publique et la clé privée sont des nombres. Ce qu’une clé permet de chiffrer, l’autre permet de le déchiffrer :
La clé publique permet de chiffrer et la clé privée permet de déchiffrer
Mais comment est-il possible que la clé publique permette de chiffrer un message sans permettre de le déchiffrer ? La cryptographie asymétrique repose en fait sur des problèmes mathématiques extrêmement difficiles à résoudre. L’algorithme de chiffrement RSA, par exemple, repose sur la « factorisation de nombres entiers ». C’est-à-dire la décomposition d’un nombre entier en nombres premiers.
Étant donné le nombre 12, il est simple de le décomposer en 2 × 2 × 3. De même, 111 est égal à 3 × 37. En revanche, comment décomposer le nombre suivant, composé de 232 chiffres ?
1230186684530117755130494958384962720772853569595334792197322452151726400 5072636575187452021997864693899564749427740638459251925573263034537315482 6850791702612214291346167042921431160222124047927473779408066535141959745 9856902143413
Le résultat est le produit de deux nombres premiers composés chacun de 116 chiffres.
Ce problème de factorisation d’entiers est étudié depuis plus de 2000 ans par des mathématiciennes ; pourtant, aucune solution pratique n’a encore été trouvée : la meilleure solution connue est d’essayer avec tous les nombres premiers possibles.
Avec un ordinateur actuel, ce calcul serait beaucoup plus long que la durée d’une vie humaine390. Les nombres les plus difficiles à factoriser sont les produits de deux grands nombres premiers. On choisira donc des nombres suffisamment grands pour que même avec des ordinateurs extrêmement puissants, la factorisation ne puisse pas se faire en un temps réaliste.
Faire confiance à cette méthode revient donc à faire le pari que son adversaire dispose d’une puissance de calcul relativement limitée. La taille des clés, qui se mesure en bits, est d’une importance capitale. En effet, si on considère qu’une clé asymétrique de 2048 bits est sûre jusqu’en 2030391, une clé de 512 bits se casse en quelques mois avec un ordinateur personnel haut de gamme actuel392. Il faut garder à l’esprit que ce qui est « cassable » par un ordinateur en dix ans pourrait l’être en un an avec dix ordinateurs identiques au premier.
De plus, si un jour une personne résout ce problème mathématique, il sera possible de déchiffrer sans trop de difficulté les échanges chiffrés qui auront ont été enregistrés — ce type de collecte et de stockage fait partie entre autres des activités de la NSA, agence de renseignement états-unienne393. Beaucoup de secrets militaires et commerciaux seraient alors révélés à ceux qui auront accès à ces enregistrements. En d’autres termes, on peut imaginer une sacrée pagaille entre entreprises concurrentes et agences de renseignements ennemies…
En attendant, les attaques utilisées à l’heure actuelle sur les systèmes de cryptographie asymétrique ciblent la façon de le mettre en œuvre dans tel ou tel logiciel, ou une erreur dans son code source, et non le principe mathématique du système.
31.4 Signature numérique
Les paires de clés utilisées pour la cryptographie asymétrique peuvent aussi être utilisées pour prouver l’authenticité d’un message. Comment cela fonctionne-t-il ? Reprenons l’exemple de Bea envoyant un message à Ana. Cette fois, Bea veut signer numériquement son message afin qu’Ana puisse être sûre qu’elle en est bien l’autrice.
Dans le premier tome de ce guide, on a parlé des sommes de contrôle, ou empreintes : un nombre qui permet de vérifier l’intégrité d’un message. Cette empreinte va également servir à signer des données numériques. Dans un premier temps, l’ordinateur de Bea calcule une empreinte du message qu’elle va envoyer à Ana.
Ensuite, cette empreinte est chiffrée avec la clé privée de Bea : c’est la signature numérique. Eh oui : l’empreinte est chiffrée avec la clé privée de Bea, dont elle est la seule à disposer, et non avec la clé publique d’Ana. Cette signature sert en effet à authentifier l’expéditeur, et non le destinataire. Or on vient de voir que clé publique et clé privée étaient en fait deux nombres choisis de telle façon que l’un permette de déchiffrer ce que l’autre a chiffré. Rien n’empêche donc de chiffrer quelque chose avec la clé privée. C’est alors la clé publique qui va permettre de le déchiffrer.
Bea envoie alors le message accompagné de sa signature à Ana.
Bea signe un message
Pour vérifier la signature, l’ordinateur d’Ana va lui aussi calculer l’empreinte du message et déchiffrer en parallèle la signature.
Ana vérifie le message
Puisqu’elle est chiffrée avec la clé privée de Bea, la clé publique de Bea suffit pour déchiffrer cette signature. Si l’empreinte du message reçu correspond à la signature déchiffrée (celle-ci n’étant rien d’autre, comme on l’a dit, que l’empreinte du message calculée par l’ordinateur de Bea), Ana est sûre de l’authenticité du message qu’elle a reçu. En effet, Bea garde sa clé privée en lieu sûr. Elle est donc la seule à avoir pu chiffrer l’empreinte qu’Ana a déchiffré avec la clé publique de Bea.
L’inconvénient de cette certitude est que Bea, possédant la clé privée, pourra plus difficilement nier être l’autrice du message.
31.5 Vérifier l’authenticité de la clé publique
La cryptograhie asymétrique permet ainsi de chiffrer et de signer des messages sans avoir besoin de s’échanger préalablement un secret partagé.
Cependant, elle ne résout pas une question importante : comment s’assurer que je possède bien la véritable clé publique de ma destinataire, et que ce n’est pas une personne qui a usurpé sa clé publique pour pouvoir intercepter mes messages, tout en me donnant une fausse impression de sécurité ?
31.5.1 L’attaque du monstre du milieu
Reprenons l’exemple d’Ana qui souhaite recevoir un message chiffré de la part de Bea, en présence d’une adversaire Carole qui peut avoir accès aux messages échangés :
Ana commence par envoyer sa clé publique à Bea. Carole peut la lire.
Bea chiffre son message avec la clé publique qu’elle a reçue, puis l’envoie à Ana.
Carole qui ne possède pas la clé privée d’Ana, mais seulement sa clé publique, ne peut pas déchiffrer le message.
Ana elle, peut déchiffrer le message à l’aide de la clé privée qu’elle garde précieusement.
Cependant si Carole est en mesure de modifier les échanges entre Ana et Bea, les choses se corsent :
Lorsqu’Ana envoie sa clé publique à Bea, Carole l’intercepte et renvoie à Bea, en lieu et place de celle d’Ana, une clé publique dont elle détient la clé privée correspondante.
Bea chiffre son message avec la clé publique qu’elle a reçue, puis l’envoie à Ana. Mais la clé qu’elle a reçue appartenait à Carole : elle l’a substituée à celle d’Ana.
Carole intercepte à nouveau le message. Mais cette fois, il est chiffré avec sa clé publique, dont elle a la clé privée. Elle peut donc déchiffrer le message pour le lire et éventuellement le modifier. Puis elle chiffre à nouveau le message avec la véritable clé publique d’Ana, avant de l’envoyer à Ana.
Ana peut alors déchiffrer le message avec sa clé privée, sans se rendre compte de rien.
Ainsi, Bea est persuadée d’utiliser la clé d’Ana, alors qu’elle utilise en réalité celle de Carole. De la même manière, Carole peut usurper la clé publique de Bea et falsifier la signature du message transmis par Bea à Ana. Ana recevra un message chiffré et dûment signé… par Carole.
On appelle cette attaque l’attaque du monstre du milieu (courramment appelée attaque de l’homme du milieu, et Man-in-the-Middle ou Monster-in-the-Middle attack, soit MitM en anglais394). Dans notre exemple, Carole était le monstre du milieu, capable de lire et de modifier la communication chiffrée en se faisant passer, aux yeux de chaque partie de la communication, pour l’autre.
Une adversaire peut se positionner en monstre du milieu par différents biais.
Le fournisseur d’accès à Internet est par exemple particulièrement bien placé, car tout le trafic passera obligatoirement par lui. De même un gros nœud du réseau par lequel passe une quantité importante du trafic sera en bonne mesure de mettre en place cette attaque395. Enfin une adversaire ayant accès au réseau local que vous utilisez pourra toujours faire transiter le trafic réseau par son ordinateur utilisant pour cela des techniques plus spécifiques396.
Pour se prémunir contre cette attaque, il faut que Bea ait une façon de vérifier que la clé publique qu’elle utilise est bien celle d’Ana. Si la clé publique n’est pas une information confidentielle, il faut donc toutefois s’assurer de son authenticité avant de l’utiliser.
Parfois, la façon la plus simple, pour Bea, est de rencontrer Ana
afin de vérifier que la clé publique dont elle dispose est bien la
sienne. Peu importe que Carole soit présente au moment de cette
rencontre : seule une vérification de clé publique aura lieu, et
aucun secret ne va être échangé (à part que Bea et Ana souhaitent
communiquer, mais ça, vu sa position, Carole peut le savoir d’autres
façons).
Une fois cette vérification faite, du chiffrement de bout en bout pourra
être mis en place entre Ana et Bea.
Entre les deux, un message dont le contenu sera chiffré circulera ; seul
l’en-tête de la
communication, que ce soit une requête HTTP ou un email, circulera en clair.
Cependant, il arrive souvent que Bea ne puisse pas rencontrer Ana — a fortiori si elle ne la connaît pas : si elle rencontre une personne qui se présente comme étant Ana, Bea ne peut pas être sûre qu’il s’agit bien d’Ana. Or, c’est généralement le cas lorsqu’on veut chiffrer ses connexions vers un site web : on ne connaît pas les personnes qui sont derrière.
31.5.2 Infrastructure à clé publique hiérarchique
La première solution couramment utilisée est de disposer d’autorités de confiance qui certifient les clés publiques en les signant numériquement : on parle de certificats. Ana demande à l’autorité de certifier sa clé publique. L’autorité vérifie l’identité d’Ana, par exemple en lui demandant sa carte d’identité, puis signe numériquement sa clé. Avant d’utiliser la clé d’Ana, Bea (ou son ordinateur) vérifie qu’elle est bien signée par une autorité qu’elle considère comme digne de confiance. On parle d’infrastructure à clé publique hiérarchique (hierarchical public key infrastructure, ou hierarchical PKI en anglais).
31.5.2.1 Le protocole TLS
C’est le principe qui est couramment utilisé pour authentifier les sites web ou les serveurs mail avec lesquels l’ordinateur établit une connexion chiffrée. Les enjeux les plus courants lors de l’établissement d’une connexion chiffrée vers un site web sont la protection de mots de passe — pour se connecter à son compte mail par exemple — ou la protection de données bancaires — pour effectuer des achats sur des sites de vente en ligne. Le protocole utilisé pour ce type de chiffrement est appelé TLS (anciennement SSL)397.
Ce standard permet d’encapsuler le protocole applicatif utilisé habituellement dans une couche de chiffrement. Par exemple, le protocole web HTTP, quand il est encapsulé dans du TLS, donc chiffré, est appelé HTTPS. Il en va de même pour les protocoles mail POPS, IMAPS et SMTPS.
On peut expliquer le protocole TLS comme une salutation très cordiale entre l’ordinateur d’origine et le serveur de destination. Ils vont s’assurer du chiffrement de la communication en s’échangeant des clés de chiffrement.
31.5.2.2 Le problème des autorités de certification
Ce sont des autorités de certification (CA, par ses initiales anglaises) qui vont assurer que ces clés de chiffrement sont les bonnes et vont produire pour cela un certificat électronique. Cependant, une telle solution ne fait que déplacer le problème : il faut faire confiance à l’autorité de certification. En général, ce sont des entreprises commerciales, et plus rarement des administrations.
Ainsi Microsoft, Apple et Mozilla incluent chacun des autorités de certification de gouvernements parmi les autorités de certification reconnues par leurs navigateurs web398. Mozilla Firefox inclut399 notamment des autorités de certifications de gouvernements (chinois, catalan, espagnol, néerlandais, turc), d’entreprises de certification (Entrust, GoDaddy, Verisign), et d’entreprises de télécommunications (Amazon, Deutsche Telecom, Google).
Firefox inclut aussi l’autorité du groupe de recherche sur la sécurité d’Internet (Internet Security Research Group). Ce groupe a mis en place Let’s Encrypt, une autorité de certification gratuite, libre et automatisée lancée en 2016 qui simplifie l’accès à des certificats électroniques valides pour les petits serveurs.
Mais les gouvernements, qui peuvent souvent se positionner en monstre du milieu, ont le pouvoir de désigner n’importe quel certificat comme valide pour un site web en le signant avec leur autorité de certification : les navigateurs web qui l’incluent n’y verraient que du feu.
Dans le cas des entreprises, leur but premier n’est pas de certifier des identités mais de gagner de l’argent, en vendant comme service la certification d’identités. Mais vérifier une identité coûte cher. Qu’est-ce qui nous prouve qu’elles le font correctement ? Que leurs clés privées utilisées pour signer sont stockées dans un endroit sûr ? Encore une fois, c’est une question de confiance. On peut espérer que, ne serait-ce que pour maintenir leur activité, ces autorités de certification font bien leur travail…
Sauf que… des exemples montrent qu’elles le font parfois très mal. Ainsi, en 2008, des chercheurs ont réussi à créer de faux certificats « valides », car six autorités de certifications utilisaient encore des algorithmes cryptographiques qui étaient, de notoriété publique, cassés depuis 2004400. Les certificats ainsi créés sont de « vrais-faux » certificats : le navigateur web les reconnaît comme vrais, car malgré leur origine frauduleuse, tout laisse à penser qu’ils ont été établis par une autorité reconnue.
En 2011, neuf vrais-faux certificats signés par Comodo, une autorité de certification, ont été créés. Au moins l’un de ces certificats aurait été utilisé sur le web401. La société a mis plus d’une semaine à assumer publiquement cette compromission — et nombre d’entre elles ne le font probablement pas dans ce genre de situations, pour éviter la mauvaise publicité402 et les pertes financières qui vont avec.
Par ailleurs, il semble que si la police ou la justice de leur pays le leur ordonne, certaines autorités de certification donnent aux flics de vrais-faux certificats, établis au nom d’entités qu’elles voudraient surveiller403. Cela dit, il faut quand même que ces vrais-faux certificats soient mis en place à l’endroit adéquat sur Internet et combinés à des attaques du monstre du milieu afin d’être exploités au mieux. Enfin, nos connexions passant en général par plusieurs pays, cette attaque peut tout à fait être déployée par un pays différent de celui depuis lequel on se connecte.
Dans une brochure commerciale, Packet Forensics, une compagnie états-unienne qui vend du matériel de surveillance réseau, écrit ainsi que « pour utiliser notre produit dans ce scénario, les utilisateurs gouvernementaux ont la possibilité d’importer une copie d’une clé légitime qu’ils peuvent obtenir (potentiellement grâce à une réquisition judiciaire) »404. Le PDG de Packet Forensics aurait confirmé oralement à l’auteur de l’étude que des clients gouvernementaux collaborent avec des autorités de certification pour obtenir des vrais-faux certificats à utiliser lors d’opérations de surveillance405.
31.5.3 Toile de confiance
Une autre solution à la question de l’authenticité des clés publiques est la toile de confiance, ou web of trust en anglais.
Plutôt que de faire confiance à quelques autorités centralisées, il s’agit d’établir un lien de confiance de proche en proche. Ainsi, Bea ne connaît pas Ana, mais elle connaît Dan, qui connaît Emi, qui connaît Ana. Il y a donc un chemin de confiance entre Bea et Ana. S’il n’y avait que ce chemin de confiance, cela impliquerait que Bea place une forte confiance en Emi, qu’elle ne connaît pas directement. Mais Bea connaît aussi Nat, qui connaît Sasha, qui connaît lui aussi Ana. Elle connaît aussi Noah qui connaît Meri, qui connaît Ana. Il y a donc trois chemins de confiance entre Ana et Bea, qui n’a pas besoin d’avoir une confiance totale dans chacune des parties en jeu dans la certification.
Toile de confiance qui relie Ana et Bea
Ces toiles de confiance sont couramment utilisées pour l’authentification des logiciels et des communications personnelles, comme des courriers électroniques, en utilisant le standard OpenPGP. Elles ne sont hélas pas utilisées couramment pour authentifier des sites web, bien que ce soit possible techniquement406.
Les toiles de confiance permettent donc de se prémunir des attaques du monstre du milieu sans devoir faire confiance à des autorités centralisées. Cependant, la participation à une toile de confiance nécessite de dévoiler les liens entre des personnes, des réseaux d’amies ou de militantes. Est-ce que l’on veut vraiment publier la liste de nos amies ou de nos camarades ?
31.6 Confidentialité persistante
Comme on l’a vu, quiconque possède une clé secrète peut l’utiliser pour déchiffrer un texte qui a été chiffré en utilisant la clé publique qui lui est associée. C’est une propriété très utile, mais qui dans certains cas peut se révéler embarrassante.
Admettons qu’une personne mal intentionnée enregistre une conversation en ligne chiffrée entre deux personnes. Elle ne pourra bien sûr rien lire du contenu de cette conversation dans l’immédiat. Mais elle peut avoir l’idée de s’introduire ensuite chez ces personnes ou dans leur ordinateur et de mettre la main sur leurs clés privées. Dans ce cas, elle sera en mesure de lire, a posteriori, toutes les conversations passées qu’elle aura conservées.
Ce fut le cas il y a quelques années, lorsque les admins du serveur autistici.org se rendirent compte lors d’un procès que la police avait mis la main sur les clés secrètes installées sur leur serveur, parce qu’ils produisaient au dossier des échanges d’emails qu’ils n’auraient normalement pas dû être capables de lire407.
Pour éviter qu’un secret éventé ne compromette a posteriori de nombreux autres secrets qui en dépendent (comme par exemple le contenu de conversations en messagerie instantanée pourtant chiffrées, des échanges d’emails, etc.) certains logiciels incluent des fonctions dites de confidentialité persistante408 (ou Perfect Forward Secrecy, en anglais).
Elles assurent que même si un jour un secret à long terme, typiquement une clé privée, est découverte par un adversaire, les échanges seront protégés d’une analyse a posteriori.
Dans les faits, au lieu d’utiliser directement la clé publique pour chiffrer les communications, ce type de chiffrement utilise un protocole d’échange de secrets conçu pour fonctionner même sur un canal de communication non sûr, en négociant une clé temporaire à chaque session de communication. La clé secrète d’une paire de clés ne sert, dans ce cas, qu’à s’assurer qu’on communique bien avec la bonne personne, en signant cet échange de secret.
C’est ensuite ce secret temporaire qui est utilisé pour chiffrer de façon symétrique les communications.
Une fois la communication terminée, il suffit que les logiciels impliqués oublient ce secret temporaire. Quand bien même quelqu’un mettrait la main sur les clés secrètes des deux parties, la confidentialité de la communication ne serait pas compromise : les participants de l’échange eux-mêmes n’y ont plus accès.
Pour protéger la vie privée des internautes, le protocole TLS implémente la confidentialité persistante.
31.7 Résumé et limites
La cryptographie asymétrique est donc un bon complément à la cryptographie symétrique dès qu’il s’agit non pas de protéger seulement nos données, mais plutôt le contenu de nos communications : échange d’emails, navigation sur le web, conversations par messagerie instantanée, etc. Son utilisation n’est pas aussi compliquée qu’on pourrait le craindre, et faire du chiffrement une routine permet aux informations particulièrement sensibles d’être noyées dans la masse.
Pour finir ce petit tour des techniques de cryptographie, il est bon de se rappeler que le chiffrement, aussi difficile à casser soit-il, a des limites, qu’on a évoquées dans le premier tome de ce guide. Ces limites touchent notamment à la confiance qu’on met dans l’ordinateur et les logiciels auxquels on confie le chiffrement et le déchiffrement (et donc le texte en clair). Elles touchent aussi aux obligations légales de fournir aux autorités les moyens de déchiffrer des communications lorsqu’elles le demandent. Elles touchent enfin à l’évolution de la cryptographie : ce qui est sûr aujourd’hui ne le sera peut-être pas demain.
Enfin, si le chiffrement permet de cacher le contenu de la communication, les parties impliquées (qui communique avec qui) restent apparentes.
Cette section est reprise de Wikipédia, 2022, Chiffrement de bout en bout.↩︎
La factorisation de ce nombre de 768 bits en 2010 a nécessité 1020 opérations. Les chercheurs qui l’ont réalisée estiment que le calcul aurait pris environ 2000 ans sur un seul cœur d’un AMD Opteron à 2,2 GHz, ce qui correspond à plusieurs centaines d’années sur un processeur actuel (Kleinjung et al., 2010, Factorization of a 768-bit RSA modulus — en anglais).↩︎
Agence nationale de la sécurité des systèmes d’information, 2014, Mécanismes cryptographiques – Règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques.↩︎
S. A. Danilov, I. A. Popovyan, 2010, Factorization of RSA-180 (en anglais).↩︎
Nicole Perlroth, Jeff Larson et Scott Shane, 2013, N.S.A. Able to Foil Basic Safeguards of Privacy on Web, The New York Times (en anglais).↩︎
L’usage courant est de parler d’attaque de l’homme du milieu. La communauté hacktiviste questionne l’inclusivité de ce concept en utilisant des expressions alternatives : humaine du milieu, personne du milieu, machine du milieu, monstre du milieu, etc.↩︎
Pixellibre.net, 2011, #OpSyria : les preuves parlent d’elle même., ou plus précis, mais en anglais Jakub Dalek and Adam Senft, 2011, Behind Blue Coat, Investigations of commercial filtering in Syria and Burma, The Citizen Lab.↩︎
SSL pour Secure Sockets Layer ou « Couche de sockets sécurisée » est le prédécesseur de TLS pour Transport Layer Security ou « Sécurité de la couche de transport ».↩︎
Christopher Soghoian, Sid Stamm, 2011, Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL, Financial Cryptography and Data Security (en anglais).↩︎
Common CA Database, 2017, CA Certificates In Firefox (en anglais).↩︎
Alexander Sotirov et al., 2008, MD5 considered harmful today – Creating a rogue CA certificate (en anglais).↩︎
Comodo, 2011, Comodo Fraud Incident (en anglais).↩︎
Jacob Appelbaum, 2011, Detecting Certificate Authority compromises and web browser collusion (en anglais).↩︎
Christopher Soghoian, Sid Stamm, 2011, Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL, Financial Cryptography and Data Security (en anglais).↩︎
« To use our product in this scenario, government users have the ability to import a copy of any legitimate key they obtain (potentially by court order) ». Citation extraite du papier de Christopher Soghoian et Sid Stamm cité ci-dessus, et traduite par nos soins.↩︎
Cette citation se trouve dans une version préliminaire, datant d’avril 2010, du papier de Christopher Soghoian et Sid Stamm cité ci-dessus ; cette version est disponible sur cryptome.org (en anglais).↩︎
Ainsi, le projet Monkeysphere (en anglais) permet d’étendre l’utilisation des toiles de confiance d’OpenPGP à l’authentification de sites web.↩︎
Austitci, 2005, CRACKDOWN, violato autistici.org – some legal notes (en anglais).↩︎