Proxies HTTP y HTTPS

Un proxy HTTP acepta solicitudes web de tu navegador o aplicación y se conecta al destino en tu nombre. Puede transportar tráfico HTTP ordinario y, si admite el método CONNECT, tráfico HTTPS cifrado. Un proxy HTTPS añade cifrado a la conexión entre tu aplicación y el propio proxy.

Son dos decisiones separadas: cómo llega tu aplicación al proxy y cómo se comunica con el sitio web a través de él. Comprender ambas ayuda a elegir la configuración de conexión adecuada. La elección general entre protocolos de proxy se trata en Proxies SOCKS y HTTP.

Qué hace un proxy HTTP con una solicitud web

Supongamos que un script de supervisión solicita http://example.com/catalog. En lugar de abrir una conexión con el sitio web, se conecta al proxy configurado. Con HTTP/1.1, envía la URL completa del destino en su solicitud para que el proxy sepa con qué servidor y página contactar. El proxy reenvía la solicitud y devuelve al script la respuesta del sitio web.

En este modo, el proxy procesa mensajes HTTP. Puede leer el método, como GET o POST, la dirección solicitada, las cabeceras y los datos enviados. Un programa configurado para ello puede aplicar reglas de acceso, registrar solicitudes o almacenar en caché las respuestas que lo permitan. La caché es una función opcional regida por las reglas de almacenamiento de la respuesta; comprar acceso a un proxy HTTP no significa que todas las páginas se almacenen en caché.

El sitio web recibe la conexión de red desde la IP de salida del proxy. El término HTTP no dice nada sobre el origen de esa IP ni sobre cuánto dura su asignación. El mismo protocolo de conexión puede ofrecerse con direcciones de centro de datos, ISP, residenciales o móviles, utilizando IP fijas o un grupo rotativo.

Cómo abre un proxy HTTP un sitio web HTTPS

Un sitio web HTTPS utiliza TLS para proteger el intercambio entre la aplicación y el sitio. Para transportar ese intercambio, un proxy HTTP crea primero un túnel. Para una solicitud a https://example.com/catalog, la secuencia es:

1. La aplicación se conecta al proxy y le pide que abra un túnel a example.com:443, mediante el método CONNECT. La solicitud indica el host y el puerto de destino, sin la ruta de la página.
2. El proxy comprueba si se permiten el acceso y el destino solicitado, incluida cualquier autenticación de proxy necesaria. Abre una conexión con el destino y confirma que el túnel está listo.
3. La aplicación realiza un intercambio TLS con el sitio web a través del túnel y comprueba el certificado del sitio.
4. La aplicación envía su solicitud web dentro de esa conexión TLS. El proxy retransmite los bytes cifrados en ambas direcciones.

El proxy no necesita leer la página para entregarla. La aplicación y el sitio web siguen siendo los extremos de la conexión TLS del sitio. CONNECT proporciona el túnel; TLS proporciona el cifrado y protege el intercambio frente a modificaciones no detectadas.

Por eso un proxy HTTP puede abrir un sitio HTTPS aunque la dirección del proxy empiece por http://. La protección HTTPS del sitio funciona dentro del túnel. No depende de que haya TLS entre la aplicación y el proxy.

Qué añade un proxy HTTPS

Con un proxy HTTPS, la aplicación establece primero TLS con el proxy y verifica su certificado. Después envía sus solicitudes HTTP, o la solicitud CONNECT para crear un túnel, dentro de esa conexión protegida. Un observador de la red entre la aplicación y el proxy no puede leer esas solicitudes.

Para un destino HTTPS, la aplicación mantiene dos conexiones TLS separadas: una con el proxy y otra con el sitio web a través del túnel. El proxy retira la protección exterior dirigida a él, pero los datos del sitio que contiene siguen cifrados. Reenvía esos bytes al sitio web, que puede descifrarlos. Para un destino HTTP no hay conexión TLS interior: solo está protegida la conexión hasta el proxy.

Esta comparación describe el reenvío ordinario mediante proxy con las comprobaciones de certificados activadas, sin inspección HTTPS ni una VPN independiente. Cifrar la conexión con un proxy no convierte un sitio HTTP en HTTPS.

Qué pueden ver el proxy y el sitio web

Para un destino HTTPS, un proxy de reenvío no puede leer la ruta de la página, los parámetros de consulta, las cookies, los datos de formularios ni el contenido devuelto dentro de la conexión TLS. Sigue conociendo la IP del cliente que se conectó a él, el host y el puerto de destino solicitados en CONNECT, y los tiempos y el volumen del tráfico. TLS hasta el proxy mantiene CONNECT privado frente a observadores de esa parte de la red, pero no frente al proxy que debe procesarlo.

Las credenciales del proxy se envían por separado del inicio de sesión del sitio web. La autenticación básica del proxy codifica el nombre de usuario y la contraseña mediante Base64, que puede decodificarse sin una clave secreta. En una conexión de proxy HTTP sin TLS, esto no las protege frente a un observador de la red. La conexión HTTPS del sitio empieza dentro del túnel y no cubre el inicio de sesión anterior del proxy. TLS hasta el proxy protege ese inicio de sesión durante el transporte.

En el otro extremo, el sitio web recibe tráfico de la IP de salida y lee las solicitudes dirigidas a él. Puede reconocer una cuenta, una cookie de sesión u otra información enviada por la aplicación. Elegir un proxy HTTPS no elimina esos identificadores ni mejora automáticamente la aceptación de la IP de salida por el sitio.

La inspección HTTPS es una configuración distinta utilizada en algunas redes administradas y herramientas de depuración. La aplicación confía en una autoridad de certificación controlada por el proxy inspector, que puede leer el tráfico manteniendo conexiones TLS separadas a cada lado. El reenvío CONNECT normal no exige instalar ese certificado. Confiar en el certificado del propio servidor proxy HTTPS es distinto de permitirle suplantar sitios web.

Cómo interpretar la configuración de conexión

Una configuración de proxy necesita una dirección, un puerto, un protocolo de conexión y cualquier autenticación requerida. El protocolo de la URL del proxy se aplica al proxy. El protocolo de la URL de destino se aplica al sitio web.

Estas órdenes curl solicitan el mismo sitio HTTPS mediante dos conexiones de proxy diferentes. Sustituye el nombre de host y el puerto del proxy por los valores proporcionados para el método de conexión elegido:

curl --proxy http://proxy.example:8080 https://example.com/
curl --proxy https://proxy.example:8443 https://example.com/

La primera orden se conecta al proxy por HTTP y después crea CONNECT y TLS hasta el sitio web. La segunda crea primero TLS hasta el proxy HTTPS y después transporta por él la conexión TLS separada del sitio. En ambos casos, proporciona también la autenticación que exija el servicio de proxies.

Cambiar simplemente http:// por https:// no convierte un puerto exclusivo de HTTP en un punto de conexión TLS. Si el servicio proporciona un nombre de host para el acceso HTTPS, utilízalo: sustituirlo por una IP puede provocar una discrepancia con el nombre del certificado.

Las etiquetas de las aplicaciones requieren la misma atención. Un campo llamado «proxy HTTPS» puede seleccionar el proxy para sitios HTTPS y seguir conectándose a él mediante HTTP sin TLS. En curl, la variable HTTPS_PROXY también selecciona un proxy para destinos HTTPS; su valor puede empezar correctamente por http://. La etiqueta indica qué solicitudes utilizan el ajuste, mientras el esquema del proxy indica cómo se establece la conexión.

DNS y tráfico que pasa por el proxy

Cuando un cliente HTTP proporciona un nombre de host de destino, el proxy suele consultar su IP y conectarse a ella. El cliente realiza una consulta independiente si necesita el nombre de host del propio proxy para llegar a él. Un navegador también puede emitir consultas DNS para predicción u otras funciones. Son consultas separadas; configurar un proxy web no encamina todas las solicitudes DNS a través de él.

El ajuste se aplica al tráfico que la aplicación realmente envía al proxy. Otro programa puede seguir conectándose directamente, y una lista de excepciones puede omitir el proxy en determinados sitios. Por ejemplo, encaminar un script de API a través de un proxy no cambia la ruta utilizada por un navegador independiente. Comprueba la dirección de salida desde la aplicación y la configuración que ejecutarán la tarea.

HTTP/2 hasta el sitio web y HTTP/2 hasta el proxy

HTTP/2 permite que varios intercambios compartan una conexión mediante flujos separados. Con un proxy, importa qué conexión lo admite. Una aplicación puede negociar HTTP/2 con un sitio dentro de un túnel creado mediante HTTP/1.1 CONNECT. El proxy retransmite los bytes cifrados y no necesita comprender los mensajes HTTP/2 del sitio.

HTTP/2 entre aplicación y proxy es una función distinta. Cada túnel CONNECT utiliza su propio flujo HTTP/2, por lo que varios túneles pueden compartir una conexión con el proxy. Por ejemplo, los túneles a dos sitios distintos pueden utilizar esa conexión manteniendo conexiones de destino y sesiones TLS de sitio separadas. Esto reduce la necesidad de conexiones adicionales entre cliente y proxy; no permite al proxy leer las solicitudes cifradas del sitio.

Ambos lados deben admitir el modo elegido. HTTPS por sí solo no implica HTTP/2: un proxy HTTPS puede utilizar HTTP/1.1. El rendimiento también depende del cliente, la ruta de red, la carga del servidor y la reutilización de conexiones. Una etiqueta HTTP/2 no garantiza un aumento de velocidad para todas las tareas.

Un túnel CONNECT ordinario también puede transportar otros protocolos basados en TCP si la aplicación y el proxy lo permiten, aunque los puertos de destino pueden estar restringidos. No retransmite UDP. HTTP/3 utiliza QUIC sobre UDP, por lo que no puede viajar del mismo modo por ese túnel TCP. El reenvío UDP mediante HTTP utiliza mecanismos adicionales como CONNECT-UDP y requiere implementaciones compatibles. La compatibilidad con HTTPS o HTTP/2 por sí sola no demuestra esa compatibilidad.

Dónde resulta útil el acceso a proxies HTTP y HTTPS

Para navegar y probar sitios web, un proxy HTTP con CONNECT proporciona un método de conexión para destinos HTTP y HTTPS. Un equipo puede utilizarlo para ver un sitio desde la red del proxy, manteniendo al navegador a cargo de la representación de páginas, las cookies y los inicios de sesión del sitio.

Para rastreadores, clientes de API y monitores programados, un cliente HTTP puede enviar solicitudes a través de una IP de salida elegida sin cambiar las URL de destino. La aplicación sigue preparando las solicitudes y procesando las respuestas. Dentro de un túnel HTTPS, el proxy transporta ese intercambio sin tener que analizar cada página o llamada a la API.

Un proxy HTTPS protegido por TLS resulta útil cuando la conexión hasta el proxy también necesita protección, incluidos el inicio de sesión del proxy y las solicitudes de destino. Esto importa cuando esa conexión atraviesa una red que no controlas. El cliente debe admitir TLS hasta el propio proxy; no basta con que pueda abrir sitios HTTPS.

Cómo interpretar los errores de conexión

Un fallo puede producirse al llegar al proxy, al abrir el túnel o al comunicarse con el sitio web. La etapa indica más que el código de error por sí solo.

Un túnel y un intercambio TLS completados demuestran que la ruta de conexión funciona. No garantizan que el sitio web acepte una cuenta, IP de salida o solicitud determinadas. Por ello, un desafío de inicio de sesión, un CAPTCHA o un límite de solicitudes pueden requerir atención en el sitio web o la aplicación incluso cuando el proxy funciona.