¿Están cifradas las URL HTTPS?
¿Se cifran todas las URL cuando se utiliza el cifrado TLS/SSL (HTTPS)? Me gustaría saberlo porque quiero que todos los datos de URL estén ocultos cuando uso TLS/SSL (HTTPS).
Si TLS/SSL ofrece cifrado total de URL, entonces no tengo que preocuparme por ocultar información confidencial de las URL.
Sí, la conexión SSL es entre la capa TCP y la capa HTTP. El cliente y el servidor primero establecen una conexión TCP cifrada segura (a través del protocolo SSL/TLS) y luego el cliente enviará la solicitud HTTP (GET, POST, DELETE...) a través de esa conexión TCP cifrada.
Sin embargo, tenga en cuenta (como también se indica en los comentarios) que la parte del nombre de dominio de la URL se envía en texto sin cifrar durante la primera parte de la negociación TLS. Por lo tanto, se puede rastrear el nombre de dominio del servidor. Pero no el resto de la URL.
Como nadie proporcionó una captura por cable, aquí hay una.
El nombre del servidor (la parte del dominio de la URL) se presenta en el ClientHellopaquete, en texto sin formato .
A continuación se muestra una solicitud del navegador para:
https://i.stack.imgur.com/path/?some=parameters&go=here
Consulte esta respuesta para obtener más información sobre los campos de versión de TLS (hay 3 de ellos, no versiones, ¡campos que contienen cada uno un número de versión!)
De https://www.ietf.org/rfc/rfc3546.txt :
3.1. Indicación del nombre del servidor
[TLS] no proporciona un mecanismo para que un cliente le diga a un servidor el nombre del servidor con el que se está comunicando. Puede ser conveniente que los clientes proporcionen esta información para facilitar conexiones seguras a servidores que alojan múltiples servidores "virtuales" en una única dirección de red subyacente.
Para proporcionar el nombre del servidor, los clientes PUEDEN incluir una extensión de tipo "server_name" en el saludo del cliente (extendido).
En breve:
FQDN (la parte del dominio de la URL) PUEDE transmitirse sin cifrar dentro del
ClientHellopaquete si se utiliza la extensión SNIEl resto de la URL (
/path/?some=parameters&go=here) no tiene por qué estar dentro,ClientHelloya que la URL de solicitud es un elemento HTTP (Capa 7 de OSI), por lo que nunca aparecerá en un protocolo de enlace TLS (Capa 4 o 5). Esto vendrá más adelante en unaGET /path/?some=parameters&go=here HTTP/1.1solicitud HTTP, DESPUÉS de que se establezca el canal TLS seguro .
RESUMEN EJECUTIVO
El nombre de dominio PUEDE transmitirse sin cifrar (si se utiliza la extensión SNI en el protocolo de enlace TLS), pero la URL (ruta y parámetros) siempre está cifrada.
ACTUALIZACIÓN DE MARZO DE 2019
Gracias carlin.scott por mencionar este.
La carga útil en la extensión SNI ahora se puede cifrar a través de este borrador de propuesta RFC . Esta capacidad solo existe en TLS 1.3 (como opción y depende de ambos extremos implementarla) y no hay compatibilidad con versiones anteriores de TLS 1.2 y versiones anteriores.
CloudFlare lo está haciendo y puedes leer más sobre los aspectos internos aquí: si la gallina debe ir antes que el huevo, ¿dónde pones la gallina?
En la práctica, esto significa que en lugar de transmitir el FQDN en texto plano (como muestra la captura de Wireshark), ahora está cifrado.
NOTA: Esto aborda el aspecto de privacidad más que el de seguridad, ya que una búsqueda DNS inversa PUEDE revelar el host de destino deseado de todos modos.
ACTUALIZACIÓN DE SEPTIEMBRE DE 2020
Ahora existe un borrador de RFC para cifrar todo el mensaje de saludo del cliente, no solo la parte SNI: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1
Al momento de escribir este artículo, el soporte de este navegador es MUY limitado.
Como ya han señalado las otras respuestas , las "URL" https están cifradas. Sin embargo, su solicitud/respuesta de DNS al resolver el nombre de dominio probablemente no lo sea y, por supuesto, si estuviera usando un navegador, es posible que sus URL también se registren.
