Several people ask on the squid mailing list they are working with a transparent proxy but they need transparently "proxy" the 443 port "HTTPS" they mean that their transparent proxy could work with https urls.
But there are some misconceptions between HTTPS/SSL and proxy/reverse proxys.
Brief description:
Working as a normal proxy, squid can tunnel SSL requests when are requested by a HTTP user-agent (Netscape Documentation) vía HTTP proxies.
This involved a HTTP method (CONNECT) for establishing the tunnel.
But in a interception proxy know as transparent proxy as well, the proxy becomes the server for the client and becomes the client for the web server. The connection between the two parts who starts the connection is broken and the identity of each is hidden (SSL), so in this special case the transparent proxy doesn't know how to handle the SSL requests because is not operating as a normal proxy.
Some ideas to implement:
- Listen on a different port than the current port used for the transparent proxy (usually 80)
- Accept the SSL connection.
- Do the acl lookups sourc/destination IP, source MAC, , time srcdomain...
- Convert it to a HTTP CONNECT request suitable for the http proxy.
2 comentarios:
Perhaps I'm wrong, but it seems to me that this is not fully possible.
In the case of interception caching, the proxy server will have access to the destination IP address and port number via the IP headers. However, the CONNECT request must include the hostname and port number, eg.
CONNECT home.netscape.com:443 HTTP/1.0
A reverse DNS lookup on the destination IP might (assuming it works) give one possible hostname, but if there are several vhosts on that IP, how can the proxy server know which one to use?
SSL servers generally need their own IP, but developments are changing this, besides which, you still can't figure out which single hostname is running the SSL vhost.
http://wiki.cacert.org/wiki/VhostTaskForce#head-7236c4e2c9932ef42056b3ff6d367053081887de
I'm happy to be corrected (I wish this were possible), but it doesn't seem workable to me.
Gavin
Uh, the IP address and port number should good enough; the IP is a hostname also.
Only the HTTP proxy will see or care about the 'hostname' in a CONNECT request, as it's not part of _either_ the HTTP or the SSL connection (the destination web server won't know the difference).
HTTP Connect with the IP and relay the session.
You won't know the hostname, but the SSL proxy doesn't need to.
Since you are not breaking apart the encryption, you just convince the HTTP proxy to connect to the IP and pass along the SSL negotiation and all encapsulated contents unmodified.
The hostname and actual URL are both included in the encrypted stuff that a transparent proxy can't see, but as long as your HTTP proxy responds to the 'CONNECT' with a raw connection to the right IP, the detination server will find the right 'Host:' header inside the HTTP transaction and serve the right content, as per the HTTP protocol.
Publicar un comentario