Cloudflare se lanzó el 27 de septiembre de 2010. Desde entonces, hemos considerado el 27 de septiembre nuestro cumpleaños. Este jueves cumplimos 8 años de edad.
Desde nuestro primer cumpleaños, hemos aprovechado la ocasión para lanzar nuevos productos o servicios. Con los años, llegamos a la conclusión de que la manera correcta de celebrar nuestro cumpleaños no era lanzar productos con los que ganar dinero, sino hacerles regalos a nuestros usuarios y a Internet en general. Mi cofundador Michelle escribió ayer sobre esta tradición en una publicación estupenda del blog.
Personalmente, uno de los momentos de mayor orgullo para mí en Cloudflare fue nuestro cumpleaños de 2014, cuando hicimos que el soporte de HTTPS fuera gratis para todos nuestros usuarios. Entones, la gente decía que estábamos locos, literalmente y con insistencia. Francamente, hubo debates internos importantes sobre si lo estábamos, ya que la encriptación era la razón principal por la que la gente actualizaba las cuentas gratuitas a cuentas de pago.
Pero era lo correcto. El hecho de que la encriptación no se hubiera integrado en la web desde el principio era, en nuestra opinión, un error. Hoy, casi exactamente cuatro años más tarde, la web está cifrada aproximadamente en un 80 %, gracias al liderazgo de grandes proyectos como Let's Encrypt, los equipos de navegadores de Google, Apple, Microsoft y Mozilla, y el hecho de que cada vez más proveedores de hosting y SaaS hayan incorporado soporte para HTTPS sin coste alguno. Me enorgullece el hecho de que lideráramos las contribuciones para iniciar esa tendencia.
Hoy es otro día del que espero estar orgulloso cuando mire atrás, porque hoy queremos contribuir a iniciar una nueva tendencia para hacer la web cifrada más privada y segura. Para entenderlo, hay que entender un poco por qué la web cifrada que existe hoy todavía filtra buena parte de tu historial de navegación.
¿Cómo de privado es tu historial de navegación?
La expectativa cuando visitas un sitio web mediante HTTPS es que nadie que escuche la línea entre tú y el sitio donde termina la conexión pueda ver lo que estás haciendo. Y hasta cierto punto, es así. Si visitas el sitio web de tu banco, HTTPS mantiene eficazmente los contenidos enviados al sitio o desde él (por ejemplo, tu nombre de usuario y contraseña o el saldo de tu cuenta bancaria) para que no se filtren a tu proveedor de Internet o a cualquiera que vigile tu conexión de red.
Mientras que los contenidos enviados o recibidos desde un sitio HTTPS están protegidos, el hecho de que has visitado el sitio se puede observar fácilmente de un par de maneras. Tradicionalmente, una de ellas ha sido el DNS (Domain Name System, en español, sistema de nombres de dominios). Las consultas del DNS están, por defecto, sin cifrar, así que tu proveedor de Internet o cualquier otra persona pueden ver adónde vas en línea. Por eso, el pasado abril, lanzamos 1.1.1.1 un resolutor público DNS gratuito (y rápido como el rayo) compatible con el DNS mediante TLS (Transport Security Layer, en español, seguridad en la capa de transporte) y el DNS mediante HTTPS.
1.1.1.1 ha tenido un gran éxito y hemos aumentado significativamente el porcentaje de consultas de DNS enviadas mediante una conexión cifrada. Los críticos, sin embargo, señalaron con razón que la identidad de los sitios que visitas todavía puede filtrarse de otras maneras. La más problemática es algo llamado la extensión del indicador del nombre de servidor (SNI, Server Name Indication en inglés).
¿Para qué sirve el SNI?
Fundamentalmente, el SNI existe para permitirte alojar muchos sitios web encriptados en una única dirección IP. Los primeros navegadores no incluían la extensión del SNI. Por ello, cuando se realizaba una solicitud para establecer una conexión HTTPS, el servidor web no tenía mucha información para continuar y solo podía devolver un certificado SSL por cada dirección IP con la que el servidor web se comunicara.
Una solución a este problema era crear certificados con muchos nombres alternativos del firmante (Subject Alternative Names o SAN por sus siglas en inglés). Estos certificados cifrarían el tráfico para varios dominios que podrían alojarse en la misma IP. Así es como Cloudflare gestiona el tráfico HTTPS de navegadores antiguos que no son compatibles con el SNI. Limitamos esa característica a nuestros clientes de pago, sin embargo, por la misma razón por la que los SAN no son una gran solución: hay que hacer modificaciones, son pesados de gestionar y pueden reducir rendimiento si incluyen demasiados dominios.
La solución más escalable era el SNI. La analogía que más me gusta es la de un sobre de correo postal. El contenido del sobre está protegido y no puede ser visto por el servicio de correos. Sin embargo, fuera del sobre está la dirección que el cartero usará para llevar el sobre al edificio correcto. En Internet, la dirección IP de un servidor web es el equivalente al nombre de la calle.
Sin embargo, si vives en un edificio con muchos pisos, el nombre de la calle no basta para llevar el sobre al destinatario correcto. Para complementar la dirección incluyes un número o el nombre del destinatario. Es el equivalente del SNI. Si un servidor web aloja varios dominios, el SNI garantiza que una solicitud se enrute al sitio correcto para que el certificado SSL adecuado se pueda devolver para poder encriptar y desencriptar cualquier contenido.
Redes cotillas
En 2003 el IETF (Internet Engineering Task Force o Grupo de Trabajo de Ingeniería de Internet) introdujo la especificación para el SNI y los navegadores introdujeron la compatibilidad en los años siguientes. Entonces, parecía una solución intermedia aceptable. La gran mayoría del tráfico de Internet estaba sin encriptar. Agregar una extensión TLS que facilitara el soporte al cifrado parecía un buen negocio incluso si la extensión en sí no estaba encriptada.
Pero hoy, como HTTPS cubre casi el 80 % de todo el tráfico web, el hecho de que el SNI filtre los sitios a los que vas a en línea a tu proveedor de Internet y a cualquiera que escuche en la línea se ha convertido en una grieta evidente de la privacidad. Saber qué sitios visitas puede crear una imagen muy precisa de quién eres y crear riesgos de seguridad y privacidad.
En los Estados Unidos, se restringió brevemente la capacidad de los proveedores de Internet para reunir datos de navegación del cliente, de acuerdo con las normas de la Comisión Federal de Comunicaciones aprobadas al final del mandato de Obama. Los proveedores de Internet, sin embargo, presionaron al Congreso y, en abril de 2017, el Presidente Trump firmó una resolución para derogar esa protección. A medida que los proveedores de Internet adquieren medios de comunicación y empresas de publicidad dirigida, la extracción de los datos de sus propios canales es un negocio cada vez más atractivo para ellos y una amenaza cada vez más preocupante para nuestra privacidad.
Cerrar la grieta de privacidad del SNI
El 3 de mayo, un mes después de que lanzáramos 1.1.1.1, yo estaba leyendo una reseña sobre nuestro nuevo servicio. Aunque el artículo elogiaba el hecho de que 1.1.1.1 se orientara a la privacidad, concluía con cierto nihilismo que todo era en vano porque los proveedores de Internet todavía podían espiarte siguiendo el SNI. Frustrado, escribí un apresurado correo a algunos ingenieros de Cloudflare y al equipo sénior de Mozilla, con quienes habíamos trabajado en un proyecto para encriptar el DNS. Mi correo concluía:
Mi documento de especificaciones técnicas resumido: si Firefox se conecta a una IP de Cloudflare, entonces te daríamos una clave pública para cifrar la entrada SNI antes de enviárnosla. ¿Cómo se escala esto a otros proveedores? Ni idea, pero tenemos que empezar por alguna parte. Consenso aproximado y código en ejecución, ¿verdad?
Al final la cosa era un poco más compleja que eso. Sin embargo, hoy me enorgullezco de anunciar que el SNI encriptado (ESNI) se ha lanzado en toda la red de Cloudflare. Esta semana esperamos que Firefox de Mozilla sea el primer navegador que soporte el nuevo protocolo en su versión Nightly. En los próximos meses, el plan es que se convierta en lo normal. Y no solo en Mozilla. Ha despertado un gran interés en los principales navegadores y tengo la esperanza de que añadan soporte para el ESNI con el tiempo.
Esperamos iniciar otra tendencia
Aunque somos los primeros compatibles con el ESNI, no lo hemos logrados solos. Hemos trabajado en el ESNI con grandes equipos de Apple, Fastly, Mozilla y otros del sector que, como nosotros, se preocupan por la privacidad en Internet. Cloudflare es la primera red de contenido que apoya el ESNI, no es un protocolo de propietario. Se está trabajando en él como un Borrador de RFC del IETF y esperamos que otros nos ayuden a formalizar el proyecto y también a implementar el estándar. Si te interesan los detalles técnicos del ESNI, puedes aprender más en esta estupenda publicación reciente en el blog hecha por mi colega Alessandro Ghedini. Por último, cuando el explorador comience a lanzarse esta semana, puedes probarlo con nuestra útil herramienta de prueba de ESNI.
Estoy orgulloso de que hace cuatro años contribuyéramos a iniciar una tendencia que hoy ha llevado a que casi toda la web esté cifrada. Hoy, espero que otra vez estamos contribuyendo a iniciar una tendencia, esta vez para hacer la web cifrada incluso más privada y segura.
Suscríbase al blog para actualizaciones diarias de todos nuestros anuncios de la semana de cumpleaños.