¿SNI revela el host virtual durante la consulta CONECTAR a un proxy HTTPS?

La respuesta en bruto a su pregunta es: sí, SNI revela el nombre del host de destino al proxy. Pero, para ser más completos:

• Como indica @Steffen, el método CONNECT generalmente funciona con los nombres de host. El cliente podría solicitar una conexión con una dirección IP de destino u otro nombre de host que resuelva (a través del DNS) a la misma dirección IP, pero los clientes no suelen hacerlo.

• Una vez que se establece la conexión, se supone que el proxy reenvía todos los bytes de datos, lo que implica, en particular, que el proxy ve todos los bytes. Si se usa SNI , entonces el mensaje ClientHello handshake del cliente contendrá el nombre de host del servidor de destino.

  Uno puede notar, en particular, que un proxy podría "retrasar" el envío. Según el RFC, cuando el proxy responde a la solicitud CONECTAR, se supone que ya ha hablado con el servidor de destino; pero un proxy ligeramente engañoso podría reclamar que se contactó con el servidor, y esperar a que el mensaje ClientHello del cliente haga la conexión real. Esto (teóricamente) permite enviar solicitudes a diferentes servidores reales dependiendo del nombre de host de destino.

• En cualquier caso, el servidor responderá con mensajes de intercambio propios, incluido su Certificate . Esto se envía, necesariamente, antes de que tenga lugar el cifrado. El certificado del servidor contendrá el nombre del servidor (el cliente lo verifica ), por lo que, independientemente de SNI, el servidor El nombre no puede considerarse un secreto bien conservado.

Lo que está encriptado es lo que se envía después del saludo, es decir, los encabezados HTTP. Pero todas las cosas de proxy pasan antes, y el propio protocolo SSL contiene datos sin cifrar.

Ahora, tal vez su pregunta sea sobre situaciones en las que la conexión al proxy utiliza SSL, y el enemigo es un intruso entre el cliente y el proxy, no el proxy en sí. En ese caso, el enemigo no verá el nombre del host objetivo. El enemigo verá el protocolo de enlace SSL, con SNI, entre el cliente y el proxy, y SNI mostrará el nombre proxy en ese nivel. Una vez que se establece el túnel, cualquier cosa que ocurra entre el cliente y el proxy es bastante opaca para el adversario (aunque aún podrá hacer una buena suposición sobre el tamaño de los intercambios de datos).

Como se señaló, las solicitudes de DNS pueden ser reveladoras. Un cliente típico primero deberá resolver el nombre de destino para decidir si se trata de un servidor "local" o "no local", este último se maneja a través del proxy. Por lo tanto, es probable que el cliente grite primero el nombre del servidor de destino, sin cifrar y fuera de cualquier contexto SSL. Probablemente es posible configurar el proxy para que no se produzcan tales fugas, pero puede tomar un poco de esfuerzo. Una solución de proxy más completa (VPN, proxy SOCK a través de SSH ...) puede ser más eficaz para ocultar los nombres de los sitios que navega de sus compañeros de trabajo / compañeros de estudios / lo que sea.

Si bien una solicitud CONECTAR se puede hacer con una IP de destino (por ejemplo, el nombre de host resuelto por el cliente) generalmente se realiza con el nombre de host de destino (y el proxy resolverá el nombre de host). El mismo nombre se envía nuevamente en texto claro dentro del mensaje de saludo del cliente al iniciar el protocolo de enlace SSL.