When the browser wants to load the page http://www.ebay.com/index.html it
tells the proxy something like:
GET http://www.ebay.com/index.html HTTP/1.1
In this case the proxy issues a relatively normally looking request to the
webserver, as if it was a browser.
When the browser wants to load the page https://www.ebay.com/login.html it
tells the proxy something like:
CONNECT https://www.ebay.com/login.html HTTP/1.1
In this case the proxy then opens a TCP connection to port 443 on the
webserver, and copies whatever bytes it receives from one side of the
connection to the other. It holds this open on both sides, until one side
drops the connection.
Described above doesn't really account for steps 4 & 5 below. Inorder to
support 4&5 below, the proxy needs it's own (X.509) Cert. In this
scenario, a SSL connection is built between browser and proxy, with the
browser accepting the Cert from the proxy. Then the request is submitted
encrypt from the browser to the proxy. The proxy decrypts the request, then
opens a separate connection to the webserver.
The proxy then decrypts the responses from the webserver, inspects them
against policy (hopefully) and encrypts them using the separate session to
the browser. I'm a little unclear about precisely when the browsers
connection is broken, however I think you get the idea.
If a proxy doesn't have a Cert installed, it must use the CONNECT HTTP method.
Netscape has excellent documentation of the proxying process, it used to
be post in the manuals of it's Proxy server.
>3) Proxy manages, somehow, to act as intermediary. (This is what I don't
>get.)
>4) The proxy sets up the SSL tunnel with the remote site.
>5) The proxy sets up the SSL tunnel with the users browser.
_______________________________________________
firewall-wizards mailing list
firewall-wizards_at_nfr.com
http://list.nfr.com/mailman/listinfo/firewall-wizards
Received on Oct 20 2001
Intro
