Re: [squid-users] Using Squid as a reverse-proxy to SSL origin?
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 signature.asc Description: This is a digitally signed message part
Re: [squid-users] Using Squid as a reverse-proxy to SSL origin?
Thank you, Amos and Henrik. I'll be testing this in 2.7/Stable 4 - I assume that's OK (no significant fixes in 3.0 in this area that I should take advantage of)? 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? 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 :-) . -- Todd On Thu, Oct 16, 2008 at 6:15 AM, Henrik Nordstrom <[EMAIL PROTECTED]> wrote: > On ons, 2008-10-15 at 16:42 -0400, Todd Lainhart wrote: >> I've looked in the archives, site, and Squid book, but I can't find >> the answer to what I'm looking to do. I suspect that it's not >> supported. > > It is. > >> My origin server accepts Basic auth over SSL (non-negotiable). I'd >> like to stick a reverse proxy/surrogate in front of it for >> caching/acceleration, and have it accept non-SSL connections w/ Basic >> auth, directing those requests as https to the origin. The origin's >> responses will be cached, to be used in subsequent GETs to the proxy. >> Both machines are in a closed IP environment. Both use the same >> authentication mechanism. > > The basic setup is a plain reverse proxy. > http://wiki.squid-cache.org/SquidFaq/ReverseProxy#head-7fa129a6528d9a5c914f8dd5671668173e39e341 > > As the backend runs https you need to adjust the cache_peer line a bit > to enable ssl (port 443, and the ssl option). > > When authentication is used you also need to tell Squid to trust the web > server with auth credentials > > http://wiki.squid-cache.org/SquidFaq/ReverseProxy#head-c59962b21bb8e2a437beb149bcce3190ee1c03fd > >> I see that Squid 3.0 has an "ssl-bump" option, but I don't think that >> does what I described. If it does, that's cool - I can change the >> requirement of the proxy to accept Basic/SSL. > > sslbump is a different thing. Not needed for what you describe. > > > But you may need to use https:// to the reverse proxy as well. This is > done by using https_port instead of http_port (and requires a suitable > certificate). > > Regards > Henrik >
Re: [squid-users] Using Squid as a reverse-proxy to SSL origin?
On ons, 2008-10-15 at 16:42 -0400, Todd Lainhart wrote: > I've looked in the archives, site, and Squid book, but I can't find > the answer to what I'm looking to do. I suspect that it's not > supported. It is. > My origin server accepts Basic auth over SSL (non-negotiable). I'd > like to stick a reverse proxy/surrogate in front of it for > caching/acceleration, and have it accept non-SSL connections w/ Basic > auth, directing those requests as https to the origin. The origin's > responses will be cached, to be used in subsequent GETs to the proxy. > Both machines are in a closed IP environment. Both use the same > authentication mechanism. The basic setup is a plain reverse proxy. http://wiki.squid-cache.org/SquidFaq/ReverseProxy#head-7fa129a6528d9a5c914f8dd5671668173e39e341 As the backend runs https you need to adjust the cache_peer line a bit to enable ssl (port 443, and the ssl option). When authentication is used you also need to tell Squid to trust the web server with auth credentials http://wiki.squid-cache.org/SquidFaq/ReverseProxy#head-c59962b21bb8e2a437beb149bcce3190ee1c03fd > I see that Squid 3.0 has an "ssl-bump" option, but I don't think that > does what I described. If it does, that's cool - I can change the > requirement of the proxy to accept Basic/SSL. sslbump is a different thing. Not needed for what you describe. But you may need to use https:// to the reverse proxy as well. This is done by using https_port instead of http_port (and requires a suitable certificate). Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [squid-users] Using Squid as a reverse-proxy to SSL origin?
> I've looked in the archives, site, and Squid book, but I can't find > the answer to what I'm looking to do. I suspect that it's not > supported. > > My origin server accepts Basic auth over SSL (non-negotiable). I'd > like to stick a reverse proxy/surrogate in front of it for > caching/acceleration, and have it accept non-SSL connections w/ Basic > auth, directing those requests as https to the origin. The origin's > responses will be cached, to be used in subsequent GETs to the proxy. > Both machines are in a closed IP environment. Both use the same > authentication mechanism. > > I see that Squid 3.0 has an "ssl-bump" option, but I don't think that > does what I described. If it does, that's cool - I can change the > requirement of the proxy to accept Basic/SSL. > > Is this configuration possible, and/or am I thinking about this wrong? > You need to configure an 'https_port' same as you would an http_port, but with added SSL certificate fields. https_port 443 accel then the cache_peer line needs 'ssl' to re-encrypt the link and "login=PASS" (exact string) to pass the login details back to the web server. cache_peer ... ssl login=PASS Ref: http://www.squid-cache.org/Versions/v3/3.0/cfgman/https_port.html http://www.squid-cache.org/Versions/v3/3.0/cfgman/cache_peer.html Amos
[squid-users] Using Squid as a reverse-proxy to SSL origin?
I've looked in the archives, site, and Squid book, but I can't find the answer to what I'm looking to do. I suspect that it's not supported. My origin server accepts Basic auth over SSL (non-negotiable). I'd like to stick a reverse proxy/surrogate in front of it for caching/acceleration, and have it accept non-SSL connections w/ Basic auth, directing those requests as https to the origin. The origin's responses will be cached, to be used in subsequent GETs to the proxy. Both machines are in a closed IP environment. Both use the same authentication mechanism. I see that Squid 3.0 has an "ssl-bump" option, but I don't think that does what I described. If it does, that's cool - I can change the requirement of the proxy to accept Basic/SSL. Is this configuration possible, and/or am I thinking about this wrong? -- Todd