¿Cuándo se deben usar los métodos CONNECT y GET HTTP en HTTP Proxy Server?

httpwebrequest http-request

Question

Estoy construyendo una biblioteca de WebClient. Ahora estoy implementando una función proxy, así que estoy investigando un poco y vi un código usando el método CONNECT para solicitar una URL.

Pero al verificarlo dentro de mi navegador web, no usa el método CONNECT pero llama al método GET.

Entonces estoy confundido ¿Cuándo debo usar ambos métodos?

Answer 1

Como regla general, GET se utiliza para HTTP simple y CONNECT para HTTPS

Sin embargo, hay más detalles, por lo que es probable que desee leer los RFC-s relevantes.

http://www.ietf.org/rfc/rfc2068.txt http://www.ietf.org/rfc/rfc2817.txt

Answer 2

Una solicitud CONEXIÓN insta a su proxy a establecer un túnel HTTP en el punto final remoto. Por lo general, se usa para conexiones SSL, aunque también se puede usar con HTTP (se utiliza con fines de proxy-encadenamiento y tunelización)

CONNECT www.google.com:443

La línea anterior abre una conexión desde su proxy a www.google.com en el puerto 443. Después de esto, el contenido enviado por el cliente lo reenvía a www.google.com:443 .

Si un usuario intenta recuperar una página http://www.google.com , el proxy puede enviar la misma solicitud exacta y recuperar la respuesta para él, en su nombre.

Con SSL (HTTPS), solo los dos puntos finales remotos comprenden las solicitudes y el proxy no puede descifrarlas. Por lo tanto, todo lo que hace es abrir ese túnel usando CONNECT, y permite que los dos puntos finales (servidor web y cliente) hablen entre sí directamente.

Encadenamiento Proxy:

Si está encadenando 2 servidores proxy, esta es la secuencia de solicitudes que se emitirán.

GET1 is the original GET request (HTTP URL)
CONNECT1 is the original CONNECT request (SSL/HTTPS URL or Another Proxy)
User Request ==CONNECT1==> (Your_Primary_Proxy ==CONNECT==> AnotherProxy-1 ... ==CONNECT==> AnotherProxy-n) ==GET1(IF is http)/CONNECT1(IF is https)==> Destination_URL

Answer 3

TL; DR un cliente web usa CONNECT solo cuando sabe que habla con un proxy y el URI final comienza con https:// .

Sí, respondo después de 4 años. Cuando un navegador dice:

CONNECT www.google.com:443 HTTP/1.1

significa:

"Hola, proxy, abre una conexión TCP en bruto a Google; escribo cualquiera de los siguientes bytes, simplemente repites esa conexión sin ninguna interpretación. Ah, y una cosa más. Haz eso solo si hablas directamente con google, pero si utilizas otra Proxy usted mismo, en cambio, simplemente dígales el mismo CONNECT ".

Tenga en cuenta que esto no dice nada sobre TLS (https). De hecho, CONNECT es ortogonal a TLS; puedes tener solo uno, puedes tener otro, o puedes tener ambos.

Dicho esto, la intención de CONNECT es permitir una sesión TLS encriptada de extremo a extremo , por lo que los datos no se pueden leer ante un proxy (o una cadena de proxy completa). Funciona incluso si un proxy no comprende TLS en absoluto, porque CONNECT se puede emitir dentro de HTTP simple y requiere del proxy nada más que copiar bytes sin formato.

Pero la conexión con el primer proxy puede ser TLS (https), aunque significa un doble cifrado de tráfico entre usted y el primer proxy.

Obviamente, no tiene sentido CONNECT cuando se habla directamente con el servidor final. Simplemente comienza a hablar TLS y luego emite HTTP GET . Los servidores finales normalmente desactivan CONNECT completo.

Para un proxy, el soporte CONNECT agrega riesgos de seguridad. Cualquier información se puede pasar a través de CONNECT , incluso ssh intento de piratería a un servidor en 192.168.1. *, Incluso SMTP envío de correo no deseado. El mundo exterior ve estos ataques como conexiones TCP normales iniciadas por un proxy. No les importa cuál es el motivo, no pueden verificar si HTTP CONNECT tiene la culpa. Por lo tanto, depende de los representantes asegurarse de un mal uso.