¿Están encriptadas las URL HTTPS?


1021

¿Se encriptan todas las URL cuando se usa el cifrado TLS / SSL (HTTPS)? Me gustaría saberlo porque quiero que todos los datos de URL estén ocultos cuando utilizo TLS / SSL (HTTPS).

Si TLS / SSL le proporciona un cifrado total de URL, entonces no tengo que preocuparme por ocultar información confidencial de las URL.


76
Probablemente sea una mala idea poner datos confidenciales en la URL de todos modos. También se mostrará en la dirección del navegador incorrecta, ¿recuerdas? A la gente no le gusta si su contraseña es visible para cualquiera que mire la pantalla. ¿Por qué crees que necesitas poner datos confidenciales en la URL?
jalf

43
Las URL también se almacenan en el historial del navegador y en los registros del servidor; si quisiera tener mi nombre y contraseña almacenados en algún lugar, no sería en estos dos lugares.
Piskvor salió del edificio el

47
Por ejemplo, supongamos que visito https://somewhere_i_trust/ways_to_protest_against_the_government/. Luego, la URL contiene datos confidenciales, es decir, la sugerencia de que estoy considerando protestar contra mi gobierno.
Steve Jessop

42
Me hacía esta pregunta al hacer una solicitud HTTP desde una aplicación nativa (no basada en navegador). Supongo que esto puede interesar a los desarrolladores de aplicaciones móviles. En este caso, los comentarios anteriores (aunque verdaderos) son irrelevantes (no hay URL visible, no hay historial de navegación), lo que hace que la respuesta, a mi entender, sea simple: "Sí, está encriptada".
DannyA

23
Para aquellos que piensan que una vez que son HTTPS, nadie sabe a dónde van, lea esto primero: el nombre de host del servidor (por ejemplo, example.com) aún se filtrará debido a SNI . Esto no tiene absolutamente nada que ver con DNS y la fuga ocurrirá incluso si no usa DNS o usa DNS cifrado.
Pacerier

Respuestas:


913

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.


98
Todavía vale la pena señalar lo mencionado por @Jalf en el comentario sobre la pregunta en sí. Los datos de URL también se guardarán en el historial del navegador, que puede ser inseguro a largo plazo.
Michael Ekstrand

20
No solo OBTENER o PUBLICAR. También puede ser DELETE, PUT, HEAD o TRACE.

44
Sí, podría ser un problema de seguridad para el historial de un navegador. Pero en mi caso no estoy usando el navegador (también la publicación original no mencionaba un navegador). Usando una llamada https personalizada detrás de escena en una aplicación nativa. Es una solución simple para asegurarse de que la conexión de servidor de su aplicación sea segura.
zingle-dingle

28
Sin embargo, tenga en cuenta que la resolución DNS de la URL probablemente no esté encriptada. Por lo tanto, alguien que detecte su tráfico aún podría ver el dominio al que intenta acceder.
ChewToy

21
SNI rompe la parte 'host' del cifrado SSL de las URL. Puede probar esto usted mismo con wireshark. Hay un selector para SNI, o simplemente puede revisar sus paquetes SSL cuando se conecta al host remoto.
cmouse

654

Como nadie proporcionó una captura de 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

ClienteHola SNI 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 un número de versión!)

Desde 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 al que está contactando. Puede ser deseable que los clientes proporcionen esta información para facilitar conexiones seguras a servidores que alojan múltiples servidores 'virtuales' en una sola dirección de red subyacente.

Para proporcionar el nombre del servidor, los clientes PUEDEN incluir una extensión de tipo "nombre_servidor" en el saludo del cliente (extendido).


En breve:

  • El FQDN (la parte del dominio de la URL) PUEDE transmitirse en claro dentro del ClientHellopaquete si se usa la extensión SNI

  • El resto de la URL ( /path/?some=parameters&go=here) no tiene ClientHellopor qué estar dentro ya que la URL de solicitud es una cosa HTTP (OSI Layer 7), por lo tanto, nunca aparecerá en un protocolo de enlace TLS (Layer 4 o 5). Eso vendrá más adelante en una GET /path/?some=parameters&go=here HTTP/1.1petición HTTP, después el seguro se establece canal TLS.


RESUMEN EJECUTIVO

El nombre de dominio PUEDE transmitirse en claro (si se usa la extensión SNI en el protocolo de enlace TLS) pero la URL (ruta y parámetros) siempre está encriptada.


ACTUALIZACIÓN MARZO 2019

Gracias carlin.scott por mencionar esto.

La carga útil en la extensión SNI ahora se puede cifrar a través de este borrador de propuesta de RFC . Esta capacidad solo existe en TLS 1.3 (como una opción y depende de ambos extremos implementarla) y no hay compatibilidad con TLS 1.2 y versiones anteriores.

CloudFlare lo está haciendo y puedes leer más sobre las partes internas aquí. Si el pollo debe venir antes que el huevo, ¿dónde lo pones?

En la práctica, esto significa que en lugar de transmitir el FQDN en texto plano (como muestra la captura de Wireshark), ahora está encriptado.

NOTA: Esto aborda el aspecto de privacidad más que el de seguridad ya que una búsqueda inversa de DNS PUEDE revelar el host de destino previsto de todos modos.


37
Respuesta perfecta, con una explicación completa de la A a la Z. Me encanta el resumen ejecutivo. Made my day @evilSnobu
oscaroscar

44
¡Respuesta perfecta, voto a favor! Todavía considere la parte del cliente ya que el historial del navegador puede ser una fuga. Sin embargo, con respecto a la capa de transporte, los parámetros de URL están encriptados.
Jens Kreidler

2
Es posible que desee actualizar esta respuesta con el hecho de que TLS 1.3 encripta la extensión SNI, y el CDN más grande está haciendo exactamente eso: blog.cloudflare.com/encrypted-sni Por supuesto, un rastreador de paquetes podría hacer una búsqueda inversa. las direcciones IP a las que te estás conectando.
carlin.scott

@evilSnobu, pero nombre de usuario: contraseña parte del nombre de usuario: contraseña@dominio.com está encriptada, ¿verdad? Por lo tanto, es seguro pasar datos confidenciales en url usando https.
Maksim Shamihulau

1
Están encriptados en el cable (en transporte) pero si cualquiera de los dos (usuario o servidor) registra la URL en un archivo de texto sin formato y no desinfecta las credenciales ... ahora esa es una conversación diferente.
evilSnobu

159

Como las otras respuestas ya han señalado, las "URL" https están encriptadas. Sin embargo, su solicitud / respuesta de DNS al resolver el nombre de dominio probablemente no lo sea, y por supuesto, si estaba usando un navegador, sus URL también podrían registrarse.


21
Y la grabación de URL es importante ya que hay hacks de Javascript que permiten que un sitio completamente no relacionado pruebe si una URL determinada está en su historial o no. Puede hacer que una URL sea incuestionable al incluir una cadena aleatoria larga, pero si es una URL pública, el atacante puede decir que ha sido visitada, y si tiene un pequeño secreto, entonces un atacante podría forzar a velocidad razonable
Steve Jessop

8
@SteveJessop, proporcione un enlace a "Hacks de Javascript que permiten que un sitio completamente no relacionado pruebe si una URL determinada está en su historial o no"
Pacerier

66
@Pacerier: piratea la fecha, por supuesto, pero de lo que estaba hablando en ese momento era de cosas como stackoverflow.com/questions/2394890/… . En 2010 fue un gran problema que se investigaran estos problemas y se refinaran los ataques, pero realmente no lo estoy siguiendo en este momento.
Steve Jessop

2
@Pacerier: más ejemplos: webdevwonders.com/… , webdevwonders.com/…
Steve Jessop

1
Puede usar OpenDNS con su servicio de DNS encriptado. Lo uso en mi Mac, pero encontré que la versión de Windows no funciona correctamente. Sin embargo, eso fue hace un tiempo, por lo que podría funcionar bien ahora. Para Linux, nada todavía. opendns.com/about/innovations/dnscrypt
SPRBRN

101

Toda la solicitud y respuesta está encriptada, incluida la URL.

Tenga en cuenta que cuando utiliza un proxy HTTP, conoce la dirección (dominio) del servidor de destino, pero no conoce la ruta solicitada en este servidor (es decir, la solicitud y la respuesta siempre están cifradas).


1
La totalidad de la solicitud. El nombre de host se envía en claro. Todo lo demás está encriptado.
Sam Sirry

98

Estoy de acuerdo con las respuestas anteriores:

Para ser explícito:

Con TLS, la primera parte de la URL ( https://www.example.com/ ) todavía es visible a medida que crea la conexión. La segunda parte (/ herearemygetparameters / 1/2/3/4) está protegida por TLS.

Sin embargo, hay varias razones por las cuales no debe poner parámetros en la solicitud GET.

Primero, como ya mencionaron otros: - fuga a través de la barra de direcciones del navegador - fuga a través del historial

Además de que tiene una fuga de URL a través del árbitro http: el usuario ve el sitio A en TLS, luego hace clic en un enlace al sitio B. Si ambos sitios están en TLS, la solicitud al sitio B contendrá la URL completa del sitio A en El parámetro de referencia de la solicitud. Y el administrador del sitio B puede recuperarlo de los archivos de registro del servidor B.)


3
@EJP No entendiste lo que dice Tobias. Está diciendo que si hace clic en un enlace en el sitio A que lo llevará al sitio B, entonces el sitio B obtendrá la URL de referencia. Por ejemplo, si está en siteA.com?u=username&pw=123123 , entonces siteB.com (que está vinculado en la página de siteA.com) recibirá " siteA.com?u=username&pw=123123 " como referencia URL, enviada a siteB.com dentro del HTTPS por el navegador. Si esto es cierto, eso es muy malo. ¿Es esto cierto Tobias?
trusktr

99
@EJP, el dominio es visible debido a SNI que utilizan todos los navegadores web modernos. También vea este diagrama del EFF que muestra que cualquiera puede ver el dominio del sitio que está visitando. No se trata de la visibilidad del navegador. Se trata de lo que es visible para los espías.
Buge

10
@trusktr: los navegadores no deben enviar un encabezado Referer desde las páginas HTTPS. Esto es parte de la especificación HTTP .
Martin Geisler

8
@MartinGeisler, la palabra clave es "debería". A los navegadores no les importa mucho "debería" (en oposición a "debe"). Desde su propio enlace: "se recomienda encarecidamente que el usuario pueda seleccionar si se envía o no el campo Referer. Por ejemplo, un cliente de navegador podría tener un interruptor para navegar abierta / anónimamente, lo que permitiría / deshabilitaría el envío de Referente y De información " . Ops, que es exactamente lo que hizo Chrome. Excepto que Chrome pierde el Referente incluso si está en modo incógnito .
Pacerier

48

Una adición a la útil respuesta de Marc Novakowski: la URL se almacena en los registros del servidor (por ejemplo, en / etc / httpd / logs / ssl_access_log), por lo que si no desea que el servidor mantenga la información durante más tiempo término, no lo pongas en la URL.


34

Si y no.

La parte de la dirección del servidor NO está encriptada ya que se usa para configurar la conexión.

Esto puede cambiar en el futuro con SNI y DNS encriptados, pero a partir de 2018, ambas tecnologías no se usan comúnmente.

La ruta, la cadena de consulta, etc. están encriptados.

Tenga en cuenta que para las solicitudes GET, el usuario aún podrá cortar y pegar la URL de la barra de ubicación, y probablemente no querrá poner información confidencial allí que pueda ver cualquiera que mire la pantalla.


8
Me gustaría hacer +1 en esto, pero creo que el "sí y no" es engañoso: debe cambiar eso para señalar que el nombre del servidor se resolverá usando DNS sin cifrado.
Lawrence Dol el

77
Según tengo entendido, el OP utiliza la palabra URL en el sentido correcto. Creo que esta respuesta es más engañosa, ya que claramente no hace la diferencia entre el nombre de host en la URL y el nombre de host en la resolución DNS.
Guillaume

44
La URL está encriptada. Cada aspecto de la transacción HTTP está encriptado. No solo 'todo lo demás'. Período. -1.
Marqués de Lorne

44
@EJP pero la búsqueda de DNS hace uso de lo que está en una parte punto de la URL, por lo que la persona no técnica, la dirección URL no están cifrados. La persona no técnica que simplemente usa Google.com para buscar cosas no técnicas no sabe dónde residen los datos o cómo se manejan. El dominio, que es parte de la URL que visita el usuario, no está 100% cifrado porque yo, como atacante, puedo oler qué sitio está visitando. Solo la ruta / de una URL está encriptada inherentemente al lego (no importa cómo).
trusktr

66
@EJP, @ trusktr, @ Lawrence, @ Guillaume. Todos ustedes están equivocados. Esto no tiene nada que ver con DNS. SNI " envía el nombre del dominio virtual como parte de la negociación de TLS ", por lo que incluso si no usa DNS o si su DNS está encriptado, un sniffer aún puede ver el nombre de host de sus solicitudes.
Pacerier

9

Un tercero que supervisa el tráfico también puede determinar la página visitada examinando su tráfico y comparándolo con el tráfico que otro usuario tiene cuando visita el sitio. Por ejemplo, si solo hubiera 2 páginas en un sitio, una mucho más grande que la otra, la comparación del tamaño de la transferencia de datos indicaría qué página visitó. Hay formas en que esto podría ocultarse a un tercero, pero no son comportamientos normales del servidor o del navegador. Consulte, por ejemplo, este documento de SciRate, https://scirate.com/arxiv/1403.0297 .

En general, otras respuestas son correctas, aunque prácticamente este documento muestra que las páginas visitadas (es decir, la URL) se pueden determinar de manera bastante efectiva.


Eso realmente solo sería factible en sitios muy pequeños, y en esos casos, el tema / tono / naturaleza del sitio probablemente seguiría siendo el mismo en cada página.
Cameron

55
De la cita que di: "Presentamos un ataque de análisis de tráfico contra más de 6000 páginas web que abarcan las implementaciones HTTPS de 10 sitios web líderes en la industria ampliamente utilizados en áreas como atención médica, finanzas, servicios legales y transmisión de video. Nuestro ataque identifica páginas individuales en el mismo sitio web con un 89% de precisión [...] ". Parece que su conclusión en cuanto a la viabilidad es incorrecta.
pbhj

2
Para cualquiera que esté interesado en leer más sobre este tipo de vulnerabilidad, estos tipos de ataques generalmente se denominan ataques de canal lateral .
Dan Bechard

7

Tampoco siempre puede contar con la privacidad de la URL completa. Por ejemplo, como suele ser el caso en las redes empresariales, los dispositivos suministrados como la PC de su empresa están configurados con un certificado raíz "confiable" adicional para que su navegador pueda confiar silenciosamente en una inspección proxy (intermediaria) del tráfico https . Esto significa que la URL completa está expuesta para inspección. Esto generalmente se guarda en un registro.

Además, sus contraseñas también están expuestas y probablemente registradas, y esta es otra razón para usar contraseñas de un solo uso o para cambiar sus contraseñas con frecuencia.

Finalmente, el contenido de la solicitud y la respuesta también se expone si no se cifra de otra manera.

Aquí, Checkpoint describe un ejemplo de la configuración de inspección . De esta manera, también se puede configurar un "cibercafé" de estilo antiguo con PC suministradas.


6

Vinculación a mi respuesta en una pregunta duplicada . La URL no solo está disponible en el historial de los navegadores, sino también en el registro del lado del servidor, sino que también se envía como encabezado HTTP Referer, que si utiliza contenido de terceros, expone la URL a fuentes fuera de su control.


Proporcionar sus llamadas de terceros también es HTTPS, aunque esto no es un problema, ¿verdad?
Liam

3
Se cifraría con el certificado de terceros para que pudieran ver la URL
JoshBerke

5

Ahora es 2019 y se lanzó el TLS v1.3. Según Cloudflare, el SNI se puede cifrar gracias a TLS v1.3. Entonces, me dije genial! veamos cómo se ve dentro de los paquetes TCP de cloudflare.com Entonces, capté un paquete de saludo de "cliente hola" de una respuesta del servidor cloudflare usando Google Chrome como navegador y cables de conexión como sniffer de paquetes. Todavía puedo leer el nombre del servidor en texto plano dentro del paquete de saludo del Cliente.

ingrese la descripción de la imagen aquí

Por lo tanto, tenga cuidado con lo que puede leer porque todavía no se trata de una conexión anónima. Un middleware entre el cliente y el servidor podría registrar cada dominio que solicite un cliente.

Por lo tanto, parece que el cifrado del SNI requiere implementaciones adicionales para funcionar junto con TLSv1.3

El siguiente artículo describe el cifrado del SNI proporcionado por Cloudflare como parte de TLSv1.3. Sin embargo, todas las URL de HTTP de cloudflare.com están en texto plano dentro del paquete TCP en TLS v1.3

[ https://blog.cloudflare.com/encrypted-sni/font>[3]


"el SNI se puede cifrar", ese es el punto clave. Al consultar cloudflare.com/ssl/encrypted-sni con Google Chrome actual, dice "Su navegador no cifró el SNI al visitar esta página". Se necesitan dos para
bailar

Aparentemente, Firefox actual puede hacer ESNI, pero está deshabilitado de forma predeterminada: debe habilitarlo network.security.esni.enabled, configurarlo network.trr.modeen 2 (que actualmente configura su resolución DoH en CloudFlare) y reiniciar el navegador (sic!); luego usará ESNI, donde sea compatible con la infraestructura del dominio. Ver blog.mozilla.org/security/2018/10/18/… para más detalles.
Piskvor salió del edificio el

2

Aunque ya hay algunas buenas respuestas aquí, la mayoría de ellas se centran en la navegación del navegador. Escribo esto en 2018 y probablemente alguien quiera saber sobre la seguridad de las aplicaciones móviles.

Para las aplicaciones móviles , si controla ambos extremos de la aplicación (servidor y aplicación), siempre que use HTTPS estará seguro . iOS o Android verificarán el certificado y mitigarán posibles ataques de MiM (ese sería el único punto débil en todo esto). Puede enviar datos confidenciales a través de conexiones HTTPS que se cifrarán durante el transporte . Solo su aplicación y el servidor conocerán los parámetros enviados a través de https.

El único "tal vez" aquí sería si el cliente o el servidor están infectados con software malicioso que puede ver los datos antes de que estén envueltos en https. Pero si alguien está infectado con este tipo de software, tendrá acceso a los datos, sin importar lo que use para transportarlos.


1

Además, si está creando una API ReSTful, la fuga del navegador y los problemas de referencia http se mitigan en su mayoría, ya que el cliente puede no ser un navegador y es posible que no haya personas haciendo clic en los enlaces.

Si este es el caso, recomendaría iniciar sesión en oAuth2 para obtener un token de portador. En cuyo caso, los únicos datos confidenciales serían las credenciales iniciales ... que probablemente deberían estar en una solicitud posterior de todos modos


Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.