In 2020, YouTube ripper Yout.com sued the RIAA , asking a Connecticut district court to declare that the site does not violate the DMCA’s anti-circumvention provision.

The music group had previously used DMCA takedown notices to remove many of Yout’s appearances in Google’s search results. This had a significant impact on revenues, the site argued, adding that it always believed it wasn’t breaking any laws and hoped the court would agree.

Dismissal and Appeal

Last October, the Connecticut district court concluded that Yout had failed to show that it doesn’t circumvent YouTube’s technological protection measures. As such, it could be breaking the law.

Yout operator Johnathan Nader opted to appeal the decision. Nader’s attorneys filed their opening brief last week at the Court of Appeals for the Second Circuit, asking it to reverse the lower court’s decision.

The YouTube ripper is not the only party calling for a reversal. Yesterday, Microsoft-owned developer platform GitHub submitted an amicus brief that argues for the same. And in a separate filing, the EFF also agrees that the lower court’s decision should be overturned.

GitHub’s Amicus Brief

GitHub’s brief starts by pointing out that the company takes no position on the ultimate resolution of this appeal, nor does it side with all of Yout’s arguments. However, it does believe that the lower court’s interpretation of the DMCA is dangerous.

The district court held that stream rippers can violate the DMCA’s anti-circumvention provision. The court noted that these tools allow people to download video and audio from YouTube, despite the streaming platform’s lack of a download button.

According to GitHub, this conclusion is premature, dangerous, and places other software types at risk.

“[T]he district court’s expansive interpretation of the DMCA’s anti-circumvention provision compels GitHub to point out how the court’s rationale needlessly threatens countless other software tools in widespread use,” GitHub writes.

The developer platform is not new to this issue. The RIAA previously tried to remove the open-source software youtube-dl – upon which Yout.com relies – from its platform. After initially removing it, GitHub later decided to reinstate the project , arguing that it doesn’t violate the DMCA.

In the present lawsuit, GitHub reiterates that stream-ripping tools should not be outlawed. The fact that YouTube doesn’t have a download button doesn’t mean that tools that enable people to download videos circumvent technological access restrictions.

“YouTube’s decision not to provide its own ‘download’ button, however, is not a restriction on access to works. It merely affects how users experience them,” GitHub writes.

If the court order is allowed to stand, GitHub warns that a broad group of developers could be exposed to criminal liability, effectively chilling technological innovation.

“The district court’s expansive interpretation is particularly alarming because, unlike most copyright provisions, the DMCA imposes criminal penalties. At a minimum, those penalties underscore the importance of rejecting a construction that sweeps in a broad range of widely accepted conduct.”

Browser Extensions, Screen Readers, Ad-Blockers and More

YouTube download tools are not the only types of software at risk, according to GitHub. There are many others that affect ‘how users experience’ online websites. These could also be seen as problematic, based on the district court’s expansive interpretation of the DMCA.

GitHub lists several examples, including browser extensions such as ‘Dark Reader,’ ‘Google Translate,’ and ‘OpenDyslexic’. The same also applies to screen readers, ad blockers, and media player software such as VLC, which plays YouTube videos outside of a web browser.

These widely accepted tools could put their creators at risk if the DMCA is interpreted too strictly, GitHub warns.

“On the district court’s erroneous theory, the developers who offer those widely embraced applications could be criminals facing hundreds of thousands of dollars in fines or years in prison.”

EFF’s Amicus Brief

The Electronic Frontier Foundation ( EFF ) also submitted an amicus curiae brief yesterday. The digital rights group takes interest in copyright cases, particularly when they get in the way of people’s ability to freely use technology.

In this instance, EFF points out that stream-rippers such as Yout.com provide a neutral technology with plenty of legal uses. They can be used for infringing purposes, but that’s also true for existing technologies – the printing press, for example.

“Like every reproduction technology — from the printing press to the smartphone — these programs, colloquially called ‘streamrippers,’ have important lawful uses as well as infringing ones.

“Video creators, educators, journalists, and human rights organizations all depend on the ability to make copies of user-uploaded videos,” EFF adds.

In common with GitHub, EFF notes that the absence of a download button on YouTube doesn’t imply that download tools automatically violate the DMCA, especially when there are no effective download restrictions on the platform.

‘No Encryption’

The DMCA’s anti-circumvention provision is aimed at tools that bypass effective technological access restrictions. That doesn’t apply to YouTube’s Javascript-based code, EFF argues.

“The YouTube website code at issue in this case is different: it was not clearly designed to limit access to videos, or the ability to copy them. YouTube videos arrive at a viewer’s device with no encryption or scrambling. No login, password, key, or other secret knowledge is required to gain access.

“Tellingly, YouTube does use encryption and a password-controlled login to limit access to subscribers of its separate pay-TV service, YouTube TV,” EFF adds.

According to EFF, Yout and similar tools provide the same functions as video cassette recorders once did. They allow people to make copies of videos that are posted publicly by their creators.

In addition, these tools are vital for some reporters and useful to creatives who use them for future work.

“Journalists and human rights monitoring organizations need to be able to save copies of eyewitness videos documenting notable events, conflicts, and malfeasance. Even copyright holders and their licensees rely on tools like Yout.com to download copies of their own or licensed works.”

“This Court should reject the unwarranted expansion of Section 1201 liability, and reverse the dismissal of Yout.com’s claims,” EFF concludes.

The RIAA has yet to respond to Yout’s appeal brief. Considering the importance of the case, it seems likely that they will also receive support from other rightsholders or their representatives.

—

A copy of GitHub’s Amicus Curiae brief calling for the reversal of the lower court’s decision in favor of the RIAA is available here (pdf) and EFF’s brief can be found here (pdf)

From: TF , for the latest news on copyright battles, piracy and more.

Bonjour à tous ! Le titre est assez explicite : on rempile sur d'autres points de vue sur le chiffrement, ce qui a été dit, les argumentaires etc. Le chiffrement est un thème complexe en général, et avant d'en avoir fait le tour, il est nécessaire d'avoir beaucoup lu, réfléchi, etc. Et encore, notre...

Bonjour à tous !

Le titre est assez explicite : on rempile sur d'autres points de vue sur le chiffrement, ce qui a été dit, les argumentaires etc.

Le chiffrement est un thème complexe en général, et avant d'en avoir fait le tour, il est nécessaire d'avoir beaucoup lu, réfléchi, etc. Et encore, notre réflexion ne s'attaque aux algorithmes que superficiellement, histoire d'en connaître leur structure et leur utilité, pas les détails d'implémentation. Vous l'avez compris, on reprend là où on s'était arrêtés.

L'EFF

On va commencer par l'argumentaire de l'EFF --- l'Electronic Frontier Foundation, une ONG composée de geeks et d'avocats, à ce que je vois, pour défendre bien des idéaux sur le net --- qui a publié un amicus curiæ --- ami de la cour en latin, désigne par métonymie un document qui servait à éclairer les décisions du souverain à l'époque, et à proposer un point de vue au gouvernement. Et vous n'imaginez pas ma surprise en le lisant. Je pensais --- sans être exhaustif, bien sûr --- avoir abordé la majorité des points importants à soulever dans ce débat, même brièvement. Eh bah non. l'amicus curiæ de l'EFF se trouve ici, et commence sur un ton très différent de mes articles sur le chiffrement. Merci internet, j'adore. Ça commence p.9 à la ligne 7.5 (si, si, allez voir le document vous dis-je) :

Amici curiae submitting this brief have a special interest in helping this Court understand that its Order places a significant burden on the free speech rights of Apple and its programmers by compelling them to write code and then to use their digital signature to endorse that code to the FBI, their customers and the world.

Si j'essaie de traduire pour les anglophobes/angloagnostiques, ça donne quelque chose comme :

Les Amis de la cour qui soumettent ce dossier ont un intérêt particulier à faire comprendre à la Cour que cet Arrêt (la demande de backdoor du chiffrement par un juge, NDT) pèse contre la liberté d'expression d'Apple et de ses programmeurs, puisque cet Arrêt les oblige à écrire du code et le signer numériquement et prendre la responsabilité de ce code devant le FBI, ses clients (Apple) et le monde.

En gros, et en français moins littéral, l'EFF soutien que :

• le premier amendement des États-Unis s'applique au code écrit par Apple (cf. la suite de l'amicus, où p.11 ils défendent le fait que le premier amendement est applicable) ;
• "par conséquent" --- tout l'intérêt de l'argumentation de l'amicus --- imposer à Apple d'écrire du code qui n'est pas le leur, puis de le signer constitue une violation du premier amendement du Bill of Rights.

On remarque qu'il y a un abîme culturel entre mon mode de pensée et celui des juristes américains, très pragmatiques, qui savent quels sont les outils à leur disposition, en l'occurence leur Constitution.

Il faut savoir qu'aux États-Unis, les principes énoncés dans le Bill of Rights ont une valeur beaucoup plus forte que dans notre France et son droit romain. C'est justement lié au type de droit en vigueur, notamment l'opposition droit romain/droit anglosaxon. Typiquement, le droit romain essaie à l'avance de prévoir tous les cas, et de définir les peines associées si nécessaire. Ce n'est pas le cas du droit anglosaxon où la jurisprudence et le lien entre les affaires est beaucoup plus important. Ainsi aux États-Unis, le premier amendement est quasi-absolu : il garantit la possibilité de pouvoir tout dire, mais dans le cas où une personne tient un discours haineux, à teneur racial où je ne sais quoi, elle risque de se retrouver devant les tribunaux s'il y a quelqu'un pour dire : "Ce que tu as dit là me porte préjudice".

Analyse

Vous comprenez la force de cet argumentaire : un juge ne peut pas décemment aller contre la constitution des États-Unis, de même le FBI ne peut pas obtenir une ordonance d'un juge pour forcer Apple à écrire du code qui n'est pas de lui. C'est sur cette base que l'amicus attaque l'ordonance qui contraint Apple (beaucoup de boîtes par extension).

À mon avis, ce type d'argumentaire a quand même une faiblesse si on regarde ce qui se passe en France : des députés menés par le Républicain Éric Ciotti ont essayé d'interdire le chiffrement fort en rendant illégal le refus de transférer des données chiffrées, applicable pour les vendeurs de logiciel, les opérateurs de télécommunications, et probablement de matériel (pas écrit mais on peut discuter la nature du chiffrement matériel à mon avis).

Les conséquences de ce type d'amendement qui interdit "les entreprises qui fournissent du chiffrement fort" de facto empêcherait des entreprises comme Apple de fournir du chiffrement fort pour la simple et bonne raison qu'Apple ne peut pas se permettre de perdre un à un des marchés aussi importants.

En conclusion de cette première partie, on peut dire que sauf si les États s'amusent à changer les règles du marché, ce qui est complètement possible, l'argumentaire de l'EFF est très fort aux États-Unis et très intéressant.

John Oliver hôte de Last Week Tonight : encryption

Vous le savez, Hashtagueule a une longueur d'avance sur tout dans ce monde --- ou presque ! Bon, d'accord, ce n'est pas vrai, sauf parfois, et en ce qui concerne le chiffrement, on est plutôt à l'heure. Donc, entre mon précédent article sur le chiffrement et celui-ci, un comédien britannique nommé John Oliver et émigré aux États-Unis a décidé que le thème de son seul-en-scène quasi-hebdomadaire à la télévision serait sur le chiffrement. Voici la vidéo sur DailyMotion et la même sur YouTube (pas disponible partout).

Je vous encourage à la regarder, puisque c'est fait sur un ton humoristique, et qu'une partie de ce qui suit commente la vidéo.

• À 2:18/6:10, John Oliver parle de l'iPhone de Syed Farook, et dit que le FBI ne peut pas rentrer dedans, ce qui n'est que la moitié de l'histoire : Apple a fourni la backup iCloud de cet iPhone. De plus la NSA a des accès aux iPhones probablement via des malwares et autres chevaux de troie, cf. ce qu'en dit Snowden, conséquence du fait qu'il n'existe pas de machine de Turing (donc d'ordinateur) absolument sécurisée contre toutes les attaques.
• À 4:26 : en effet, beaucoup pensent de manière trop simpliste au chiffrement. Pas de sécurité sur internet sans. Et c'est pas parce qu'on veut quelque chose qu'on l'obtient. En l'occurrence, les maths disent le contraire : si je chiffre des données avec un algorithme puissant, il va parfois être nécessaire d'utiliser des centaines de machines pendant des milliers d'heures pour décrypter ce qui a été chiffré. D'où l'utilisation d'une backdoor dans le logiciel comme solution alternative.
• À 8:00 : 175 iPhones état de NY seul. Cela conforte mon opinion que l'essentiel de cette affaire est le côté légal, cf. les autres arguments de La guerre sur le chiffrement 1.
• À 8:39 : All Writs Act : déjà cité dans l'amicus de l'EFF : selon l'EFF cet argument de type légal ne peut pas aller contre la constitution, cf. p.32 de l'amicus. Le texte de la loi énonce :

(a) The Supreme Court and all courts established by Act of Congress may issue all writs necessary or appropriate in aid of their respective jurisdictions and agreeable to the usages and principles of law.

En gros les juridictions peuvent faire les décrets pour faire appliquer des lois en vigueur, dans les limites de la loi.

Une brêve histoire de la guerre contre le chiffrement

• À 8:50--9:55 : John parle rapidement de l'histoire sur la guerre contre le chiffrement. Eh oui. C'est pas nouveau sous le soleil, tout ça, loin de là ! J'en profite pour faire un exposé un peu plus approfondi sur le sujet.

Dans les années 90, le chiffrement était encore classé comme arme de guerre aux États-Unis, avec les avantages et les inconvénients que ça comporte (le droit de porter une arme, par exemple) :

Legal Hacks @xkcd.com/504

Les inconvénients étant que l'export d'armes depuis les États-Unis était limité --- interdit aux civils.

N'en faisant qu'à sa tête --- et on le remercie --- Philip Zimmermann publie sur son FTP (public) le code source de sa première version de PGP (Pretty Good Privacy) un logiciel de chiffrement destiné aux mails (puis il publiera le code source dans un livre, de mémoire, qui sera publié à l'étranger :)).

Le résultat, c'est qu'il a eu des problèmes pendant à peu près trois grosses années pour avoir fait ça, et qu'un peu avant il a été repéré par un type super du nom de Eben Moglen --- un socle en ce qui concerne le droit dans le logiciel libre --- ce qu'il raconte dans cette vidéo YouTube de 10 min (le lien envoie directement à la partie sur le chiffrement), et aussi dans ce plus long PDF.

Pour faire court jusqu'en 1995 il aura des soucis avec la justice, jusqu'à ce que l'affaire tombe, lorsque les banques et commerces se sont rendus compte qu'il ne pouvait pas y avoir de transactions sur internet sans chiffrement pour la confidentialité, et signature pour la sécurité des échanges.

John Oliver ne parle pas énormément du problème qu'aurait été le fameux "Clipper Chip" permettant aux gouvernements une backdoor généralisée dans les ordinateurs : peut-être la majorité fait-elle confiance au gouvernement états-unien pour ne pas être dangereux, autant d'autres gouvernements sur la planète ne sont pas si agréables.

Qui plus est, on a appris que la NSA avait des programmes pour faire de l'espionnage industriel ce qui veut dire que même du gouvernement états-unien, beaucoup ont intérêt à se protéger, au moins un minimum.

• À 12:21 : "most agree" : cf les 46 grands noms de l'informatique qui signent l'amicus de l'EFF. Au hasard, il y a des cryptographes renommés (Zimmermann, Martin Hellman, Ron Rivest et j'en passe...), le créateur du langage Python, un des professeurs de Donald Knuth (impressionant !) et beaucoup trop pour une toute petite liste, allez lire la fin de l'amicus.
• À 12:55--13:34 : Le chiffrement est disponible et amélioré souvent en  open source ou logiciel libre, ou les algorithmes sont ouverts et disponibles sur internet. Personnellement je préfère utiliser Signal que Telegram, et Snowden aussi (et cette fois c'est pas du bullshit contrairement à la case "Le saviez-vous" de Hashtagueule, où l'une des citations est "Je tiens mes infos de Hashtagueule --- Snowden")
• À 15:00 : "until i started getting briefed by people in the intel community." Je pense que la conclusion la plus objective concernant la guerre sur le chiffrement est "it's possible. but not that simple".

De nouvelles perspectives ?

Le dernier point que je vais aborder est la confiance. Je l'ai déjà évoquée, mais je refais une couche pour illustrer. Si l'on avait plus confiance dans son smartphone, de nouveaux services pourraient voir le jour, de nouvelles utilisation exister. Par exemple peu de gens utilisent leur téléphone pour parler à leur avocat ou leur notaire (je sais qu'il s'agit d'actes rares, mais surtout d'un endroit où il faut avoir pleinement confiance dans l'identité de la personne à qui l'on parle, les données échangées).

Pour illustrer mon propos, je vais faire simple : avec du chiffrement, les écoutes entre le téléphone portable de Sarkozy et son avocat auraient été plus difficilles. Il aurait fallu compromettre le téléphone et non pas seulement le mettre sur écoute. Qu'on l'aime ou qu'on trouve que c'est une ordure, je ne peux pas le plaindre étant donné qu'il a le premier renforcé discrètement le renseignement, et que sans son décret de 2008, il n'aurait peut-être pas été mis sur écoute, et qu'avec du chiffrement fort, il aurait très probablement eu la paix.

Merci de m'avoir suivi jusqu'ici, je vous souhaite une très bonne journée, j'espère que vous commenterez l'article, donnerez votre opinion sur le chiffrement, que ça nourira votre pensée itout. À très vite !

Motius

PS : tl;dr :

• l'EFF utilise le premier amendement pour défendre le droit d'Apple d'écrire du code, et par extension des logiciels de chiffrement fort.
• John Oliver traite du chiffrement dans son seul-en-scène.

Bonjour à tous ! Le titre est assez explicite : on rempile sur d'autres points de vue sur le chiffrement, ce qui a été dit, les argumentaires etc. Le chiffrement est un thème complexe en général, et avant d'en avoir fait le tour, il est nécessaire d'avoir beaucoup lu, réfléchi, etc. Et encore, notre...

Bonjour à tous !

Le titre est assez explicite : on rempile sur d'autres points de vue sur le chiffrement, ce qui a été dit, les argumentaires etc.

Le chiffrement est un thème complexe en général, et avant d'en avoir fait le tour, il est nécessaire d'avoir beaucoup lu, réfléchi, etc. Et encore, notre réflexion ne s'attaque aux algorithmes que superficiellement, histoire d'en connaître leur structure et leur utilité, pas les détails d'implémentation. Vous l'avez compris, on reprend là où on s'était arrêtés.

L'EFF

On va commencer par l'argumentaire de l'EFF --- l'Electronic Frontier Foundation, une ONG composée de geeks et d'avocats, à ce que je vois, pour défendre bien des idéaux sur le net --- qui a publié un amicus curiæ --- ami de la cour en latin, désigne par métonymie un document qui servait à éclairer les décisions du souverain à l'époque, et à proposer un point de vue au gouvernement. Et vous n'imaginez pas ma surprise en le lisant. Je pensais --- sans être exhaustif, bien sûr --- avoir abordé la majorité des points importants à soulever dans ce débat, même brièvement. Eh bah non. l'amicus curiæ de l'EFF se trouve ici, et commence sur un ton très différent de mes articles sur le chiffrement. Merci internet, j'adore. Ça commence p.9 à la ligne 7.5 (si, si, allez voir le document vous dis-je) :

Amici curiae submitting this brief have a special interest in helping this Court understand that its Order places a significant burden on the free speech rights of Apple and its programmers by compelling them to write code and then to use their digital signature to endorse that code to the FBI, their customers and the world.

Si j'essaie de traduire pour les anglophobes/angloagnostiques, ça donne quelque chose comme :

Les Amis de la cour qui soumettent ce dossier ont un intérêt particulier à faire comprendre à la Cour que cet Arrêt (la demande de backdoor du chiffrement par un juge, NDT) pèse contre la liberté d'expression d'Apple et de ses programmeurs, puisque cet Arrêt les oblige à écrire du code et le signer numériquement et prendre la responsabilité de ce code devant le FBI, ses clients (Apple) et le monde.

En gros, et en français moins littéral, l'EFF soutien que :

• le premier amendement des États-Unis s'applique au code écrit par Apple (cf. la suite de l'amicus, où p.11 ils défendent le fait que le premier amendement est applicable) ;
• "par conséquent" --- tout l'intérêt de l'argumentation de l'amicus --- imposer à Apple d'écrire du code qui n'est pas le leur, puis de le signer constitue une violation du premier amendement du Bill of Rights.

On remarque qu'il y a un abîme culturel entre mon mode de pensée et celui des juristes américains, très pragmatiques, qui savent quels sont les outils à leur disposition, en l'occurence leur Constitution.

Il faut savoir qu'aux États-Unis, les principes énoncés dans le Bill of Rights ont une valeur beaucoup plus forte que dans notre France et son droit romain. C'est justement lié au type de droit en vigueur, notamment l'opposition droit romain/droit anglosaxon. Typiquement, le droit romain essaie à l'avance de prévoir tous les cas, et de définir les peines associées si nécessaire. Ce n'est pas le cas du droit anglosaxon où la jurisprudence et le lien entre les affaires est beaucoup plus important. Ainsi aux États-Unis, le premier amendement est quasi-absolu : il garantit la possibilité de pouvoir tout dire, mais dans le cas où une personne tient un discours haineux, à teneur racial où je ne sais quoi, elle risque de se retrouver devant les tribunaux s'il y a quelqu'un pour dire : "Ce que tu as dit là me porte préjudice".

Analyse

Vous comprenez la force de cet argumentaire : un juge ne peut pas décemment aller contre la constitution des États-Unis, de même le FBI ne peut pas obtenir une ordonance d'un juge pour forcer Apple à écrire du code qui n'est pas de lui. C'est sur cette base que l'amicus attaque l'ordonance qui contraint Apple (beaucoup de boîtes par extension).

À mon avis, ce type d'argumentaire a quand même une faiblesse si on regarde ce qui se passe en France : des députés menés par le Républicain Éric Ciotti ont essayé d'interdire le chiffrement fort en rendant illégal le refus de transférer des données chiffrées, applicable pour les vendeurs de logiciel, les opérateurs de télécommunications, et probablement de matériel (pas écrit mais on peut discuter la nature du chiffrement matériel à mon avis).

Les conséquences de ce type d'amendement qui interdit "les entreprises qui fournissent du chiffrement fort" de facto empêcherait des entreprises comme Apple de fournir du chiffrement fort pour la simple et bonne raison qu'Apple ne peut pas se permettre de perdre un à un des marchés aussi importants.

En conclusion de cette première partie, on peut dire que sauf si les États s'amusent à changer les règles du marché, ce qui est complètement possible, l'argumentaire de l'EFF est très fort aux États-Unis et très intéressant.

John Oliver hôte de Last Week Tonight : encryption

Vous le savez, Hashtagueule a une longueur d'avance sur tout dans ce monde --- ou presque ! Bon, d'accord, ce n'est pas vrai, sauf parfois, et en ce qui concerne le chiffrement, on est plutôt à l'heure. Donc, entre mon précédent article sur le chiffrement et celui-ci, un comédien britannique nommé John Oliver et émigré aux États-Unis a décidé que le thème de son seul-en-scène quasi-hebdomadaire à la télévision serait sur le chiffrement. Voici la vidéo sur DailyMotion et la même sur YouTube (pas disponible partout).

Je vous encourage à la regarder, puisque c'est fait sur un ton humoristique, et qu'une partie de ce qui suit commente la vidéo.

• À 2:18/6:10, John Oliver parle de l'iPhone de Syed Farook, et dit que le FBI ne peut pas rentrer dedans, ce qui n'est que la moitié de l'histoire : Apple a fourni la backup iCloud de cet iPhone. De plus la NSA a des accès aux iPhones probablement via des malwares et autres chevaux de troie, cf. ce qu'en dit Snowden, conséquence du fait qu'il n'existe pas de machine de Turing (donc d'ordinateur) absolument sécurisée contre toutes les attaques.
• À 4:26 : en effet, beaucoup pensent de manière trop simpliste au chiffrement. Pas de sécurité sur internet sans. Et c'est pas parce qu'on veut quelque chose qu'on l'obtient. En l'occurrence, les maths disent le contraire : si je chiffre des données avec un algorithme puissant, il va parfois être nécessaire d'utiliser des centaines de machines pendant des milliers d'heures pour décrypter ce qui a été chiffré. D'où l'utilisation d'une backdoor dans le logiciel comme solution alternative.
• À 8:00 : 175 iPhones état de NY seul. Cela conforte mon opinion que l'essentiel de cette affaire est le côté légal, cf. les autres arguments de La guerre sur le chiffrement 1.
• À 8:39 : All Writs Act : déjà cité dans l'amicus de l'EFF : selon l'EFF cet argument de type légal ne peut pas aller contre la constitution, cf. p.32 de l'amicus. Le texte de la loi énonce :

(a) The Supreme Court and all courts established by Act of Congress may issue all writs necessary or appropriate in aid of their respective jurisdictions and agreeable to the usages and principles of law.

En gros les juridictions peuvent faire les décrets pour faire appliquer des lois en vigueur, dans les limites de la loi.

Une brêve histoire de la guerre contre le chiffrement

• À 8:50--9:55 : John parle rapidement de l'histoire sur la guerre contre le chiffrement. Eh oui. C'est pas nouveau sous le soleil, tout ça, loin de là ! J'en profite pour faire un exposé un peu plus approfondi sur le sujet.

Dans les années 90, le chiffrement était encore classé comme arme de guerre aux États-Unis, avec les avantages et les inconvénients que ça comporte (le droit de porter une arme, par exemple) :

Legal Hacks @xkcd.com/504

Les inconvénients étant que l'export d'armes depuis les États-Unis était limité --- interdit aux civils.

N'en faisant qu'à sa tête --- et on le remercie --- Philip Zimmermann publie sur son FTP (public) le code source de sa première version de PGP (Pretty Good Privacy) un logiciel de chiffrement destiné aux mails (puis il publiera le code source dans un livre, de mémoire, qui sera publié à l'étranger :)).

Le résultat, c'est qu'il a eu des problèmes pendant à peu près trois grosses années pour avoir fait ça, et qu'un peu avant il a été repéré par un type super du nom de Eben Moglen --- un socle en ce qui concerne le droit dans le logiciel libre --- ce qu'il raconte dans cette vidéo YouTube de 10 min (le lien envoie directement à la partie sur le chiffrement), et aussi dans ce plus long PDF.

Pour faire court jusqu'en 1995 il aura des soucis avec la justice, jusqu'à ce que l'affaire tombe, lorsque les banques et commerces se sont rendus compte qu'il ne pouvait pas y avoir de transactions sur internet sans chiffrement pour la confidentialité, et signature pour la sécurité des échanges.

John Oliver ne parle pas énormément du problème qu'aurait été le fameux "Clipper Chip" permettant aux gouvernements une backdoor généralisée dans les ordinateurs : peut-être la majorité fait-elle confiance au gouvernement états-unien pour ne pas être dangereux, autant d'autres gouvernements sur la planète ne sont pas si agréables.

Qui plus est, on a appris que la NSA avait des programmes pour faire de l'espionnage industriel ce qui veut dire que même du gouvernement états-unien, beaucoup ont intérêt à se protéger, au moins un minimum.

• À 12:21 : "most agree" : cf les 46 grands noms de l'informatique qui signent l'amicus de l'EFF. Au hasard, il y a des cryptographes renommés (Zimmermann, Martin Hellman, Ron Rivest et j'en passe...), le créateur du langage Python, un des professeurs de Donald Knuth (impressionant !) et beaucoup trop pour une toute petite liste, allez lire la fin de l'amicus.
• À 12:55--13:34 : Le chiffrement est disponible et amélioré souvent en  open source ou logiciel libre, ou les algorithmes sont ouverts et disponibles sur internet. Personnellement je préfère utiliser Signal que Telegram, et Snowden aussi (et cette fois c'est pas du bullshit contrairement à la case "Le saviez-vous" de Hashtagueule, où l'une des citations est "Je tiens mes infos de Hashtagueule --- Snowden")
• À 15:00 : "until i started getting briefed by people in the intel community." Je pense que la conclusion la plus objective concernant la guerre sur le chiffrement est "it's possible. but not that simple".

De nouvelles perspectives ?

Le dernier point que je vais aborder est la confiance. Je l'ai déjà évoquée, mais je refais une couche pour illustrer. Si l'on avait plus confiance dans son smartphone, de nouveaux services pourraient voir le jour, de nouvelles utilisation exister. Par exemple peu de gens utilisent leur téléphone pour parler à leur avocat ou leur notaire (je sais qu'il s'agit d'actes rares, mais surtout d'un endroit où il faut avoir pleinement confiance dans l'identité de la personne à qui l'on parle, les données échangées).

Pour illustrer mon propos, je vais faire simple : avec du chiffrement, les écoutes entre le téléphone portable de Sarkozy et son avocat auraient été plus difficilles. Il aurait fallu compromettre le téléphone et non pas seulement le mettre sur écoute. Qu'on l'aime ou qu'on trouve que c'est une ordure, je ne peux pas le plaindre étant donné qu'il a le premier renforcé discrètement le renseignement, et que sans son décret de 2008, il n'aurait peut-être pas été mis sur écoute, et qu'avec du chiffrement fort, il aurait très probablement eu la paix.

Merci de m'avoir suivi jusqu'ici, je vous souhaite une très bonne journée, j'espère que vous commenterez l'article, donnerez votre opinion sur le chiffrement, que ça nourira votre pensée itout. À très vite !

Motius

PS : tl;dr :

• l'EFF utilise le premier amendement pour défendre le droit d'Apple d'écrire du code, et par extension des logiciels de chiffrement fort.
• John Oliver traite du chiffrement dans son seul-en-scène.

Bonjour à tous ! J'espère que vous avez passé de très bonnes fêtes, je suis désolé de ne pas avoir écrit plus tôt, il y a pourtant deux autres articles en préparation mais voilà, on aime tous passer du temps en famille, et puis le boulot ça occupe, mine de rien. J'ai déjà dû vous parler de l'EFF à p...

Bonjour à tous !

J'espère que vous avez passé de très bonnes fêtes, je suis désolé de ne pas avoir écrit plus tôt, il y a pourtant deux autres articles en préparation mais voilà, on aime tous passer du temps en famille, et puis le boulot ça occupe, mine de rien.

J'ai déjà dû vous parler de l'EFF à plusieurs reprises, et aujourd'hui, --- enfin il y a une semaine --- l'EFF a mis à jour son panopticlick. Petit tour des nouveautés.

Si vous ne connaissez pas l'EFF ni son outil panopticlick, sachez que le premier est une organisation de défense des libertés sur internet (c'est-à-dire des libertés, faut dire les choses telles qu'elles sont), et l'"outil" panopticlick est une page web qui à l'origine utilisait des programmes glanés sur le web pour identifier un navigateur web de manière unique.

Pour ce faire, les outils permettaient de trouver plein d'info à propos du navigateur, comme par exemple :

• s'il accepte les cookies (peu d'infomation) ;
• la résolution de l'écran (pas mal d'information, y'a beaucoup de tailles d'écran différentes) et profondeur de couleur ;
• quels plugins et extensions sont installés sur votre navigateur (Flash, Java, GNOME shell, etc...)
• zone géographique ;
• langue et pays (fr_FR, en_US...) ;
• type de navigateur (Firefox, Chromium, Lynx, Elinks, W3m, Opéra, Chrome, etc...) ;
• version du navigateur web ;
• système d'exploitation.

Avec la version 2, l'EFF va d'abord tester si votre navigateur web bloque les publicités qui vous épient. Ça ressemble à ça :

Test de mon firefox en navigation privée. Chromium en incognito donne à peu près le même résultat.

Donc là mes navigateurs bloquent les publicités intrusives, mais ils sont identifiables. Le seul navigateur non identifiable que je connaisse est le Tor Browser.

N'hésitez pas à partager le lien vers panopticlick (et cet article ;)) puisque plus l'EFF fait de tests et mieux elle peut dire si un navigateur web apparaît unique ou non.

Bonne journée et encore bonnes fêtes !

Motius

Bonjour à tous ! J'espère que vous avez passé de très bonnes fêtes, je suis désolé de ne pas avoir écrit plus tôt, il y a pourtant deux autres articles en préparation mais voilà, on aime tous passer du temps en famille, et puis le boulot ça occupe, mine de rien. J'ai déjà dû vous parler de l'EFF à p...

Bonjour à tous !

J'espère que vous avez passé de très bonnes fêtes, je suis désolé de ne pas avoir écrit plus tôt, il y a pourtant deux autres articles en préparation mais voilà, on aime tous passer du temps en famille, et puis le boulot ça occupe, mine de rien.

J'ai déjà dû vous parler de l'EFF à plusieurs reprises, et aujourd'hui, --- enfin il y a une semaine --- l'EFF a mis à jour son panopticlick. Petit tour des nouveautés.

Si vous ne connaissez pas l'EFF ni son outil panopticlick, sachez que le premier est une organisation de défense des libertés sur internet (c'est-à-dire des libertés, faut dire les choses telles qu'elles sont), et l'"outil" panopticlick est une page web qui à l'origine utilisait des programmes glanés sur le web pour identifier un navigateur web de manière unique.

Pour ce faire, les outils permettaient de trouver plein d'info à propos du navigateur, comme par exemple :

• s'il accepte les cookies (peu d'infomation) ;
• la résolution de l'écran (pas mal d'information, y'a beaucoup de tailles d'écran différentes) et profondeur de couleur ;
• quels plugins et extensions sont installés sur votre navigateur (Flash, Java, GNOME shell, etc...)
• zone géographique ;
• langue et pays (fr_FR, en_US...) ;
• type de navigateur (Firefox, Chromium, Lynx, Elinks, W3m, Opéra, Chrome, etc...) ;
• version du navigateur web ;
• système d'exploitation.

Avec la version 2, l'EFF va d'abord tester si votre navigateur web bloque les publicités qui vous épient. Ça ressemble à ça :

Test de mon firefox en navigation privée. Chromium en incognito donne à peu près le même résultat.

Donc là mes navigateurs bloquent les publicités intrusives, mais ils sont identifiables. Le seul navigateur non identifiable que je connaisse est le Tor Browser.

N'hésitez pas à partager le lien vers panopticlick (et cet article ;)) puisque plus l'EFF fait de tests et mieux elle peut dire si un navigateur web apparaît unique ou non.

Bonne journée et encore bonnes fêtes !

Motius

Bonjour à tous ! Savez-vous comment marche le mécanisme de la confiance dans une page web reçue avec HTTPS ? Petit tour rapide et présentation de Let's Encrypt. Si vous êtes un lecteur régulier du site, vous savez que le chiffrement de bout en bout est un dada chez moi, plutôt que le chiffrement poi...

Bonjour à tous !

Savez-vous comment marche le mécanisme de la confiance dans une page web reçue avec HTTPS ? Petit tour rapide et présentation de Let's Encrypt.

Si vous êtes un lecteur régulier du site, vous savez que le chiffrement de bout en bout est un dada chez moi, plutôt que le chiffrement point-à-point. On n'a pas encore fait de glossaire, donc je vais le réexpliquer à cette occasion, mais on finira par se référer à un petit manuel de bases. Donc si vous connaissez, vous pouvez zaper la partie 0 qui suit.

Chiffrement de bout en bout vs chiffrement point à point.

C'est assez simple :

• le chiffrement de bout en bout signifie que votre ordinateur chiffre avec la clef de votre correspondant, et par conséquent sur le réseau, le message est toujours chiffré ;
• le chiffrement point à point est appliqué entre vous et votre pair direct, puis (éventuellement) votre pair chiffre avec son pair, etc. jusqu'à destination, le message peut donc :
  • traverser un bout du réseau sans chiffrement ;
  • être lu par tous les pairs qui ont acheminé le message.
  • En comparaison, c'est comme si une lettre à La Poste était lu par tous ceux qui l'ont en main, et que de temps en temps le service de poste était négligent, et laissait à tous la possibilité de lire la lettre.

Sur internet vous utilisez les deux :

• le mail utilise le chiffrment point à point (sur lequel vous pouvez rajouter du chiffrement de bout en bout avec GPG/PGP) ;
• parler HTTPS avec un serveur permet de récupérer une page qui sera chiffrée entre vous et le serveur, donc d'un bout du réseau à l'autre.

Comment fonctionne le HTTPS ?

HTTP vs HTTPS, méthode de chiffement

HTTP est un protocole qui permet de récupérer des pages web. Exemples de ce qu'on peut "dire en HTTP" :

• quand on est le client :
  • donne moi la page à cette URL ;
• quand on est le serveur :
  • la page que tu m'as demandé, je l'ai, la voici ;
  • la page que tu m'as demandé, je l'ai, mais attends un peu, je suis surbooké, là (schématiquement) ;
  • la page que tu m'as demandé, bah elle existe pas (404) ;
  • ce que tu demandes n'est pas ici, va voir ailleurs (301) ;
  • j'ai pas compris ce que tu m'as demandé (400) ;
  • ce que tu fais-là, tu n'en as pas le droit (403) ;
  • le serveur est en panne (503)...

Et beaucoup d'autres. HTTPS n'est que l'utilisation d'une couche de chiffrement (SSL/TLS) pour chiffrer les données :

• la requête (pas celles initiant le chiffrement) ;
• les données échangées par la suite.

Pour visualiser la couche de chiffrement, on peut se représenter un tunnel entre le client et le serveur dans lequel la donnée passe. Personne ne peut accéder à l'intérieur du tunnel parce qu'il est solide, et le tunnel a une entrée (le client) et une sortie (le serveur).

Confiance de HTTPS

Lorsqu'Alice va demander la page web de Bob en HTTPS, que va-t-il se passer ?

• Le client A (son navigateur web Firefox) va faire une requête vers un serveur B
• B qui va indiquer qu'il sait parler HTTPS ;
• A va interroger B ;
• B va répondre, et s'il a la page, la transmettre.

Tout ça s'est fait automatiquement. Voyons un peu l'architecture de chiffrement mise en place ici. Il s'agit d'une infrastructure clef publique/clef privée + autorité de confiance :

• A va obtenir via le réseau la clef publique de B.
• Le navigateur web de A va vérifier que la clef est valide, c'est à dire qu'il s'agit bien de la bonne clef (et pas celle d'un attaquant) et qu'elle est toujours valide (par mesure de sécurité, les clefs ont une durée de validité, d'un an en général).
• A va chiffrer ses messages pour B avec la clef publique de B.
• B déchiffre ses messages avec sa clef privée.

Ainsi, la confiance que l'on a dans HTTPS dépend de deux facteurs :

• comment le navigateur reconnait qu'un certificat est valide ;
• la qualité du chiffrement, ie les algorithmes utilisés (RC4 : mauvais, AES-256 très bon, à ce jour).

On ne parlera pas plus des algorithmes ici, à la place on se concentrera sur comment le navigateur a décidé de reconnaître un certificat, ou de l'invalider.

Réseau de confiance de l'architecture X509

Le problème de fond, c'est de reconnaître la validité d'une clef de chiffrement (publique) pouvant changer fréquemment obtenue via internet.

On utilise ce qu'on appelle un pair de confiance. Si un certificat est signé par un pair de confiance, alors le certificat est considéré comme valide. Le pair de confiance dans l'architecture X509 s'appelle une autorité de certification (AC, parce que j'ai pas envie de le réécrire ;) ). Par défaut Firefox fait donc confiance à un certaint nombre d'AC.

Ainsi lorsqu'une clef publique arrive depuis internet :

• si le certificat est signé par une AC, il est valide (sauf cas exceptionnel où l'utilisateur a interdit le certificat) ;
• si le certificat n'est pas signé par une AC, mais est accepté par l'utilisateur, il est valide ;
• le reste poubelle, la connexion est terminée.

Dans les AC vous en connaissez peut-être quelques unes dont Thawte, VeriSign, GoDaddy, CA-Cert, Gandi, Google (eh oui, il font ça aussi), et depuis peu Let's Encrypt.

Mais la chaîne de confiance n'est pas complète. Comment savoir quelles sont les entités reconnues, comment en rajouter sans mettre à jour tous les navigateurs ?

Eh bien à la base de la création de X509, on a généré une clef c0, et une clef c1, on a signé la clef c1 avec la clef c0 et découpé c0 en plusieurs (4 ?) parties qu'on a dispachées dans des coffres-forts. On fait donc en sorte que la clef 0 soit reconnue, et on signe les AC avec la clef c1. Les entités créent leur clef c_entite (plusieurs en fait), qui est valide, puisque signée par c1, elle-même valide puisque signée par c0.

Récapitulons. On fait confiance à c0. c0 signe c1, de telle sorte que :

• c1 puisse signer des certificats ;
• c1 puisse signer des AC ;

On signe les AC, qui créent leur clefs, qui sont signées par c1 de telle sorte que :

• elles puissent signer des certificats ;
• éventuellement elles puissent signer d'autres AC.

Ainsi, la chaîne de confiance est une hiérarchie. Faire confiance à c0 permet/implique a priori de faire confiance à beaucoup de gens (on peut cependant demander à Firefox de ne pas accepter un certificat valide).

Subtilité de X509, résilience

Vous avez peut-être remarqué que c0 ne sert qu'à signer c1, puis on demande au navigateur de reconnaître c0, puis on signe avec c1.

Vous vous demandez peut être pourquoi... Imaginons que c0 = c1 = c$latex \alpha $, c'est à dire qu'au début de la chaîne de confiance il y ait non pas deux mais une seule clef c$latex \alpha $.

Un problème se pose, et a pas mal de répercussions :

Si la clef $latex \alpha $ est perdue alors toute la sécurité de l'architecture X509 s'effondre.

• Dans le cas où on n'a qu'une clef c$latex \alpha $, on ne peut rien faire.
• Dans le cas ou on a c0 et c1, et c1 est perdue (on suppose que c0 n'est pas perdue, elle sous clef, éparpillée sur le globe), on révoque c1 à l'aide de c0, et on regénère une clef c1'. Ça permet notamment de pouvoir rapidement recréer un environnement de confiance, et de ne pas avoir besoin de rediffuser la clef à toutes les machines.

Let's Encrypt

Alors pourquoi est-ce que je vous rabats les oreilles avec tout ça ? Eh bien pour deux raisons :

• d'abord pour que vous sachiez quelle confiance accorder dans des connexions HTTPS ;
• ensuite pour vous parler spécialement d'une AC : Let's Encrypt.

Vous l'avez compris, il y a beaucoup d'enjeux concernant une AC. La confiance qu'on a, la qualité de son travail, de la façon dont elle sécurise ses données pour ne pas perdre sa clef et servir de vecteur d'attaque, etc. Il y a d'autres enjeux dont la possibilité pour tous de chiffrer facilement, en effet les certificats ne sont pas gratuits, sauf certains de CA-Cert, et de Gandi.

C'est pourquoi Mozilla Cisco l'EFF et d'autres se sont unis pour créer une AC dont le but serit de permettre à tous de pratiquer le chiffrement à tour de bras. Et voilà qui est fait.

Depuis le 19 octobre 2015 les certificats de Let's Encrypt sont de confiance par défaut dans les versions récentes de Firefox (probablement Chrome/Chromium, Microsoft Edge, et Safari).

Let's Encrypt va donc pouvoir se mettre à un rythme de croisière de signatures de certificats d'ici très peu de temps.

Bon chiffrement à tous et bonne journée !

Motius

Bonjour à tous ! Savez-vous comment marche le mécanisme de la confiance dans une page web reçue avec HTTPS ? Petit tour rapide et présentation de Let's Encrypt. Si vous êtes un lecteur régulier du site, vous savez que le chiffrement de bout en bout est un dada chez moi, plutôt que le chiffrement poi...

Bonjour à tous !

Savez-vous comment marche le mécanisme de la confiance dans une page web reçue avec HTTPS ? Petit tour rapide et présentation de Let's Encrypt.

Si vous êtes un lecteur régulier du site, vous savez que le chiffrement de bout en bout est un dada chez moi, plutôt que le chiffrement point-à-point. On n'a pas encore fait de glossaire, donc je vais le réexpliquer à cette occasion, mais on finira par se référer à un petit manuel de bases. Donc si vous connaissez, vous pouvez zaper la partie 0 qui suit.

Chiffrement de bout en bout vs chiffrement point à point.

C'est assez simple :

• le chiffrement de bout en bout signifie que votre ordinateur chiffre avec la clef de votre correspondant, et par conséquent sur le réseau, le message est toujours chiffré ;
• le chiffrement point à point est appliqué entre vous et votre pair direct, puis (éventuellement) votre pair chiffre avec son pair, etc. jusqu'à destination, le message peut donc :
  • traverser un bout du réseau sans chiffrement ;
  • être lu par tous les pairs qui ont acheminé le message.
  • En comparaison, c'est comme si une lettre à La Poste était lu par tous ceux qui l'ont en main, et que de temps en temps le service de poste était négligent, et laissait à tous la possibilité de lire la lettre.

Sur internet vous utilisez les deux :

• le mail utilise le chiffrment point à point (sur lequel vous pouvez rajouter du chiffrement de bout en bout avec GPG/PGP) ;
• parler HTTPS avec un serveur permet de récupérer une page qui sera chiffrée entre vous et le serveur, donc d'un bout du réseau à l'autre.

Comment fonctionne le HTTPS ?

HTTP vs HTTPS, méthode de chiffement

HTTP est un protocole qui permet de récupérer des pages web. Exemples de ce qu'on peut "dire en HTTP" :

• quand on est le client :
  • donne moi la page à cette URL ;
• quand on est le serveur :
  • la page que tu m'as demandé, je l'ai, la voici ;
  • la page que tu m'as demandé, je l'ai, mais attends un peu, je suis surbooké, là (schématiquement) ;
  • la page que tu m'as demandé, bah elle existe pas (404) ;
  • ce que tu demandes n'est pas ici, va voir ailleurs (301) ;
  • j'ai pas compris ce que tu m'as demandé (400) ;
  • ce que tu fais-là, tu n'en as pas le droit (403) ;
  • le serveur est en panne (503)...

Et beaucoup d'autres. HTTPS n'est que l'utilisation d'une couche de chiffrement (SSL/TLS) pour chiffrer les données :

• la requête (pas celles initiant le chiffrement) ;
• les données échangées par la suite.

Pour visualiser la couche de chiffrement, on peut se représenter un tunnel entre le client et le serveur dans lequel la donnée passe. Personne ne peut accéder à l'intérieur du tunnel parce qu'il est solide, et le tunnel a une entrée (le client) et une sortie (le serveur).

Confiance de HTTPS

Lorsqu'Alice va demander la page web de Bob en HTTPS, que va-t-il se passer ?

• Le client A (son navigateur web Firefox) va faire une requête vers un serveur B
• B qui va indiquer qu'il sait parler HTTPS ;
• A va interroger B ;
• B va répondre, et s'il a la page, la transmettre.

Tout ça s'est fait automatiquement. Voyons un peu l'architecture de chiffrement mise en place ici. Il s'agit d'une infrastructure clef publique/clef privée + autorité de confiance :

• A va obtenir via le réseau la clef publique de B.
• Le navigateur web de A va vérifier que la clef est valide, c'est à dire qu'il s'agit bien de la bonne clef (et pas celle d'un attaquant) et qu'elle est toujours valide (par mesure de sécurité, les clefs ont une durée de validité, d'un an en général).
• A va chiffrer ses messages pour B avec la clef publique de B.
• B déchiffre ses messages avec sa clef privée.

Ainsi, la confiance que l'on a dans HTTPS dépend de deux facteurs :

• comment le navigateur reconnait qu'un certificat est valide ;
• la qualité du chiffrement, ie les algorithmes utilisés (RC4 : mauvais, AES-256 très bon, à ce jour).

On ne parlera pas plus des algorithmes ici, à la place on se concentrera sur comment le navigateur a décidé de reconnaître un certificat, ou de l'invalider.

Réseau de confiance de l'architecture X509

Le problème de fond, c'est de reconnaître la validité d'une clef de chiffrement (publique) pouvant changer fréquemment obtenue via internet.

On utilise ce qu'on appelle un pair de confiance. Si un certificat est signé par un pair de confiance, alors le certificat est considéré comme valide. Le pair de confiance dans l'architecture X509 s'appelle une autorité de certification (AC, parce que j'ai pas envie de le réécrire ;) ). Par défaut Firefox fait donc confiance à un certaint nombre d'AC.

Ainsi lorsqu'une clef publique arrive depuis internet :

• si le certificat est signé par une AC, il est valide (sauf cas exceptionnel où l'utilisateur a interdit le certificat) ;
• si le certificat n'est pas signé par une AC, mais est accepté par l'utilisateur, il est valide ;
• le reste poubelle, la connexion est terminée.

Dans les AC vous en connaissez peut-être quelques unes dont Thawte, VeriSign, GoDaddy, CA-Cert, Gandi, Google (eh oui, il font ça aussi), et depuis peu Let's Encrypt.

Mais la chaîne de confiance n'est pas complète. Comment savoir quelles sont les entités reconnues, comment en rajouter sans mettre à jour tous les navigateurs ?

Eh bien à la base de la création de X509, on a généré une clef c0, et une clef c1, on a signé la clef c1 avec la clef c0 et découpé c0 en plusieurs (4 ?) parties qu'on a dispachées dans des coffres-forts. On fait donc en sorte que la clef 0 soit reconnue, et on signe les AC avec la clef c1. Les entités créent leur clef c_entite (plusieurs en fait), qui est valide, puisque signée par c1, elle-même valide puisque signée par c0.

Récapitulons. On fait confiance à c0. c0 signe c1, de telle sorte que :

• c1 puisse signer des certificats ;
• c1 puisse signer des AC ;

On signe les AC, qui créent leur clefs, qui sont signées par c1 de telle sorte que :

• elles puissent signer des certificats ;
• éventuellement elles puissent signer d'autres AC.

Ainsi, la chaîne de confiance est une hiérarchie. Faire confiance à c0 permet/implique a priori de faire confiance à beaucoup de gens (on peut cependant demander à Firefox de ne pas accepter un certificat valide).

Subtilité de X509, résilience

Vous avez peut-être remarqué que c0 ne sert qu'à signer c1, puis on demande au navigateur de reconnaître c0, puis on signe avec c1.

Vous vous demandez peut être pourquoi... Imaginons que c0 = c1 = c$latex \alpha $, c'est à dire qu'au début de la chaîne de confiance il y ait non pas deux mais une seule clef c$latex \alpha $.

Un problème se pose, et a pas mal de répercussions :

Si la clef $latex \alpha $ est perdue alors toute la sécurité de l'architecture X509 s'effondre.

• Dans le cas où on n'a qu'une clef c$latex \alpha $, on ne peut rien faire.
• Dans le cas ou on a c0 et c1, et c1 est perdue (on suppose que c0 n'est pas perdue, elle sous clef, éparpillée sur le globe), on révoque c1 à l'aide de c0, et on regénère une clef c1'. Ça permet notamment de pouvoir rapidement recréer un environnement de confiance, et de ne pas avoir besoin de rediffuser la clef à toutes les machines.

Let's Encrypt

Alors pourquoi est-ce que je vous rabats les oreilles avec tout ça ? Eh bien pour deux raisons :

• d'abord pour que vous sachiez quelle confiance accorder dans des connexions HTTPS ;
• ensuite pour vous parler spécialement d'une AC : Let's Encrypt.

Vous l'avez compris, il y a beaucoup d'enjeux concernant une AC. La confiance qu'on a, la qualité de son travail, de la façon dont elle sécurise ses données pour ne pas perdre sa clef et servir de vecteur d'attaque, etc. Il y a d'autres enjeux dont la possibilité pour tous de chiffrer facilement, en effet les certificats ne sont pas gratuits, sauf certains de CA-Cert, et de Gandi.

C'est pourquoi Mozilla Cisco l'EFF et d'autres se sont unis pour créer une AC dont le but serit de permettre à tous de pratiquer le chiffrement à tour de bras. Et voilà qui est fait.

Depuis le 19 octobre 2015 les certificats de Let's Encrypt sont de confiance par défaut dans les versions récentes de Firefox (probablement Chrome/Chromium, Microsoft Edge, et Safari).

Let's Encrypt va donc pouvoir se mettre à un rythme de croisière de signatures de certificats d'ici très peu de temps.

Bon chiffrement à tous et bonne journée !

Motius