privacyguides/privacyguides.org
1
0
Fork 0
mirror of https://github.com/privacyguides/privacyguides.org.git synced 2025-07-28 14:21:08 +00:00
Code Issues Activity

Download Translations from Crowdin (#2054)

Browse Source
This commit is contained in:
Crowdin Bot
2023-02-28 14:22:46 -06:00
committed by Jonah Aragon
parent 4c8cd3f295
commit 1ac4dd75c7
1733 changed files with 199297 additions and 170 deletions
Download Patch File Download Diff File Expand all files Collapse all files

104
i18n/fr/advanced/communication-network-types.md Normal file
View File

@@ -0,0 +1,104 @@
---
title: "Types de réseaux de communication"
icon: 'material/transit-connection-variant'
---
Il existe plusieurs architectures réseau couramment utilisées pour relayer des messages entre des personnes. Ces réseaux peuvent offrir des garanties différentes en matière de protection de la vie privée. C'est pourquoi il est utile de tenir compte de votre [modèle de menace](../basics/threat-modeling.md) lorsque vous décidez quelle application à utiliser.
[Messageries instantanées recommandées](../real-time-communication.md ""){.md-button}
## Réseaux Centralisés
![Centralized networks diagram](../assets/img/layout/network-centralized.svg){ align=left }
Les messageries centralisées sont celles où tous les participants se trouvent sur le même serveur ou réseau de serveurs, contrôlés par la même organisation.
Certaines messageries auto-hébergées vous permettent de configurer votre propre serveur. L'auto-hébergement peut offrir des garanties de confidentialité supplémentaires, tel que l'absence de journaux d'utilisation ou un accès limité aux métadonnées (les données sur qui parle à qui). Les messageries centralisées auto-hébergées sont isolées et tout le monde doit être sur le même serveur pour communiquer.
**Avantages :**
- Les nouvelles fonctionnalités et les changements peuvent être mis en place plus rapidement.
- Il est plus facile de démarrer et de trouver des contacts.
- L'écosystème de fonctionnalités est plus mature et plus stable, car plus facile à programmer dans un logiciel centralisé.
- Les problèmes de confidentialité peuvent être réduits lorsque vous faites confiance à un serveur que vous hébergez vous-même.
**Inconvénients :**
- Peut inclure des [restrictions de contrôle ou d'accès](https://drewdevault.com/2018/08/08/Signal.html). Cela peut inclure des choses telles que :
- Être [interdit de connecter des clients tiers](https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165) au réseau centralisé, ce qui pourrait permettre une plus grande personnalisation ou une meilleure expérience. Ces modalités sont souvent définies dans les conditions d'utilisation.
- Documentation insuffisante ou inexistante pour les développeurs tiers.
- La [propriété](https://web.archive.org/web/20210729191953/https://blog.privacytools.io/delisting-wire/), la politique de confidentialité et les opérations du service peuvent changer facilement lorsqu'une seule entité le contrôle, ce qui peut compromettre le service par la suite.
- L'auto-hébergement demande des efforts et des connaissances sur la manière de mettre en place un service.
## Réseaux Fédérés
![Federated networks diagram](../assets/img/layout/network-decentralized.svg){ align=left }
Les messageries fédérées utilisent plusieurs serveurs indépendants et décentralisés capables de communiquer entre eux (le courrier électronique est un exemple de service fédéré). La fédération permet aux administrateurs système de contrôler leur propre serveur tout en faisant partie d'un réseau de communication plus vaste.
Lorsqu'ils sont auto-hébergés, les membres d'un serveur fédéré peuvent découvrir et communiquer avec les membres d'autres serveurs, bien que certains serveurs puissent choisir de rester privés en étant non fédérés (par exemple, un serveur d'équipe de travail).
**Avantages :**
- Permet un meilleur contrôle de vos propres données lorsque vous utilisez votre propre serveur.
- Vous permet de choisir à qui confier vos données en choisissant entre plusieurs serveurs "publics".
- Permet souvent l'utilisation de clients tiers qui peuvent fournir une expérience plus naturelle, personnalisée ou accessible.
- Il est possible de vérifier que le logiciel du serveur correspond au code source public, en supposant que vous avez accès au serveur ou que vous faites confiance à la personne qui y a accès (par exemple, un membre de la famille).
**Inconvénients :**
- L'ajout de nouvelles fonctionnalités est plus complexe, car ces dernières doivent être normalisées et testées pour s'assurer qu'elles fonctionnent avec tous les serveurs du réseau.
- En raison du point précédent, les fonctionnalités peuvent manquer, être incomplètes ou fonctionner de manière inattendue par rapport aux plateformes centralisées, comme le relais des messages hors ligne ou la suppression des messages.
- Certaines métadonnées peuvent être disponibles (par exemple, des informations comme "qui parle à qui", mais pas le contenu réel du message si le chiffrement de bout en bout est utilisé).
- Les serveurs fédérés nécessitent généralement de faire confiance à l'administrateur de votre serveur. Il peut s'agir d'un amateur ou d'une personne qui n'est pas un "professionnel de la sécurité", et il se peut qu'il ne fournisse pas de documents aux normes comme une politique de confidentialité ou des conditions de service détaillant l'utilisation de vos données.
- Les administrateurs de serveurs choisissent parfois de bloquer d'autres serveurs, qui sont une source d'abus non modérés ou qui enfreignent les règles générales de comportement accepté. Cela entravera votre capacité à communiquer avec les membres de ces serveurs.
## Réseaux Pair-à-Pair
![P2P diagram](../assets/img/layout/network-distributed.svg){ align=left }
Les messageries P2P se connectent à un [réseau distribué](https://fr.wikipedia.org/wiki/Réseau_distribué) de nœuds pour relayer un message au destinataire sans serveur tiers.
Les clients (les pairs) se trouvent généralement les uns les autres grâce à l'utilisation d'un réseau de [calcul distribué](https://fr.wikipedia.org/wiki/Calcul_distribué). Citons par exemple les [Tables de Hachages Distribuées](https://fr.wikipedia.org/wiki/Table_de_hachage_distribuée) (THD), utilisées par les [Torrents](https://fr.wikipedia.org/wiki/BitTorrent) et [l'IPFS](https://fr.wikipedia.org/wiki/InterPlanetary_File_System). Une autre approche est celle des réseaux basés sur la proximité, où une connexion est établie par Wi-Fi ou Bluetooth (par exemple Briar ou le protocole de réseau social [Scuttlebutt](https://www.scuttlebutt.nz)).
Lorsqu'un pair a trouvé une route vers son contact par l'une de ces méthodes, une connexion directe est établie entre eux. Bien que les messages soient généralement cryptés, un observateur peut toujours déduire l'emplacement et l'identité de l'expéditeur et du destinataire.
Les réseaux P2P n'utilisent pas de serveurs, car les pairs communiquent directement entre eux, et ne peuvent donc pas être auto-hébergés. Cependant, certains services supplémentaires peuvent dépendre de serveurs centralisés, comme la découverte d'autres utilisateurs ou le relais des messages hors ligne, qui peuvent bénéficier de l'auto-hébergement.
**Avantages :**
- Minimum d'informations exposées à des tiers.
- Les plateformes P2P modernes implémentent l'E2EE par défaut. Il n'y a pas de serveurs qui pourraient potentiellement intercepter et déchiffrer vos transmissions, contrairement aux modèles centralisés et fédérés.
**Inconvénients :**
- Ensemble de fonctionnalités réduit :
- Les messages ne peuvent être envoyés que lorsque les deux pairs sont en ligne. Toutefois, votre client peut stocker les messages localement pour attendre le retour en ligne du contact.
- Augmente généralement l'utilisation de la batterie sur les appareils mobiles, car le client doit rester connecté au réseau distribué pour savoir qui est en ligne.
- Certaines fonctionnalités courantes de messageries peuvent ne pas être mises en œuvre ou de manière incomplète, comme la suppression des messages.
- Votre adresse IP et celle des contacts avec lesquels vous communiquez peuvent être exposées si vous n'utilisez pas le logiciel avec un VPN [](../vpn.md) ou [Tor](../tor.md). De nombreux pays disposent d'une forme de surveillance de masse et/ou de conservation des métadonnées.
## Routage Anonyme
![Anonymous routing diagram](../assets/img/layout/network-anonymous-routing.svg){ align=left }
Une messagerie utilisant le [routage anonyme](https://doi.org/10.1007/978-1-4419-5906-5_628) cache soit l'identité de l'expéditeur, celle du destinataire, ou la preuve qu'ils aient communiqué. Idéalement, une messagerie devrait cacher les trois.
Il existe de [nombreuses](https://doi.org/10.1145/3182658) façons différentes de mettre en œuvre le routage anonyme. L'une des plus célèbres est le [routage en oignon](https://en.wikipedia.org/wiki/Onion_routing) comme [Tor](https://fr.wikipedia.org/wiki/Tor_(réseau)), qui communique des messages chiffrés par le biais d'un [réseau superposé](https://fr.wikipedia.org/wiki/Réseau_superposé) qui masque l'emplacement de chaque nœud ainsi que le destinataire et l'expéditeur de chaque message. L'expéditeur et le destinataire n'interagissent jamais directement et ne se rencontrent que par l'intermédiaire d'un nœud de rendez-vous secret, de sorte qu'il n'y ait aucune fuite d'adresses IP ni de localisation physique. Les nœuds ne peuvent pas déchiffrer les messages ni la destination finale, seul le destinataire le peut. Chaque nœud intermédiaire ne peut déchiffrer qu'une partie qui indique où envoyer ensuite le message encore chiffré, jusqu'à ce qu'il arrive au destinataire qui peut le déchiffrer entièrement, d'où les "couches d'oignon."
L'auto-hébergement d'un nœud dans un réseau de routage anonyme ne procure pas à l'hébergeur des avantages supplémentaires en matière de confidentialité, mais contribue plutôt à la résilience de l'ensemble du réseau contre les attaques d'identification pour le bénéfice de tous.
**Avantages :**
- Minimum d'informations exposées à des tiers.
- Les messages peuvent être relayés de manière décentralisée même si l'une des parties est hors ligne.
**Inconvénients :**
- Propagation des messages lente.
- Souvent limité à un nombre restreint de types de médias, principalement du texte, car le réseau est lent.
- Moins fiable si les nœuds sont sélectionnés par un routage aléatoire, certains nœuds peuvent être très éloignés de l'expéditeur et du récepteur, ce qui ajoute une latence ou même l'impossibilité de transmettre les messages si l'un des nœuds se déconnecte.
- Plus complexe à mettre en œuvre car la création et la sauvegarde sécurisée d'une clé cryptographique privé sont nécessaires.
- Comme pour les autres plateformes décentralisées, l'ajout de fonctionnalités est plus complexe pour les développeurs que sur une plateforme centralisée. Par conséquent, des fonctionnalités peuvent manquer ou être incomplètement mises en œuvre, comme le relais des messages hors ligne ou la suppression des messages.
--8<-- "includes/abbreviations.fr.txt"

307
i18n/fr/advanced/dns-overview.md Normal file
View File

@@ -0,0 +1,307 @@
---
title: "Présentation de DNS"
icon: material/dns
---
Le [système de nom de domaine](https://fr.wikipedia.org/wiki/Domain_Name_System) est "l'annuaire de l'internet". Le DNS traduit les noms de domaine en adresses IP afin que les navigateurs et autres services puissent charger les ressources de l'internet, grâce à un réseau décentralisé de serveurs.
## Qu'est-ce que le DNS ?
Lorsque vous visitez un site web, une adresse numérique est renvoyée. Par exemple, lorsque vous visitez `privacyguides.org`, l'adresse `192.98.54.105` est renvoyée.
Le DNS existe depuis [les premiers jours](https://fr.wikipedia.org/wiki/Domain_Name_System#Histoire) de l'Internet. Les demandes DNS faites à destination et en provenance des serveurs DNS sont généralement **non** chiffrées. Dans un environnement résidentiel, un client se voit attribuer des serveurs par le FAI via [DHCP](https://fr.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol).
Les demandes DNS non chiffrées peuvent être facilement **surveillées** et **modifiées** en transit. Dans certaines régions du monde, les fournisseurs d'accès à Internet reçoivent l'ordre de procéder à un [ filtrage DNS primitif](https://en.wikipedia.org/wiki/DNS_blocking). Lorsque vous demandez l'adresse IP d'un domaine bloqué, le serveur peut ne pas répondre ou répondre avec une adresse IP différente. Le protocole DNS n'étant pas crypté, le FAI (ou tout opérateur de réseau) peut utiliser [DPI](https://fr.wikipedia.org/wiki/Deep_packet_inspection) pour surveiller les demandes. Les FAI peuvent également bloquer des requêtes sur la base de caractéristiques communes, quel que soit le serveur DNS utilisé. Un DNS non crypté utilise toujours le [port](https://fr.wikipedia.org/wiki/Port_(logiciel)) 53 et utilise toujours UDP.
Ci-dessous, nous discutons et fournissons un tutoriel pour prouver ce qu'un observateur extérieur peut voir en utilisant le DNS normal non crypté et le [DNS crypté](#what-is-encrypted-dns).
### DNS non chiffré
1. En utilisant [`tshark`](https://www.wireshark.org/docs/man-pages/tshark.html) (qui fait partie du projet [Wireshark](https://fr. wikipedia. org/wiki/Wireshark)), nous pouvons surveiller et enregistrer le flux de paquets Internet. Cette commande enregistre les paquets qui répondent aux règles spécifiées :
```bash
tshark -w /tmp/dns.pcap udp port 53 and host 1.1.1.1 or host 8.8.8.8
```
2. Nous pouvons ensuite utiliser [`dig`](https://en.wikipedia.org/wiki/Dig_(command)) (Linux, MacOS etc) ou [`nslookup`](https://en.wikipedia.org/wiki/Nslookup) (Windows) pour envoyer la recherche DNS aux deux serveurs. Les logiciels tels que les navigateurs web effectuent ces recherches automatiquement, à moins qu'ils ne soient configurés pour utiliser un DNS crypté.
=== "Linux, macOS"
```
dig +noall +answer privacyguides.org @1.1.1.1
dig +noall +answer privacyguides.org @8.8.8.8
```
=== "Windows"
```
nslookup privacyguides.org 1.1.1.1
nslookup privacyguides.org 8.8.8.8
```
3. Ensuite, nous voulons [ analyser](https://www.wireshark.org/docs/wsug_html_chunked/ChapterIntroduction.html#ChIntroWhatIs) les résultats :
=== "Wireshark"
```
wireshark -r /tmp/dns.pcap
```
=== "tshark"
```
tshark -r /tmp/dns.pcap
```
Si vous exécutez la commande Wireshark ci-dessus, le volet supérieur affiche les "[trames](https://en.wikipedia.org/wiki/Ethernet_frame)", et le volet inférieur affiche toutes les données relatives à la trame sélectionnée. Les solutions de filtrage et de surveillance d'entreprise (telles que celles achetées par les gouvernements) peuvent effectuer ce processus automatiquement, sans interaction humaine, et peuvent agréger ces trames pour produire des données statistiques utiles à l'observateur du réseau.
| No. | Heure | Source | Destination | Protocole | Longueur | Info |
| --- | -------- | --------- | ----------- | --------- | -------- | ---------------------------------------------------------------------- |
| 1 | 0.000000 | 192.0.2.1 | 1.1.1.1 | DNS | 104 | Standard query 0x58ba A privacyguides.org OPT |
| 2 | 0.293395 | 1.1.1.1 | 192.0.2.1 | DNS | 108 | Standard query response 0x58ba A privacyguides.org A 198.98.54.105 OPT |
| 3 | 1.682109 | 192.0.2.1 | 8.8.8.8 | DNS | 104 | Standard query 0xf1a9 A privacyguides.org OPT |
| 4 | 2.154698 | 8.8.8.8 | 192.0.2.1 | DNS | 108 | Standard query response 0xf1a9 A privacyguides.org A 198.98.54.105 OPT |
Un observateur pourrait modifier n'importe lequel de ces paquets.
## Qu'est-ce que le "DNS crypté" ?
Le DNS crypté peut faire référence à un certain nombre de protocoles, les plus courants étant :
### DNSCrypt
[**DNSCrypt**](https://en.wikipedia.org/wiki/DNSCrypt) était l'une des premières méthodes de cryptage des requêtes DNS. DNSCrypt opère sur le port 443 et fonctionne avec les protocoles de transport TCP ou UDP. DNSCrypt n'a jamais été soumis à l'IETF (Internet Engineering Task Force) [](https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force) et n'est pas passé par le processus de demande de commentaires (RFC) [](https://en.wikipedia.org/wiki/Request_for_Comments) . Il n'a donc pas été largement utilisé en dehors de quelques implémentations [](https://dnscrypt.info/implementations). En conséquence, il a été largement remplacé par le plus populaire [DNS over HTTPS](#dns-over-https-doh).
### DNS sur TLS (DoT)
[**DNS over TLS**](https://en.wikipedia.org/wiki/DNS_over_TLS) est une autre méthode de cryptage des communications DNS qui est définie dans [RFC 7858](https://datatracker.ietf.org/doc/html/rfc7858). La prise en charge a été implémentée pour la première fois dans Android 9, iOS 14, et sur Linux dans [systemd-resolved](https://www.freedesktop.org/software/systemd/man/resolved.conf.html#DNSOverTLS=) dans la version 237. Ces dernières années, la préférence du secteur s'est déplacée de DoT vers DoH, car DoT est un protocole complexe [](https://dnscrypt.info/faq/) et sa conformité au RFC varie selon les implémentations existantes. Le DoT fonctionne également sur un port dédié 853 qui peut être facilement bloqué par des pare-feu restrictifs.
### DNS sur HTTPS (DoH)
[**DNS sur HTTPS**](https://en.wikipedia.org/wiki/DNS_over_HTTPS) tel que défini dans [RFC 8484](https://datatracker.ietf.org/doc/html/rfc8484) regroupe les requêtes dans le protocole [HTTP/2](https://en.wikipedia.org/wiki/HTTP/2) et assure la sécurité avec HTTPS. La prise en charge a d'abord été ajoutée dans les navigateurs web tels que Firefox 60 et Chrome 83.
L'implémentation native de DoH est apparue dans iOS 14, macOS 11, Microsoft Windows et Android 13 (cependant, elle ne sera pas activée [par défaut](https://android-review.googlesource.com/c/platform/packages/modules/DnsResolver/+/1833144)). Sous Linux le support sera assuré par [ l'implémentation dans systemd](https://github.com/systemd/systemd/issues/8639) donc [l'installation de logiciels tiers est encore nécessaire](../dns.md#linux).
## Que peut voir un tiers ?
Dans cet exemple, nous allons enregistrer ce qui se passe lorsque nous faisons une requête DoH :
1. Tout d'abord, lancez `tshark`:
```bash
tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1
```
2. Deuxièmement, faites une requête avec `curl`:
```bash
curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org
```
3. Après avoir fait la demande, nous pouvons arrêter la capture de paquets avec <kbd>CTRL</kbd> + <kbd>C</kbd>.
4. Analysez les résultats dans Wireshark :
```bash
wireshark -r /tmp/dns_doh.pcap
```
Nous pouvons voir [l'établissement de la connexion](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment) et [TLS handshake](https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/) qui se produit avec toute connexion chiffrée. Lorsque l'on regarde les paquets de "données d'application" qui suivent, aucun d'entre eux ne contient le domaine que nous avons demandé ou l'adresse IP renvoyée.
## Pourquoi **ne devrais-je pas** utiliser un DNS chiffré ?
Dans les endroits où il existe un filtrage (ou une censure) de l'Internet, la visite de ressources interdites peut avoir ses propres conséquences que vous devez prendre en compte dans votre [modèle de menace](../basics/threat-modeling.md). Nous ne suggérons **pas** l'utilisation de DNS chiffrés à cette fin. Utilisez plutôt [Tor](https://torproject.org) ou un [VPN](../vpn.md). Si vous utilisez un VPN, vous devez utiliser les serveurs DNS de votre VPN. En utilisant un VPN, vous lui confiez déjà toute votre activité réseau.
Lorsque nous effectuons une recherche DNS, c'est généralement parce que nous voulons accéder à une ressource. Nous examinerons ci-dessous certaines des méthodes susceptibles de divulguer vos activités de navigation, même lorsque vous utilisez un DNS chiffré :
### Adresse IP
Le moyen le plus simple de déterminer l'activité de navigation est de regarder les adresses IP auxquelles vos appareils accèdent. Par exemple, si l'observateur sait que `privacyguides.org` est à `198.98.54.105`, et que votre appareil demande des données à `198.98.54.105`, il y a de fortes chances que vous visitiez Privacy Guides.
Cette méthode n'est utile que lorsque l'adresse IP appartient à un serveur qui n'héberge que quelques sites web. Elle n'est pas non plus très utile si le site est hébergé sur une plateforme partagée (par exemple, Github Pages, Cloudflare Pages, Netlify, WordPress, Blogger, etc). Il n'est pas non plus très utile si le serveur est hébergé derrière un [proxy inverse](https://fr.wikipedia.org/wiki/Proxy_inverse), ce qui est très courant actuellement sur Internet.
### Server Name Indication (SNI)
La Server Name Indication (indication du nom du serveur) est généralement utilisée lorsqu'une adresse IP héberge de nombreux sites web. Il peut s'agir d'un service comme Cloudflare, ou d'une autre protection contre les [attaques par déni de service](https://fr.wikipedia.org/wiki/Attaque_par_déni_de_service).
1. Recommencez à capturer avec `tshark`. Nous avons ajouté un filtre avec notre adresse IP pour que vous ne capturiez pas beaucoup de paquets :
```bash
tshark -w /tmp/pg.pcap port 443 et hôte 198.98.54.105
```
2. Ensuite, nous visitons [https://privacyguides.org](https://privacyguides.org).
3. Après avoir visité le site web, nous voulons arrêter la capture de paquets avec <kbd>CTRL</kbd> + <kbd>C</kbd>.
4. Ensuite, nous voulons analyser les résultats :
```bash
wireshark -r /tmp/pg.pcap
```
Nous verrons l'établissement de la connexion, suivi du TLS handshake pour le site web Privacy Guides. Au niveau de l'image 5, vous verrez un "Client Hello".
5. Développez le triangle &#9656; à côté de chaque champ :
```text
▸ Transport Layer Security
▸ TLSv1.3 Record Layer : Handshake Protocol : Client Hello
▸ Handshake Protocol : Client Hello
▸ Extension : server_name (len=22)
▸ Server Name Indication extension
```
6. Nous pouvons voir la valeur SNI qui révèle le site web que nous visitons. La commande `tshark` peut vous donner directement la valeur pour tous les paquets contenant une valeur SNI :
```bash
tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
```
Cela signifie que même si nous utilisons des serveurs "DNS Chiffré", le domaine sera probablement divulgué par le SNI. Le protocole [TLS v1.3](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3) apporte avec lui [Encrypted Client Hello](https://blog.cloudflare.com/encrypted-client-hello/), qui empêche ce type de fuite.
Des gouvernements, en particulier [la Chine](https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-https-traffic-using-tls-1-3-and-esni/) et [la Russie](https://www.zdnet.com/article/russia-wants-to-ban-the-use-of-secure-protocols-such-as-tls-1-3-doh-dot-esni/), ont déjà commencé à [bloquer](https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypted_Client_Hello) le protocole ou ont exprimé le souhait de le faire. Récemment, la Russie [a commencé à bloquer les sites web étrangers](https://github.com/net4people/bbs/issues/108) qui utilisent le standard [HTTP/3](https://en.wikipedia.org/wiki/HTTP/3). En effet, le protocole [QUIC](https://fr.wikipedia.org/wiki/QUIC) qui fait partie de HTTP/3 exige que `ClientHello` soit également chiffré.
### Online Certificate Status Protocol (OCSP)
Une autre façon dont votre navigateur peut divulguer vos activités de navigation est avec [l'Online Certificate Status Protocol](https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol) (protocole de vérification de certificat en ligne). Lors de la visite d'un site Web HTTPS, le navigateur peut vérifier si le [certificat](https://fr.wikipedia.org/wiki/Certificat_%C3%A9lectronique) du site Web a été révoqué. Cela se fait généralement via le protocole HTTP, ce qui signifie qu'il **n'est pas** chiffré.
La requête OCSP contient le certificat "[serial number](https://en.wikipedia.org/wiki/Public_key_certificate#Common_fields)", qui est unique. Il est envoyé au "OCSP responder" afin de vérifier son statut.
Nous pouvons simuler ce que ferait un navigateur en utilisant la commande [`openssl`](https://fr.wikipedia.org/wiki/OpenSSL).
1. Obtenez le certificat du serveur et utilisez [`sed`](https://fr.wikipedia.org/wiki/Stream_Editor) pour ne garder que la partie importante et l'écrire dans un fichier :
```bash
openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 |
sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert
```
2. Obtenez le certificat intermédiaire. Les [Autorités de certification](https://fr.wikipedia.org/wiki/Autorité_de_certification) (CA) ne signent normalement pas directement un certificat ; elles utilisent ce que l'on appelle un certificat "intermédiaire".
```bash
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 |
sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
```
3. Le premier certificat dans `pg_and_intermediate.cert` est en fait le certificat du serveur de l'étape 1. Nous pouvons utiliser à nouveau `sed` pour tout supprimer jusqu'à la première instance de END :
```bash
sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
/tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
```
4. Obtenir le répondeur OCSP pour le certificat du serveur :
```bash
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
```
Notre certificat montre le répondeur du certificat Lets Encrypt. Si nous voulons voir tous les détails du certificat, nous pouvons utiliser :
```bash
openssl x509 -text -noout -in /tmp/pg_server.cert
```
5. Démarrer la capture de paquets :
```bash
tshark -w /tmp/pg_ocsp.pcap -f "tcp port http"
```
6. Faites la demande OCSP :
```bash
openssl ocsp -issuer /tmp/intermediate_chain.cert \
-cert /tmp/pg_server.cert \
-text \
-url http://r3.o.lencr.org
```
7. Ouvrez la capture :
```bash
wireshark -r /tmp/pg_ocsp.pcap
```
Il y aura deux paquets avec le protocole "OCSP" : un "Demande" et un "Réponse". Pour la "Demande", nous pouvons voir le "numéro de série" en développant le triangle &#9656; à côté de chaque champ :
```bash
▸ Online Certificate Status Protocol
▸ tbsRequest
▸ requestList: 1 item
▸ Request
▸ reqCert
serialNumber
```
Pour la "Réponse", nous pouvons également voir le "numéro de série" :
```bash
▸ Online Certificate Status Protocol
▸ responseBytes
▸ BasicOCSPResponse
▸ tbsResponseData
▸ responses: 1 item
▸ SingleResponse
▸ certID
serialNumber
```
8. Ou utilisez `tshark` pour filtrer les paquets du numéro de série :
```bash
tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber
```
Si l'observateur du réseau dispose du certificat public, qui est accessible au public, il peut faire correspondre le numéro de série à ce certificat et donc déterminer le site que vous visitez à partir de celui-ci. Le processus peut être automatisé et permet d'associer des adresses IP à des numéros de série. Il est également possible de vérifier les journaux de [Certificate Transparency](https://en.wikipedia.org/wiki/Certificate_Transparency) (en anlais) pour le numéro de série.
## Devrais-je utiliser un DNS chiffré ?
Nous avons créé cet organigramme pour décrire quand vous *devriez* utiliser des DNS cryptés:
``` mermaid
graph TB
Démarrage[Start] --> anonyme{Essayez-vous d'être<br> anonyme ?}
anonyme --> | Oui | tor(Utilisez Tor)
anonyme --> | Non | censure{Eviter la<br> censure ?}
censure --> | Oui | vpnOuTor(Utilisez<br> VPN ou Tor)
censure --> | Non | viePrivée{Protéger votre vie privée<br> du FAI ?}
p(vie privée) --> | Oui | vpnOuTor
p(vie privée) --> | Non | nuisible{FAI fait des<br> redirections<br> nuisibles ?}
nuisible --> | Oui | DNScryptés(Utilisez <br> DNS cryptés<br> avec application tierce)
nuisible --> | Non | DNSfai{FAI supporte les<br> DNS cryptés ?}
DNSfai --> | Oui | utilisezFAI(Utilisez<br> DNS cryptés<br> avec FAI)
DNSfai --> | Non | rien(Ne rien faire)
```
Le DNS chiffré avec des serveurs tiers ne doit être utilisé que pour contourner le [blocage DNS](https://en.wikipedia.org/wiki/DNS_blocking) de base lorsque vous êtes certain qu'il n'y aura pas de conséquences ou que vous êtes intéressés par un fournisseur qui effectue un filtrage rudimentaire.
[Liste des serveurs DNS recommandés](../dns.md ""){.md-button}
## Qu'est-ce que le DNSSEC ?
[Domain Name System Security Extensions](https://fr.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) (extension de SECurité du Système de Nom de Domaine) est une fonctionnalité du DNS qui authentifie les réponses aux recherches de noms de domaine. Il ne fournit pas de protection de la vie privée pour ces recherches, mais empêche les attaquants de manipuler ou d'empoisonner les réponses aux requêtes DNS.
En d'autres termes, le DNSSEC signe numériquement les données afin de garantir leur validité. Afin de garantir une recherche sécurisée, la signature a lieu à chaque niveau du processus de consultation du DNS. Par conséquent, toutes les réponses du DNS sont fiables.
Le processus de signature DNSSEC est similaire à celui d'une personne qui signe un document juridique avec un stylo ; cette personne signe avec une signature unique que personne d'autre ne peut créer, et un expert judiciaire peut examiner cette signature et vérifier que le document a été signé par cette personne. Ces signatures numériques garantissent que les données n'ont pas été altérées.
DNSSEC met en œuvre une politique de signature numérique hiérarchique à travers toutes les couches du DNS. Par exemple, dans le cas d'une consultation de `privacyguides.org`, un serveur DNS racine signe une clé pour le serveur de noms `.org`, et le serveur de noms `.org` signe ensuite une clé pour le serveur de noms faisant autorité `privacyguides.org`.
<small>Adapté de [DNS Security Extensions (DNSSEC) overview](https://cloud.google.com/dns/docs/dnssec) par Google et [DNSSEC : An Introduction](https://blog.cloudflare.com/dnssec-an-introduction/) par Cloudflare, tous deux sous licence [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).</small>
## Qu'est-ce que la minimization QNAME ?
Un QNAME est un "nom qualifié", par exemple `privacyguides.org`. La QNAME minimization réduit la quantité d'informations envoyées par le serveur DNS au [serveur de noms](https://en.wikipedia.org/wiki/Name_server#Authoritative_name_server) faisant autorité.
Au lieu d'envoyer le domaine entier `privacyguides.org`, la QNAME minimization signifie que le serveur DNS demandera tous les enregistrements qui se terminent par `.org`. Une description technique plus détaillée est définie dans [RFC 7816](https://datatracker.ietf.org/doc/html/rfc7816).
## Qu'est-ce que le sous-réseau client EDNS (ECS) ?
Le [EDNS Client Subnet](https://en.wikipedia.org/wiki/EDNS_Client_Subnet) est une méthode permettant à un résolveur DNS récursif de spécifier un [sous-réseau](https://fr.wikipedia.org/wiki/Sous-réseau) pour l'hôte ou le [client](https://fr.wikipedia.org/wiki/Client_(informatique)) qui effectue la requête DNS.
Il est destiné à "accélérer" la transmission des données en donnant au client une réponse qui appartient à un serveur proche de lui, comme un [réseau de diffusion de contenu](https://fr.wikipedia.org/wiki/Réseau_de_diffusion_de_contenu), souvent utilisé pour la diffusion de vidéos en continu et pour servir des applications Web JavaScript.
Cette fonction a un coût en termes de confidentialité, car elle fournit au serveur DNS des informations sur la localisation du client.
--8<-- "includes/abbreviations.fr.txt"

81
i18n/fr/advanced/tor-overview.md Normal file
View File

@@ -0,0 +1,81 @@
---
title: "Présentation de Tor"
icon: 'simple/torproject'
---
Tor est un réseau décentralisé, gratuit, conçu pour utiliser Internet avec le plus de confidentialité possible. S'il est utilisé correctement, le réseau permet une navigation et des communications privées et anonymes.
## Construction d'un chemin
Tor fonctionne en acheminant votre trafic à travers un réseau composé de milliers de serveurs gérés par des volontaires, appelés nœuds (ou relais).
Chaque fois que vous vous connectez à Tor, il choisira trois nœuds pour construire un chemin vers Internet - ce chemin est appelé un "circuit". Chacun de ces nœuds a sa propre fonction:
### Le nœud d'entrée
Le noeud d'entrée, souvent appelé le noeud de garde, est le premier noeud auquel votre client Tor se connecte. Le nœud d'entrée est capable de voir votre adresse IP, mais il est incapable de voir à quoi vous vous connectez.
Contrairement aux autres nœuds, le client Tor choisira aléatoirement un nœud d'entrée et restera avec lui pendant deux à trois mois pour vous protéger de certaines attaques.[^1]
### Le nœud central
Le noeud central est le second noeud auquel votre client Tor se connecte. Il peut voir de quel nœud provient le trafic - le nœud d'entrée - et vers quel nœud il se dirige ensuite. Le nœud central ne peut pas voir votre adresse IP ou le domaine auquel vous vous connectez.
Pour chaque nouveau circuit, le nœud central est choisi au hasard parmi tous les nœuds Tor disponibles.
### Le nœud de sortie
Le nœud de sortie est le point où votre trafic web quitte le réseau Tor et est transféré vers la destination souhaitée. Le nœud de sortie ne peut pas voir votre adresse IP, mais il sait à quel site il se connecte.
Le noeud de sortie sera choisi au hasard parmi tous les noeuds Tor disponibles et exécutés avec une balise "relais de sortie".[^2]
<figure markdown>
![Tor path](../assets/img/how-tor-works/tor-path.svg#only-light)
![Tor path](../assets/img/how-tor-works/tor-path-dark.svg#only-dark)
<figcaption>Chemin du circuit Tor</figcaption>
</figure>
## Chiffrement
Tor chiffre chaque paquet (un bloc de données transmises) trois fois avec les clés du nœud de sortie, du nœud central, et du nœud d'entrée, dans cet ordre.
Une fois que Tor a construit un circuit, la transmission des données se fait comme suit:
1. Premièrement: lorsque le paquet arrive au nœud d'entrée, la première couche de chiffrement est supprimée. Dans ce paquet chiffré, le nœud d'entrée trouvera un autre paquet chiffré avec l'adresse du nœud central. Le nœud d'entrée transmet ensuite le paquet au nœud central.
2. Deuxièmement : lorsque le nœud central reçoit le paquet du nœud d'entrée, il supprime lui aussi une couche de chiffrement avec sa clé, et trouve cette fois un paquet chiffré avec l'adresse du nœud de sortie. Le nœud central transmet ensuite le paquet au nœud de sortie.
3. Enfin, lorsque le nœud de sortie reçoit son paquet, il supprime la dernière couche de chiffrement avec sa clé. Le nœud de sortie verra l'adresse de destination et transmettra le paquet à cette adresse.
Vous trouverez ci-dessous un autre schéma illustrant le processus. Chaque nœud supprime sa propre couche de chiffrement, et lorsque le serveur de destination renvoie les données, le même processus se déroule entièrement en sens inverse. Par exemple, le nœud de sortie ne sait pas qui vous êtes, mais il sait de quel nœud il provient. Il ajoute donc sa propre couche de chiffrement et renvoie le message.
<figure markdown>
![Tor encryption](../assets/img/how-tor-works/tor-encryption.svg#only-light)
![Tor encryption](../assets/img/how-tor-works/tor-encryption-dark.svg#only-dark)
<figcaption>Envoyer et recevoir des données à travers le réseau Tor</figcaption>
</figure>
Tor nous permet de nous connecter à un serveur sans que personne ne connaisse le chemin entier. Le nœud d'entrée sait qui vous êtes, mais pas où vous allez; le nœud central ne sait pas qui vous êtes ni où vous allez; et le nœud de sortie sait où vous allez, mais pas qui vous êtes. Comme le nœud de sortie est celui qui établit la connexion finale, le serveur de destination ne connaîtra jamais votre adresse IP.
## Mises en garde 
Bien que Tor offre de solides garanties de confidentialité, il faut être conscient que Tor n'est pas parfait:
- Des adversaires bien financés ayant la capacité d'observer passivement la plupart du trafic réseau mondial ont une chance de désanonymiser les utilisateurs de Tor au moyen d'une analyse avancée du trafic. Tor ne vous protège pas non plus contre le risque de vous exposer par erreur, par exemple si vous partagez trop d'informations sur votre véritable identité.
- Les nœuds de sortie de Tor peuvent également surveiller le trafic qui passe par eux. Cela signifie que le trafic qui n'est pas chiffré, comme le trafic HTTP ordinaire, peut être enregistré et surveillé. Si ce trafic contient des informations permettant de vous identifier, il peut vous désanonymiser aux yeux de ce nœud de sortie. Par conséquent, nous recommandons d'utiliser HTTPS via Tor dans la mesure du possible.
Si vous souhaitez utiliser Tor pour naviguer sur le web, nous ne recommandons que le navigateur Tor **officiel** - il est conçu pour empêcher la prise d'empreintes numériques.
- [Navigateur Tor :material-arrow-right-drop-circle:](../tor.md#tor-browser)
## Ressources Supplémentaires
- [Manuel d'utilisation du navigateur Tor](https://tb-manual.torproject.org)
- [Comment Tor fonctionne - Computerphile](https://invidious.privacyguides.net/embed/QRYzre4bf7I?local=true) <small>(YouTube)</small>
- [Services onion Tor - Computerphile](https://invidious.privacyguides.net/embed/lVcbq_a5N9I?local=true) <small>(YouTube)</small>
--8<-- "includes/abbreviations.fr.txt"
[^1]: Le premier relais de votre circuit est appelé "garde d'entrée" ou "garde". Il s'agit d'un relais rapide et stable qui reste le premier de votre circuit pendant 2 à 3 mois afin de vous protéger contre une attaque connue de rupture d'anonymat. Le reste de votre circuit change avec chaque nouveau site web que vous visitez, et tous ensemble ces relais fournissent les protections complètes de Tor en matière de vie privée. Pour en savoir plus sur le fonctionnement des relais de garde, consultez cet [article de blog](https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters) et ce [document](https://www-users.cs.umn.edu/~hoppernj/single_guard.pdf) sur les gardes d'entrée. ([https://support.torproject.org/fr/tbb/tbb-2/](https://support.torproject.org/fr/tbb/tbb-2/))
[^2]: Balise de relai: une (dis-)qualification spéciale des relais pour les positions de circuit (par exemple, "Guard", "Exit", "BadExit"), les propriétés de circuit (par exemple, "Fast", "Stable") ou les rôles (par exemple, "Authority", "HSDir"), tels qu'attribués par les autorités de l'annuaire et définis plus précisément dans la spécification du protocole de l'annuaire. ([https://metrics.torproject.org/glossary.html](https://metrics.torproject.org/glossary.html))