La operadora de telecomunicaciones que te suministra el servicio de red es capaz de saber todo lo que haces en el mundo físico, y en el mundo digital.

Todo pese a que ya desde hace años las conexiones que realizamos tanto a apps como a webs se realizan mediante HTTPs, y por tanto van cifradas de punto a punto.

  • ¿Cómo lo hacen?
  • Y más importante aún: ¿Qué podemos hacer nosotros para defendernos?

¡Comencemos!

como evitar espionaje

Un repaso a los protocolos de privacidad en Internet

Para entender cómo una operadora puede saber por qué páginas navegamos y con quién estamos chateando, hay que explicar aunque sea brevemente cómo funcionan las tuberías de Internet. Por dónde y cómo «navegan» nuestros datos cuando nos conectamos a una web o cualquier otro servicio digital.

Obviamente, hay muchísimas tecnologías y protocolos que hacen esto posible, pero como tampoco quiero aburrir a la audiencia con siglas extrañas, voy a centrarme en los 5 protocolos más importantes, y su impacto en la privacidad de nuestras comunicaciones.

Hyper Text Transfer Protocol (sin la «s» final)

El protocolo HTTP es la base en la que se sustentan esas «tuberías». Gracias a él, es posible que cualquiera de nosotros, desde nuestros dispositivos, entremos en una página web o accedamos al contenido de un servicio online que está, recordemos, alojado en un servidor externo (o en múltiples).

Es por tanto la base del Internet tal y como lo conocemos, y funciona por tanto desde el comienzo del mismo.

¿El problema? Pues que cuando se diseñó, tenía como objetivo poner en comunicación ordenadores de distintas universidades (recordemos que Internet se creó dentro de algunas universidades norteamericanas), y por tanto para comunicar usuarios que NO tenían fines maquiavélicos.

Por este mismo motivo. en una comunicación HTTP todo lo que compartimos se envía en texto plano, es decir, accesible por cualquiera que esté «escuchando» en esa misma red.

Claro está, el proyecto creció y, de pronto, millones de usuarios empezaron a usarlo. Algunos, la mayoría, con fines lícitos, pero también otros que buscan hacer daño o sacar tajada de la buena fe del resto (operadoras de telecomunicaciones incluidas, ejem, ejem).

Así es como, un buen día, se decidió que era momento de migrar las comunicaciones a un protocolo actualizado de HTTP que tuviera además en cuenta la privacidad de las mismas.

Así nació HTTPs.

Hyper Text Transfer Protocol SECURE

El protocolo HTTPs no es más que, como decía, una extensión cifrada del protocolo HTTP. Ofrece lo mismo que este último, pero además se encarga de que toda comunicación que se realice mediante HTTPs vaya cifrada mediante una capa que puede ser SSL o TLS (hablaré más tarde de esto).

Históricamente, el HTTPs cumplía dos objetivos principales:

  • Por un lado, mantiene la integridad y privacidad de los datos: Es decir, se asegura de que lo que sale de tu dispositivo y llega al servidor objetivo vaya cifrado de punto a punto, de manera que si hay alguien escuchando por en medio (el típico ataque de Man in the Middle), lo que vea no es el contenido que estás enviando o recibiendo en texto plano, sino ese mismo contenido pero cifrado (caracteres «raros» que aparentemente no tienen sentido).
  • Por otro, legitimaba el servicio digital: Demostraba que esa página a donde querías acceder es quien decía ser, y no una página falsa que emula ser la original.

Esto último, hace ya años, por cierto, que no se cumple. Como expliqué en su día en un artículo que causó muchísimo revuelo cuando lo publiqué en una conocida revista del sector, antaño para poder firmar una conexión mediante HTTPs, era necesario pagarle a una certificadora que, valga la redundancia, certificaba que esa conexión se hacía por HTTPs.

Con la llegada de Let’s Encrypt a mediados de la década pasada, se democratizó el acceso a conexiones HTTPs (Let’s Encrypt es un servicio gratuito autoalojado), pero al no depender de certificadoras centralizadas… se perdió también esa fase de moderación previa, y por tanto, esa legitimación de la veracidad de un dominio.

Una de cal, una de arena…

Secure Sockets Layer y Transport Layer Security

Te decía hace un momento que el protocolo HTTPs se asegura de que nuestras conexiones vayan cifradas de punto a punto gracias a dos protocolos criptográficos: SSL y TLS.

Estos se encargan de decidir cómo se va a cifrar el contenido, y cómo se va a pasar la clave necesaria para descifrarlo por parte del receptor.

Sobre este punto, y para no entrar en muchísimos detalles técnicos, quédate con la idea que el TLS es la versión actualizada del SSL, que por cierto, llegó hasta la versión 3… ¡en 1996!

Desde entonces, la amplia mayoría de conexiones HTTPs se realizan mediante alguna versión de TLS, que va, versión tras versión, corrigiendo algunas vulnerabilidades conocidas, como fue el caso de POODLE, que permitía forzar a la conexión a usar una versión más antigua del protocolo y por tanto aprovecharse de alguna vulnerabilidad pasada, o Heartbleed, que en su momento afectó a dos terceras partes de Internet, y que permitía acceder al contenido cifrado mediante un ataque a la memoria del sistema.

Ambas, por cierto, que ya traté en día en profundidad por la página.

Pese a todo, y por puro branding, la mayoría seguimos refiriéndonos al SSL como el sistema de cifrado de las conexiones HTTPs. Pese a que ya esté obsoleto y prácticamente todos los que gestionamos servicios digitales hayamos migrado a TLS.

  • ¿Cómo encaja todo esto con la privacidad de nuestras comunicaciones?
  • ¿Por qué, pese a usar HTTPs y un TLS, la operadora puede saber hacia dónde navegamos y con quién nos comunicamos?

Pues porque el diablo está en los detalles.

Gracias al HTTPs, la contenido que enviamos o recibimos en nuestra navegación online va cifrado de punto a punto, y por tanto, la operadora (que no deja de ser un intermediario que opera como si de un ataque de Man in the Middle se tratase), no puede ver qué estamos compartiendo.

Pero gracias al TLS, y la necesidad de compartir esos metadatos de cifrado (el navegador necesita saber a qué dominio queremos entrar para verificar si cuenta con un certificado), sí puede saber hacia dónde estamos llamando. Hacia qué web, o con quién estamos hablando.

No sabe por tanto el contenido, pero sí puede ver el contenedor.

Para remediar esto, entra en juego otro protocolo más (el último, lo prometo): ECH.

Encrypted Client Hello

ECH es una extensión del TLS actual que llega para intentar proteger la privacidad de los usuarios en navegación web.

Con él, se soluciona justo ese problema que te contaba que tenían las versiones TLS actuales: Que necesitan compartir la dirección de conexión a la que estamos llamando cuando intentamos acceder, por ejemplo, a una web, en texto plano.

Gracias a ECH, esa extensión pasa a ser cifrada, de manera que, al menos hasta que se encuentre otra manera «creativa» de espiar conexiones, las operadoras, y en definitiva cualquier agente «malicioso» interesado en exponer nuestra navegación, pierden la potestad de saber ya no solo qué estamos enviando o recibiendo, sino también hacia dónde y con quién lo estamos haciendo.

Encrypted Client Hello (ECH) es un sucesor de ESNI y enmascara la indicación del nombre del servidor (SNI) que se utiliza para negociar un protocolo de enlace TLS. Esto significa que cada vez que un usuario visita un sitio web en Cloudflare que tiene ECH habilitado, nadie, excepto el usuario, Cloudflare y el propietario del sitio web, podrá determinar qué sitio web fue visitado.

Cloudflare

Este «pequeño» cambio… lo cambia todo

Gracias a la paulatina implementación de ECH en cada vez más navegadores y servicios de intermediación (recientemente, por ejemplo, Chrome y Firefox ya lo han habilitado, y CloudFlare, que es una de las herramientas más usadas por administradores de servicios online, y una de las DNS más fiables del mundo, también lo ofrece), entramos en una nueva etapa en la que las operadoras y otros servicios digitales no podrán saber qué hacemos mientras usamos las «tuberías» de Internet.

Esto es importantísimo para proteger la privacidad del usuario, por supuesto, pero también para asegurar la accesibilidad del contenido, y es que al no poder saber hacia dónde vas a navegar… la operadora tampoco podrá bloquearnos el acceso a según qué páginas.

Es decir, que se limita enormemente la capacidad de censura del gobierno y demás organismos corporativos, nacionales y supranacionales.

Para terminar, hay que dejar claro que ECH aún está en fase de borrador, y por tanto, es necesario habilitarlo manualmente para disfrutar de sus ventajas.

Para ello, en Chrome tendremos que escribir en la barra de búsqueda: «chrome://flags» (banderas en inglés), y habilitar estos tres comandos:

  • Habilitar ‘encrypted-client-hello (todo en inglés, ya sabes…)
  • Habilitar ‘dns-https-svcb
  • Habilitar ‘use-dns-https-svcb-alpn

Por último, y ya como recomendación personal, cambiaría en los ajustes de Chrome > Privacidad y Seguridad > Seguridad, la opción de «Usar DNS seguro» en vez del que viene por defecto, que es el que nos suministra la propia operadora, y cambiarlo al de CloudFlare o al de OpenDNS.

Solo con esto ya podremos visitar la mayoría de páginas y servicios online que por el motivo que sea (considera que tiene contenido ilegal, por ejemplo) la operadora ha decidido bloquear. Y, para colmo, seguramente hasta notaremos una mejora en la velocidad de navegación.

Te dejo por aquí un enlace a un tutorial en el que explico cómo cambiar las DNS en cualquier sistema operativo y navegador.

Dicho esto, turno para tí:

  • ¿Conocías de la existencia de ECH y la importancia que tiene para la privacidad de nuestras comunicaciones?
  • ¿Usabas hasta ahora, o eras consciente, de los riesgos que supone usar las DNS que nos dan por defecto nuestra operadora de telecomunicaciones?

Te leo en comentarios.

Sobre el videopodcast enCLAVE DIGITAL

enCLAVE DIGITAL es el videopodcast de Pablo F. Iglesias, consultor de presencia digital y reputación online.

Si este contenido te sirve para estar bien informado sobre la actualidad en materia de negocios digitales, reputación y tecnología, te agradecería que le dieras a suscribirte en mi canal de Youtube o en la plataforma de podcasting desde donde me escuchas, le des a Me Gusta, me dejes un comentario o reseña y lo compartas con aquellos a los que les pueda interesar.

¡Seguimos!

Si utilizas otra plataforma de podcasting, busca «enCLAVE DIGITAL« en la app para localizarlo, o visita la página del videopodcast, donde ofrezco enlaces directos a las principales plataformas actuales: