¿Es posible oler las URL de HTTPS? [duplicar]

TL; DR Un atacante no puede ver nada más allá del dominio.

Estructura de una solicitud HTTP

HTTP funciona enviando dos cosas a un sitio web: el método , y el headers . Los métodos más comunes son GET , POST y HEAD , que recupera una página, transfiere datos o solicita solo encabezados de respuesta, respectivamente. TLS cifra la totalidad del tráfico HTTP, incluidos los encabezados y el método. En HTTP, la ruta en la URL se envía junto con el cuerpo del encabezado. Tome este ejemplo, con wget cargando la página foo.example.com/some/page.html :

GET /some/page.html HTTP/1.1
User-Agent: Wget/1.19.1 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: foo.example.com

El servidor responderá con un HTTP código de estado , algunos headers propios , y opcionalmente algunos datos (como HTML). Un ejemplo, dando una redirección 301 y un texto simple como respuesta, puede ser:

HTTP/1.1 301 Moved Permanently
Date: Wed, 27 Dec 2017 04:42:54 GMT
Server: Apache
Location: https://bar.example.com/new/location.html
Content-Length: 56
Content-Type: text/plain

Thank you Mario, but our princess is in another castle!

Lo que le diría al cliente que la ubicación correcta está en otro lugar.

Estos son los encabezados enviados directamente al sitio a través de TCP. TLS funciona en una capa diferente, haciendo todo esto encriptado. Esto incluye la página a la que está accediendo con el método GET . Tenga en cuenta que, aunque el encabezado Host también se encuentra en el cuerpo del encabezado y, por lo tanto, está cifrado, el host todavía se puede obtener a través de rDNS busque en la dirección IP, o marcando SNI , que transmite el dominio en texto sin formato.

Estructura de una URL

https://foo.example.com/some/page.html#some-fragment
| proto |    domain    |     path     |  fragment  |

• proto : solo hay dos protocolos de uso común, HTTP y HTTPS.
• domain : el dominio es example.com y *.example.com , detectable con rDNS o SNI.
• ruta : la ruta está completamente encriptada y solo puede ser leída por el servidor de destino.
• fragmento : el fragmento es visible solo para el navegador web y no se transmite.

Lo que un atacante puede ver

Entonces, ¿qué puede ver un atacante si realiza una solicitud a través de HTTPS? Tomemos la solicitud hipotética anterior desde la perspectiva de un intruso pasivo en la red. Si quisiera saber a qué está accediendo, solo tengo opciones limitadas:

• Veo que estás realizando una solicitud web cifrada con HTTPS que va a 203.0.113.98 .
• Veo que el puerto de destino es 443, que sé que se usa para HTTPS.
• Realizo una búsqueda rDNS y veo que se usa IP para example.com y example.org .
• Miro el registro SNI y veo que te estás conectando a foo.example.com .

Esto es todo lo que pude hacer. No podría ver la ruta que está solicitando, ni siquiera qué método está utilizando, salvo el análisis heurístico basado en el tamaño de los datos que se envían y reciben, llamados ataques de análisis de tráfico . Para un servicio grande como Wikipedia, no tengo idea de qué artículo está viendo solo por el análisis de los datos no cifrados.

Una nota importante sobre los remitentes en navegadores antiguos

A pesar de que HTTPS cifra la ruta a la que está accediendo, si hace clic en un hipervínculo dentro de ese sitio que va a una página sin cifrar, la ruta completa se puede filtrar en el encabezado referer . Esto es ya no es el caso para muchos navegadores más nuevos, pero los navegadores más antiguos o no compatibles pueden tener este comportamiento. al igual que los sitios web que configuran la metaetiqueta de referencia HTML5 para enviar siempre la información. Un ejemplo enviado sin cifrar por un cliente para saltar de https://example.com/private/details.html a http://example.org/public/page.html en tal caso sería:

GET /public/page.html
Referer: https://example.com/private/details.html
User-Agent: Wget/1.19.1 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: example.org

Como tal, navegar desde una página HTTPS a una página HTTP puede filtrar la URL completa (excluyendo el fragmento) de la página anterior, así que ten eso en cuenta.

La respuesta ingenua es no: la URL está cifrada en la secuencia TLS. Pero esa respuesta ignora una gran cantidad de información relevante.

Supongamos que es Wikipedia. ¿Por cuánto tiempo es una solicitud HTTP GET para https://en.wikipedia.org/wiki/Cryptography versus https://en.wikipedia.org/wiki/Information_security , asumiendo que todos los campos de encabezado son los mismos? Si puede medir la longitud de una solicitud, que probablemente se enviará en un solo registro TLS, entonces probablemente pueda diferenciarlas.

Eso no le ayuda a distinguir una solicitud para el artículo sobre criptografía del artículo sobre coreografía, por supuesto. Tampoco ayuda si el cliente TLS agrega hábilmente algún relleno, ignorado por el servidor, al registro TLS para redondearlo a un múltiplo de algún tamaño de bloque. Pero la Wikipedia en inglés tiene un artículo mucho más largo sobre criptografía que sobre coreografía. Entonces, incluso si los puntos finales rellenan sus registros TLS hasta un máximo de 16384 bytes, probablemente pueda distinguir el artículo sobre criptografía del artículo sobre coreografía.

Hay una complicación desde su perspectiva como atacante: el cliente puede usar la misma transmisión TLS para muchas solicitudes y muchas respuestas. Pero es probable que todos se cronometren en una ráfaga mientras la víctima carga una sola página con CSS incorporado, imágenes, JavaScript, etc. , y luego se queda en silencio mientras la víctima lee la página. El tiempo y el número de estas solicitudes proporciona otra variable en la que puede discriminar qué página estaban buscando.

Todas estas variables pueden incluirse en un modelo probabilístico de páginas— aquí hay un ejemplo , extraído de la < a href="https://www.freehaven.net/anonbib/" title="Free Haven's Selected Papers in Anonymity"> bibliografía de anonimato . Derrotar ese ejemplo no significa que la distribución de datos que un atacante en la red aprende para una página es indistinguible de otra página, solo que ese distintivo en particular no es tan efectivo.

Por lo tanto, , como el espía, se garantiza para poder leer la URL de forma remota. No: está cifrado en el flujo TLS (¡a menos que se elija el cifrado NULL!), Por lo que, como mucho, puede inferirlo de otras variables observables con dependencias probabilísticas en él.

Por otra parte, ¿la víctima garantiza que su URL está oculta a un intruso? No: hay muchas variables que dependen de la URL de la cual un atacante puede inferir información importante, como la enfermedad de transmisión sexual sobre la cual estás leyendo en la Clínica Mayo.

(Tenga en cuenta que cualquier cosa en el fragmento de una URL, la parte después de la marca # en https://en.wikipedia.org/wiki/Cryptography#Terminology , no se transmite en la solicitud HTTP GET, a menos que haya alguna secuencia de comandos en la página que desencadena un tráfico de red diferente según el fragmento de URL.)

La URL como usted dice está dentro de los encabezados HTTP que están, como el cuerpo HTTP, dentro del flujo TLS, lo que significa que están cifrados. Puede obtener el nombre del servidor rastreando las solicitudes de DNS antes de la solicitud de HTTPS, pero es posible que no obtenga resultados, si el nombre ya está en el caché local, por ejemplo.

La URL también se cifra mientras utiliza el método de comunicación TLS. No hay forma de averiguar el contenido o la URL del recurso mediante la detección del tráfico seguro HTTPS. Pero aún así, las mejores prácticas de seguridad recomiendan no enviar ninguna información confidencial a través de cadenas de consulta HTTP. El motivo es que se puede almacenar en caché en su navegador o iniciar sesión en sus servidores.