On tor, 2008-10-16 at 10:56 -0400, Todd Lainhart wrote:
> Could I do the same thing with SSL to the reverse proxy? That is, the
> reverse proxy is the endpoint for the client, gets the creds, becomes
> the endpoint for the server, decrypts and caches the origin response,
> and then serves cached content encrypted back to the client?
Yes.
> I would
> guess this falls into man-in-the-middle style ugliness, is
> out-of-bounds for SSL and so wouldn't be supported. But then again I
> was wrong about my original use-case not being supported :-) .
It's supported, and not a man-in-the-middle attack as the reverse proxy
is the administrative endpoint, and as far as the user is concerned is
the authoriative server. The fact that this web server happens to use
HTTP (or HTTP over SSL) to fetch it's content is an implementation
detail.
You'll need a valid certificate on the reverse proxy. The certifiate on
the actual web server may be self-signed or by an internal CA, not
visible to the end-user, only the reverse proxy.
There is one notable limitation however, and that is that the origin
server can not request SSL client certifiacates from the end-user.
because the SSL is terminated at the reverse proxy there is no SSL
between web server and end-user. The proxy can request client
certificates, and may also relay details about the user provided
certificate (not sure such relaying is implemented by Squid yet). The
proxy can also present it's own client certificate to the web server
provint authenticity that it's really a trusted reverse proxy.
Regards
Henrik
This archive was generated by hypermail 2.2.0 : Sat Oct 18 2008 - 12:00:03 MDT