Digamos que nunca me conecté al sitio example.com .
Si este sitio es https y escribo https://example.com/supersecretpage , ¿se enviará la URL en texto sin cifrar ya que es la primera vez que me conecto al sitio y, por lo tanto, las claves de cifrado aún no se han intercambiado? Si no, ¿cuándo tiene lugar esto? ¿Alguien podría explicar los pasos cuando escribo esa URL?
Respuesta corta: No, la URL está cifrada, pero el (sub) dominio se envía en texto sin formato.
En su caso, un atacante (pasivo) sabe que se está conectando a example.com , pero no sabe a qué página específica está accediendo.
En resumen, hay tres veces en las que un atacante puede obtener información sobre el sitio al que está accediendo (ordenado cronológicamente):
Sin embargo, el ...
Para más detalles, lea la explicación a continuación.
Nota: Cuando escribo "(sub) dominio", me refiero tanto al dominio ( example.com ) como al subdominio ( mydomain.example.com ). Cuando solo escribo "dominio" realmente me refiero al dominio ( example.com ) sin el subdominio.
Básicamente lo que sucede es:
example.com también puede incluir www.example.com , devserver.example.com y how-to-develop-tls.example . Estas entradas se denominan Nombres alternativos del sujeto y el certificado es válido para todos ellos. Después de que todo esto sucedió, se envía una solicitud HTTP "habitual" (a través del canal TLS seguro). Esto significa que esta es la primera vez en la solicitud completa donde aparece la URL completa . La solicitud por ej. se ve así:
GET / supersecretpage HTTP / 1.1
Anfitrión: example.com
[...]
* Si el certificado es un certificado comodín, no incluye los subdominios, sino solo *.example.com .
Otra cosa que vale la pena mencionar: antes de poder establecer la conexión, todo lo que el cliente necesita para resolver el nombre DNS. Para ello, envía consultas de DNS sin cifrar a un servidor DNS y éstas también contienen el (sub) dominio , que por lo tanto puede ser utilizado por un atacante para ver los dominios visitados. .
Sin embargo esto no siempre tiene que suceder de esta manera, ya que supones que el usuario escribe manualmente https://example.com/supersecretpage en la barra de URL. Pero esto es muy raro ya que la mayoría de los usuarios, por ejemplo. preferiría escribir example.com/supersecretpage . Otro problema sería que los visitantes hagan clic en un enlace inseguro , que utiliza HTTP, en contraste con un enlace HTTPS seguro ). Tales enlaces podrían p. Ej. ser enlaces antiguos creados cuando el sitio no era compatible con HTTPS o no se redirigía a HTTPS de forma predeterminada.
¿Preguntas por qué esto importa?
En este caso (habitual) no hay https:// en la URL. Cuando no se ingresa ningún protocolo en la barra de URL, todos los navegadores "convierten" internamente esta URL a http://example.com/supersecretpage (observe el enlace allí) ya que no pueden esperar que el servidor admita HTTPS.
Esto significa que el navegador primero intenta conectarse al sitio web mediante HTTP inseguro y solo después de que el sitio web envía un redireccionamiento (301) a la URL de HTTPS, utiliza el modo seguro.
En este caso, el atacante puede ver la URL completa en la solicitud HTTP sin cifrar.
Puede probarlo fácilmente por sí mismo mirando el "panel de red" de su navegador. Allí debería ver esta "actualización de HTTPS":
Sin embargo, tenga en cuenta que existen técnicas para evitar esta primera solicitud HTTP insegura. En particular, HSTS y - para proteger incluso la primera conexión que realice con el sitio - precarga de HSTS , pero también HTTPS en todas partes ayuda contra tales ataques. Para su información: De acuerdo con Netcraft 95 El% de todos los servidores HTTPS vulnerables fueron vulnerables a tales ataques (eliminación de SSL) a partir de marzo de 2016.
No, la URL no se enviará en texto claro.
Inmediatamente después de que se complete el protocolo de enlace de tres vías TCP, su cliente inicia la negociación TLS con el servidor. Solo después de que se haya completado la negociación y se haya implementado el cifrado, se enviará la solicitud HTTP.
Como nunca ha visitado el sitio www.example.com, su navegador debe resolver el nombre de dominio a la dirección IP. Por lo tanto, envía una consulta de resolución de DNS que contiene el nombre de dominio del sitio al que está intentando conectarse. Por lo tanto, un MITM puede averiguar a qué dominio está intentando conectarse, a menos que use un DNS seguro.