¿Cómo rastrean los datos los servidores proxy?

Cuando un navegador web usa un proxy HTTP, las cosas van de la siguiente manera. Supongamos que la URL de destino es http://www.example.com/index.html . El navegador se conecta al proxy y le dice: "Quiero obtener la página en http://www.example.com/index.html ". El proxy cumple, obtiene los datos y los envía de vuelta al navegador. Por construcción, el proxy ve todos los datos. La conexión entre el proxy y el navegador podría estar encriptada, pero el proxy todavía lo ve todo.

Si la URL de destino usa SSL ( https://www.example.com/index.html : tenga en cuenta el s en https ), entonces el navegador se conecta al proxy y le dice: "Quiero conectarme al puerto 443 de www.example.com ; hazlo y luego transmite todos los bytes en ambas direcciones ". La Sección 5.2 de RFC 2817 describe este mecanismo. Luego, el proxy actúa como retransmisión para todos los bytes entre el navegador y el servidor web, estos bytes codifican lo que el navegador y el servidor web deseen que sean, es decir, en la práctica, un protocolo de enlace SSL y los datos subsiguientes. En ese caso, el proxy está fuera del túnel SSL y no puede ver los datos de intercambio. El túnel SSL aún se encuentra entre el servidor web y el navegador, y el proxy es un mecanismo puramente de transporte.

El proxy todavía está en la posición ideal para intentar ataques Man-in-the-Middle , ya que todas las comunicaciones pasan por ello; pero SSL está protegido contra eso, es decir, en virtud del servidor web certificado que está siendo validado por el cliente. Por supuesto, esto se basa en que el usuario humano no haga clic en las advertencias sobre certificados no válidos. En algunas organizaciones, los administradores de sistemas locales instalan certificados de CA raíz "rogue" adicionales en sistemas de escritorio para que puedan crear un certificado de servidor falso en el proxy y hagan el ataque MitM, otorgándoles acceso a los datos intercambiados (para que puedan aplicar filtros de antivirus) incluso en el tráfico HTTPS, o al menos eso dicen).

Salvo una instalación de CA fraudulenta (que es, básicamente, una violación de la seguridad del equipo cliente), el proxy no podrá ver los datos intercambiados entre el navegador y el servidor HTTPS. El proxy aún podrá saber con qué servidor se contactó y observar el tamaño de los intercambios de datos: el cifrado oculta el contenido, no el tamaño.

La situación de SOCKS es conceptualmente similar. El diálogo entre el navegador y el proxy es diferente, pero lo básico sigue siendo el mismo: el proxy podrá ver todo el tráfico HTTP y ninguno del tráfico HTTPS.

Editar: al parecer, existen otros tipos de "proxies", en los que su navegador entra en contacto con un servidor dedicado, que a su vez ejecuta un navegador, realiza su búsqueda por usted y le devuelve las páginas. . Desafortunadamente, algunas personas lo llaman "proxies web", una terminología que ha estado en uso durante dos décadas para designar lo que, técnicamente, es un proxy HTTP. La confusión sigue.

Tales "proxies de navegación" son similares, en concepto, con la apertura de una sesión en el servidor con un protocolo de escritorio remoto y ejecutando su navegador desde allí. Esto otorga todo el poder posible a los administradores de proxy en sus actividades de navegación. No desea hacerlo si no confía absolutamente en los administradores de sistemas proxy.

Y preferiría no utilizar la expresión "proxy web" si existe algún riesgo de ambigüedad.

La única forma plausible en la que puedo pensar es que de alguna manera usted permite que el software proxy en cuestión agregue su propia CA a su lista de CA raíz de confianza. Esto permitirá que el servidor proxy realice un ataque MITM en su conexión.

Si no se realiza este paso, el servidor proxy no debería tener forma de leer los datos enviados a través de SSL.

Consulte: Man-in-the -meddle Blue Coat proxy SSL o qué? para obtener más información.

En primer lugar, me gustaría hacer una distinción entre lo que comúnmente se conoce como Proxies HTTP , para lo cual, se aplican otras respuestas, la confidencialidad no se romperá a menos que agregue la CA del proxy a sus CA confiables; y Proxies web (aún no podemos estar de acuerdo con un nombre, puede llamarlo Proxy HTML o Proxy de navegación).

No voy a entrar en detalles, pero básicamente, un proxy web es un sitio web que usted visita y le pide que "proxy" / "enrute" una página web para usted. Por ejemplo, HideMyAss , ZendProxy , AWebProxy , o básicamente cualquiera de los resultados si busca en Google "proxy web".

Esos proxies web son capaces de romper la confidencialidad de su sesión HTTPS, y son capaces de hacerlo y sin ser detectados. Por lo tanto, solo use proxies web en los que confíe, o, mejor, no los use en absoluto.

Un proxy web se interpone entre usted y el sitio web habilitado para SSL que está visitando. Actúa como un navegador intermediario. Descifra lo que el servidor le envía y encripta lo que usted envía al servidor. Gestiona tu sesión y maneja tus cookies. Sentado en la capa de aplicación, puede hacer todo eso y posiblemente más.

Ya que visita https://web-proxy.com todo el tiempo, no hay ninguna razón para que su navegador le avise cuando el proxy rompe la confidencialidad.

Por otro lado, los proxies que configura en la configuración del navegador o del sistema pueden ser seguros. Cuando visite un sitio web que debería ser seguro, verifique que esté en el dominio correcto (como "example.com") y que la conexión https no esté interrumpida (generalmente aparece un icono de candado cuando está seguro). Esto es diferente de los proxies web porque con un proxy web, el nombre de dominio es el dominio del proxy.

En realidad no. Sin embargo, asegúrese de escribir https en la barra de URL y no http ; la mayoría de los sitios web 301 redirigen a HTTPS, pero el servidor proxy puede evitar que esto suceda.

También, tenga cuidado con los ataques tipo phishing: el servidor proxy puede ofrecerle un sitio como mаil.google.com (el a es Cryllic). Esto debería dar una advertencia en la mayoría de las implementaciones, sin embargo, la redirección desde un sitio HTTPS requiere el certificado de ese sitio. Además, muchos servidores proxy que tienen una página de destino (con inicio de sesión) generalmente le piden que agregue una excepción SSL (porque intentar acceder a una página HTTPS antes del inicio de sesión dará lugar a un redireccionamiento inseguro). Hay posibilidades de que esta excepción SSL sea explotada.

Tenga en cuenta que el servidor proxy puede ver el dominio al que intenta acceder.

Como @Adnan menciona correctamente, los proxies web (páginas web en las que acaba de ingresar a un sitio web sin navegador o configuración de red) son completamente inseguros. Los proxies web obtienen páginas en su nombre y le envían el código HTML (a diferencia de otros proxies que le transmiten una respuesta bruta ligeramente modificada). Publican solicitudes en su nombre y son el "cliente" en las conexiones HTTPS (solo le entregan una copia del HTML descifrado y cifran sus respuestas por usted). Así que tienen la opción de leer todos tus datos. Si desea protegerse contra el rastreo, use HTTPS en un proxy HTTP / SOCKS.