Git-Mirrors/privacyguides.org
1
0
Fork 0
mirror of https://github.com/privacyguides/privacyguides.org.git synced 2025-05-02 06:16:27 -04:00
Code Issues Projects Releases Packages Wiki Activity

Add Crowdin Translations (#2026)

Browse source 
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
Co-authored-by: Jonah Aragon <jonah@triplebit.net>
This commit is contained in:
Privacy Guides [bot] 2023-02-24 16:47:54 -06:00 • committed by GitHub
parent 2150385184
commit 7b6a158e4d
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
167 changed files with 22466 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

102
docs/advanced/communication-network-types.es.md Normal file
View file

@ -0,0 +1,102 @@
---
title: "Tipos de redes de comunicación"
icon: 'material/transit-connection-variant'
---
Existen varias arquitecturas de red utilizadas habitualmente para transmitir mensajes entre personas. Estas redes pueden ofrecer diferentes garantías de privacidad, por lo que conviene tener en cuenta tu [modelo de amenaza](../basics/threat-modeling.md) a la hora de decidir qué aplicación utilizar.
[Servicios de mensajería instantáneos recomendados](../real-time-communication.md ""){.md-button}
## Redes centralizadas
![Diagrama de redes centralizadas](../assets/img/layout/network-centralized.svg){ align=left }
Los mensajeros centralizados son aquellos en los que todos los participantes están en el mismo servidor o red de servidores controlados por la misma organización.
Algunos servicios de mensajería autoalojados te permiten configurar tu propio servidor. El autoalojamiento puede ofrecer garantías adicionales de privacidad, como la ausencia de registros de uso o el acceso limitado a los metadatos (datos sobre quién habla con quién). Los servicios de mensajería centralizados autoalojados están aislados y todos deben estar en el mismo servidor para comunicarse.
**Ventajas:**
- Las nuevas funciones y cambios pueden aplicarse más rápidamente.
- Es más fácil empezar y encontrar contactos.
- Ecosistemas de características más maduras y estables, ya que son más fáciles de programar en un software centralizado.
- Los problemas de privacidad pueden reducirse cuando se confía en un servidor que está autoalojando.
**Desventajas:**
- Puede incluir [control o acceso restringido](https://drewdevault.com/2018/08/08/Signal.html). Esto puede incluir cosas como:
- Estar [prohibido conectar clientes de terceros](https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165) a la red centralizada que podría proporcionar una mayor personalización o una mejor experiencia. A menudo se define en los Términos y condiciones de uso.
- Documentación pobre o nula para desarrolladores de terceros.
- La [propiedad](https://web.archive.org/web/20210729191953/https://blog.privacytools.io/delisting-wire/), la política de privacidad y las operaciones del servicio pueden cambiar fácilmente cuando una sola entidad lo controla, pudiendo comprometer el servicio más adelante.
- El autoalojamiento requiere esfuerzo y conocimiento de cómo configurar un servicio.
## Redes federadas
![Diagrama de redes federadas](../assets/img/layout/network-decentralized.svg){ align=left }
Los servicios de mensajería federados utilizan varios servidores independientes y descentralizados que pueden comunicarse entre sí (el correo electrónico es un ejemplo de servicio federado). La federación permite a los administradores de sistemas controlar su propio servidor y seguir formando parte de la red de comunicaciones más amplia.
Cuando se autoaloja, los miembros de un servidor federado pueden descubrir y comunicarse con los miembros de otros servidores, aunque algunos servidores pueden optar por permanecer privados al no estar federados (por ejemplo, el servidor del equipo de trabajo).
**Ventajas:**
- Permite un mayor control sobre tus propios datos cuando administras tu propio servidor.
- Te permite elegir en quién confiar tus datos eligiendo entre varios servidores "públicos".
- A menudo permite los clientes de terceros que pueden ofrecer una experiencia más nativa, personalizada o accesible.
- Se puede verificar que el software del servidor coincide con el código fuente público, suponiendo que se tiene acceso al servidor o se confía en la persona que lo tiene (por ejemplo, un familiar).
**Desventajas:**
- Añadir nuevas funcionalidades es más complejo porque estas funcionalidades tienen que ser estandarizadas y probadas para asegurar que funcionan con todos los servidores de la red.
- Debido al punto anterior, pueden faltar funciones, o estar incompletas o funcionar de forma inesperada en comparación con las plataformas centralizadas, como la retransmisión de mensajes cuando se está desconectado o la eliminación de mensajes.
- Algunos metadatos pueden estar disponibles (por ejemplo, información como "quién habla con quién", pero no el contenido real del mensaje si se utiliza E2EE).
- Los servidores federados generalmente requieren confiar en el administrador de tu servidor. Puede que sean aficionados o que no sean "profesionales de la seguridad", y puede que no sirvan documentos estándar como una política de privacidad o unas condiciones de servicio que detallen cómo se utilizan tus datos.
- Los administradores de los servidores a veces deciden bloquear otros servidores que son fuente de abusos no moderados o que rompen las normas generales de comportamiento aceptadas. Esto dificultará tu capacidad de comunicación con los miembros de esos servidores.
## Redes par a par (P2P)
![Diagrama P2P](../assets/img/layout/network-distributed.svg){ align=left }
Los servicios de mensajería P2P se conectan a una [red distribuida](https://es.wikipedia.org/wiki/Red_distribuida) de nodos para transmitir un mensaje al destinatario sin necesidad de un servidor externo.
Los clientes (pares) suelen encontrarse entre sí mediante el uso de una red de [computación distribuida](https://es.wikipedia.org/wiki/Computación_distribuida). Ejemplos de esto incluyen la [Tabla de hash distribuida](https://es.wikipedia.org/wiki/Tabla_de_hash_distribuida) (DHT), usada por [torrents](https://es.wikipedia.org/wiki/BitTorrent) y [IPFS](https://es.wikipedia.org/wiki/Sistema_de_archivos_interplanetario) por ejemplo. Otro enfoque son las redes basadas en la proximidad, en las que se establece una conexión a través de WiFi o Bluetooth (por ejemplo, Briar o el protocolo de red social [Scuttlebutt](https://www.scuttlebutt.nz)).
Una vez que un par ha encontrado una ruta a su contacto a través de cualquiera de estos métodos, se establece una conexión directa entre ellos. Aunque los mensajes suelen estar encriptados, un observador puede deducir la ubicación y la identidad del remitente y del destinatario.
Las redes P2P no utilizan servidores, ya que los pares se comunican directamente entre sí y, por tanto, no pueden ser autoalojadas. Sin embargo, algunos servicios adicionales pueden depender de servidores centralizados, como el descubrimiento de usuarios o la retransmisión de mensajes sin conexión, que pueden beneficiarse del autoalojamiento.
**Ventajas:**
- La información que se expone a terceros es mínima.
- Las plataformas P2P modernas implementan E2EE por defecto. No hay servidores que puedan interceptar y descifrar tus transmisiones, a diferencia de los modelos centralizados y federados.
**Desventajas:**
- Conjunto de funciones reducido:
- Los mensajes solo pueden enviarse cuando ambos pares están en línea, sin embargo, tu cliente puede almacenar los mensajes localmente para esperar a que el contacto vuelva a estar en línea.
- Por lo general, aumenta el uso de la batería en los dispositivos móviles, ya que el cliente debe permanecer conectado a la red distribuida para saber quién está conectado.
- Es posible que algunas funciones comunes de mensajería no se implementen o sean incompletas, como la eliminación de mensajes.
- Tu dirección IP y la de los contactos con los que te comunicas puede quedar expuesta si no utilizas el software junto con una [VPN](../vpn.md) o [Tor](../tor.md). Muchos países tienen alguna forma de vigilancia masiva y/o retención de metadatos.
## Enrutamiento anónimo
![Diagrama de enrutamiento anónimo](../assets/img/layout/network-anonymous-routing.svg){ align=left }
Un servicio de mensajería que utilice [enrutamiento anónimo](https://doi.org/10.1007/978-1-4419-5906-5_628) oculta la identidad del emisor, del receptor o la evidencia de que se han comunicado. Idealmente, un servicio de mensajería debería ocultar los tres.
Hay [muchas](https://doi.org/10.1145/3182658) formas diferentes de implementar el enrutamiento anónimo. Una de las más famosas es el [enrutamiento cebolla](https://es.wikipedia.org/wiki/Encaminamiento_cebolla) (es decir, [Tor](tor-overview.md)), que comunica mensajes cifrados a través de una red [superpuesta virtual](https://es.wikipedia.org/wiki/Red_superpuesta) que oculta la ubicación de cada nodo, así como el destinatario y el remitente de cada mensaje. El remitente y el destinatario nunca interactúan directamente y solo se reúnen a través de un nodo de encuentro secreto para que no haya filtración de direcciones IP ni de la ubicación física. Los nodos no pueden descifrar los mensajes, ni el destino final; solo el destinatario puede hacerlo. Cada nodo intermediario solo puede desencriptar una parte que indica a dónde enviar el mensaje aún encriptado a continuación, hasta que llega al destinatario que puede desencriptarlo completamente, de ahí las "capas de cebolla."
El autoalojamiento de un nodo en una red de enrutamiento anónimo no proporciona al anfitrión beneficios adicionales de privacidad, sino que contribuye a la resistencia de toda la red contra los ataques de identificación en beneficio de todos.
**Ventajas:**
- La información que se expone a otras partes es mínima o nula.
- Los mensajes pueden transmitirse de forma descentralizada incluso si una de las partes está desconectada.
**Desventajas:**
- Lenta propagación de mensajes.
- A menudo se limita a menos tipos de medios, sobre todo de texto, ya que la red es lenta.
- Menos fiable si los nodos se seleccionan mediante enrutamiento aleatorio, algunos nodos pueden estar muy lejos del emisor y del receptor, añadiendo latencia o incluso dejando de transmitir mensajes si uno de los nodos se desconecta.
- Más complejo para empezar, ya que se requiere la creación y el respaldo seguro de una clave privada criptográfica.
- Al igual que en otras plataformas descentralizadas, añadir funciones es más complejo para los desarrolladores que en una plataforma centralizada. Por lo tanto, pueden faltar funciones o estar implementadas de forma incompleta, como la retransmisión de mensajes fuera de línea o la eliminación de mensajes.

102
docs/advanced/communication-network-types.fr.md Normal file
View file

@ -0,0 +1,102 @@
---
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.

102
docs/advanced/communication-network-types.he.md Normal file
View file

@ -0,0 +1,102 @@
---
title: "סוגי רשתות תקשורת"
icon: 'material/transit-connection-variant'
---
ישנם מספר ארכיטקטורות רשת המשמשות בדרך כלל להעברת הודעות בין אנשים. רשתות אלה יכולות לספק ערבויות פרטיות שונות, ולכן כדאי לשקול מודל איום [שלך](../basics/threat-modeling.md) כאשר מחליטים באיזו אפליקציה להשתמש.
[הודעות מיידיות מומלצות](../real-time-communication.md ""){.md-button}
## רשתות מרכזיות
![תרשים רשתות מרכזיות](../assets/img/layout/network-centralized.svg){ align=left }
שירותי שליחת הודעות מיידיות (מסנג'רים) מרכזיים הם אלה שבהם כל המשתתפים נמצאים באותו שרת או רשת של שרתים הנשלטים על ידי אותו ארגון.
כמה מסנג'רים שמאפשרים לך באחסון עצמי להגדיר שרת משלך. אחסון עצמי יכול לספק ערבויות פרטיות נוספות, כגון אי-שימוש ביומני שימוש או גישה מוגבלת למטה-נתונים (נתונים על מי מדבר עם מי). שירותי שליחת הודעות מיידיות באירוח עצמי מבודד וכולם חייבים להיות באותו שרת כדי לתקשר.
**יתרונות:**
- תכונות ושינויים חדשים יכולים להיות מיושמים מהר יותר.
- קל יותר להתחיל ולמצוא אנשי קשר.
- רוב מערכות אקולוגיות מורכבות ויציבות, כפי שהן קלות יותר לתכנת בתוכנה מרכזית.
- ייתכן שבעיות הפרטיות יצומצמו כשתבטחו בשרת שאתם מארחים באופן עצמאי.
**חסרונות:**
- יכול לכלול שליטה מוגבלת [או גישה](https://drewdevault.com/2018/08/08/Signal.html). זה יכול לכלול דברים כמו:
- חל איסור על [לחבר לקוחות צד שלישי](https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165) לרשת המרכזית שעשויה לספק התאמה אישית טובה יותר או חוויה טובה יותר. לעתים קרובות מוגדרים בתנאים וההגבלות של השימוש.
- תיעוד לקוי או ללא תיעוד עבור מפתחי צד שלישי.
- [הבעלות](https://web.archive.org/web/20210729191953/https://blog.privacytools.io/delisting-wire/), מדיניות הפרטיות והתפעול של השירות יכולים להשתנות בקלות כאשר ישות אחת שולטת בו, מה שעלול לסכן את השירות בהמשך.
- אירוח עצמי דורש מאמץ וידע לגבי הגדרת שירות.
## רשתות מאוחדות
![דיאגרמת רשתות מאוחדות](../assets/img/layout/network-decentralized.svg){ align=left }
מסנג'רים מאוחדים משתמשים בשרתים מרובים, עצמאיים ומבוזרים המסוגלים לדבר זה עם זה (דואר אלקטרוני הוא דוגמה אחת לשירות מאוחד). הפדרציה מאפשרת למנהלי המערכת לשלוט בשרת שלהם ועדיין להיות חלק מרשת התקשורת הגדולה יותר.
בעת אירוח עצמי, חברים בשרת פדרלי יכולים לגלות ולתקשר עם חברים בשרתים אחרים, אם כי חלק מהשרתים עשויים לבחור להישאר פרטיים על ידי אי - הארכת שירות (לדוגמה, שרתים בצוות עבודה).
**יתרונות:**
- מאפשר שליטה רבה יותר על הנתונים שלך בעת הפעלת השרת שלך.
- מאפשר לך לבחור עם מי לסמוך על הנתונים שלך על ידי בחירה בין מספר שרתים "ציבוריים ".
- לעתים קרובות מאפשר לקוחות צד שלישי שיכולים לספק חוויה מקורית, מותאמת אישית או נגישה יותר.
- ניתן לאמת שתוכנת השרת תואמת לקוד המקור הציבורי, בהנחה שיש לך גישה לשרת או שאתה בוטח באדם שעושה זאת (למשל, בן משפחה).
**חסרונות:**
- הוספת תכונות חדשות היא מורכבת יותר מכיוון שיש לתקנן ולבדוק תכונות אלה כדי להבטיח שהן פועלות עם כל השרתים ברשת.
- בשל הנקודה הקודמת, תכונות יכולות להיות חסרות, או לא שלמות או לעבוד בדרכים בלתי צפויות בהשוואה לפלטפורמות מרכזיות, כגון ממסר הודעה כאשר לא מקוון או מחיקת הודעה.
- מטא נתונים מסוימים עשויים להיות זמינים (לדוגמה, מידע כגון "מי מדבר עם מי ", אך לא תוכן ההודעה בפועל אם נעשה שימוש ב - E2EE).
- שרתים פדרליים דורשים בדרך כלל אמון במנהל המערכת של השרת שלך. הם עשויים להיות חובבים או שאינם "מומחי אבטחה" באופן אחר, וייתכן שלא יגישו מסמכים סטנדרטיים כגון מדיניות פרטיות או תנאי שירות המפרטים את אופן השימוש בנתונים שלך.
- מנהלי שרתים בוחרים לעתים לחסום שרתים אחרים, המהווים מקור לשימוש לרעה ללא שינוי או הפרות כללים כלליים של אופן פעולה מקובל. פעולה זו תעכב את היכולת שלך לתקשר עם חברים בשרתים אלה.
## רשתות עמית לעמית (p2p)
![תרשים P2P](../assets/img/layout/network-distributed.svg){ align=left }
מסנג'רים P2P מתחברים לרשת מבוזרת [](https://en.wikipedia.org/wiki/Distributed_networking) של צמתים כדי להעביר הודעה לנמען ללא שרת צד שלישי.
לקוחות (עמיתים) בדרך כלל מוצאים זה את זה באמצעות שימוש [ברשת מחשוב מבוזרת](https://en.wikipedia.org/wiki/Distributed_computing). דוגמאות לכך [טבלאות גיבוב מבוזרות](https://en.wikipedia.org/wiki/Distributed_hash_table) (DHT),בשימוש על ידי [טורנטים](https://en.wikipedia.org/wiki/BitTorrent_(protocol)) וגם [IPFS](https://en.wikipedia.org/wiki/InterPlanetary_File_System) לדוגמא. גישה נוספת היא רשתות מבוססות קרבה, שבהן נוצר חיבור באמצעות WiFi או Bluetooth (לדוגמה, Briar או פרוטוקול הרשת החברתית Scuttlebutt).
לאחר שעמית(peer) מצא נתיב ליצירת קשר באמצעות אחת מהשיטות הללו, נוצר קשר ישיר ביניהם. אף על פי שהודעות מוצפנות בדרך כלל, צופה עדיין יכול להסיק את המיקום והזהות של השולח והנמען.
רשתות P2P אינן משתמשות בשרתים, מכיוון שעמיתים מתקשרים ישירות זה עם זה ולכן לא ניתן לארח אותם באופן עצמאי. עם זאת, שירותים נוספים מסוימים עשויים להסתמך על שרתים מרכזיים, כגון גילוי משתמשים או העברת הודעות לא מקוונות, שיכולים להפיק תועלת מאירוח עצמי.
**יתרונות:**
- מידע מינימלי נחשף לצדדים שלישיים.
- פלטפורמות P2P מודרניות מיישמות E2EE כברירת מחדל. אין שרתים שעלולים ליירט ולפענח את השידורים שלך, בניגוד לדגמים מרכזיים ומאוחדים.
**חסרונות:**
- סט תכונות מצומצם:
- ניתן לשלוח הודעות רק כאשר שני העמיתים במצב מחובר, עם זאת, הלקוח שלך עשוי לאחסן הודעות באופן מקומי כדי להמתין עד שאיש הקשר יחזור למצב מחובר.
- באופן כללי מגדיל את השימוש בסוללה במכשירים ניידים, מכיוון שהלקוח חייב להישאר מחובר לרשת המבוזרת כדי ללמוד מי מחובר.
- ייתכן שחלק מהתכונות הנפוצות של מסנג'רים לא ימומשו או לא יושמו במלואן, כגון מחיקת הודעות.
- כתובת ה - IP שלכם ושל אנשי הקשר שאיתם אתם מתקשרים עשויה להיחשף אם לא תשתמשו בתוכנה בשילוב עם VPN [](../vpn.md) או [Tor](../tor.md). במדינות רבות יש צורה כלשהי של מעקב המוני ו / או שמירת מטא נתונים.
## ניתוב אנונימי
![תרשים ניתוב אנונימי](../assets/img/layout/network-anonymous-routing.svg){ align=left }
מסנג'ר המשתמש ב - [ניתוב אנונימי](https://doi.org/10.1007/978-1-4419-5906-5_628) מסתיר את זהות השולח, המקבל או ראיות לכך שהוא מתקשר. באופן אידיאלי, מסנג'ר צריך להסתיר את כל השלושה.
ישנן דרכים [רבות](https://doi.org/10.1145/3182658) ושונות ליישם ניתוב אנונימי. אחד המפורסמים ביותר הוא [ניתוב בצל](https://en.wikipedia.org/wiki/Onion_routing) (כלומר [Tor](tor-overview.md)), אשר מתקשר הודעות מוצפנות באמצעות רשת [שכבה וירטואלית](https://en.wikipedia.org/wiki/Overlay_network) המסתירה את המיקום של כל צומת, כמו גם את הנמען והשולח של כל הודעה. השולח והנמען לעולם אינם מתקשרים ישירות ונפגשים רק דרך צומת מפגש סודי, כך שאין דליפה של כתובות IP או מיקום פיזי. צמתים אינם יכולים לפענח הודעות, וגם לא את היעד הסופי; רק הנמען יכול. כל צומת מתווך יכול לפענח רק חלק שמציין לאן לשלוח את ההודעה המוצפנת הבאה, עד שהיא מגיעה לנמען שיכול לפענח אותה באופן מלא, ומכאן "שכבות הבצל "
אחסון עצמי של צומת ברשת ניתוב אנונימית אינו מספק למארח יתרונות פרטיות נוספים, אלא תורם לחוסן הרשת כולה מפני התקפות זיהוי לטובת כולם.
**יתרונות:**
- מידע מינימלי עד לא נחשף לגורמים אחרים.
- ניתן להעביר הודעות באופן מבוזר גם אם אחד הצדדים אינו מחובר.
**חסרונות:**
- הפצת מסרים איטיים.
- לעתים קרובות מוגבל בפחות סוגי מדיה, בעיקר טקסט, מאחר שהרשת איטית.
- פחות אמין אם צמתים נבחרים על ידי ניתוב אקראי, צמתים מסוימים עשויים להיות רחוקים מאוד מהשולח והמקלט, מה שמוסיף השהיה או אפילו לא מצליח להעביר הודעות אם אחד הצמתים עובר למצב לא מקוון.
- מורכב יותר להתחלה, שכן נדרשת יצירה וגיבוי מאובטח של מפתח קריפטוגרפי פרטי.
- בדיוק כמו פלטפורמות מבוזרות אחרות, הוספת תכונות מורכבת יותר עבור מפתחים מאשר על פלטפורמה מרכזית. לכן, תכונות עשויות להיות חסרות או לא מיושמות במלואן, כגון העברת הודעות במצב לא מקוון או מחיקת הודעות.

102
docs/advanced/communication-network-types.nl.md Normal file
View file

@ -0,0 +1,102 @@
---
title: "Soorten communicatienetwerken"
icon: 'material/transit-connection-variant'
---
Er zijn verschillende netwerkarchitecturen die gewoonlijk worden gebruikt om berichten tussen mensen door te geven. Deze netwerken kunnen verschillende privacygaranties bieden, en daarom is het de moeite waard jouw [bedreigingsmodel](../basics/threat-modeling.md) in overweging te nemen bij de beslissing welke app je gaat gebruiken.
[Aanbevolen Instant Messengers](../real-time-communication.md ""){.md-button}
## Gecentraliseerde netwerken
![Diagram gecentraliseerde netwerken](../assets/img/layout/network-centralized.svg){ align=left }
Gecentraliseerde berichten diensten zijn die waarbij alle deelnemers zich op dezelfde server of hetzelfde netwerk van servers bevinden die door dezelfde organisatie worden gecontroleerd.
Bij sommige zelf gehoste berichten diensten kun je je eigen server opzetten. Zelf-hosting kan extra privacywaarborgen bieden, zoals geen gebruikslogs of beperkte toegang tot metadata (gegevens over wie met wie praat). Zelf gehoste gecentraliseerde berichten diensten zijn geïsoleerd en iedereen moet op dezelfde server zijn om te kunnen communiceren.
**Voordelen:**
- Nieuwe functies en veranderingen kunnen sneller worden doorgevoerd.
- Gemakkelijker om mee te beginnen en om contacten te vinden.
- De meeste volwassen en stabiele functies, ecosystemen, omdat ze gemakkelijker te programmeren zijn in een gecentraliseerde software.
- Privacyproblemen kunnen worden verminderd wanneer je vertrouwt op een server die je zelf host.
**Nadelen:**
- Kan [beperkte controle of toegang](https://drewdevault.com/2018/08/08/Signal.html)omvatten. Dit kan dingen inhouden zoals:
- Het is [verboden om clients van derden](https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165) aan te sluiten op het gecentraliseerde netwerk, wat zou kunnen zorgen voor meer maatwerk of een betere ervaring. Vaak gedefinieerd in de gebruiksvoorwaarden.
- Slechte of geen documentatie voor externe ontwikkelaars.
- De [eigendom](https://web.archive.org/web/20210729191953/https://blog.privacytools.io/delisting-wire/), het privacybeleid en de verrichtingen van de dienst kunnen gemakkelijk veranderen wanneer één enkele entiteit de dienst controleert, waardoor de dienst later in gevaar kan worden gebracht.
- Zelf-hosting vergt inspanning en kennis van het opzetten van een dienst.
## Gefedereerde netwerken
![Federated networks diagram](../assets/img/layout/network-decentralized.svg){ align=left }
Bij gefedereerde berichten diensten worden meerdere, onafhankelijke, gedecentraliseerde servers gebruikt die met elkaar kunnen praten (e-mail is een voorbeeld van een gefedereerde dienst). Federatie stelt systeembeheerders in staat hun eigen server te beheren en toch deel uit te maken van het grotere communicatienetwerk.
Bij zelf-hosting kunnen leden van een federatieve server leden van andere servers ontdekken en met hen communiceren, hoewel sommige servers ervoor kunnen kiezen privé te blijven door niet-federated te zijn (bv. een werk team server).
**Voordelen:**
- Maakt een grotere controle over jouw eigen gegevens mogelijk wanneer je jouw eigen server gebruikt.
- Hiermee kunt je kiezen aan wie je jouw gegevens toevertrouwt door te kiezen tussen meerdere "openbare" servers.
- Staat vaak clients van derden toe die een meer native, aangepaste of toegankelijke ervaring kunnen bieden.
- Bij serversoftware kan worden nagegaan of deze overeenkomt met de openbare broncode, ervan uitgaande dat je toegang hebt tot de server of dat je de persoon die dat heeft (bijvoorbeeld een familielid) vertrouwt.
**Nadelen:**
- Het toevoegen van nieuwe functies is ingewikkelder, omdat deze functies moeten worden gestandaardiseerd en getest om ervoor te zorgen dat ze werken met alle servers op het netwerk.
- Door het vorige punt kunnen functies ontbreken, of onvolledig zijn of op onverwachte manieren werken in vergelijking met gecentraliseerde platforms, zoals het doorgeven van berichten wanneer zij offline zijn of het verwijderen van berichten.
- Sommige metadata kunnen beschikbaar zijn (bv. informatie zoals "wie praat met wie", maar niet de eigenlijke berichtinhoud indien E2EE wordt gebruikt).
- Voor federatieve servers is het over het algemeen nodig de beheerder van uw server te vertrouwen. Ze kunnen een hobbyist zijn of anderszins geen "beveiligingsprofessional", en dienen misschien geen standaarddocumenten in zoals een privacybeleid of servicevoorwaarden waarin staat hoe jouw gegevens worden gebruikt.
- Serverbeheerders kiezen er soms voor andere servers te blokkeren, die een bron van ongemodereerd misbruik zijn of algemene regels van aanvaard gedrag overtreden. Dit zal jouw vermogen om te communiceren met leden van die servers belemmeren.
## Peer-to-Peer netwerken
![P2P-diagram](../assets/img/layout/network-distributed.svg){ align=left }
P2P berichten diensten maken verbinding met een [gedistribueerd netwerk](https://en.wikipedia.org/wiki/Distributed_networking) van knooppunten om een bericht door te geven aan de ontvanger zonder een server van derden.
Cliënten (peers) vinden elkaar meestal via een [gedistribueerd computernetwerk](https://en.wikipedia.org/wiki/Distributed_computing). Voorbeelden hiervan zijn [Distributed Hash Tables](https://en.wikipedia.org/wiki/Distributed_hash_table) (DHT), gebruikt door [torrents](https://en.wikipedia.org/wiki/BitTorrent_(protocol)) en [IPFS](https://en.wikipedia.org/wiki/InterPlanetary_File_System) bijvoorbeeld. Een andere benadering is op nabijheid gebaseerde netwerken, waarbij een verbinding tot stand wordt gebracht via WiFi of Bluetooth (bijvoorbeeld Briar of het [Scuttlebutt](https://www.scuttlebutt.nz) sociale netwerkprotocol).
Zodra een peer via een van deze methoden een route naar zijn contactpersoon heeft gevonden, wordt een rechtstreekse verbinding tussen hen tot stand gebracht. Hoewel berichten meestal versleuteld zijn, kan een waarnemer toch de locatie en de identiteit van de verzender en de ontvanger afleiden.
P2P-netwerken maken geen gebruik van servers, aangezien peers rechtstreeks met elkaar communiceren en dus niet zelf gehost kunnen worden. Sommige aanvullende diensten kunnen echter afhankelijk zijn van gecentraliseerde servers, zoals het ontdekken van gebruikers of het doorgeven van offline berichten, die baat kunnen hebben bij zelfhosting.
**Voordelen:**
- Er wordt zo min mogelijk informatie aan derden verstrekt.
- Moderne P2P-platforms implementeren standaard E2EE. Er zijn geen servers die jouw transmissies kunnen onderscheppen en ontsleutelen, in tegenstelling tot gecentraliseerde en gefedereerde netwerken.
**Nadelen:**
- Beperkte functies:
- Berichten kunnen alleen worden verzonden als beide peers online zijn, maar jouw cliënt kan berichten lokaal opslaan om te wachten tot de contactpersoon weer online is.
- Verhoogt in het algemeen het batterijverbruik op mobiele toestellen, omdat de client verbonden moet blijven met het gedistribueerde netwerk om te weten te komen wie online is.
- Sommige veelgebruikte messenger-functies zijn mogelijk niet of onvolledig geïmplementeerd, zoals het verwijderen van berichten.
- Uw IP-adres en dat van de contacten waarmee je communiceert kunnen worden blootgesteld als je de software niet gebruikt in combinatie met een [VPN](../vpn.md) of [Tor](../tor.md). Veel landen kennen een vorm van massasurveillance en/of het bewaren van metadata.
## Anonieme routering
![Anoniem routeringsschema](../assets/img/layout/network-anonymous-routing.svg){ align=left }
Een berichten diensten die gebruik maakt van [anonieme routering](https://doi.org/10.1007/978-1-4419-5906-5_628) verbergt de identiteit van de verzender, de ontvanger of het bewijs dat zij hebben gecommuniceerd. Idealiter zou een berichten diensten alle drie moeten verbergen.
Er zijn [veel](https://doi.org/10.1145/3182658) verschillende manieren om anonieme routering te implementeren. Een van de bekendste is [onion routing](https://en.wikipedia.org/wiki/Onion_routing) (d.w.z. [Tor](tor-overview.md)), waarbij versleutelde berichten worden gecommuniceerd via een virtueel [overlay netwerk](https://en.wikipedia.org/wiki/Overlay_network) dat de locatie van elk knooppunt en de ontvanger en verzender van elk bericht verbergt. De verzender en de ontvanger hebben nooit rechtstreeks contact en ontmoeten elkaar alleen via een geheim rendez-vousknooppunt, zodat er geen IP-adressen of fysieke locatie uitlekken. Knooppunten kunnen berichten niet ontcijferen, noch de eindbestemming; alleen de ontvanger kan dat. Elk tussenliggend knooppunt kan slechts een deel decoderen dat aangeeft waar het nog versleutelde bericht naartoe moet, totdat het aankomt bij de ontvanger die het volledig kan decoderen, vandaar de "ui-lagen"
Het zelf hosten van een knooppunt in een anoniem routenetwerk biedt de hoster geen extra privacyvoordelen, maar draagt bij tot de weerbaarheid van het hele netwerk tegen identificatieaanvallen, wat in ieders voordeel is.
**Voordelen:**
- Minimale tot geen informatie wordt blootgesteld aan andere partijen.
- Berichten kunnen op gedecentraliseerde wijze worden doorgegeven, zelfs als een van de partijen offline is.
**Nadelen:**
- Trage verspreiding van berichten.
- Vaak beperkt tot minder mediatypen, meestal tekst, omdat het netwerk traag is.
- Minder betrouwbaar als de knooppunten worden geselecteerd door gerandomiseerde routering, kunnen sommige knooppunten zeer ver van de verzender en de ontvanger verwijderd zijn, waardoor vertraging optreedt of zelfs berichten niet worden verzonden als een van de knooppunten offline gaat.
- Ingewikkelder om mee te beginnen omdat de creatie en beveiligde backup van een cryptografische private sleutel vereist is.
- Net als bij andere gedecentraliseerde platforms is het toevoegen van functies ingewikkelder voor ontwikkelaars dan op een gecentraliseerd platform. Daarom kunnen functies ontbreken of onvolledig zijn geïmplementeerd, zoals het offline doorgeven van berichten of het verwijderen van berichten.

103
docs/advanced/communication-network-types.zh.md Normal file
View file

@ -0,0 +1,103 @@
---
title: "通信网络类型"
icon: 'material/transit-connection-variant'
---
有几种网络架构常用于人与人之间的信息传递。 这些网络可以提供不同的隐私保证，这就是为什么在决定使用哪种应用程序时，应该考虑你的 [威胁模型](../basics/threat-modeling.md)。
[推荐的即时通讯工具](../real-time-communication.md ""){.md-button}
## 集中式网络
![集中式网络示意图](../assets/img/layout/network-centralized.svg){ align=left }
集中式通讯软件是指所有参与者都在同一服务器或由同一组织控制的服务器网络上。
一些自托管通讯软件允许您设置自己的服务器。 自托管可以提供额外的隐私保证，例如没有使用日志或对元数据（关于谁与谁交谈的数据）的访问限制。 自我托管的集中式通讯是孤立的，所有人都必须在同一个服务器上进行交流。
**优点：**
- 新的功能和更改可以更快地实施。
- 更容易开始使用和寻找联系人。
- 成熟和稳定的功能生态系统，因为它们集成于一套体系。
- 当您选择自托管服务器时，隐私问题能缓解不少。
**缺点**
- 可以包括 [访问限制和审查](https://drewdevault.com/2018/08/08/Signal.html)。 这可能包括以下内容：
- 封禁将可能提供更灵活的定制或更好的体验的[第三方客户端](https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165)。 通常在使用条款和条件中定义。
- 为第三方开发者提供的文件很差或没有。
- 当单个实体控制服务时，[所有权](https://web.archive.org/web/20210729191953/https://blog.privacytools.io/delisting-wire/)，隐私政策和服务的行为很容易改变，可能会在以后危及服务。
- 自托管需要耐心和知识。
## 联邦网络
![联邦网络示意图](../assets/img/layout/network-decentralized.svg){ align=left }
联邦网络使用多个独立的去中心化服务器，这些服务器能够相互通信（例如电子邮件）。 联邦允许系统管理员控制自己的服务器，并且仍然是更大的网络的一部分。
自托管时，联合服务器的成员可以发现其他服务器的成员并与其进行通信，尽管某些服务器可以选择通过不联邦化（例如工作团队服务器）来保持私密性。
**优点：**
- 允许在运行自己的服务器时更好地控制自己的数据。
- 允许您通过在多个“公共”服务器之间选择信任谁。
- 通常允许第三方客户端提供更原生、定制或可访问的体验。
- 可以验证服务器与公共源代码匹配，假设您有权访问服务器或您信任这样做的人（例如，家庭成员）。
**缺点**
- 添加新功能更加复杂，因为这些功能需要进行标准化和测试，以确保网络上的所有服务器都能一起使用。
- 由于前一点，与集中式平台相比，功能可能缺乏，不完整或以意想不到的方式工作，例如脱机或消息删除时的消息中继。
- 一些元数据可能是泄漏的（例如，像 "谁在和谁说话 "这样的信息，但如果使用E2EE，则没有实际的消息内容）。
- 通常需要信任服务器的管理员。 他们可能是业余爱好者，也可能不是“安全专业人士” ，并且可能不会提供标准文档，如隐私政策或服务条款，详细说明如何使用您的数据。
- 因为其他服务器的滥用行为或违反了公认的行为的一般规则，服务器管理员有时会选择封锁其他服务器 这会妨碍您与这些服务器的成员进行通信。
## 点对点网络
![P2P网络示意图](../assets/img/layout/network-distributed.svg){ align=left }
点对点聊天软件连接到一个由节点组成的 [分布式网络](https://en.wikipedia.org/wiki/Distributed_networking) ，在没有第三方服务器的情况下将信息转发给收件人。
客户端（对等节点）通常通过使用 [分布式网络](https://en.wikipedia.org/wiki/Distributed_computing) 找到对方。 这方面的例子包括 [分布式哈希表](https://en.wikipedia.org/wiki/Distributed_hash_table) (DHT)，由 [torrents](https://en.wikipedia.org/wiki/BitTorrent_(protocol)) 和 [IPFS](https://en.wikipedia.org/wiki/InterPlanetary_File_System) 等使用。 另一种方法是基于近距离的网络，通过WiFi或蓝牙建立连接（例如，Briar或 [Scuttlebutt](https://www.scuttlebutt.nz) 社交网络协议）。
一旦一个节点通过这些方法中的任何一种找到了通往其联系人的路线，它们之间就会建立直接连接。 虽然信息通常是加密的，但观察者仍然可以推断出发件人和收件人的位置和身份。
P2P网络不使用服务器，因为节点之间直接通信，因此不存在自我托管。 不过，一些附加服务可能依赖于集中式服务器，例如用户发现或中继离线消息，自托管对此仍有帮助。
**优点：**
- 很小的第三方暴露。
- 现代P2P平台默认端对端加密。 与集中式和联邦式模式不同，没有任何服务器可能会拦截和解密你的信息。
**缺点**
- 缺少很多特性：
- 消息只有在两个节点都在线时才能发送，然而，你的客户端可以将消息存储在本地，以等待联系人重新上线。
- 通常会增加移动设备的电池用量，因为客户端必须保持与分布式网络的连接，以了解联系人的在线情况。
- 某些常见的Messenger功能可能没有实现或不完整，例如消息删除。
- 如果你不与 [VPN](../vpn.md) 或 [Tor](../tor.md)结合使用该软件，你的IP地址和与你通信的联系人的IP地址可能会被暴露。 许多国家都有某种形式的大规模监控或元数据保留。
## 匿名路由
![匿名网络示意图](../assets/img/layout/network-anonymous-routing.svg){ align=left }
使用 [匿名路由](https://doi.org/10.1007/978-1-4419-5906-5_628) 的Messenger隐藏发送方、接收方的身份或他们一直在通信的证据。 理想情况下，Messenger应该将这三者都隐藏起来。
有 [许多](https://doi.org/10.1145/3182658) 不同的方法来实现匿名网络。 其中最著名的是
洋葱路由 （即 [Tor](tor-overview.md)），它通过一个强加密的 [覆盖网络](https://en.wikipedia.org/wiki/Overlay_network) ，隐藏每个节点的位置以及每个信息的接收者和发送者来通信。 发件人和收件人从不直接交互，只通过一个秘密的会合节点会面，这样就不会泄露IP地址或物理位置。 节点不能解密信息，也不能解密最终目的地；只有收件人可以。 每个中间节点只能解密一部分，表明下一步将把仍然加密的信息发送到哪里，直到它到达可以完全解密的收件人那里，因此命名为 "洋葱路由"。</p>
在匿名网络中自托管一个节点并不为托管者提供额外的隐私，而是有助于整个网络对识别攻击的抗性，对每个人都有好处。
**优点：**
- 最小第三方暴露。
- 消息可以以去中心的方式中继，即使其中一方处于离线状态。
**缺点：**
- 慢
- 通常仅限于较少的媒体类型，主要是文本，因为很慢。
- 如果通过随机路由选择节点，则某些节点可能远离发送方和接收方，增加延迟，甚至在其中一个节点脱机时无法传输消息。
- 开始时比较复杂，因为需要创建和安全备份一个加密私钥。
- 就像其他去中心化平台一样，对开发者来说，增加功能比中心化平台更复杂。 因此，功能可能缺乏或未完全实现，例如脱机消息中继或消息删除。

305
docs/advanced/dns-overview.es.md Normal file
View file

@ -0,0 +1,305 @@
---
title: "Resumen DNS"
icon: material/dns
---
El [Sistema de Nombres de Dominio](https://es.wikipedia.org/wiki/Sistema_de_nombres_de_dominio) es el 'directorio telefónico del Internet'. El DNS traduce los nombres de dominio a direcciones IP para que los navegadores y otros servicios puedan cargar los recursos de Internet, a través de una red descentralizada de servidores.
## ¿Qué es el DNS?
Cuando visitas un sitio web, se devuelve una dirección numérica. Por ejemplo, cuando visitas `privacyguides.org`, la dirección `192.98.54.105` es devuelta.
DNS ha existido desde los [primeros días](https://es.wikipedia.org/wiki/Sistema_de_nombres_de_dominio#Historia) de Internet. Las solicitudes DNS realizadas desde y hacia servidores DNS **no** son generalmente cifradas. En un entorno residencial, el cliente recibe servidores del ISP a través de [DHCP](https://es.wikipedia.org/wiki/Protocolo_de_configuraci%C3%B3n_din%C3%A1mica_de_host).
Las solicitudes de DNS sin cifrar pueden ser fácilmente **vigiladas** y **modificadas** en tránsito. En algunas partes del mundo, a los ISP se les ordena que hagan un [filtrado de DNS](https://en.wikipedia.org/wiki/DNS_blocking) primitivo. Cuando se solicita la dirección IP de un dominio que está bloqueado, es posible que el servidor no responda o lo haga con una dirección IP diferente. Como el protocolo DNS no está encriptado, el ISP (o cualquier operador de red) puede utilizar [DPI](https://es.wikipedia.org/wiki/Inspecci%C3%B3n_profunda_de_paquete) para controlar las solicitudes. Los ISP también pueden bloquear las solicitudes en función de características comunes, independientemente del servidor DNS que se utilice. El DNS no cifrado siempre utiliza el [puerto](https://es.wikipedia.org/wiki/Puerto_de_red) 53 y siempre utiliza UDP.
A continuación, discutimos y proporcionamos un tutorial para probar lo que un observador externo puede ver usando DNS regulares sin encriptar y [DNS encriptado](#what-is-encrypted-dns).
### DNS sin cifrado
1. Usando [`tshark`](https://www.wireshark.org/docs/man-pages/tshark.html) (parte del proyecto [Wireshark](https://es.wikipedia.org/wiki/Wireshark)) podemos monitorear y registrar el flujo de paquetes de Internet. Este comando registra los paquetes que cumplen las reglas especificadas:
```bash
tshark -w /tmp/dns.pcap udp port 53 and host 1.1.1.1 or host 8.8.8.8
```
2. Entonces podemos usar [`dig`](https://es.wikipedia.org/wiki/Dig_(comando)) (Linux, macOS, etc) o [`nslookup`](https://es.wikipedia.org/wiki/Nslookup) (Windows) para enviar la búsqueda DNS a ambos servidores. Software como los navegadores web hacen estas búsquedas automáticamente, a menos que estén configurados para usar DNS cifrado.
=== "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. A continuación, queremos [analizar](https://www.wireshark.org/docs/wsug_html_chunked/ChapterIntroduction.html#ChIntroWhatIs) los resultados:
=== "Wireshark"
```
wireshark -r /tmp/dns.pcap
```
=== "tshark"
```
tshark -r /tmp/dns.pcap
```
Si ejecutas el comando Wireshark anterior, el panel superior muestra los "[frames](https://en.wikipedia.org/wiki/Ethernet_frame)", y el panel inferior muestra todos los datos sobre el frame seleccionado. Las soluciones empresariales de filtrado y monitorización (como las adquiridas por los gobiernos) pueden realizar el proceso de forma automática, sin interacción humana, y pueden agregar esas tramas para producir datos estadísticos útiles para el observador de la red.
| No. | Tiempo | Fuente | Destino | Protocolo | Duración | Información |
| --- | -------- | --------- | --------- | ------------------------- | -------- | ----------------------------------------------------------------------------- |
| 1 | 0.000000 | 192.0.2.1 | 1.1.1.1 | Almacenamiento en la Nube | 104 | Consulta estándar 0x58ba A privacyguides.org OPT |
| 2 | 0.293395 | 1.1.1.1 | 192.0.2.1 | Almacenamiento en la Nube | 108 | Respuesta de consulta estándar 0x58ba A privacyguides.org A 198.98.54.105 OPT |
| 3 | 1.682109 | 192.0.2.1 | 8.8.8.8 | Almacenamiento en la Nube | 104 | Consulta estándar 0xf1a9 A privacyguides.org OPT |
| 4 | 2.154698 | 8.8.8.8 | 192.0.2.1 | Almacenamiento en la Nube | 108 | Respuesta de consulta estándar 0xf1a9 A privacyguides.org A 198.98.54.105 OPT |
Un observador podría modificar cualquiera de estos paquetes.
## ¿Qué es "DNS cifrado"?
DNS cifrado puede referirse a uno de un número de protocolos, siendo los más comunes:
### DNSCrypt
[**DNSCrypt**](https://en.wikipedia.org/wiki/DNSCrypt) fue uno de los primeros métodos de encriptación de consultas DNS. DNSCrypt opera en el puerto 443 y funciona con los protocolos de transporte TCP o UDP. DNSCrypt nunca ha sido enviado al [Grupo de Trabajo de Ingeniería en Internet (IETF)](https://es.wikipedia.org/wiki/Grupo_de_Trabajo_de_Ingenier%C3%ADa_de_Internet) ni ha pasado por el proceso de ["Request for Comments" (RFC)](https://es.wikipedia.org/wiki/Request_for_Comments) por lo que no ha sido utilizado ampliamente fuera de unas pocas [implementaciones](https://dnscrypt.info/implementations). Como resultado, ha sido sustituido en gran medida por el más popular [DNS sobre HTTPS](#dns-over-https-doh).
### DNS sobre TLS (DoT)
[**DNS sobre TLS**](https://es.wikipedia.org/wiki/DNS_mediante_TLS) es otro método para cifrar la comunicación DNS que se define en [RFC 7858](https://datatracker.ietf.org/doc/html/rfc7858). La compatibilidad se implementó por primera vez en Android 9, iOS 14 y en Linux en [systemd-resolved](https://www.freedesktop.org/software/systemd/man/resolved.conf.html#DNSOverTLS=) en la versión 237. La preferencia en la industria se ha estado alejando del DoT al DoH en los últimos años, ya que el DoT es un [protocolo complejo](https://dnscrypt.info/faq/) y tiene un cumplimiento variable del RFC en todas las implementaciones que existen. DoT también opera en un puerto dedicado 853 que puede ser bloqueado fácilmente por cortafuegos restrictivos.
### DNS sobre HTTPS (DoH)
[**DNS sobre HTTPS**](https://es.wikipedia.org/wiki/DNS_mediante_HTTPS) como se define en [RFC 8484](https://datatracker.ietf.org/doc/html/rfc8484) empaqueta las consultas en el protocolo [HTTP/2](https://es.wikipedia.org/wiki/HTTP/2) y proporciona seguridad con HTTPS. La compatibilidad se añadió por primera vez en navegadores web como Firefox 60 y Chrome 83.
La implementación nativa de DoH apareció en iOS 14, macOS 11, Microsoft Windows y Android 13 (sin embargo, no estará habilitada [por defecto](https://android-review.googlesource.com/c/platform/packages/modules/DnsResolver/+/1833144)). El soporte general de los escritorios de Linux está a la espera de la [implementación](https://github.com/systemd/systemd/issues/8639) de systemd por lo que [la instalación de software de terceros sigue siendo necesaria](../dns.md#linux).
## ¿Qué puede ver un tercero?
En este ejemplo registraremos lo que sucede cuando hacemos una solicitud de DoH:
1. En primer lugar, inicia `tshark`:
```bash
tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1"
```
2. En segundo lugar, hace una petición con `curl`:
```bash
curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org
```
3. Después de hacer la solicitud, podemos detener la captura de paquetes con <kbd>CTRL</kbd> + <kbd>C</kbd>.
4. Analiza los resultados en Wireshark:
```bash
wireshark -r /tmp/dns_doh.pcap
```
Podemos ver el [establecimiento de la conexión](https://es.wikipedia.org/wiki/Protocolo_de_control_de_transmisi%C3%B3n#Establecimiento_de_la_conexi%C3%B3n_(negociaci%C3%B3n_en_tres_pasos)) y [enlace TLS](https://www.cloudflare.com/es-es/learning/ssl/what-happens-in-a-tls-handshake/) que ocurre con cualquier conexión encriptada. Al mirar los paquetes de "datos de aplicación" que siguen, ninguno de ellos contiene el dominio que solicitamos ni la dirección IP devuelta.
## ¿Por qué **no debería** utilizar un DNS cifrado?
En los lugares en los que existe el filtrado de Internet (o la censura), visitar recursos prohibidos puede tener sus propias consecuencias, que deberás tener en cuenta en tu [modelo de amenazas](../basics/threat-modeling.md). Nosotros **no** sugerimos el uso de DNS encriptados para este propósito. Usa [Tor](https://torproject.org) o una [VPN](../vpn.md) en su lugar. Si estás usando una VPN, deberías usar los servidores DNS de tu VPN. Al utilizar una VPN, ya les estás confiando toda tu actividad en la red.
Cuando hacemos una búsqueda en el DNS, generalmente es porque queremos acceder a un recurso. A continuación, hablaremos de algunos de los métodos que pueden revelar tus actividades de navegación incluso cuando se utiliza un DNS cifrado:
### Dirección IP
La forma más sencilla de determinar la actividad de navegación podría ser mirar las direcciones IP a las que acceden sus dispositivos. Por ejemplo, si el observador sabe que `privacyguides.org` está en `198.98.54.105`, y tu dispositivo solicita datos de `198.98.54.105`, es muy probable que estés visitando Privacy Guides.
Este método sólo es útil cuando la dirección IP pertenece a un servidor que sólo aloja unos pocos sitios web. Tampoco es muy útil si el sitio está alojado en una plataforma compartida (por ejemplo, Github Pages, Cloudflare Pages, Netlify, WordPress, Blogger, etc). Tampoco es muy útil si el servidor está alojado detrás de un [proxy inverso](https://es.wikipedia.org/wiki/Proxy_inverso), lo cual es muy común en la Internet moderna.
### Indicación del Nombre del Servidor (SNI)
La Indicación del Nombre del Servidor se suele utilizar cuando una dirección IP aloja muchos sitios web. Esto podría ser un servicio como Cloudflare, o alguna otra protección de [ataque de denegación de servicio](https://es.wikipedia.org/wiki/Ataque_de_denegaci%C3%B3n_de_servicio).
1. Comienza a capturar de nuevo con `tshark`. Hemos añadido un filtro con nuestra dirección IP para que no captures muchos paquetes:
```bash
tshark -w /tmp/pg.pcap port 443 and host 198.98.54.105
```
2. Luego visitamos [https://privacyguides.org](https://privacyguides.org).
3. Después de visitar el sitio web, queremos detener la captura de paquetes con <kbd>CTRL</kbd> + <kbd>C</kbd>.
4. A continuación queremos analizar los resultados:
```bash
wireshark -r /tmp/pg.pcap
```
Veremos el establecimiento de la conexión, seguido del enlace TLS para el sitio web de Privacy Guides. Alrededor del marco 5. verás un "Client Hello".
5. Expande el triángulo &#9656; junto a cada campo:
```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. Podemos ver el valor SNI que revela el sitio web que estamos visitando. El comando `tshark` puede darte el valor directamente para todos los paquetes que contienen un valor SNI:
```bash
tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
```
Esto significa que incluso si estamos utilizando servidores "DNS cifrados", es probable que el dominio se divulgue a través de SNI. El protocolo [TLS v1.3](https://es.wikipedia.org/wiki/Seguridad_de_la_capa_de_transporte#TLS_1.3) trae consigo [Client Hello Encriptado](https://blog.cloudflare.com/encrypted-client-hello/), que evita este tipo de fugas.
Los gobiernos, en particular de [China](https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-https-traffic-using-tls-1-3-and-esni/) y [Russia](https://www.zdnet.com/article/russia-wants-to-ban-the-use-of-secure-protocols-such-as-tls-1-3-doh-dot-esni/), ya han [empezado a bloquearlo](https://es.wikipedia.org/wiki/Server_Name_Indication#Funcionamiento_de_ESNI) o han expresado su deseo de hacerlo. Recientemente, Rusia ha [comenzado a bloquear sitios web extranjeros](https://github.com/net4people/bbs/issues/108) que utilizan el estándar [HTTP/3](https://es.wikipedia.org/wiki/HTTP/3). Esto se debe a que el protocolo [QUIC](https://es.wikipedia.org/wiki/QUIC) que forma parte de HTTP/3 requiere que `ClientHello` también esté cifrado.
### Protocolo de comprobación del Estado de un Certificado En línea (OCSP)
Otra forma en que tu navegador puede revelar tus actividades de navegación es con el [Protocolo de comprobación del Estado de un Certificado En línea](https://es.wikipedia.org/wiki/Online_Certificate_Status_Protocol). Al visitar un sitio web HTTPS, el navegador puede comprobar si el [certificado](https://es.wikipedia.org/wiki/Certificado_de_clave_p%C3%BAblica) del sitio web ha sido revocado. Esto se hace generalmente a través del protocolo HTTP, lo que significa que **no** está cifrado.
La solicitud OCSP contiene el "[número de serie](https://es.wikipedia.org/wiki/Certificado_de_clave_p%C3%BAblica#Campos_comunes)" del certificado, que es único. Se envía al "Respondedor OCSP" para comprobar su estado.
Podemos simular lo que haría un navegador utilizando el comando [`openssl`](https://es.wikipedia.org/wiki/OpenSSL).
1. Obtén el certificado del servidor y usa [`sed`](https://es.wikipedia.org/wiki/Sed_(inform%C3%A1tica)) para conservar sólo la parte importante y escribirla en un archivo:
```bash
openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 |
sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert
```
2. Obtén el certificado intermedio. Las [Autoridades de Certificación (CA)](https://es.wikipedia.org/wiki/Autoridad_de_certificaci%C3%B3n) normalmente no firman un certificado directamente; utilizan lo que se conoce como un certificado "intermedio".
```bash
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 |
sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
```
3. El primer certificado en `pg_and_intermediate.cert` es en realidad el certificado del servidor del paso 1. Podemos usar `sed` de nuevo para borrar hasta la primera instancia de END:
```bash
sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
/tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
```
4. Obtén el respondedor OCSP para el certificado del servidor:
```bash
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
```
Nuestro certificado muestra el respondedor del certificado Lets Encrypt. Si queremos ver todos los detalles del certificado podemos utilizar:
```bash
openssl x509 -text -noout -in /tmp/pg_server.cert
```
5. Inicia la captura de paquetes:
```bash
tshark -w /tmp/pg_ocsp.pcap -f "tcp port http"
```
6. Realiza la solicitud OCSP:
```bash
openssl ocsp -issuer /tmp/intermediate_chain.cert \
-cert /tmp/pg_server.cert \
-text \
-url http://r3.o.lencr.org
```
7. Abre la captura:
```bash
wireshark -r /tmp/pg_ocsp.pcap
```
Habrá dos paquetes con el protocolo "OCSP": una "Solicitud" y una "Respuesta". Para la "Solicitud" podemos ver el "número de serie" expandiendo el triángulo &#9656; al lado de cada campo:
```bash
▸ Online Certificate Status Protocol
▸ tbsRequest
▸ requestList: 1 item
▸ Request
▸ reqCert
serialNumber
```
Para la "Respuesta" también podemos ver el "número de serie":
```bash
▸ Online Certificate Status Protocol
▸ responseBytes
▸ BasicOCSPResponse
▸ tbsResponseData
▸ responses: 1 item
▸ SingleResponse
▸ certID
serialNumber
```
8. O usa `tshark` para filtrar los paquetes por el número de serie:
```bash
tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber
```
Si el observador de red tiene el certificado público, que está disponible públicamente, puede hacer coincidir el número de serie con ese certificado y, por lo tanto, determinar el sitio que estás visitando a partir de ese. El proceso puede automatizarse y asociar las direcciones IP con los números de serie. También es posible consultar los registros de [Certificate Transparency](https://es.wikipedia.org/wiki/Certificate_Transparency) para conocer el número de serie.
## ¿Debería utilizar un DNS cifrado?
Hemos elaborado este diagrama de flujo para describir cuándo *deberías* usar el DNS cifrado:
``` mermaid
graph TB
Comienzo[Start] --> anonymous{¿Tratando de ser<br> anónimo?}
anonymous--> | Sí | tor(Usa Tor)
anonymous --> | No | censorship{¿Evitando la<br> censura?}
censorship --> | Sí | vpnOrTor(Usa una<br> VPN o Tor)
censorship --> | No | privacy{¿Quieres privacidad<br> del ISP?}
privacy --> | Sí | vpnOrTor
privacy --> | No | obnoxious{¿El ISP hace<br> odiosas<br> redirecciones?}
obnoxious --> | Sí | encryptedDNS(Usa<br> DNS cifrado<br> con terceros)
obnoxious --> | No | ispDNS{¿El ISP soporta<br> DNS cifrado?}
ispDNS --> | Sí | useISP(Usa<br> DNS cifrado<br> con ISP)
ispDNS --> | No | nothing(No hagas nada)
```
El DNS cifrado con un tercero solo debe usarse para evitar redirecciones y el [bloqueo básico de DNS](https://en.wikipedia.org/wiki/DNS_blocking) cuando puedas estar seguro de que no habrá consecuencias o estés interesado en un proveedor que realice un filtrado rudimentario.
[Lista de servidores DNS recomendados](../dns.md ""){.md-button}
## ¿Qué es DNSSEC?
Las [extensiones de seguridad para el sistema de nombres de dominio](https://es.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) (DNSSEC) son una función del DNS que autentifica las respuestas a las búsquedas de nombres de dominio. No proporciona protecciones de privacidad para esas búsquedas, sino que evita que los atacantes manipulen o envenenen las respuestas a las solicitudes de DNS.
En otras palabras, DNSSEC firma digitalmente los datos para ayudar a garantizar su validez. Para garantizar una búsqueda segura, la firma se produce en todos los niveles del proceso de búsqueda del DNS. Como resultado, todas las respuestas del DNS son de confianza.
El proceso de firma de DNSSEC es similar al de alguien que firma un documento legal con un bolígrafo; esa persona firma con una firma única que nadie más puede crear, y un perito judicial puede mirar esa firma y verificar que el documento fue firmado por esa persona. Estas firmas digitales garantizan que los datos no han sido manipulados.
DNSSEC implementa una política de firma digital jerárquica en todas las capas del DNS. Por ejemplo, en el caso de una búsqueda en `privacyguides.org`, un servidor DNS raíz firmaría una clave para el servidor de nombres `.org`, y el servidor de nombres `.org` firmaría entonces una clave para el servidor de nombres autoritativo `privacyguides.org`.
<small>Adaptado de [DNS Security Extensions (DNSSEC) overview](https://cloud.google.com/dns/docs/dnssec) por Google y [DNSSEC: An Introduction](https://blog.cloudflare.com/dnssec-an-introduction/) por Cloudflare, ambos licensiados bajo [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).</small>
## ¿Qué es la minimización de QNAME?
Un QNAME es un "nombre cualificado", por ejemplo `privacyguides.org`. La minimización de QNAME reduce la cantidad de información enviada desde el servidor DNS al [servidor de nombres autoritativo](https://es.wikipedia.org/wiki/Servidor_de_nombres).
En lugar de enviar todo el dominio `privacyguides.org`, la minimización de QNAME significa que el servidor DNS pedirá todos los registros que terminen en `.org`. Una descripción técnica más detallada se encuentra en [RFC 7816](https://datatracker.ietf.org/doc/html/rfc7816).
## ¿Qué es la Subred del Cliente EDNS (ECS)?
La [Subred de Cliente EDNS](https://en.wikipedia.org/wiki/EDNS_Client_Subnet) es un método para que un resolvedor DNS recursivo especifique una [subred](https://es.wikipedia.org/wiki/Subred) para el [host o cliente](https://es.wikipedia.org/wiki/Cliente_(inform%C3%A1tica)) que está realizando la consulta DNS.
Su objetivo es "acelerar" la entrega de datos dando al cliente una respuesta que pertenece a un servidor que está cerca de él, como una [red de distribución de contenidos](https://es.wikipedia.org/wiki/Red_de_distribuci%C3%B3n_de_contenidos), que se utilizan a menudo en la transmisión de vídeo y el servicio de aplicaciones web de JavaScript.
Esta característica tiene un coste de privacidad, ya que indica al servidor DNS cierta información sobre la ubicación del cliente.

305
docs/advanced/dns-overview.fr.md Normal file
View file

@ -0,0 +1,305 @@
---
title: "DNS Overview"
icon: material/dns
---
Le [Domain Name System"](https://fr.wikipedia.org/wiki/Domain_Name_System) (Système de nom de domaine) 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 **non** généralement crypté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 crypté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 ?}
vie privée --> | Oui | vpnOuTor
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.

305
docs/advanced/dns-overview.he.md Normal file
View file

@ -0,0 +1,305 @@
---
title: "סקירה כללית של DNS"
icon: material/dns
---
מערכת שמות הדומיינים[](https://en.wikipedia.org/wiki/Domain_Name_System) היא 'ספר הטלפונים של האינטרנט '. DNS מתרגם שמות דומיין לכתובות IP כדי שדפדפנים ושירותים אחרים יוכלו לטעון משאבי אינטרנט, באמצעות רשת מבוזרת של שרתים.
## מה זה DNS?
כאשר אתה מבקר באתר אינטרנט, כתובת מספרית מוחזרת. לדוגמה, בעת ביקור `privacyguides.org`, הכתובת הזו `192.98.54.105` מוחזרת.
DNS קיים [מראשית ימי](https://en.wikipedia.org/wiki/Domain_Name_System#History) האינטרנט. בקשות DNS המתבצעות אל ומשרתי DNS **אינן** מוצפנות באופן כללי. בסביבת מגורים, ללקוח ניתן על ידי ספק האינטרנט באמצעות [DHCP](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol).
בקשות DNS לא מוצפנות יכולות בקלות להיות במעקב **** ו**שונה** במעבר. בחלקים מסוימים של העולם, ספקיות האינטרנט נדרשות לבצע [סינון DNS](https://en.wikipedia.org/wiki/DNS_blocking) פרימיטבי. כאשר אתה מבקש את כתובת ה - IP של דומיין חסום, ייתכן שהשרת לא יגיב או יגיב עם כתובת IP אחרת. מכיוון שפרוטוקול ה- DNS אינו מוצפן, ספק שירותי האינטרנט (או כל מפעיל רשת) יכול להשתמש[DPI](https://en.wikipedia.org/wiki/Deep_packet_inspection) כדי לפקח על בקשות. ספקי האינטרנט יכולים גם לחסום בקשות על סמך מאפיינים משותפים, ללא קשר לאיזה שרת DNS נעשה שימוש. DNS לא מוצפן תמיד משתמש ב - [יציאה](https://en.wikipedia.org/wiki/Port_(computer_networking)) 53 ותמיד משתמש ב - UDP.
למטה, אנו דנים ומספקים הדרכה כדי להוכיח מה צופה חיצוני עשוי לראות באמצעות DNS רגיל לא מוצפן ו - [DNS מוצפן](#what-is-encrypted-dns).
### DNS לא מוצפן
1. שימוש[`tshark`](https://www.wireshark.org/docs/man-pages/tshark.html) (בחלק מה [Wireshark](https://en.wikipedia.org/wiki/Wireshark) project) אנו יכולים לפקח ולהקליט זרימת מנות אינטרנט. פקודה זו מתעדת מנות העומדות בכללים שצוינו:
```bash
tshark -w /tmp/dns.pcap udp port 53 and host 1.1.1.1 or host 8.8.8.8
```
2. אנחנו יכולים להשתמש ב [`dig`](https://en.wikipedia.org/wiki/Dig_(command)) (Linux, MacOS etc) or [`nslookup`](https://en.wikipedia.org/wiki/Nslookup) (Windows) כדי לשלוח את בדיקת המידע של DNS לשני השרתים. תוכנות כגון דפדפני אינטרנט מבצעות חיפושים אלה באופן אוטומטי, אלא אם הן מוגדרות לשימוש ב - DNS מוצפן.
== לינוקס, macOS ==
```
dig +noall +answer privacyguides.org @1.1.1.1
dig +noall +answer privacyguides.org @8.8.8.8
```
=== "ווינדוס"
```
nslookup privacyguides.org 1.1.1.1
nslookup privacyguides.org 8.8.8.8
```
3. לאחר מכן, נרצה [לנתח](https://www.wireshark.org/docs/wsug_html_chunked/ChapterIntroduction.html#ChIntroWhatIs) את התוצאות:
=== "Wireshark"
```
wireshark -r /tmp/dns.pcap
```
=== "tshark"
```
tshark -r /tmp/dns.pcap
```
אם אתה מפעיל את פקודת Wireshark לעיל, החלונית העליונה מציגה את "[פריימים](https://en.wikipedia.org/wiki/Ethernet_frame)", והחלונית התחתונה מציגה את כל הנתונים אודות המסגרת שנבחרה. פתרונות סינון ומעקב ארגוניים (כגון אלה שנרכשו על ידי ממשלות) יכולים לבצע את התהליך באופן אוטומטי, ללא אינטראקציה אנושית, ויכולים לצבור מסגרות אלה כדי לייצר נתונים סטטיסטיים השימושיים לצופה ברשת.
| מספר. | זמן | מקור | יעד | פרוטוקול | אורך | מידע |
| ----- | -------- | --------- | --------- | -------- | ---- | ---------------------------------------------------------------------- |
| 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 0x58ba 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 |
משקיף יכול לשנות כל אחת מהחבילות האלה.
## מה זה "DNS מוצפן "?
DNS מוצפן יכול להתייחס לאחד ממספר פרוטוקולים, הנפוצים ביותר הם:
### DNSCrypt
[**DNSCrypt**](https://en.wikipedia.org/wiki/DNSCrypt) הייתה אחת השיטות הראשונות להצפנת שאילתות DNS. DNSCrypt פועלת על פורט 443 ועובדת עם פרוטוקולי התחבורה של TCP או UDP. DNSCrypt מעולם לא הוגשה ל [כוח המשימה להנדסת אינטרנט (IETF)](https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force) הוא גם לא עבר את תהליך [Request for Comments (RFC)](https://en.wikipedia.org/wiki/Request_for_Comments) תהליך, ולכן זה לא היה בשימוש נרחב מחוץ כמה [יישומי](https://dnscrypt.info/implementations). כתוצאה מכך, הוא הוחלף במידה רבה על ידי ה - DNS [הפופולרי יותר על HTTPS](#dns-over-https-doh).
### DNS באמצעות DoT) TLS)
[**DNS באמצעות TLS**](https://en.wikipedia.org/wiki/DNS_over_TLS) היא שיטה נוספת להצפנת תקשורת DNS המוגדרת ב - [RFC 7858](https://datatracker.ietf.org/doc/html/rfc7858). התמיכה יושמה לראשונה באנדרואיד 9, iOS 14, ובלינוקס ב [systemd-resolved](https://www.freedesktop.org/software/systemd/man/resolved.conf.html#DNSOverTLS=) בגרסא 237. ההעדפה בתעשייה התרחקה מ - DOT ל - DOH בשנים האחרונות, מכיוון ש - DOT הוא פרוטוקול [מורכב](https://dnscrypt.info/faq/) ויש לו תאימות משתנה ל - RFC על פני היישומים הקיימים. Dot פועלת גם על פורט ייעודי 853 שניתן לחסום בקלות על ידי חומות אש מגבילות.
### DNS על פני HTTPS
[**DNS באמצעות HTTPS**](https://en.wikipedia.org/wiki/DNS_over_HTTPS) as defined in [RFC 8484](https://datatracker.ietf.org/doc/html/rfc8484) packages queries in the [HTTP/2](https://en.wikipedia.org/wiki/HTTP/2) protocol and provides security with HTTPS. תמיכה נוספה לראשונה בדפדפני אינטרנט כגון Firefox 60 ו - Chrome 83.
יישום מקורי של DoH הופיע ב - iOS 14, macOS 11, מייקרוספט חלונות ו - אנדרואיד 13 (עם זאת, הוא לא יופעל [כברירת מחדל](https://android-review.googlesource.com/c/platform/packages/modules/DnsResolver/+/1833144)). תמיכת שולחן העבודה הכללית של לינוקס ממתינה ליישום systemd [](https://github.com/systemd/systemd/issues/8639) כך שעדיין נדרש להתקין [תוכנות צד שלישי](../dns.md#linux).
## מה צד חיצוני יכול לראות?
בדוגמה זו נתעד את המתרחש בעת הגשת בקשת DoH:
1. ראשית, התחל `tshark`:
```bash
tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1"
```
2. שנית, להגיש בקשה עם `curl`:
```bash
curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org
```
3. לאחר ביצוע הבקשה, אנו יכולים לעצור את לכידת החבילה עם <kbd>CTRL</kbd> + <kbd>C</kbd>.
4. נתח את התוצאות ב wireshark:
```bash
wireshark -r /tmp/dns_doh.pcap
```
אנחנו יכולים לראות [הקמת חיבור](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment) and [TLS handshake](https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/) המתרחשת עם כל חיבור מוצפן. כאשר בוחנים את חבילות "נתוני היישום" שבאות לאחר מכן, אף אחת מהן לא מכילה את הדומיין שביקשנו או את כתובת ה - IP שהוחזרה.
## מדוע** לא כדאי** לי להשתמש ב- DNS מוצפן?
במקומות שבהם יש סינון באינטרנט (או צנזורה), ביקור במשאבים אסורים עשוי להיות השלכות משלו, אשר עליך לשקול במודל [האיום שלך](../basics/threat-modeling.md). אנו **לא** מציעים להשתמש ב- DNS מוצפן למטרה זו. השתמש [Tor](https://torproject.org) או ב [VPN](../vpn.md) במקום זאת. אם אתם משתמשים ב - VPN, אתם צריכים להשתמש בשרתי ה - DNS של ה - VPN שלכם. כשאתם משתמשים ב - VPN, אתם כבר סומכים עליו עם כל הפעילות שלכם ברשת.
כשאנחנו עורכים חיפוש DNS, זה בדרך כלל בגלל שאנחנו רוצים לגשת למשאב. בהמשך נדון בכמה מהשיטות שעשויות לחשוף את פעילויות הגלישה שלך גם בעת שימוש ב - DNS מוצפן:
### כתובת IP
הדרך הפשוטה ביותר לקבוע את פעילות הגלישה עשויה להיות להסתכל על כתובות ה - IP שהמכשירים שלך ניגשים אליהן. לדוגמא, אם הצופה יודע ש `privacyguides.org` היא `198.98.54.105`, והמכשיר שלך מבקש מידע מ `198.98.54.105`,יש סיכוי טוב שאתה מבקר ב Privacy Guides.
שיטה זו שימושית רק כאשר כתובת ה - IP שייכת לשרת שמארח רק אתרים מעטים. הוא גם לא שימושי במיוחד אם האתר מתארח בפלטפורמה משותפת, (לדוגמה, דפי Github, דפי Cloudflare, Netlify, WordPress, Blogger וכו '). זה גם לא מאוד שימושי אם השרת מתארח מאחורי [ פרוקסי הפוך ](https://en.wikipedia.org/wiki/Reverse_proxy), אשר נפוץ מאוד באינטרנט המודרני.
### סימון שם השרת (SNI)
אינדיקציה לשם השרת משמשת בדרך כלל כאשר כתובת IP מארחת אתרים רבים. זה יכול להיות שירות כמו Cloudflare, או הגנה אחרת [מניעת שירות התקפה](https://en.wikipedia.org/wiki/Denial-of-service_attack).
1. התחל לתעד שוב עם `tshark`. הוספנו מסנן עם כתובת ה - IP שלנו כדי שלא יתפסו מנות רבות:
```bash
tshark -w /tmp/pg.pcap port 443 and host 198.98.54.105
```
2. לאחר מכן נבקר בכתובת [https://privacyguides.org](https://privacyguides.org).
3. לאחר ביקור באתר, אנו רוצים לעצור את לכידת החבילה עם <kbd>CTRL</kbd> + <kbd>C</kbd>.
4. בשלב הבא אנו רוצים לנתח את התוצאות:
```bash
wireshark -r /tmp/pg.pcap
```
אנו נראה את יצירת החיבור, ולאחר מכן את לחיצת היד TLS עבור אתר מדריכי הפרטיות Privacy Guides. סביב מסגרת 5. אתה תראה "שלום לקוח ".
5. מרחיבים את המשולש &#9656; ליד כל שדה:
```text
אבטחת שכבת▸ תחבורה
▸ TLSv1.3 שכבת שיא: פרוטוקול לחיצת יד: לקוח שלום
פרוטוקול ▸ לחיצת יד: לקוח שלום
▸ סיומת: server_name (len=22)
סיומת סימון שם ▸ שרת
```
6. אנחנו יכולים לראות את הערך של SNI שמגלה את האתר שבו אנחנו מבקרים. הפקודה `tshark` יכולה לתת לך את הערך ישירות עבור כל החבילות המכילות ערך SNI:
```bash
tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
```
המשמעות היא שגם אם אנו משתמשים בשרתי "DNS מוצפנים ", סביר להניח שהדומיין ייחשף באמצעות SNI. ה [TLS v1.3](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3) פרטוקול מביא עם ז [לקוח מוצפן שלום](https://blog.cloudflare.com/encrypted-client-hello/), מה שמונע דליפה מסוג זה.
ממשלות, ובפרט סין [](https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-https-traffic-using-tls-1-3-and-esni/) ורוסיה [](https://www.zdnet.com/article/russia-wants-to-ban-the-use-of-secure-protocols-such-as-tls-1-3-doh-dot-esni/), כבר החלו לחסום את סין [](https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypted_Client_Hello) או הביעו רצון לעשות זאת. לאחרונה רוסיה [החלה לחסום אתרים](https://github.com/net4people/bbs/issues/108) המשתמשים בתקן זה [HTTP/3](https://en.wikipedia.org/wiki/HTTP/3) סטנדרטי. הסיבה לכך היא ש [QUIC](https://en.wikipedia.org/wiki/QUIC) פרוטוקול המהווה חלק מ HTTP/3 דורש שגם `ClientHello` יהיה מוצפן.
### פרוטוקול סטטוס תעודה מקוון (OCSP)
דרך נוספת שבה הדפדפן שלך יכול לחשוף את פעילויות הגלישה שלך היא באמצעות פרוטוקול סטטוס [לתעודה מקוונת](https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol). בעת ביקור באתר HTTPS, הדפדפן עשוי לבדוק אם אתר האינטרנט[ התעודה](https://en.wikipedia.org/wiki/Public_key_certificate) שלו בוטלה. פעולה זו נעשית בדרך כלל באמצעות פרוטוקול HTTP, כלומר היא **אינה** מוצפנת.
בקשת OCSP מכילה את האישור "[מספר סידורי](https://en.wikipedia.org/wiki/Public_key_certificate#Common_fields)", שהוא ייחודי. הוא נשלח אל "המגיב של OCSP" כדי לבדוק את הסטטוס שלו.
אנו יכולים לדמות מה דפדפן יעשה באמצעות הפקודה [`openssl`](https://en.wikipedia.org/wiki/OpenSSL).
1. קבל את אישור השרת והשתמש בו[`sed`](https://en.wikipedia.org/wiki/Sed) כדי לשמור רק את החלק החשוב ולכתוב אותו לקובץ:
```bash
openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 |
sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert
```
2. קבל את תעודת הביניים. רשויות התעודה [(CA)](https://en.wikipedia.org/wiki/Certificate_authority) בדרך כלל לא חותמות על אישור ישירות; הן משתמשות במה שמכונה "תעודת ביניים ".
```bash
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 |
sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
```
3. האישור הראשון ב-`pg_and_intermediate.cert` הוא למעשה אישור השרת משלב 1. אנו יכולים להשתמש ב - `SED` שוב כדי למחוק עד המופע הראשון של הסוף:
```bash
sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
/tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
```
4. קבל את התגובה OCSP עבור אישור השרת:
```bash
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
```
Our certificate shows the Lets Encrypt certificate responder. אם ברצוננו לראות את כל פרטי התעודה, נוכל להשתמש ב:
```bash
openssl x509 -text -noout -in /tmp/pg_server.cert
```
5. התחל את לכידת החבילה:
```bash
tshark -w /tmp/pg_ocsp.pcap -f "tcp port http"
```
6. הגש את בקשת ה - OCSP:
```bash
openssl ocsp -issuer /tmp/intermediate_chain.cert \
-cert /tmp/pg_server.cert \
-text \
-url http://r3.o.lencr.org
```
7. פתח את הלכידה:
```bash
wireshark -r /tmp/pg_ocsp.pcap
```
יהיו שתי מנות עם פרוטוקול "OCSP ";" בקשה "ו -" תגובה ". עבור "בקשה" אנו יכולים לראות את "המספר הסידורי" על ידי הרחבת המשולש &#9656; ליד כל שדה:
```bash
▸ פרוטוקול מצב אישור מקוון
▸ tbsRequest
▸ requestList: 1 item
▸ Request
▸ reqCert
serialNumber
```
עבור "התגובה" אנו יכולים לראות גם את "המספר הסידורי ":
```bash
פרוטוקול מצב אישור▸ מקוון
▸ responseBytes
▸ BasicOCSPResponse
▸ tbsResponseData
▸ תגובות: פריט 1
▸ SingleResponse
▸ certID
serialNumber
```
8. לחלופין,`tshark` השתמש כדי לסנן את המנות עבור המספר הסידורי:
```bash
tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber
```
אם לצופה ברשת יש את האישור הציבורי, שזמין לציבור הרחב, הוא יכול להתאים את המספר הסידורי עם אישור זה ולכן לקבוע את האתר שבו אתה מבקר. התהליך יכול להיות אוטומטי ויכול לשייך כתובות IP עם מספרים סידוריים. ניתן גם לבדוק ביומני [תעודות שקיפות](https://en.wikipedia.org/wiki/Certificate_Transparency) את המספר הסידורי.
## האם להשתמש ב - DNS מוצפן?
יצרנו תרשים זרימה זה כדי לתאר מתי אתה צריך ** להשתמש DNS מוצפן:
``` mermaid
גרף TB
התחל[Start] -> אנונימי{מנסה להיות<br> אנונימי?}
אנונימי--> | כן | tor(השתמש ב Tor)
אנונימי --> | לא | צנזורה{הימנע<br> צינזור?}
צנזורה --> | כן | vpnOrTor(השתמש ב - VPN<br> או Tor)
צנזורה --> | אין פרטיות{רוצה פרטיות<br> מספק שירותי אינטרנט?}
פרטיות --> | כן | vpnOrTor
פרטיות --> | לא | גועל נפש {ISP עושה<br><br> הפניות גועליות?}
דוחה --> | כן | מוצפןDNS (השתמש ב - DNS<br> מוצפן<br> עם צד שלישי)
דוחה --> | לא | ISPDNS {האם ספק שירותי האינטרנט תומך ב - DNS מוצפן<br>?}
ispDNS --> | כן | useISP (השתמש ב - DNS<br> מוצפן<br> עם ISP)
ispDNS --> | לא | כלום(אל תעשה כלום)
```
יש להשתמש ב- DNS מוצפן עם צד שלישי רק כדי לעקוף הפניות ובסיסי[DNS blocking](https://en.wikipedia.org/wiki/DNS_blocking) כאשר אתה יכול להיות בטוח שלא יהיו השלכות או שאתה מעוניין בספק שעושה סינון בסיסי.
[רשימת שרתי DNS מומלצים](../dns.md ""){.md-button}
## מהו DNSSEC?
[Domain Name System Security Extensions](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) (DNSSEC) היא תכונה של DNS המאמתת תגובות לבדיקות מידע של שמות תחומים. הוא אינו מספק הגנות פרטיות עבור חיפושים אלה, אלא מונע מתוקפים לתפעל או להרעיל את התגובות לבקשות DNS.
במילים אחרות, DNSSEC חותם דיגיטלית על נתונים כדי להבטיח את תקפותם. על מנת להבטיח חיפוש מאובטח, החתימה מתבצעת בכל רמה בתהליך החיפוש של DNS. כתוצאה מכך, כל התשובות מ - DNS ניתן לסמוך.
תהליך החתימה ב - DNSSEC דומה לחתימה על מסמך משפטי עם עט; אותו אדם חותם עם חתימה ייחודית שאף אחד אחר לא יכול ליצור, ומומחה מטעם בית המשפט יכול לעיין בחתימה זו ולוודא שהמסמך נחתם על ידי אותו אדם. חתימות דיגיטליות אלה מבטיחות כי הנתונים לא השתנו בידי גורם זר.
DNSSEC מיישמת מדיניות חתימה דיגיטלית היררכית בכל שכבות ה - DNS. לדוגמה, במקרה של חיפוש `privacyguides.org`, שרת DNS ראשי יחתום על מפתח עבור שרת השמות `.org`, ושרת השמות `.org` יחתום על מפתח עבור שרת השמות הסמכותי של `privacyguides.org`.
<small>הותאם לסקירה של [DNS Security Extensions (DNSSEC)](https://cloud.google.com/dns/docs/dnssec) על ידי גוגל -[ DNSSEC: An Introduction]( https://blog.cloudflare.com/dnssec-an-introduction/) ועל ידי קלאודפלייר, שניהם ברישיון תחת [CC BY 4.0]( https://creativecommons.org/licenses/by/4.0 /).</small>
## מהו מזעור QName?
QNAME הוא "שם מוסמך", לדוגמה`privacyguides.org`. מזעור QName מצמצם את כמות המידע הנשלחת משרת ה - DNS לשרת [שם סמכותי](https://en.wikipedia.org/wiki/Name_server#Authoritative_name_server).
במקום לשלוח את הדומיין `privacyguides.org`, מזעור QNAME פירושו ששרת ה- DNS ישאל בשביל כל הרשומות המסתיימות ב-`.org`. תיאור טכני נוסף מוגדר ב [RFC 7816](https://datatracker.ietf.org/doc/html/rfc7816).
## מהי רשת משנה של לקוח EDNS (ECS)?
[EDNS Client Subnet](https://en.wikipedia.org/wiki/EDNS_Client_Subnet) היא שיטה לפתרון DNS רקורסיבי כדי לציין [subnetwork](https://en.wikipedia.org/wiki/Subnetwork) עבור מארח [או לקוח](https://en.wikipedia.org/wiki/Client_(computing)) אשר עושה את שאילתת ה - DNS.
הוא נועד "להאיץ" את מסירת הנתונים על ידי מתן תשובה ללקוח ששייכת לשרת שקרוב אליו, כגון רשת [למסירת תוכן](https://en.wikipedia.org/wiki/Content_delivery_network), המשמשת לעתים קרובות בהזרמת וידאו ובהגשת יישומי אינטרנט של JavaScript.
תכונה זו באה בעלות פרטיות, שכן היא אומרת לשרת ה - DNS מידע מסוים על מיקום הלקוח.

305
docs/advanced/dns-overview.it.md Normal file
View file

@ -0,0 +1,305 @@
---
title: "Panoramica DNS"
icon: material/dns
---
Il [Domain Name System](https://it.wikipedia.org/wiki/Domain_Name_System) è 'l'elenco telefonico di Internet'. Il DNS traduce i nomi di dominio in indirizzi IP, in modo che i browser e altri servizi possano caricare le risorse internet mediante un network decentralizzato di server.
## Che cos'è il DNS?
Quando visiti un sito, viene restituito un indirizzo numerico. Per esempio, quando visiti `privacyguides.org`,viene restituito l'indirizzo `192.98.54.105`.
Il DNS esiste dai [primi giorni](https://en.wikipedia.org/wiki/Domain_Name_System#History) di Internet. Le richieste DNS fatte da e verso i server DNS **non sono** crittografate generalmente. In un ambiente residenziale, un cliente riceve i server dall'ISP mediante [DHCP](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol).
Le richieste DNS non crittografate possono essere facilmente **sorvegliate** e **modificate** in transito. In alcune parti del mondo, agli ISP viene ordinato di eseguire un [filtraggio primitivo del DNS](https://en.wikipedia.org/wiki/DNS_blocking). Quando viene effettuata una richiesta dell'indirizzo IP di un dominio bloccato, il server potrebbe non rispondere o fornire un indirizzo IP differente. Dato che il protocollo DNS non è crittografato, l'ISP (o qualsiasi operatore di rete) può utilizzare la [DPI](https://it.wikipedia.org/wiki/Deep_packet_inspection) per monitorare le richieste. Gli ISP possono inoltre bloccare richieste aventi caratteristiche comuni, indipendentemente dal server DNS utilizzato. DNS non crittografato utilizza sempre la [porta](https://it.wikipedia.org/wiki/Porta_(reti)) 53 e l'UDP.
Di seguito, discutiamo e foniamo un tutorial per dimostrare cosa un osservatore esterno potrebbe vedere in entrambi i casi di [DNS crittografato](#what-is-encrypted-dns) e non.
### DNS non crittografato
1. Utilizzando [`tshark`](https://www.wireshark.org/docs/man-pages/tshark.html) (parte del progetto [Wireshark](https://it.wikipedia.org/wiki/Wireshark)) possiamo monitorare e registrare il flusso di pacchetti Internet. Il comando registra pacchetti che soddisfano le regole specificate:
```bash
tshark -w /tmp/dns.pcap udp port 53 and host 1.1.1.1 or host 8.8.8.8
```
2. Possiamo poi utilizzare il comando [`dig`](https://it.wikipedia.org/wiki/Domain_Information_Groper) (Linux, MacOS ecc.) o [`nslookup`](https://it.wikipedia.org/wiki/Nslookup) (Windows) per inviare la ricerca DNS ad entrambi i server. Software come i browser web effettuano queste ricerche automaticamente, a meno che non venga specificato di utilizzare DNS crittografato.
=== "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. Successivamente vogliamo [analizzare](https://www.wireshark.org/docs/wsug_html_chunked/ChapterIntroduction.html#ChIntroWhatIs) i risultati:
=== "Wireshark"
```
wireshark -r /tmp/dns.pcap
```
=== "tshark"
```
tshark -r /tmp/dns.pcap
```
Se esegui il comando Wireshark sopra citato, il pannello superiora mostra i "[frame](https://en.wikipedia.org/wiki/Ethernet_frame)", mentre quello inferiore mostra tutti i dati riguardanti il "frame" selezionato. Soluzioni di filtraggio e monitoraggio aziendali (come quelle acquistate dalle amministrazioni pubbliche) possono eseguire il processo automaticamente, senza interazione umana, e aggregare i "frame" per produrre dati statistici utili all'osservatore della rete.
| No. | Tempo | Fonte | Destinazione | Protocollo | Lunghezza | Info |
| --- | -------- | --------- | ------------ | ---------- | --------- | --------------------------------------------------------------------------- |
| 1 | 0.000000 | 192.0.2.1 | 1.1.1.1 | DNS | 104 | Query standard 0x58ba A privacyguides.org OPT |
| 2 | 0.293395 | 1.1.1.1 | 192.0.2.1 | DNS | 108 | Risposta standard alla query 0x58ba A privacyguides.org A 198.98.54.105 OPT |
| 3 | 1.682109 | 192.0.2.1 | 8.8.8.8 | DNS | 104 | Query standard 0xf1a9 A privacyguides.org OPT |
| 4 | 2.154698 | 8.8.8.8 | 192.0.2.1 | DNS | 108 | Risposta standard alla query 0xf1a9 A privacyguides.org A 198.98.54.105 OPT |
Un osservatore potrebbe modificare uno qualsiasi di questi pacchetti.
## Che cos'è il "DNS crittografato"?
Il DNS crittografato può riferirsi a uno dei diversi protocolli, i più comuni dei quali sono:
### DNSCrypt
[**DNSCrypt**](https://en.wikipedia.org/wiki/DNSCrypt) fu uno dei primi metodi per la crittografia delle query DNS. DNSCrypt opera sulla porta 443 e funziona con entrambi i protocolli di trasporto TCP e UDP. DNSCrypt non è mai stato sottoposto alla [Internet Engineering Task Force (IETF)](https://it.wikipedia.org/wiki/Internet_Engineering_Task_Force), né è passato attraverso il processo di [Request for Comments (RFC, "richiesta di commenti")](https://it.wikipedia.org/wiki/Request_for_Comments); non è mai stato quindi ampiamente utilizzato al di fuori di alcune [implementazioni](https://dnscrypt.info/implementations). DI conseguenza, è stato largamente rimpiazzato dal più popolare [DNS over HTTPS](#dns-over-https-doh).
### DNS over TLS (DoT)
[**DNS over TLS**](https://en.wikipedia.org/wiki/DNS_over_TLS) è un altro metodo per criptare le comunicazioni DNS, definito in [RFC 7858](https://datatracker.ietf.org/doc/html/rfc7858). Il supporto è stato implementato per la prima volta in Android 9, iOS 14 e su Linux in [systemd-resolved](https://www.freedesktop.org/software/systemd/man/resolved.conf.html#DNSOverTLS=) nella versione 237. Negli ultimi anni la preferenza del settore si è spostata da DoT a DoH, in quanto DoT è [protocollo complesso](https://dnscrypt.info/faq/) e presenta una conformità variabile all'RFC tra le implementazioni esistenti. DoT opera anche su una porta dedicata 853 che può essere facilmente bloccata da firewall restrittivi.
### DNS over HTTPS (DoH)
[**DNS over HTTPS**](https://it.wikipedia.org/wiki/DNS_over_HTTPS) come definito in [RFC 8484](https://datatracker.ietf.org/doc/html/rfc8484) pacchettizza le query nel protocollo [HTTP/2](https://it.wikipedia.org/wiki/HTTP/2) e fornisce sicurezza con HTTPS. Il supporto è stato aggiunto per la prima volta in browser web come Firefox 60 e Chrome 83.
L'implementazione nativa di DoH è presente in iOS 14, macOS 11, Microsoft Windows e Android 13 (tuttavia, non sarà abilitata [per impostazione predefinita](https://android-review.googlesource.com/c/platform/packages/modules/DnsResolver/+/1833144)). Il supporto generale per i desktop Linux è in attesa dell'implementazione di systemd [](https://github.com/systemd/systemd/issues/8639) quindi [l'installazione di software di terze parti è ancora necessaria](../dns.md#linux).
## Cosa può vedere un esterno?
In questo esempio registreremo ciò che accade quando facciamo una richiesta al DoH:
1. Per prima cosa, avviare `tshark`:
```bash
tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1"
```
2. In secondo luogo, fare una richiesta con `curl`:
```bash
curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org
```
3. Dopo aver effettuato la richiesta, possiamo interrompere la cattura dei pacchetti con <kbd>CTRL</kbd> + <kbd>C</kbd>.
4. Analizzare i risultati con Wireshark:
```bash
wireshark -r /tmp/dns_doh.pcap
```
Possiamo vedere l'[instaurazione della connessione](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment) e l'[handshake TLS](https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/) che si verifica con qualsiasi connessione crittografata. Osservando i pacchetti "application data" che seguono, nessuno di essi contiene il dominio richiesto o l'indirizzo IP restituito.
## Perché **non dovrei** utilizzare un DNS criptato?
Nei luoghi in cui vige il filtraggio (o la censura) di Internet, la visita a risorse proibite può avere conseguenze che vanno considerate nel [modello di minaccia](../basics/threat-modeling.md). Noi **non** suggeriamo l'uso di DNS criptati per questo scopo. Utilizza [Tor](https://torproject.org) o una [VPN](../vpn.md). Se utilizzi una VPN, usufruisci dei server DNS della VPN. Quando si utilizza una VPN, ci si affida già a loro per tutte le attività di rete.
Quando si effettua una ricerca DNS, in genere è perché si vuole accedere a una risorsa. Di seguito verranno illustrati alcuni dei metodi che possono rivelare le attività di navigazione dell'utente anche quando si utilizza un DNS crittografato:
### Indirizzo IP
Il modo più semplice per determinare l'attività di navigazione potrebbe essere quello di esaminare gli indirizzi IP a cui accedono i dispositivi. Ad esempio, se l'osservatore sa che `privacyguides.org` si trova all'indirizzo `198.98.54.105`, e il tuodispositivo sta richiedendo dati da `198.98.54.105`, è molto probabile che tu stia visitando Privacy Guides.
Questo metodo è utile solo quando l'indirizzo IP appartiene a un server che ospita solo pochi siti web. Inoltre, non è molto utile se il sito è ospitato su una piattaforma condivisa (ad esempio, Github Pages, Cloudflare Pages, Netlify, WordPress, Blogger, ecc). Inoltre, non è molto utile se il server è ospitato dietro un reverse proxy [](https://it.wikipedia.org/wiki/Reverse_proxy), molto comune nella moderna Internet.
### Indicazione del nome del server (Server Name Indication, SNI)
L'indicazione del nome del server è tipicamente utilizzata quando un indirizzo IP ospita molti siti web. Potrebbe trattarsi di un servizio come Cloudflare o di un'altra protezione [attacco denial-of-service](https://it.wikipedia.org/wiki/Denial_of_service).
1. Avviare nuovamente la cattura con `tshark`. Abbiamo aggiunto un filtro con il nostro indirizzo IP in modo da non catturare molti pacchetti:
```bash
tshark -w /tmp/pg.pcap port 443 and host 198.98.54.105
```
2. Poi visitiamo [https://privacyguides.org](https://privacyguides.org).
3. Dopo aver visitato il sito web, vogliamo interrompere la cattura dei pacchetti con <kbd>CTRL</kbd> + <kbd>C</kbd>.
4. Poi vogliamo analizzare i risultati:
```bash
wireshark -r /tmp/pg.pcap
```
Vedremo la creazione della connessione, seguita dall'handshake TLS per il sito web di Privacy Guides. Intorno al frame 5. vedrai "Client Hello".
5. Espandi il triangolo &#9656; accanto a ciascun campo:
```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. Possiamo vedere il valore SNI che rivela il sito web che stiamo visitando. Il comando `tshark` può fornire direttamente il valore per tutti i pacchetti contenenti un valore SNI:
```bash
tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
```
Ciò significa che anche se si utilizzano server "DNS criptati", il dominio sarà probabilmente divulgato tramite SNI. Il protocollo [TLS v1.3](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3) porta con sé [Encrypted Client Hello](https://blog.cloudflare.com/encrypted-client-hello/), che impedisce questo tipo di fuga d'informazioni.
I governi, in particolare [Cina](https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-https-traffic-using-tls-1-3-and-esni/) e [Russia](https://www.zdnet.com/article/russia-wants-to-ban-the-use-of-secure-protocols-such-as-tls-1-3-doh-dot-esni/), hanno[già iniziato a bloccarlo](https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypted_Client_Hello) o hanno espresso il desiderio di farlo. Recentemente, la Russia ha [iniziato a bloccare i siti web](https://github.com/net4people/bbs/issues/108) stranieri che utilizzano lo standard [HTTP/3](https://it.wikipedia.org/wiki/HTTP/3). Questo perché il protocollo [QUIC](https://it.wikipedia.org/wiki/QUIC) che fa parte di HTTP/3 richiede che anche `ClientHello` sia criptato.
### Online Certificate Status Protocol (OCSP)
Un altro modo in cui il browser può rivelare le attività di navigazione è il protocollo [Online Certificate Status Protocol](https://it.wikipedia.org/wiki/Online_Certificate_Status_Protocol). Quando si visita un sito web HTTPS, il browser potrebbe verificare se il [certificato](https://it.wikipedia.org/wiki/Certificato_digitale) del sito web è stato revocato. Questo avviene generalmente tramite il protocollo HTTP, il che significa che è **non** crittografato.
La richiesta OCSP contiene il certificato "[numero seriale](https://it.wikipedia.org/wiki/Certificato_digitale#Struttura_dei_Certificati)", che è unico. Viene inviato al "responder OCSP" per verificarne lo stato.
Possiamo simulare quello che farebbe un browser usando il comando [`openssl`](https://it.wikipedia.org/wiki/OpenSSL).
1. Ottenere il certificato del server e utilizzare [`sed`](https://it.wikipedia.org/wiki/Sed_(Unix)) per conservare solo la parte importante e scriverla in un file:
```bash
openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 |
sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert
```
2. Ottenere il certificato intermedio. [Autorità di certificazione (CA)](https://it.wikipedia.org/wiki/Certificate_authority) di solito non firmano direttamente un certificato, ma utilizzano un cosiddetto certificato "intermedio".
```bash
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 |
sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
```
3. Il primo certificato in `pg_and_intermediate.cert` è in realtà il certificato del server dal passo 1. Possiamo usare di nuovo `sed` per cancellare fino alla prima istanza di END:
```bash
sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
/tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
```
4. Ottenere il responder OCSP per il certificato del server:
```bash
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
```
Il nostro certificato mostra il risponditore del certificato Lets Encrypt. Se si desidera visualizzare tutti i dettagli del certificato, è possibile utilizzare:
```bash
openssl x509 -text -noout -in /tmp/pg_server.cert
```
5. Avviare l'acquisizione dei pacchetti:
```bash
tshark -w /tmp/pg_ocsp.pcap -f "tcp port http"
```
6. Effettuare la richiesta OCSP:
```bash
openssl ocsp -issuer /tmp/intermediate_chain.cert \
-cert /tmp/pg_server.cert \
-text \
-url http://r3.o.lencr.org
```
7. Aprire l'acquisizione:
```bash
wireshark -r /tmp/pg_ocsp.pcap
```
Il protocollo "OCSP" prevede due pacchetti: una "Richiesta" e una "Risposta". Per la "Richiesta" possiamo vedere il "numero seriale" espandendo il triangolo &#9656; accanto a ciascun campo:
```bash
▸ Online Certificate Status Protocol
▸ tbsRequest
▸ requestList: 1 item
▸ Request
▸ reqCert
serialNumber
```
Per la "Risposta" possiamo vedere anche il "numero seriale":
```bash
▸ Online Certificate Status Protocol
▸ responseBytes
▸ BasicOCSPResponse
▸ tbsResponseData
▸ responses: 1 item
▸ SingleResponse
▸ certID
serialNumber
```
8. Oppure utilizzare `tshark` per filtrare i pacchetti per il numero seriale:
```bash
tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber
```
Se l'osservatore della rete dispone del certificato pubblico, che è pubblicamente disponibile, può abbinare il numero seriale a quel certificato e quindi determinare il sito che stai visitando. Il processo può essere automatizzato e può associare gli indirizzi IP ai numeri seriali. È anche possibile controllare i log di [Certificate Transparency](https://en.wikipedia.org/wiki/Certificate_Transparency) per il numero seriale.
## Dovrei utilizzare un DNS criptato?
Abbiamo creato questo diagramma di flusso per descrivere quando *dovresti* utilizzare il DNS criptato:
``` mermaid
graph TB
Inizio[Inizio] --> anonymous{Cerchi di<br> essere anonimo?}
anonymous--> | Sì | tor(Usa Tor)
anonymous --> | No | censorship{Evitare<br> la censura?}
censorship --> | Sì | vpnOrTor(Usa<br> VPN o Tor)
censorship --> | No | privacy{Vuoi privacy<br> dall'ISP?}
privacy --> | Sì | vpnOrTor
privacy --> | No | obnoxious{ISP fa<br> reindirizzamenti<br> odiosi?}
obnoxious --> | Sì | encryptedDNS(Usa<br> DNS criptato<br> di terze parti)
obnoxious --> | No | ispDNS{L'ISP supporta<br> DNS criptato?}
ispDNS --> | Sì | useISP(Usa<br> DNS criptato<br> con l'ISP)
ispDNS --> | No | nothing(Non fare nulla)
```
Il DNS criptato con una terza parte dovrebbe essere usato solo per aggirare i reindirizzamenti e il [blocco DNS](https://en.wikipedia.org/wiki/DNS_blocking) basilare quando puoi essere sicuro che non ci saranno conseguenze o sei interessato a un provider che faccia qualche filtro rudimentale.
[Elenco dei server DNS consigliati](../dns.md ""){.md-button}
## Che cosa sono le DNSSEC?
Le [Domain Name System Security Extensions](https://it.wikipedia.org/wiki/DNSSEC) (DNSSEC) sono una funzione del DNS che autentica le risposte alle ricerche di nomi di dominio. Non forniscono una protezione della privacy per tali ricerche, ma piuttosto impedisce agli aggressori di manipolare o avvelenare le risposte alle richieste DNS.
In altre parole, le DNSSEC firmano digitalmente i dati per garantirne la validità. Per garantire una ricerca sicura, la firma avviene a ogni livello del processo di ricerca DNS. Di conseguenza, tutte le risposte del DNS sono affidabili.
Il processo di firma delle DNSSEC è simile a quello di una persona che firma un documento legale con una penna; quella persona firma con una firma unica che nessun altro può creare e un esperto del tribunale può esaminare quella firma e verificare che il documento è stato firmato da quella persona. Queste firme digitali garantiscono che i dati non siano stati manomessi.
Le DNSSEC implementano una politica di firma digitale gerarchica su tutti i livelli del DNS. Ad esempio, nel caso di una ricerca su `privacyguides.org`, un server DNS root firmerà una chiave per il server dei nomi `.org` e il server dei nomi `.org` firmerà una chiave per il server dei nomi autoritativo `privacyguides.org`.
<small>Adattato da [DNS Security Extensions (DNSSEC) overview (Panoramica delle DNS Security Extensions (DNSSEC))](https://cloud.google.com/dns/docs/dnssec) di Google e [DNSSEC: An Introduction (DNSSEC: una introduzione)](https://blog.cloudflare.com/dnssec-an-introduction/) di Cloudflare, entrambi con licenza [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).</small>
## Che cos'è la minimizzazione del QNAME?
Un QNAME è un "nome qualificato", ad esempio `privacyguides.org`. La minimizzazione del QNAME riduce la quantità di informazioni inviate dal server DNS al [server dei nomi autoritativi](https://en.wikipedia.org/wiki/Name_server#Authoritative_name_server).
Invece di inviare l'intero dominio `privacyguides.org`, la minimizzazione del QNAME significa che il server DNS chiederà tutti i record che terminano in `.org`. Ulteriori descrizioni tecniche sono definite in [RFC 7816](https://datatracker.ietf.org/doc/html/rfc7816).
## Che cos'è la sottorete client EDNS (EDNS Client Subnet, ECS)?
La [sottorete client EDNS](https://en.wikipedia.org/wiki/EDNS_Client_Subnet) è un metodo che consente a un resolver DNS ricorsivo di specificare una [sottorete](https://it.wikipedia.org/wiki/Sottorete) per l'host o il [client](https://it.wikipedia.org/wiki/Client) che sta effettuando la query DNS.
Ha lo scopo di "velocizzare" la consegna dei dati fornendo al client una risposta che appartiene a un server vicino, come ad esempio una rete di distribuzione di contenuti [](https://it.wikipedia.org/wiki/Content_Delivery_Network), spesso utilizzata per lo streaming video e per servire applicazioni web in JavaScript.
Questa funzione ha un costo in termini di privacy, in quanto comunica al server DNS alcune informazioni sulla posizione del client.

305
docs/advanced/dns-overview.nl.md Normal file
View file

@ -0,0 +1,305 @@
---
title: "Inleiding tot DNS"
icon: material/dns
---
Het [Domain Name System](https://en.wikipedia.org/wiki/Domain_Name_System) is het "telefoonboek van het internet". DNS vertaalt domeinnamen naar IP-adressen zodat browsers en andere diensten internetbronnen kunnen laden, via een gedecentraliseerd netwerk van servers.
## Wat is DNS?
Wanneer je een website bezoekt, wordt een numeriek adres teruggezonden. Wanneer je bijvoorbeeld `privacyguides.org`bezoekt, wordt het adres `192.98.54.105` teruggezonden.
DNS bestaat al sinds de [begindagen](https://en.wikipedia.org/wiki/Domain_Name_System#History) van het internet. DNS-verzoeken aan en van DNS-servers zijn **niet** over het algemeen gecodeerd. In een residentiële omgeving krijgt een klant servers van de ISP via [DHCP](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol).
Onversleutelde DNS-verzoeken kunnen onderweg gemakkelijk worden **gesurveilleerd** en **gewijzigd**. In sommige delen van de wereld worden ISP's opgedragen primitieve [DNS-filters te gebruiken](https://en.wikipedia.org/wiki/DNS_blocking). Wanneer je het IP-adres opvraagt van een domein dat is geblokkeerd, antwoordt de server mogelijk niet of met een ander IP-adres. Aangezien het DNS-protocol niet versleuteld is, kan de ISP (of om het even welke netwerkexploitant) [DPI](https://en.wikipedia.org/wiki/Deep_packet_inspection) gebruiken om verzoeken te controleren. ISP's kunnen ook verzoeken blokkeren op basis van gemeenschappelijke kenmerken, ongeacht welke DNS-server wordt gebruikt. Onversleutelde DNS gebruikt altijd [poort](https://en.wikipedia.org/wiki/Port_(computer_networking)) 53 en gebruikt altijd UDP.
Hieronder bespreken we en geven we een tutorial om te bewijzen wat een externe waarnemer kan zien met gewone onversleutelde DNS en [versleutelde DNS](#what-is-encrypted-dns).
### Onversleutelde DNS
1. Met [`tshark`](https://www.wireshark.org/docs/man-pages/tshark.html) (onderdeel van het [Wireshark](https://en.wikipedia.org/wiki/Wireshark) project) kunnen we de internet packet flow monitoren en opnemen. Dit commando registreert pakketten die aan de gespecificeerde regels voldoen:
```bash
tshark -w /tmp/dns.pcap udp poort 53 en host 1.1.1.1 of host 8.8.8.8
```
2. We kunnen dan [`dig`](https://en.wikipedia.org/wiki/Dig_(command)) (Linux, MacOS etc) of [`nslookup`](https://en.wikipedia.org/wiki/Nslookup) (Windows) gebruiken om de DNS lookup naar beide servers te sturen. Software zoals webbrowsers doen deze lookups automatisch, tenzij zij geconfigureerd zijn om gecodeerde DNS te gebruiken.
=== "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. Vervolgens willen wij [analyseren](https://www.wireshark.org/docs/wsug_html_chunked/ChapterIntroduction.html#ChIntroWhatIs) de resultaten:
=== "Wireshark"
```
wireshark -r /tmp/dns.pcap
```
=== "tshark"
```
tshark -r /tmp/dns.pcap
```
Als je het bovenstaande Wireshark-commando uitvoert, toont het bovenste deelvenster de "[frames](https://en.wikipedia.org/wiki/Ethernet_frame)", en het onderste deelvenster toont alle gegevens over het geselecteerde frame. Oplossingen voor bedrijfsfiltering en -monitoring (zoals die welke door overheden worden aangeschaft) kunnen dit proces automatisch uitvoeren, zonder menselijke tussenkomst, en kunnen deze frames samenvoegen tot statistische gegevens die nuttig zijn voor de netwerkwaarnemer.
| Nee. | Tijd | Bron | Bestemming | Protocol | Lengte | Info |
| ---- | -------- | --------- | ---------- | -------- | ------ | ----------------------------------------------------------------------- |
| 1 | 0.000000 | 192.0.2.1 | 1.1.1.1 | DNS | 104 | Standaard zoekopdracht 0x58ba A privacyguides.org OPT |
| 2 | 0.293395 | 1.1.1.1 | 192.0.2.1 | DNS | 108 | Standaard vraag antwoord 0x58ba A privacyguides.org A 198.98.54.105 OPT |
| 3 | 1.682109 | 192.0.2.1 | 8.8.8.8 | DNS | 104 | Standaard zoekopdracht 0xf1a9 A privacyguides.org OPT |
| 4 | 2.154698 | 8.8.8.8 | 192.0.2.1 | DNS | 108 | Standaard query-antwoord 0xf1a9 A privacyguides.org A 198.98.54.105 OPT |
Een waarnemer kan elk van deze pakketten wijzigen.
## Wat is "versleutelde DNS"?
Versleutelde DNS kan verwijzen naar een van een aantal protocollen, waarvan de meest voorkomende zijn:
### DNSCrypt
[**DNSCrypt**](https://en.wikipedia.org/wiki/DNSCrypt) was een van de eerste methoden om DNS-query's te versleutelen. DNSCrypt werkt op poort 443 en werkt met zowel de TCP- als de UDP-transportprotocollen. DNSCrypt is nooit ingediend bij de [Internet Engineering Task Force (IETF)](https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force) en is ook nooit door het [Request for Comments (RFC)](https://en.wikipedia.org/wiki/Request_for_Comments) proces gegaan, dus is het buiten een paar [implementaties nog niet op grote schaal gebruikt](https://dnscrypt.info/implementations). Als gevolg daarvan is het grotendeels vervangen door het meer populaire [DNS over HTTPS](#dns-over-https-doh).
### DNS over TLS (DoT)
[**DNS over TLS**](https://en.wikipedia.org/wiki/DNS_over_TLS) is een andere methode voor het versleutelen van DNS-communicatie die is gedefinieerd in [RFC 7858](https://datatracker.ietf.org/doc/html/rfc7858). Ondersteuning werd voor het eerst geïmplementeerd in Android 9, iOS 14, en op Linux in [systemd-resolved](https://www.freedesktop.org/software/systemd/man/resolved.conf.html#DNSOverTLS=) in versie 237. De laatste jaren is de voorkeur in de sector verschoven van DoT naar DoH, omdat DoT een [complex protocol is](https://dnscrypt.info/faq/) en de naleving van de RFC in de bestaande implementaties varieert. DoT werkt ook op een speciale poort 853 die gemakkelijk kan worden geblokkeerd door restrictieve firewalls.
### DNS over HTTPS (DoH)
[**DNS over HTTPS**](https://en.wikipedia.org/wiki/DNS_over_HTTPS) zoals gedefinieerd in [RFC 8484](https://datatracker.ietf.org/doc/html/rfc8484) verpakt query's in het [HTTP/2](https://en.wikipedia.org/wiki/HTTP/2) protocol en biedt beveiliging met HTTPS. Ondersteuning werd voor het eerst toegevoegd in webbrowsers zoals Firefox 60 en Chrome 83.
Native implementatie van DoH dook op in iOS 14, macOS 11, Microsoft Windows, en Android 13 (het zal echter niet standaard worden ingeschakeld [](https://android-review.googlesource.com/c/platform/packages/modules/DnsResolver/+/1833144)). Algemene Linux desktop ondersteuning wacht op de systemd [implementatie](https://github.com/systemd/systemd/issues/8639) dus [het installeren van third-party software is nog steeds vereist](../dns.md#linux).
## Wat kan een buitenstaander zien?
In dit voorbeeld zullen we vastleggen wat er gebeurt als we een DoH-verzoek doen:
1. Start eerst `tshark`:
```bash
tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1"
```
2. Ten tweede, doe een aanvraag met `curl`:
```bash
curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org
```
3. Na het verzoek te hebben gedaan, kunnen we de packet capture stoppen met <kbd>CTRL</kbd> + <kbd>C</kbd>.
4. Analyseer de resultaten in Wireshark:
```bash
wireshark -r /tmp/dns_doh.pcap
```
We zien de [verbinding tot stand brengen](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment) en [TLS handshake](https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/) die bij elke versleutelde verbinding optreedt. Als we kijken naar de "toepassings gegevens" pakketten die volgen, bevat geen van hen het domein dat we hebben aangevraagd of het IP adres dat wordt teruggestuurd.
## Waarom **zou ik geen** versleutelde DNS gebruiken?
Op plaatsen waar internet wordt gefilterd (of gecensureerd), kan het bezoeken van verboden bronnen eigen gevolgen hebben waarmee je rekening moet houden in jouw [bedreigingsmodel](../basics/threat-modeling.md). Wij **niet** suggereren het gebruik van gecodeerde DNS voor dit doel. Gebruik in plaats daarvan [Tor](https://torproject.org) of een [VPN](../vpn.md). Als je een VPN gebruikt, moet je de DNS-servers van jouw VPN gebruiken. Wanneer je een VPN gebruikt, vertrouwt je hen al jouw netwerkactiviteiten toe.
Wanneer we een DNS lookup doen, is dat meestal omdat we toegang willen tot een bron. Hieronder bespreken we enkele van de methoden die jouw surf-activiteiten kunnen onthullen, zelfs wanneer je versleutelde DNS gebruikt:
### IP-adres
De eenvoudigste manier om de surfactiviteit vast te stellen, is te kijken naar de IP-adressen waartoe jouw apparaten toegang hebben. Als de waarnemer bijvoorbeeld weet dat `privacyguides.org` op `198.98.54.105`staat, en jouw apparaat gegevens opvraagt van `198.98.54.105`, is de kans groot dat je Privacy Guides bezoekt.
Deze methode is alleen nuttig wanneer het IP-adres toebehoort aan een server die slechts enkele websites host. Het is ook niet erg nuttig als de site wordt gehost op een gedeeld platform (bijv. Github Pages, Cloudflare Pages, Netlify, WordPress, Blogger, enz). Het is ook niet erg nuttig als de server gehost wordt achter een [reverse proxy](https://en.wikipedia.org/wiki/Reverse_proxy), wat heel gebruikelijk is op het moderne Internet.
### Server Naam Aanwijzing (SNA)
Server Name Indication wordt meestal gebruikt wanneer een IP-adres veel websites host. Dit kan een dienst als Cloudflare zijn, of een andere [Denial-of-service-aanval](https://en.wikipedia.org/wiki/Denial-of-service_attack) bescherming.
1. Begin opnieuw te vangen met `tshark`. We hebben een filter toegevoegd met ons IP adres zodat je niet veel pakketten opvangt:
```bash
tshark -w /tmp/pg.pcap poort 443 en host 198.98.54.105
```
2. Dan gaan we naar [https://privacyguides.org](https://privacyguides.org).
3. Na het bezoek aan de website, willen we de packet capture stoppen met <kbd>CTRL</kbd> + <kbd>C</kbd>.
4. Vervolgens willen we de resultaten analyseren:
```bash
wireshark -r /tmp/pg.pcap
```
We zullen de verbinding tot stand zien komen, gevolgd door de TLS handshake voor de Privacy Gidsen website. Rond frame 5. zie je een "Client Hello".
5. Vouw de driehoek &#9656; uit naast elk veld:
```text
▸ Transport Layer Security
▸ TLSv1.3 Record Layer: Handshake Protocol: Client Hello
▸ Handshake Protocol: Client Hello
▸ Uitbreiding: server_name (len=22)
▸ Uitbreiding servernaam-aanduiding
```
6. Wij kunnen de SNI-waarde zien die aangeeft welke website wij bezoeken. Het `tshark` commando kan je de waarde rechtstreeks geven voor alle pakketten die een SNI waarde bevatten:
```bash
tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
```
Dit betekent dat zelfs als we "Encrypted DNS" servers gebruiken, het domein waarschijnlijk zal worden onthuld via SNI. Het [TLS v1.3](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3) protocol brengt het [Encrypted Client Hello](https://blog.cloudflare.com/encrypted-client-hello/) met zich mee, dat dit soort lekken voorkomt.
Regeringen, met name [China](https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-https-traffic-using-tls-1-3-and-esni/) en [Rusland](https://www.zdnet.com/article/russia-wants-to-ban-the-use-of-secure-protocols-such-as-tls-1-3-doh-dot-esni/), zijn al begonnen [met het blokkeren van](https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypted_Client_Hello) of hebben de wens geuit dit te doen. Onlangs is Rusland [begonnen met het blokkeren van buitenlandse websites](https://github.com/net4people/bbs/issues/108) die gebruik maken van de [HTTP/3](https://en.wikipedia.org/wiki/HTTP/3) norm. Dit komt doordat het [QUIC](https://en.wikipedia.org/wiki/QUIC) protocol dat deel uitmaakt van HTTP/3 vereist dat `ClientHello` ook gecodeerd wordt.
### Protocol voor onlinecertificaatstatus (PVOC/OCSP)
Een andere manier waarop jouw browser jouw surfactiviteiten kan onthullen is met het [Online Certificate Status Protocol](https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol). Wanneer je een HTTPS-website bezoekt, kan de browser controleren of het [-certificaat](https://en.wikipedia.org/wiki/Public_key_certificate) van de website is ingetrokken. Dit gebeurt over het algemeen via het HTTP-protocol, wat betekent dat het **niet** versleuteld is.
Het OCSP-verzoek bevat het certificaat "[serienummer](https://en.wikipedia.org/wiki/Public_key_certificate#Common_fields)", dat uniek is. Het wordt naar de "OCSP responder" gezonden om de status ervan te controleren.
We kunnen simuleren wat een browser zou doen met het [`openssl`](https://en.wikipedia.org/wiki/OpenSSL) commando.
1. Haal het server certificaat op en gebruik [`sed`](https://en.wikipedia.org/wiki/Sed) om alleen het belangrijke deel te bewaren en schrijf het uit naar een bestand:
```bash
openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 |
sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert
```
2. Haal het tussenliggende certificaat op. [Certificaatautoriteiten (CA)](https://en.wikipedia.org/wiki/Certificate_authority) ondertekenen een certificaat gewoonlijk niet rechtstreeks; zij gebruiken een zogeheten "intermediair" certificaat.
```bash
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 |
sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
```
3. Het eerste certificaat in `pg_and_intermediate.cert` is eigenlijk het servercertificaat uit stap 1. We kunnen `sed` opnieuw gebruiken om te wissen tot de eerste instantie van END:
```bash
sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
/tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
```
4. Haal de OCSP responder voor het server certificaat op:
```bash
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
```
Ons certificaat toont de Lets Encrypt certificaat responder. Als we alle details van het certificaat willen zien, kunnen we gebruik maken van:
```bash
openssl x509 -text -noout -in /tmp/pg_server.cert
```
5. Start de pakketopname:
```bash
tshark -w /tmp/pg_ocsp.pcap -f "tcp port http"
```
6. Doe het OCSP-verzoek:
```bash
openssl ocsp -issuer /tmp/intermediate_chain.cert \
-cert /tmp/pg_server.cert \
-text \
-url http://r3.o.lencr.org
```
7. Open de opname:
```bash
wireshark -r /tmp/pg_ocsp.pcap
```
Er komen twee pakketten met het "OCSP"-protocol: een "Request" en een "Response". Voor de "Aanvraag" kunnen we het "serienummer" zien door het driehoekje &#9656; naast elk veld uit te vouwen:
```bash
▸ Online Certificate Status Protocol
▸ tbsRequest
▸ requestList: 1 item
▸ Verzoek
▸ reqCert
serialNumber
```
Voor de "Response" kunnen we ook het "serienummer" zien:
```bash
▸ Online Certificate Status Protocol
▸ responseBytes
▸ BasicOCSPResponse
▸ tbsResponseData
▸ antwoorden: 1 item
▸ SingleResponse
▸ certID
serialNumber
```
8. Of gebruik `tshark` om de pakketten te filteren op het Serienummer:
```bash
tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber
```
Als de netwerkwaarnemer het publieke certificaat heeft, dat publiekelijk beschikbaar is, kunnen zij het serienummer met dat certificaat vergelijken en op basis daarvan de site bepalen die je bezoekt. Het proces kan worden geautomatiseerd en IP-adressen kunnen worden gekoppeld aan serienummers. Het is ook mogelijk om [Certificate Transparency](https://en.wikipedia.org/wiki/Certificate_Transparency) logs te controleren op het serienummer.
## Moet ik versleutelde DNS gebruiken?
We hebben dit stroomschema gemaakt om te beschrijven wanneer u *versleutelde DNS zou moeten* gebruiken:
``` mermaid
grafiek TB
Start[Start] --> anoniem{Probeert<br> anoniem te zijn?}
anonymous--> | Yes | tor(Use Tor)
anonymous --> | No | censorship{Avoiding<br> censorship?}
censuur --> | Ja | vpnOrTor(Gebruik<br> VPN of Tor)
censuur --> | Nee | privacy{Wil je privacy<br> van ISP?}
privacy --> | Yes | vpnOrTor
privacy --> | No | obnoxious{ISP makes<br> obnoxious<br> redirects?}
onaangenaam --> | Yes | encryptedDNS(Gebruik<br> gecodeerde DNS<br> met derde partij)
onaangenaam --> | No | ispDNS{Doet ISP ondersteunen<br> gecodeerde DNS?}
ispDNS --> | Yes | useISP(Gebruik<br> gecodeerde DNS<br> met ISP)
ispDNS --> | No | nothing(Doe niets)
```
Versleutelde DNS met een derde partij mag alleen worden gebruikt om redirects en basis-DNS-blokkering van [te omzeilen](https://en.wikipedia.org/wiki/DNS_blocking) als je er zeker van kunt zijn dat er geen gevolgen zijn of als je geïnteresseerd bent in een provider die een aantal rudimentaire filters uitvoert.
[Lijst van aanbevolen DNS-servers](../dns.md ""){.md-button}
## Wat is DNSSEC?
[DNSSEC (Domain Name System Security Extensions](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions)) is een functie van DNS waarmee reacties op domeinnaamzoekopdrachten worden geverifieerd. Het biedt geen bescherming van de privacy voor die lookups, maar voorkomt dat aanvallers de antwoorden op DNS-verzoeken manipuleren of vergiftigen.
Met andere woorden, DNSSEC ondertekent gegevens digitaal om de geldigheid ervan te helpen garanderen. Om een veilige lookup te garanderen, vindt de ondertekening plaats op elk niveau in het DNS lookup-proces. Als gevolg daarvan kunnen alle antwoorden van DNS worden vertrouwd.
Het DNSSEC-ondertekeningsproces is vergelijkbaar met iemand die een juridisch document met een pen ondertekent; die persoon ondertekent met een unieke handtekening die niemand anders kan maken, en een gerechtsdeskundige kan naar die handtekening kijken en verifiëren dat het document door die persoon is ondertekend. Deze digitale handtekeningen garanderen dat er niet met de gegevens is geknoeid.
DNSSEC implementeert een hiërarchisch digitaal ondertekeningsbeleid over alle lagen van DNS. Bijvoorbeeld, in het geval van een `privacyguides.org` lookup, zou een root DNS-server een sleutel ondertekenen voor de `.org` nameserver, en de `.org` nameserver zou dan een sleutel ondertekenen voor `privacyguides.org`'s gezaghebbende nameserver.
<small>Aangepast uit [DNS Security Extensions (DNSSEC) overview](https://cloud.google.com/dns/docs/dnssec) van Google en [DNSSEC: An Introduction](https://blog.cloudflare.com/dnssec-an-introduction/) van Cloudflare, beide met een licentie onder [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).</small>
## Wat is QNAME-minimalisatie?
Een QNAME is een "gekwalificeerde naam", bijvoorbeeld `privacyguides.org`. QNAME-minimalisatie vermindert de hoeveelheid informatie die van de DNS-server naar de [authoratieve naamserver](https://en.wikipedia.org/wiki/Name_server#Authoritative_name_server) wordt gestuurd.
In plaats van het hele domein `privacyguides.org` te sturen, betekent QNAME-minimalisatie dat de DNS-server alle records opvraagt die eindigen op `.org`. Een verdere technische beschrijving is te vinden in [RFC 7816](https://datatracker.ietf.org/doc/html/rfc7816).
## Wat is EDNS Client Subnet (ECS)?
Het [EDNS Client Subnet](https://en.wikipedia.org/wiki/EDNS_Client_Subnet) is een methode voor een recursieve DNS-oplosser om een [subnetwerk](https://en.wikipedia.org/wiki/Subnetwork) te specificeren voor de [host of client](https://en.wikipedia.org/wiki/Client_(computing)) die de DNS-query uitvoert.
Het is bedoeld om de levering van gegevens te "versnellen" door de client een antwoord te geven dat toebehoort aan een server die zich dicht bij hem bevindt, zoals een [content delivery network](https://en.wikipedia.org/wiki/Content_delivery_network), die vaak worden gebruikt bij videostreaming en het serveren van JavaScript-webapps.
Deze functie gaat wel ten koste van de privacy, aangezien de DNS-server informatie krijgt over de locatie van de client.

79
docs/advanced/tor-overview.es.md Normal file
View file

@ -0,0 +1,79 @@
---
title: "Resumen de Tor"
icon: 'simple/torproject'
---
Tor es una red descentralizada y gratuita diseñada para utilizar Internet con la mayor privacidad posible. Si se utiliza correctamente, la red permite la navegación y las comunicaciones privadas y anónimas.
## Construcción de ruta
Tor funciona enrutando tu tráfico a través de una red compuesta por miles de servidores gestionados por voluntarios llamados nodos (o repetidores).
Cada vez que te conectes a Tor, elegirá tres nodos para construir una ruta a Internet-esta ruta se llama "circuito." Cada uno de estos nodos tiene su propia función:
### El nodo de entrada
El nodo de entrada, a menudo llamado nodo de guardia, es el primer nodo al que se conecta tu cliente Tor. El nodo de entrada puede ver tu dirección IP, pero no puede ver a qué te estás conectando.
A diferencia de los otros nodos, el cliente Tor seleccionará aleatoriamente un nodo de entrada y se quedará con él durante dos o tres meses para protegerte de ciertos ataques.[^1]
### El nodo medio
El nodo del medio es el segundo nodo al que se conecta tu cliente Tor. Puede ver de qué nodo procede el tráfico -el nodo de entrada- y a qué nodo se dirige a continuación. El nodo intermedio no puede, ver tu dirección IP o el dominio al que te estás conectando.
Para cada nuevo circuito, el nodo central se selecciona aleatoriamente de entre todos los nodos Tor disponibles.
### El nodo de salida
El nodo de salida es el punto en el que tu tráfico web abandona la red Tor y es reenviado a su destino deseado. El nodo de salida no puede ver tu dirección IP, pero sí sabe a qué sitio te estás conectando.
El nodo de salida será elegido al azar de entre todos los nodos Tor disponibles ejecutados con una bandera de retransmisión de salida.[^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>Ruta del circuito de tor</figcaption>
</figure>
## Cifrado
Tor encripta cada paquete (un bloque de datos transmitidos) tres veces con las claves del nodo de salida, medio y de entrada, en ese orden.
Una vez que Tor ha construido un circuito, la transmisión de datos se realiza de la siguiente manera:
1. En primer lugar: cuando el paquete llega al nodo de entrada, se elimina la primera capa de cifrado. En este paquete encriptado, el nodo de entrada encontrará otro paquete encriptado con la dirección del nodo intermedio. El nodo de entrada reenviará entonces el paquete al nodo intermedio.
2. Segundo: cuando el nodo intermedio recibe el paquete del nodo de entrada, también elimina una capa de encriptación con su clave, y esta vez encuentra un paquete encriptado con la dirección del nodo de salida. El nodo intermedio reenviará entonces el paquete al nodo de salida.
3. Por último, cuando el nodo de salida reciba su paquete, eliminará la última capa de cifrado con su clave. El nodo de salida verá la dirección de destino y reenviará el paquete a esa dirección.
A continuación se presenta un diagrama alternativo que muestra el proceso. Cada nodo elimina su propia capa de encriptación, y cuando el servidor de destino devuelve los datos, el mismo proceso ocurre completamente a la inversa. Por ejemplo, el nodo de salida no sabe quién eres, pero sí sabe de qué nodo procede, por lo que añade su propia capa de encriptación y lo envía de vuelta.
<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>Envío y recepción de datos a través de la red Tor</figcaption>
</figure>
Tor nos permite conectarnos a un servidor sin que nadie conozca la ruta completa. El nodo de entrada sabe quién eres, pero no a dónde vas; el nodo intermedio no sabe quién eres ni a dónde vas; y el nodo de salida sabe a dónde vas, pero no quién eres. Como el nodo de salida es el que realiza la conexión final, el servidor de destino nunca conocerá tu dirección IP.
## Advertencias
Aunque Tor proporciona fuertes garantías de privacidad, uno debe ser consciente de que Tor no es perfecto:
- Los adversarios bien financiados con la capacidad de observar pasivamente la mayor parte del tráfico de la red en todo el mundo tienen la posibilidad de desanonimizar a los usuarios de Tor mediante el análisis avanzado del tráfico. Tor tampoco te protege de exponerte por error, como por ejemplo si compartes demasiada información sobre tu identidad real.
- Los nodos de salida de Tor también pueden monitorear el tráfico que pasa a través de ellos. Esto significa que el tráfico que no está encriptado, como el tráfico HTTP simple, puede ser grabado y monitoreado. Si dicho tráfico contiene información personal identificable, entonces puede desanonimizarlo a ese nodo de salida. Por lo tanto, recomendamos utilizar HTTPS sobre Tor siempre que sea posible.
Si deseas utilizar Tor para navegar por la web, sólo recomendamos el navegador Tor Browser **oficial**-está diseñado para evitar las huellas digitales.
- [Tor Browser :material-arrow-right-drop-circle:](../tor.md#tor-browser)
## Recursos Adicionales
- [Manual del usuario del navegador Tor](https://tb-manual.torproject.org)
- [How Tor Works - Computerphile](https://www.youtube-nocookie.com/embed/QRYzre4bf7I) <small>(YouTube)</small>
- [Tor Onion Services - Computerphile](https://www.youtube-nocookie.com/embed/lVcbq_a5N9I) <small>(YouTube)</small>
[^1]: El primer repetidor en tu circuito se llama "guardia de entrada" o "guardia". Es un repetidor rápido y estable que se mantiene como el primero en tu circuito durante 2-3 meses para protegerse de un ataque conocido de ruptura del anonimato. El resto de tu circuito cambia con cada nuevo sitio web que visitas, y todos juntos estos repetidores proporcionan las protecciones de privacidad completas de Tor. Para obtener más información sobre el funcionamiento de los repetidores de protección, consulta esta [entrada del blog](https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters) y el [documento](https://www-users.cs.umn.edu/~hoppernj/single_guard.pdf) sobre los guardias de entrada. ([https://support.torproject.org/tbb/tbb-2/](https://support.torproject.org/tbb/tbb-2/))
[^2]: Bandera de repetidor: una (des)calificación de los repetidores para las posiciones de los circuitos (por ejemplo, "Guardia", "Salida", "MalaSalida"), las propiedades de los circuitos (por ejemplo, "Rápido", "Estable"), o los roles (por ejemplo, "Autoridad", "HSDir"), tal y como los asignan las autoridades de los directorios y se definen con más detalle en la especificación del protocolo del directorio. ([https://metrics.torproject.org/glossary.html](https://metrics.torproject.org/glossary.html))

79
docs/advanced/tor-overview.fr.md Normal file
View file

@ -0,0 +1,79 @@
---
title: "Vue d'Ensemble 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://www.youtube-nocookie.com/embed/QRYzre4bf7I) <small>(YouTube)</small>
- [Services Onion Tor - Computerphile](https://www.youtube-nocookie.com/embed/lVcbq_a5N9I) <small>(YouTube)</small>
[^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))

79
docs/advanced/tor-overview.he.md Normal file
View file

@ -0,0 +1,79 @@
---
title: "סקירה כללית של Tor"
icon: 'simple/torproject'
---
Tor היא רשת מבוזרת חופשית לשימוש, המיועדת לשימוש באינטרנט עם פרטיות רבה ככל האפשר. אם נעשה בו שימוש נכון, הרשת מאפשרת גלישה פרטית ואנונימית ותקשורת.
## בניית נתיב
Tor פועלת על ידי ניתוב התנועה שלך באמצעות רשת המורכבת מאלפי שרתים המופעלים בהתנדבות הנקראים צמתים (או ממסרים).
בכל פעם שאתם מתחברים ל - Tor, הוא יבחר שלושה צמתים כדי לבנות נתיב לאינטרנט - נתיב זה נקרא "מעגל " לכל אחד מהצמתים האלה יש פונקציה משלו:
### צומת הכניסה
צומת הכניסה, הנקרא לעיתים צומת השמירה, הוא הצומת הראשון אליו מתחבר לקוח ה - Tor שלך. צומת הכניסה יכול לראות את כתובת ה - IP שלך, אך הוא לא יכול לראות למה אתה מתחבר.
בניגוד לצמתים האחרים, הלקוח של Tor יבחר באופן אקראי צומת כניסה ויישאר איתו במשך חודשיים עד שלושה כדי להגן עליך מפני התקפות מסוימות.
### הצומת האמצעי
הצומת האמצעי הוא הצומת השני שאליו מתחבר לקוח ה - Tor שלך. הוא יכול לראות מאיזה צומת הגיעה התנועה - וצומת הכניסה - ולאיזה צומת הוא מגיע. הצומת האמצעי לא יכול לראות את כתובת ה - IP שלך או את הדומיין שאליו אתה מתחבר.
עבור כל מעגל חדש, הצומת האמצעי נבחר באקראי מתוך כל צמתי Tor הזמינים.
### צומת היציאה
צומת היציאה הוא הנקודה שבה תנועת האינטרנט שלך עוזבת את רשת Tor ומועברת ליעד הרצוי. לצומת היציאה אין אפשרות לראות את כתובת ה - IP שלך, אך הוא יודע לאיזה אתר הוא מתחבר.
צומת היציאה ייבחר באקראי מכל צמתי Tor הזמינים עם דגל ממסר יציאה.[^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>Tor מסלול מעגלי</figcaption>
</figure>
## הצפנה
Tor מצפין כל מנה (בלוק של נתונים שהועברו) שלוש פעמים עם המפתחות מהיציאה, האמצע וצומת הכניסה - בסדר זה.
לאחר ש - Tor בנה מעגל, העברת הנתונים מתבצעת באופן הבא:
1. ראשית: כאשר החבילה מגיעה לצומת הכניסה, שכבת ההצפנה הראשונה מוסרת. בחבילה מוצפנת זו, צומת הכניסה תמצא חבילה מוצפנת אחרת עם הכתובת של הצומת האמצעי. צומת הכניסה יעביר את החבילה לצומת האמצעי.
2. שנית: כאשר הצומת האמצעי מקבל את החבילה מצומת הכניסה, הוא גם יסיר שכבה של הצפנה עם המפתח שלו, והפעם ימצא חבילה מוצפנת עם הכתובת של צומת היציאה. הצומת האמצעי יעביר את החבילה לצומת היציאה.
3. לבסוף: כאשר צומת היציאה מקבלת את החבילה שלה, היא תסיר את השכבה האחרונה של ההצפנה עם המפתח שלה. צומת היציאה יראה את כתובת היעד ויעביר את החבילה לכתובת הזו.
להלן תרשים חלופי המציג את התהליך. כל צומת מסיר את שכבת ההצפנה שלו, וכאשר שרת היעד מחזיר נתונים, אותו תהליך קורה לגמרי הפוך. לדוגמה, צומת היציאה לא יודע מי אתה, אבל הוא כן יודע מאיזה צומת הוא הגיע, ולכן הוא מוסיף את שכבת ההצפנה שלו ושולח אותה בחזרה.
<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>Sending and receiving data through the Tor Network</figcaption>
</figure>
Tor מאפשר לנו להתחבר לשרת מבלי שאף אחד מהצדדים ידע את כל הנתיב. צומת הכניסה יודע מי אתה, אבל לא לאן אתה הולך; צומת האמצע לא יודע מי אתה או לאן אתה הולך; וצומת היציאה יודע לאן אתה הולך, אבל לא מי אתה. מכיוון שצומת היציאה היא זו שיוצרת את החיבור הסופי, שרת היעד לעולם לא יידע את כתובת ה - IP שלך.
## הסתייגויות
למרות ש - Tor מספקת ערבויות פרטיות חזקות, יש להיות מודעים לכך ש - Tor אינו מושלם:
- ליריבים ממומנים היטב עם היכולת לצפות באופן פסיבי ברוב תעבורת הרשת ברחבי העולם יש סיכוי להפוך את משתמשי Tor לאי אנונימיים באמצעות ניתוח תעבורה מתקדם. Tor גם לא מגן עליכם מפני חשיפת עצמכם בטעות, למשל אם אתם משתפים יותר מדי מידע על זהותכם האמיתית.
- צמתי יציאה של Tor יכולים גם לנטר את התנועה העוברת דרכם. משמעות הדבר היא תנועה שאינה מוצפנת, כגון תעבורת HTTP רגילה, ניתן להקליט ולנטר. אם תנועה כזו מכילה מידע המאפשר זיהוי אישי, אז זה יכול להוריד את האנונימיות שלך בצומת היציאה. לכן, אנו ממליצים להשתמש HTTPS מעל Tor במידת האפשר.
אם ברצונך להשתמש ב - Tor לגלישה באינטרנט, אנו ממליצים רק על הדפדפן הרשמי **Tor** - הוא נועד למנוע טביעת אצבע.
- [דפדפן תור :material-arrow-right-drop-circle:](../tor.md#tor-browser)
## משאבים נוספים
- [מדריך למשתמש בדפדפן Tor](https://tb-manual.torproject.org)
- [How Tor Works - Computerphile](https://www.youtube-nocookie.com/embed/QRYzre4bf7I) <small>(YouTube)</small>
- [שירותי בצל Tor - קובץ מחשב](https://www.youtube-nocookie.com/embed/lVcbq_a5N9I) <small>(YouTube)</small>
[^1]: הממסר הראשון במעגל שלך נקרא "שומר כניסה" או "שומר ". זהו ממסר מהיר ויציב שנשאר הראשון במעגל שלך במשך 2-3 חודשים על מנת להגן מפני התקפה הידועה כשוברת אנונימיות. שאר המעגל שלכם משתנה עם כל אתר חדש שאתם מבקרים בו, וכולם יחד הממסרים האלה מספקים את הגנות הפרטיות המלאות של Tor. לקבלת מידע נוסף על אופן הפעולה של ממסרי מגן, עיין במאמר זה [בלוג פוסט](https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters) וגם [דף](https://www-users.cs.umn.edu/~hoppernj/single_guard.pdf) על שומרי כניסה. ([https://support.torproject.org/tbb/tbb-2/](https://support.torproject.org/tbb/tbb-2/))
[^2]: דגל ממסר: הסמכה מיוחדת (דיס-)של ממסרים למיקומי מעגלים (לדוגמה, "Guard", "Exit", "BadExit"), מאפייני מעגל (לדוגמה, "מהיר", "יציב"), או תפקידים (לדוגמה, "רשות", "HSDir"), כפי שהוקצו על ידי רשויות הספריות והוגדרו עוד יותר במפרט פרוטוקול הספריות. ([https://metrics.torproject.org/glossary.html](https://metrics.torproject.org/glossary.html))

79
docs/advanced/tor-overview.nl.md Normal file
View file

@ -0,0 +1,79 @@
---
title: "Tor Overzicht"
icon: 'simple/torproject'
---
Tor is een gratis te gebruiken, gedecentraliseerd netwerk dat is ontworpen om het internet met zoveel mogelijk privacy te gebruiken. Bij correct gebruik maakt het netwerk privé en anoniem browsen en communicatie mogelijk.
## Route opbouwen
Tor werkt door jouw webverkeer te routeren via een netwerk dat bestaat uit duizenden vrijwillig gerunde servers die knooppunten (of nodes/relays) worden genoemd.
Elke keer dat u verbinding maakt met Tor, kiest het drie knooppunten om een pad naar het internet te bouwen - dit pad wordt een "circuit" genoemd Elk van deze knooppunten heeft zijn eigen functie: Elk van deze knooppunten heeft zijn eigen functie:
### De Entry Node
De entry node, vaak de guard node genoemd, is het eerste knooppunt waarmee uw Tor-client verbinding maakt. De entry node kan uw IP-adres zien, maar het kan niet zien waarmee u verbinding maakt.
In tegenstelling tot de andere nodes, zal de Tor client willekeurig een entry node kiezen en deze twee tot drie maanden aanhouden om je te beschermen tegen bepaalde aanvallen.[^1]
### De Middle Node
De Middle node is het tweede knooppunt waarmee je Tor client verbinding maakt. Het kan zien van welk knooppunt het verkeer afkomstig is - de entry node - en naar welk knooppunt het vervolgens gaat. De middle node kan jouw IP-adres of het domein waarmee je verbinding maakt niet zien.
Voor elk nieuw circuit wordt de middle node willekeurig gekozen uit alle beschikbare Tor-knooppunten.
### De Exit Node
De exit node is het punt waar je webverkeer het Tor netwerk verlaat en wordt doorgestuurd naar de gewenste bestemming. De exit node kan jouw IP-adres niet zien, maar weet wel met welke site hij verbinding maakt.
De exit node wordt willekeurig gekozen uit alle beschikbare Tor-knooppunten met een exit-relaisvlag.[^2]
<figure markdown>
Tor-pad](../assets/img/how-tor-works/tor-path.svg#only-light)
![Tor-pad](../assets/img/how-tor-works/tor-path-dark.svg#only-dark)
<figcaption>Tor-circuitpad</figcaption>
</figure>
## Encryptie
Tor versleutelt elk netwerk pakket ( in een blok verzonden gegevens) drie keer met de sleutels van het Exit-, middle- en entry node- in die volgorde.
Zodra Tor een circuit heeft gebouwd, verloopt de gegevensoverdracht als volgt:
1. Ten eerste: wanneer het pakket bij het entry node aankomt, wordt de eerste encryptielaag verwijderd. In dit versleutelde pakket vindt de entry een ander versleuteld pakket met het adres van de middle node. De entry node stuurt het pakket dan door naar de middle node.
2. Ten tweede: wanneer de middle node het pakket van de entr node ontvangt, verwijdert het ook een versleutelingslaag met zijn sleutel, en vindt ditmaal een versleuteld pakket met het adres van de exit node. De middle node stuurt het pakket dan door naar de exit node.
3. Ten slotte: wanneer de exit node zijn pakket ontvangt, verwijdert het de laatste versleutelingslaag met zijn sleutel. De exit node ziet hierna bestemmingsadres en stuurt het pakket door naar dat adres.
Hieronder staat een alternatief schema dat het proces weergeeft. Elke node verwijdert zijn eigen versleutelings laag, en wanneer de bestemmings server gegevens terugstuurt, gebeurt hetzelfde proces volledig in omgekeerde richting. Zo weet de exit node niet wie je bent, maar wel van welk knooppunt het afkomstig is, en dus voegt het zijn eigen versleutelings laag toe en stuurt het het terug.
<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>Gegevens verzenden en ontvangen via het Tor Netwerk</figcaption>
</figure>
Met Tor kunnen we verbinding maken met een server zonder dat een enkele partij het hele pad kent. De entry node weet wie je bent, maar niet waar je naartoe gaat; De middle node weet niet wie je bent of waar je naartoe gaat; en de exit node weet waar je naartoe gaat, maar niet wie je bent. Omdat de exit node de uiteindelijke verbinding maakt, zal de bestemmingsserver nooit jouw IP-adres kennen.
## Opmerkingen
Hoewel Tor sterke privacygaranties biedt, moet men beseffen dat Tor niet perfect is:
- Goed gefinancierde tegenstanders met de mogelijkheid om passief het meeste netwerkverkeer over de hele wereld te bekijken, hebben een kans om Tor-gebruikers te deanonimiseren door middel van geavanceerde verkeersanalyse. Tor beschermt je ook niet tegen het per ongeluk blootstellen van jezelf, bijvoorbeeld als je te veel informatie over je echte identiteit deelt.
- Tor exit nodes kunnen ook het verkeer controleren dat via hen verloopt. Dit betekent dat verkeer dat niet versleuteld is, zoals gewoon HTTP-verkeer, kan worden geregistreerd en gecontroleerd. Als dergelijk verkeer persoonlijk identificeerbare informatie bevat, kan het u deanonimiseren tot dat exit-knooppunt. Daarom raden wij aan waar mogelijk HTTPS over Tor te gebruiken.
Als je Tor wilt gebruiken om op het web te surfen, raden we alleen de **officiële** Tor Browser aan - deze is ontworpen om vingerafdrukken te voorkomen.
- [Tor Browser :material-arrow-right-drop-circle:](../tor.md#tor-browser)
## Extra bronnen
- [Tor Browser Gebruikershandleiding](https://tb-manual.torproject.org)
- [How Tor Works - Computerphile](https://www.youtube-nocookie.com/embed/QRYzre4bf7I) <small>(YouTube)</small>
- [Tor Onion Services - Computerphile](https://www.youtube-nocookie.com/embed/lVcbq_a5N9I) <small>(YouTube)</small>
[^1]: De entry node in jouw circuit wordt een "bewaker" of "Guard" genoemd. Het is een snel en stabiel node dat gedurende 2-3 maanden de eerste blijft in jouw circuit, ter bescherming tegen een bekende anonimiteitsdoorbrekende aanval. De rest van je circuit verandert bij elke nieuwe website die je bezoekt, en alles bij elkaar bieden deze relays de volledige privacybescherming van Tor. Voor meer informatie over de werking van guard nodes, zie deze [blogpost](https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters) en [paper](https://www-users.cs.umn.edu/~hoppernj/single_guard.pdf) over inloopbeveiliging. ([https://support.torproject.org/tbb/tbb-2/](https://support.torproject.org/tbb/tbb-2/))
[^2]: Relaysvlag: een speciale (dis-)kwalificatie van relais voor circuitposities (bijvoorbeeld "Guard", "Exit", "BadExit"), circuiteigenschappen (bijvoorbeeld "Fast", "Stable"), of rollen (bijvoorbeeld "Authority", "HSDir"), zoals toegewezen door de directory-autoriteiten en nader gedefinieerd in de specificatie van het directory-protocol. ([https://metrics.torproject.org/glossary.html/](https://metrics.torproject.org/glossary.html))