Comprendo cómo puede crear una conexión segura a través del protocolo de enlace, pero cómo puede iniciar una conexión segura sin enviar primero una solicitud sin cifrar, revelando así el sitio web de destino (pero no los datos enviados o recibidos desde / al destino ...) a un potencial "hombre en el medio" atacante ...? o no lo esta escondiendo?
No confunda la seguridad con la privacidad.
La tarea de SSL / TLS es seguridad, no privacidad. Esto significa que los datos en sí están encriptados, pero los metadatos, como la IP de origen y destino, el nombre de host (con SNI como los utilizan todos los navegadores modernos), el tamaño de la carga útil y la sincronización, etc. no lo son. Y todo esto se puede usar para hacer un perfil de navegación que incluya los sitios que visita y, a veces, incluso las páginas que visita en el sitio (según el tiempo y el tamaño de la carga útil). Pero SSL / TLS se asegura de que el contenido no público (como cookies, datos de formularios, etc.) esté protegido contra el rastreo y la manipulación.
Si desea una mejor privacidad, necesita combinar SSL / TLS con algo como Tor, pero incluso esto no puede garantizar una privacidad completa.
SSL / TLS no oculta las direcciones IP de origen y de destino. Es imposible (al menos, con una solución puramente ssl / tls), porque las direcciones src / dst deben ser válidas para una conexión TCP que funcione.
El nombre del sitio web conectado, está oculto de forma predeterminada , o, al menos, hasta hace algunos años.
Desde entonces, hay una extensión de la TLS denominada " Indicación del nombre del servidor ", que proporciona el nombre del sitio conectado sin cifrar , sin embargo, en la fase de negociación.
El sitio Man-in-the-middle es una cosa diferente. Con mitm, un atacante puede jugar el destino para el cliente y jugar al cliente para el servidor, usando diferentes teclas y diferentes sesiones ssl / ttls. Pero no tiene nada que ver con el descifrado ssl.
Como lo ha dicho el otro, la conexión inicial no está asegurada y al menos contiene la dirección IP (aunque cada vez más el nombre del servidor también se debe a SNI). El servidor de destino responde con un certificado de clave pública y negocian la sesión SSL / TLS.
La clave para evitar los ataques del hombre en el medio es el certificado y el hecho de que haya sido aprobado por una autoridad de certificación en la que su navegador confía.
Supongamos que un hacker intercepta las comunicaciones entre un cliente y un servidor. El cliente ha solicitado una conexión segura al sitio web enlace (por ejemplo). El pirata informático puede enviar la solicitud al sitio web real y transmitir las respuestas. El pirata informático también podrá leer la primera respuesta del servidor al cliente ya que es texto sin formato. Sin embargo, no puede leer el siguiente mensaje del cliente al servidor, ya que está cifrado con la clave pública del sitio web y, por lo tanto, solo se puede descifrar con la clave privada (que el pirata informático no tiene). Dado que estos mensajes posteriores se utilizan para negociar la clave que se usará para la conexión SSL / TLS real, el pirata informático está básicamente bloqueado después de ese primer mensaje.
Alternativamente, en lugar de actuar como un relé directo, el pirata informático puede otorgar un certificado falso (para el que conoce la clave privada) para la conexión cliente-pirata informático y luego puede configurar su propia conexión de servidor pirata informático y pasar. mensajes entre los dos. Sin embargo, en este escenario, a menos que hayan logrado comprometer uno de los principales emisores de certificados que el navegador del cliente acepta automáticamente, habría un gran candado rojo que indicaría que el certificado que el pirata informático envió al cliente es 1) no es real o 2 ) no para este sitio web.
La mayoría de los ataques MITM dependen de mantener la conexión en http estándar. Por ejemplo, vaya a www.mybank.com (de modo que el navegador intente http: // de manera predeterminada, ya que no ha especificado un protocolo). Normalmente, el banco lo redireccionaría a enlace , pero en cambio el hacker intercepta ese redireccionamiento y lo mantiene en http para la conexión cliente-hacker, pero establece un Conexión https adecuada del hacker al servidor. En este escenario, el pirata informático espera que los usuarios no se den cuenta de que no hay un candado verde y no se han cambiado a https. Los hackers están bastante fuera de suerte si el usuario va directamente a https.