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

Download Translations from Crowdin (#2054)

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

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

@@ -0,0 +1,104 @@
---
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ánea 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.
--8<-- "includes/abbreviations.es.txt"

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

@@ -0,0 +1,307 @@
---
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.
--8<-- "includes/abbreviations.es.txt"

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

@@ -0,0 +1,81 @@
---
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)
- [¿Cómo funciona Tor? - Computerphile](https://invidious.privacyguides.net/embed/QRYzre4bf7I?local=true) <small>(YouTube)</small>
- [Servicios Onion de Tor - Computerphile](https://invidious.privacyguides.net/embed/lVcbq_a5N9I?local=true) <small>(YouTube)</small>
--8<-- "includes/abbreviations.es.txt"
[^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))