TechTok #7. Privacidad y seguridad: más allá de la superficie

En esta edición de nuestra columna TechTok, hablaremos sobre el consumo de batería en relación con los protocolos resistentes a la computación cuántica, explicaremos la diferencia entre DoH y DoQ, y exploraremos qué son los certificados SSL y cómo interactúan con herramientas como AdGuard.

Big Mekk nos pregunta:

Noté que su newsletter dice que AdGuard ofrecerá soporte para el protocolo Kyber — resistente a la computación cuántica — en su VPN. ¿Eso consume más batería si activo esa opción? Me refiero especialmente en dispositivos móviles, por el procesamiento y todo eso.

Para quienes no están al tanto: AdGuard VPN añadió soporte para Kyber, un algoritmo diseñado para proteger contra amenazas de la computación cuántica, tanto en sus aplicaciones de escritorio como móviles. Ahora sí, vamos a la respuesta: aquí está cómo lo estamos implementando. En ambas plataformas — desktop y móvil — usamos un enfoque híbrido que combina el clásico algoritmo de curva elíptica X25519 con ML-KEM768, basado en Kyber768.

Cuando se establece una conexión entre tu dispositivo móvil y AdGuard VPN, se usan ambos algoritmos en paralelo. Tu dispositivo envía dos claves públicas — una para X25519 y otra para Kyber768 — y el servidor responde de la misma forma. Luego, cada lado genera secretos compartidos con ambos algoritmos y los combina de manera segura en una sola clave de cifrado que protege la sesión VPN. Esta es una doble negociación, y sí, requiere más datos que un handshake tradicional. Mientras que uno "normal" usa unos 32 bytes en cada dirección, este híbrido requiere aproximadamente 1.2 KB.

En cuanto al impacto en la batería, este procesamiento adicional sí exige un poco más del CPU de tu dispositivo. Si usas un teléfono más viejo o lento, establecer una conexión con Kyber activado podría tardar hasta 0.1 segundos más de lo normal. Esto puede generar un ligero aumento en el consumo de batería, pero solo durante la fase inicial de conexión. El impacto es prácticamente imperceptible — sobre todo comparado con acciones cotidianas como encender la pantalla o abrir una app. Una vez establecida la conexión VPN, la sesión utiliza cifrado simétrico tradicional, por lo que el consumo de batería es el mismo de siempre.

En resumen: a menos que tu conexión VPN se caiga muchas veces por sesión y tenga que reconectarse constantemente, activar el algoritmo Kyber no tendrá un impacto significativo en la duración de tu batería.

¿Qué protocolo DNS es más privado, DoH o DoQ?

¡Buena pregunta, Álvaro! Antes que nada, hay que aclarar qué significan DoH (DNS sobre HTTPS) y DoQ (DNS sobre QUIC), y cómo transportan tus datos — porque eso es justo lo que hacen. Para ello, necesitamos entender rápidamente cómo funciona el DNS (Sistema de Nombres de Dominio).

Cuando tu navegador intenta acceder a un sitio, necesita conocer su dirección IP. Ahí entra el servidor DNS: traduce (o “resuelve”) el nombre de dominio legible (por ejemplo, google.com) a una dirección IP numérica que las computadoras usan para ubicar sitios web.

Antes, este proceso se hacía completamente en texto plano — sin ningún cifrado. Eso significaba que tus consultas DNS, incluyendo los sitios que visitabas, podían ser vistas fácilmente por tu proveedor de internet (ISP). Además, dejaba tu tráfico DNS vulnerable a espionaje, manipulación o suplantación. Esta era la realidad antes de que surgieran protocolos cifrados como DoT (DNS sobre TLS), y más adelante DoH (DNS sobre HTTPS). DoT fue el primer gran paso en proteger el tráfico DNS. Encapsula el tráfico dentro del protocolo TLS (Transport Layer Security) y usa un puerto específico — el 853 — dedicado al DNS cifrado. Esto facilita la vida de los administradores de red, pero también hace que el tráfico DoT sea más fácil de identificar (y, en algunos casos, de bloquear) por firewalls o censores.

En cambio, DNS sobre HTTPS (DoH) envía consultas a través de HTTPS, mezclándose con el tráfico web común en el puerto 443 — el mismo que se usa para acceder a sitios seguros. Esto tiene sus pros y sus contras: por un lado, hace más difícil detectar o bloquear el tráfico DoH, lo que mejora la privacidad. Por otro, como el DoH muchas veces comparte la misma conexión HTTPS que los sitios que estás visitando (especialmente en navegadores), puede revelar ciertos patrones — como qué consultas DNS están ligadas a qué sitios o sesiones. A fin de cuentas, HTTP y, por extensión, HTTPS no son protocolos de capa de transporte. Lo recordaremos más adelante.

Entonces, ¿cómo envía tus datos el DoH? Usa HTTP/2 o HTTP/3 en la capa de aplicación — que define cómo se intercambian los datos — corriendo sobre protocolos de transporte cifrados como TCP (en el caso de HTTP/2) o QUIC (en el caso de HTTP/3). Cuando se usa HTTP/2, varias consultas DNS pueden enviarse al mismo tiempo por una sola conexión, gracias a una función llamada multiplexación, que permite que múltiples solicitudes y respuestas compartan el mismo canal sin tener que esperar a que una termine para iniciar otra. Sin embargo, como HTTP/2 funciona sobre una única conexión TCP, todos los paquetes de datos comparten la misma capa de transporte. Esto lleva a un problema conocido como head-of-line blocking: si un solo paquete se pierde o se retrasa, todos los siguientes — aunque sean de otras consultas — deben esperar a que ese paquete sea reenviado y recibido. Esto retrasa toda la secuencia, aunque el resto de los datos ya esté listo.

Con DoQ, cada consulta/respuesta DNS va en su propio flujo, eliminando el problema de head-of-line blocking que mencionamos.

Ahora, volvamos a la pregunta principal: ¿qué significa todo esto para tu privacidad?

Cuando las consultas DNS se envían a través de un flujo compartido —como ocurre con DoH utilizando HTTP/2—, sus tiempos de envío se entrelazan. Si una consulta se retrasa, puede afectar el tiempo de las demás, creando patrones visibles en el tráfico. Aunque el contenido esté cifrado, un observador —como un administrador de red, proveedor de servicios de Internet (ISP) o censor— aún puede analizar estos patrones para intentar adivinar qué sitios estás visitando, cuándo y con qué frecuencia.

Otra ventaja de DoQ sobre DoH en términos de privacidad es la forma en que maneja el tráfico. DoQ se construye sobre el protocolo UDP y utiliza QUIC. A diferencia de DoH, que mezcla las consultas DNS con el tráfico web común, DoQ mantiene el tráfico DNS separado —de manera similar a DoT, pero sin el problema de head-of-line blocking (bloqueo de cabeza de línea). Esta separación significa que no hay mezcla con otros contenidos HTTPS, lo que dificulta que observadores externos vinculen la actividad DNS con el comportamiento de navegación, incluso si este tipo de tráfico es más fácil de identificar como DNS.

Pero tal vez te estés preguntando: ¿y qué pasa con HTTP/3, la versión más reciente del protocolo HTTP, que también utiliza QUIC como capa de transporte? Buena pregunta. De hecho, más del 95% de los principales navegadores, incluidos Chrome, Firefox y Safari, ya ofrecen soporte para HTTP/3. Pero aquí está el punto: aunque HTTP/3 utiliza QUIC en su base, HTTP en sí no es un protocolo de transporte. Y aunque puede reemplazar un protocolo de transporte en algunas situaciones, esto puede traer muchos riesgos innecesarios. Especialmente en el ámbito de la privacidad, el tráfico basado en HTTP generalmente incluye elementos como cookies, encabezados de autenticación, User-Agent y otros metadatos. Estos datos pueden ser utilizados para rastrear, identificar o incluso crear perfiles de usuarios —exactamente el tipo de información que no deseas mezclar con algo tan sensible como el tráfico DNS.

Por lo tanto, en resumen: aunque DoH ofrece una buena privacidad al mezclarse con el tráfico web común (lo que dificulta su detección o bloqueo), DoQ evita el head-of-line blocking, mantiene el tráfico DNS separado de otras actividades en la web y reduce las posibilidades de filtración de información identificable. En términos de privacidad, DoQ es la mejor opción.

Esto nos lleva a la última pregunta, inspirada por un usuario anónimo:

Los certificados de clave pública se han vuelto esenciales en las redes modernas. AdGuard instala un certificado en tu dispositivo local —¿cómo protege los datos? ¿Instalar este certificado hace más daño que bien, o al revés?

Antes de profundizar en el tema, necesitamos entender qué son los certificados digitales. La forma más sencilla de pensarlos es como identidades digitales que todos los sitios web, servicios web y APIs deben presentar para demostrar que realmente son quienes dicen ser. En general, todo lo que está "expuesto en internet" —accesible remotamente e interactuando con usuarios u otros sistemas— necesita un certificado para probar su autenticidad. Sí, tu tráfico puede estar cifrado con HTTPS y seguro durante la transmisión, pero sin los certificados digitales, no tendrías forma de saber si el sitio con el que te estás conectando es verdadero o una imitación hecha para robar tus datos.

Pero si un estafador está dispuesto a crear un sitio falso solo para robar tu información, ¿qué impediría que esa persona falsifique un certificado también? Afortunadamente, no es tan fácil. Cada vez que tu navegador se conecta a un sitio, ese sitio envía su certificado, junto con certificados intermedios que forman una cadena hasta una autoridad certificadora (CA) raíz confiable —ya reconocida por el navegador. El navegador luego utiliza criptografía de clave pública para verificar la firma digital de cada certificado en la cadena. Si todo está correcto, aprueba la conexión. Esto hace que sea prácticamente imposible falsificar un certificado sin comprometer o hacerse pasar por una CA. No es imposible, pero es extremadamente improbable —el último gran incidente de compromiso de una CA ocurrió en 2017. Los navegadores y sistemas operativos ya vienen con una lista de autoridades certificadoras confiables, y estas listas se actualizan regularmente por los fabricantes, eliminando CAs comprometidas o no confiables y agregando nuevas. Los usuarios también pueden agregar CAs manualmente, pero deben hacerlo con extremo cuidado.

Ahora, volviendo al papel de AdGuard en todo esto. Supongamos que has instalado una aplicación de AdGuard para Windows, Mac o Android (las extensiones de navegador y la aplicación para iOS funcionan de manera diferente), y tu navegador intenta conectarse a un servidor web. AdGuard se posiciona "entre" el navegador y el servidor, haciendo que el tráfico pase primero por él. Pero al igual que el navegador necesita confiar en el servidor al conectarse directamente, también necesita confiar en AdGuard en este escenario —de lo contrario, no habría forma de que AdGuard descifre el tráfico HTTPS. Y como ya vimos, esto requiere un certificado confiable. Por eso, durante la instalación, AdGuard genera un certificado raíz especial y lo instala en tu sistema.

Mencionamos anteriormente que los usuarios no deben agregar certificados personalizados sin necesidad —y mantenemos esa recomendación. Existe una razón para ello: si confías en alguien que no deberías, las consecuencias pueden ser graves. Pero nosotros tomamos la seguridad muy en serio. En la criptografía de clave pública, es extremadamente importante mantener tu clave privada segura, y AdGuard genera esta clave localmente en tu dispositivo. Está cifrada y almacenada localmente —nunca se comparte con nadie, y ni siquiera nosotros tenemos acceso a ella.

Y claro, tu tráfico saliente permanece seguro con AdGuard. Después de descifrar el tráfico HTTPS y bloquear todos los anuncios y rastreadores encontrados allí, lo vuelve a cifrar. AdGuard también verifica la autenticidad del servidor web comprobando su certificado —exactamente como lo haría tu navegador. Tomamos medidas de seguridad adicionales —puedes saber más sobre ellas en este artículo de la base de conocimientos.

En resumen, AdGuard no aumenta directamente la seguridad de tu conexión, pero tampoco representa riesgos adicionales. Puedes instalar la aplicación AdGuard en tu dispositivo con la confianza de que tu tráfico estará libre de anuncios y rastreadores —y continuará seguro.