Acaba de surgir la noticia de que Apple, Cloudflare, Fastly y Mozilla han estado colaborando para mejorar el cifrado del mecanismo de identificación del nombre del servidor de HTTPS en el IETF 102 Hackathon, como lo indica un tweet de Nick Sullivan de Cloudflare. El tweet felicitó al equipo de mezcla de los cuatro gigantes tecnológicos diciendo 'Un trabajo increíble' y compartiéndolo en los enlaces a los servidores en funcionamiento en esni.examp1e.net y cloudflare-esni.com .
Impresionante trabajo en el hackathon IETF 102 realizado por el equipo SNI encriptado que consta de gente de @Cloudflare @rapidamente @mozilla y @manzana . Ahora hay implementaciones en BoringSSL, NSS y picotls.
Los servidores en funcionamiento están activos en https://t.co/sLI9xLRjlK y https://t.co/AoC2SIlJ7N .
- Nick Sullivan (@grittygrease) 15 de julio de 2018
El IETF Hackathon es una plataforma que invita a los desarrolladores jóvenes y entusiastas de la tecnología a unirse en la redacción de soluciones para problemas relacionados con la tecnología que enfrenta el usuario común en la actualidad. Los eventos son gratuitos, abiertos a todos y fomentan el trabajo en equipo en lugar de la competencia. El IETF Hackathon de este año se celebró en Montreal el 14thy 15thde julio. El logro más destacado que se ha obtenido, al parecer, es el cifrado de la Indicación de nombre del servidor (SNI) de Transport Layer Security (TLS), un problema que ha plagado a los desarrolladores durante la última década, uno que los miembros de Apple, Cloudflare, Fastly , y Mozilla ahora ha propuesto una solución para.
Evento IETF Hackathon. IETF
Ha habido un cambio global claro del Protocolo de transferencia de hipertexto (HTTP) al Protocolo de transferencia de hipertexto seguro (TLS SNI HTTPS) de indicación de nombre del servidor de seguridad de la capa de transporte en la última década y media. los problema lo que surgió de la optimización del sistema TLS SNI HTTPS fue la capacidad del hacker de usar SNI en contra de su propósito de hacer coincidir la transferencia de datos para descifrarlos más tarde.
Antes del desarrollo de SNI, era difícil establecer conexiones seguras a varios servidores virtuales utilizando el mismo primer protocolo de enlace del cliente. Cuando una dirección IP interactuó con un servidor, los dos intercambiaron 'saludos', el servidor envió sus certificados, la computadora envió su clave de cliente, los dos intercambiaron comandos 'ChangeCipherSpec' y luego la interacción terminó cuando se estableció una conexión. Esto puede parecer fácil de la forma en que se acaba de decir, pero el proceso involucró múltiples intercambios y respuestas que fácilmente se volvieron bastante problemáticos a medida que aumentaba la cantidad de servidores con los que se comunicaban. Si todos los sitios usaban los mismos certificados, entonces esto no era un gran problema, pero desafortunadamente ese rara vez era el caso. Cuando varios sitios enviaban varios certificados de un lado a otro, era difícil para el servidor determinar qué certificado estaba buscando la computadora y, en la compleja red de intercambios, era difícil identificar quién envió qué y cuándo, terminando así toda la actividad. con un mensaje de advertencia por completo.
TLS SNI se introdujo en junio de 2003 a través de una cumbre de IETF y el propósito que sirvió, en cierto sentido, fue crear etiquetas de nombre para las computadoras y servicios involucrados en la web de intercambio. Esto hizo que el proceso de intercambio de saludo servidor-cliente fuera mucho más sencillo, ya que el servidor pudo proporcionar los certificados exactos necesarios y los dos pudieron tener su propio intercambio de conversación sin confundirse acerca de quién dijo qué. Es un poco como tener nombres de contacto para los chats y no confundirse en cuanto a la procedencia de los mensajes, y también poder responder a cada consulta de manera adecuada, proporcionando los documentos correctos a cualquier computadora que los necesite. Esta definición de SNI es exactamente lo que provocó el mayor problema con este método de optimización del proceso de intercambio.
La lucha que enfrentaron muchas empresas al cambiar a HTTPS fue la adaptación de muchos certificados al formato SNI con direcciones IP individuales para realizar solicitudes para cada certificado. Lo que TLS hizo por ellos fue simplificar la generación de certificados para responder a tales solicitudes y lo que SNI hizo aún más fue eliminar la necesidad de direcciones IP de certificados dedicadas individualizadas al incorporar un sistema de identificación completo en toda la red de Internet. Lo que vino con la actualización del siglo fue el hecho de que permitió a los piratas informáticos usar los 'nombres de contacto' establecidos para monitorear y ocultar la transferencia de datos y extraer la información que necesitan para descifrar en una etapa posterior.
Aunque TLS permitía que los datos se enviaran de un lado a otro en un canal cifrado, con SNI asegurando que llegara al destino correcto, este último también proporcionó medios para que los piratas informáticos monitorearan la actividad en línea y la relacionaran con su fuente siguiendo las solicitudes de DNS, direcciones IP y flujos de datos. Aunque se han implementado políticas de codificación SNI más estrictas al pasar información de DNS a través del canal TLS también, queda una pequeña ventana para que los piratas informáticos puedan usar esto como un medio de identificación para seguir la información que les gustaría extraer y aislar. descifrado. Los servidores complejos que se ocupan de un mayor tráfico de datos cifrados TLS utilizan SNI de texto sin formato para enviar la comunicación en sus servidores y esto es lo que hace que sea más fácil para los piratas informáticos identificar los canales y flujos de información que quieren seguir. Una vez que un pirata informático puede extraer la información SNI de los datos de interés, puede configurar una reproducción falsa del comando en una conexión TLS separada con el servidor, enviando la información SNI robada y recuperando la información que estaba asociado con él. Ha habido varios intentos de resolver este problema de SNI en el pasado, pero la mayoría ha ido en contra del principio de simplicidad con el que opera SNI para convertirlo en un método de identificación conveniente para los servidores.
Volviendo a la cumbre que trabajó por primera vez para establecer este método, los participantes de cuatro gigantes tecnológicos han regresado a la conferencia en Montreal para desarrollar un cifrado para TLS SNI porque a pesar de la mayor eficiencia en el sistema contiguo multi HTTPS, la seguridad sigue siendo una preocupación. tanto como lo hizo antes.
Para ocultar el SNI en TLS, se debe mantener un 'Servicio oculto' bajo la apariencia de un 'Servicio frontal' que el pirata informático puede ver. Sin poder observar directamente el servicio oculto, el pirata informático se equivocará con el disfraz de fachada bajo el que se esconde en texto plano sin poder identificar los parámetros del servicio secreto subyacente utilizados para transmitir los datos cifrados. A medida que el observador sigue el rastro del servicio frontal, los datos se eliminarán del canal observado a medida que se redirigen a su servicio oculto previsto, momento en el que el pirata informático habrá perdido su rastro. Dado que el servidor también estará expuesto al servicio frontal, a medida que los datos lleguen hasta allí, se enviará una segunda señal SNI paralela al servicio frontal para redirigir los datos hacia el servicio oculto y en este proceso de cambio de dirección, el hacker perderse en la web del servidor. Este mecanismo de billetes dobles se desarrolla aún más en un billete combinado bajo el mismo SNI. A medida que se envía un dato al servidor, los datos producen un re-director SNI cooperante y los dos trabajan en conjunto para llevar los datos cifrados TLS a donde deben ir. Sin poder descifrar el servicio de fronting aleatorio que cubre ambas pistas SNI, el hacker no podrá seguir el rastro de los datos, pero el servidor aún podrá conectar los dos y descifrar el servicio oculto como la ubicación final de los datos. Esto permite que los servidores continúen usando SNI para optimizar su transferencia de datos en el cifrado TLS mientras se asegura que los piratas informáticos no puedan aprovechar el mecanismo SNI.
