¿Qué usos legítimos tienen los proxies del navegador?

Uno de los primeros usos de los proxies HTTP fue el almacenamiento en caché de los servidores proxy con el fin de hacer un mejor uso del costoso ancho de banda y acelerar la navegación mediante el almacenamiento en caché de contenido muy utilizado cerca del usuario. Recuerdo un momento en que los ISP emplearon proxies obligatorios explícitos para los usuarios. Esto ocurrió en un momento en que la mayoría del contenido en Internet era estático y no era específico del usuario y, por lo tanto, el almacenamiento en caché era muy efectivo. Pero incluso muchos años después, los servidores proxy transparentes (es decir, no se necesita una configuración explícita) todavía se utilizaban en las redes móviles.

Otro caso de uso importante y temprano son los proxies en las empresas. Se utilizan para restringir el acceso y también se siguen utilizando para almacenar contenido en caché. Si bien muchos cortafuegos perimetrales emplean proxies transparentes donde no se necesita configuración, las puertas de enlace web seguras clásicas generalmente tienen al menos la capacidad de requerir acceso proxy explícito (no transparente). Por lo general, no todo el tráfico se envía a través del proxy, es decir, el tráfico interno generalmente se excluye con alguna configuración explícita o mediante un archivo PAC que define el proxy en función de la URL de destino. Un proxy de uso común en esta área es el Squid proxy gratuito que proporciona ACL extensas, almacenamiento en caché distribuido, autenticación, inspección de contenido, intercepción SSL etc.

El uso de un proxy explícito para el filtrado tiene la ventaja de que puede requerirse la autenticación en banda contra el proxy, es decir, identificar al usuario por nombre de usuario en lugar de la dirección IP de origen. Otra ventaja es que la conexión del cliente finaliza en el proxy, y el proxy solo envía la solicitud al servidor que figura en la solicitud del proxy HTTP si la comprobación de ACL está bien y tal vez después de volver a escribir partes de la solicitud (como asegurarse de que el encabezado Host en realidad coincide con el host de destino). Al contrario de lo que ocurre en inline-IDS / IPS (que es la tecnología básica en muchos NGFW), la configuración de la conexión desde el cliente ya se envía al servidor final y las verificaciones de ACL se realizan en función del encabezado Host , que puede o no coincide con la dirección IP a la que se está conectando el cliente. Esto se usa en realidad en algunas comunicaciones de malware C2 para omita el bloqueo o la detección al reclamar un host incluido en la lista blanca en el encabezado Host pero con un objetivo diferente como dirección IP.

Algunos ejemplos a continuación:

• Para habilitar una regla de firewall como 'servidor proxy a cualquier destino en 80, 443' en lugar de 'cualquier interno a cualquier externo'
• Para monitorear todos los sitios web visitados a través de registros
• Para controlar, limitar, filtrar los sitios web visitados a través de las reglas de cumplimiento, pueden ser listas de sitios aprobados, sitios de la lista negra, categorías de contenido, etc.
• Para imponer la autenticación del usuario para usar Internet, por ejemplo, Limitar a los usuarios del dominio, titulares de certificados
• Podría tener puntos de egreso separados para diferentes contextos si está en VPN, en la oficina local, en la estación de trabajo, en un servidor

Por la razón "original", piense en 1993, cuando se lanzó Netscape 0.9. Tenía un diálogo de Opciones de "Correo y Proxies" (por una copia del manual ). En ese momento, la mayoría de los enlaces de Internet eran de 56 kbit o líneas T1 fraccionarias entre los campus universitarios y el gobierno. Había varias formas en que un proxy HTTP podía ayudar o incluso ser requerido:

• El navegador web puede estar en una LAN TCP / IP sin enrutamiento (de nivel IP) a Internet, pero con un host de doble enlace en esa LAN e Internet. El host dual-homed podría ejecutar un servicio de proxy HTTP y un servicio de proxy DNS, permitiendo a los clientes en la LAN acceder a la Web. (Tenga en cuenta que los RFC que describen los rangos estándar de direcciones privadas y NAT, RFC 1597 y RFC 1631 , no se publicaron hasta marzo y mayo de 1994.)
• Incluso si la LAN tenía direcciones enrutables, o incluso después de la implementación de NAT, el ancho de banda fuera del sitio probablemente era mucho menor que el ancho de banda local entre los clientes y una ubicación de proxy potencial. Mientras los clientes exploraban una cantidad significativa del mismo contenido, estático o de cambio lento, el proxy mejoró las cosas para los clientes (devolviendo el contenido almacenado en caché rápidamente), así como el operador de la red (al liberar ancho de banda para otros funciones de red, o reducir los cargos por el uso de datos cuando la facturación fue por paquete o por byte).
• Si suficientes usuarios finales estaban detrás de los proxies, eliminó lo que 10 años más tarde se llamaría el "efecto Slashdot": los servidores de origen para contenido popular en todo el mundo solo tendrían que servirlo a cada proxy, no a cada extremo usuario.

Por supuesto, enviar todo el tráfico HTTP a través de un proceso designado también hace que ese proceso sea un buen punto de control para aplicar la política de seguridad: filtrado por palabras clave en el cuerpo de la solicitud o respuesta (decodificado); solo permitiendo el acceso a usuarios que se autentiquen al proxy; explotación florestal.

Sí, hay organizaciones que "aplican" una política de proxy a los dispositivos de usuario final que controlan, y la aplican mediante una política restrictiva en los enrutadores de la frontera.

También tenga en cuenta que incluso si cree que está navegando en una red "limpia", su tráfico puede estar pasando por un proxy; vea, por ejemplo, el Proxy transparente con Linux y el mini-CÓMO de Squid .

Pero es cierto que un proxy configurado explícitamente puede ofrecer pocas ventajas o incluso empeorar la navegación en Internet de hoy. Cuando los sitios web populares utilizan CDN y la mayoría del contenido es dinámico, e incluso el contenido que parece que podría almacenarse en caché (como los mosaicos de Google Maps y los datos de video de Youtube) varía según la versión del navegador, el sistema operativo, el tamaño de la pantalla o incluso una cookie aleatoria. em> significaba para que sea incachable, el almacenamiento en caché ahorra poco ancho de banda para un caché cerca del usuario final (aunque los servidores de origen a menudo tienen cachés delante de ellos). Para el contenido no almacenable, otro caché agrega RTT a cada solicitud, lo que hace que la navegación sea más lenta.

Sí, se utilizan con frecuencia en el mundo corporativo. Quizás menos ahora que en el pasado, pero hace años solían ser la única puerta de enlace desde una red local a Internet. En muchos casos, solo algunos usuarios del dominio estaban autorizados a acceder a Internet, y un servidor proxy como ISA se configuraría en el borde de la red, y los usuarios tendrían que autenticarse para atravesarlo.

Más allá de simplemente restringir quién podía acceder a Internet, esto se usó para el filtrado de contenido, la inspección de contenido y los informes sobre quién pasaba todo su tiempo de trabajo buscando nuevos trabajos en Monster.com. También había otras funciones no relacionadas con la seguridad, como el almacenamiento en caché. Hace 20 años no era infrecuente tener cientos o incluso miles de personas en una instalación conectada a Internet usando una tubería relativamente pequeña como un T-3 fraccional, o incluso un T-1. Fue muy útil poder almacenar en caché el contenido en el borde de la red local, por lo que el ancho de banda muy limitado que el mundo exterior no estaba saturado con solicitudes repetidas de los mismos recursos.

El acceso a revistas académicas a menudo está restringido, y algunas veces parte de la restricción es la dirección IP. Al usar el servidor proxy de mi universidad (que requería un inicio de sesión válido), podía acceder a las revistas mientras trabajaba desde mi casa (tiempo pasado solo porque no lo he probado durante un par de años). Podría configurarlo solo para sitios web de editores de revistas o usar una extensión de cambio de proxy en Firefox.

Pienso que podría haber usado la VPN de la universidad, pero aquí se requiere un programa cliente que no se ejecute en Linux (y mucho menos en mi Chromebook). Una VPN anterior requería una gran cantidad de reglas de configuración en una IU estúpida para que funcionen las cosas básicas (como cualquier correo electrónico que no se ejecute por ellas).

Además, hay casos de uso para controlar el tráfico HTTP que no es del navegador :

actualización automática y "llamada a casa" en las aplicaciones de escritorio pueden controlarse hasta cierto punto al permitir que los navegadores web reales y controlados por meatware utilicen un proxy que sea menos restrictivo de lo que la infraestructura de red permite de forma predeterminada.

De la misma manera, los servidores pueden vigilarse, mientras que hay algunos procesos en un servidor que crean tráfico legítimo de egreso de http, lo que permite que todo egreso de http sea más útil para alguien que intente hackear / sabotear el servidor. Además, a menudo tiene sentido documentar todo el tráfico de egreso del servidor (lo que puede hacer un proxy).

Además, las redes de bajo ancho de banda (por ejemplo, satphone o umts) que necesitan conservar el ancho de banda a menudo usan proxies para recodificar imágenes grandes y otros contenidos multimedia que no serán útiles en el formato de alta resolución y alto tráfico, especialmente en dispositivos móviles. dispositivos.