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
Attachment:
signature.asc
Description: This is a digitally signed message part
