Puede ser más simple verlo en etapas. Primero, en un mundo HTTP completo (sin SSL), una solicitud HTTP es una colección de encabezados, que indica la URL de destino y se envía a través de una conexión TCP (generalmente en el puerto 80). Los encabezados de solicitud comienzan con un "verbo" que generalmente es GET o POST.
Cuando hay un proxy, la solicitud se envía al proxy; el proxy luego abre la conexión con el servidor de destino (u otro proxy) y reenvía la solicitud a través de esa nueva conexión. La respuesta sigue el mismo camino, hacia atrás.
Ahora entra SSL. SSL se combina con HTTP de la siguiente manera: una vez que se establece la conexión TCP, se realiza un protocolo de enlace SSL, estableciendo un túnel cifrado entre el cliente y el servidor. La solicitud HTTP se enviará dentro de este túnel.
Cuando hay un proxy, un cliente que desea hablar con un servidor con SSL enviará una solicitud CONECTAR. La solicitud identifica el nombre y el puerto del servidor de destino. El proxy luego se conecta a ese servidor (TCP) y reenvía los bytes de un lado a otro. El protocolo de enlace SSL se produce entre el cliente y el servidor; el proxy se mantiene "en el exterior". El proxy (y los espías en la línea entre el cliente y el proxy, y entre el proxy y el servidor) aún pueden ver el mensaje de negociación y, por tanto, saber con qué servidor se está contactando (en particular a través de Indicación del nombre del servidor , y también el certificado enviado por el servidor).
Sucede que el proxy en sí puede también ser un servidor SSL. En ese caso, las comunicaciones entre el cliente y el proxy se encapsularán en un túnel SSL. Cuando la conexión de cliente a proxy está protegida por SSL, los interceptores en la línea entre el cliente y el proxy pueden saber que el cliente está hablando con el proxy, pero no puede ver las solicitudes y respuestas. En particular, no pueden conocer la identidad del servidor de destino final.
Los dos SSL no están correlacionados. Esto implica cierta confusión considerable, porque cuando las personas dicen "proxy HTTPS", pueden significar dos cosas diferentes:
- un proxy que conoce el verbo "CONECTAR" y puede reenviar las conexiones a un servidor de destino con SSL definitivo;
- un proxy que es en sí mismo un servidor SSL y se comprometerá en SSL con el cliente, para proteger las solicitudes y respuestas cuando transitan entre el cliente y el proxy.
Las dos características son ortogonales entre sí, lo que significa que puede obtener una, la otra, o ambas. Si tiene ambos, el cliente realmente administra dos conexiones SSL, una anidada en la otra.
Si desea derrotar a los que escuchan información en la línea entre el cliente y el proxy, y el objetivo de los atacantes es adivinar la identidad de los sitios con los que está hablando, entonces necesita un proxy con tecnología SSL, es decir, uno que admita SSL por sí mismo; y también querrá un proxy que admita CONECTAR, de modo que pueda navegar por el sitio web HTTP y HTTPS bajo la protección de su proxy con tecnología SSL.
Dado que un proxy determinado puede o no ser compatible con un protocolo específico (al menos conceptualmente, un proxy puede negarse a entender una solicitud de "CONEXIÓN"), los navegadores web pueden configurarse para usar diferentes proxies según el tipo de protocolo que desean usar. En su caso, esto solo aumenta la confusión.
Una alternativa es usar un proxy SOCKS. Esto es fácil de configurar con SSH . Con un proxy SOCKS potenciado por SSH, todas las comunicaciones que emanan de su navegador pasarán a través de un túnel SSH entre la máquina cliente y el servidor proxy.