[squid-users] Accelerator Mode - HSTS and Redirect

[Amos Jeffries]

On 24/09/2016 10:25 a.m., squid wrote:
> Thank you.  Just want to make sure I understand before we dive in.
> 
> On Thu, Sep 22, 2016, at 09:03 PM, Amos Jeffries wrote:
>> On 23/09/2016 12:45 p.m., creditu wrote:
>>> We have been using squid in accelerator mode for a number of years. In
>>> the current setup we have the squid frontends that send all the http
>>> requests to the backend apache webservers using a simple redirect
>>> script.  We need to switch to https for the public presence.
>>
>> redirect/rewrite script is very rarely a suitable way to do this for
>> reverse-proxy.
>>
>> Use cache_peer to configure what backend servers exist and
>> cache_peer_access rules to determine which one(s) any given request can
>> be sent to.
>>
>> The backends should be capable of accepting the traffic as if the proxy
>> were not there. If for some reason it has to have a different domain
>> name (actual need for this is rare), then the cache_peer forcedomain=
>> option can be used.
>>>
>>> So, our initial thought would be to use https_port for public HTTPS
>>> presence and send the requests using cache_peer to the backend apache
>>> servers using plain http.  Basically terminating HTTPS from clients and
>>> relaying it to backend servers using HTTP.  
>>>
>>> We will need to implement HSTS at some point (i.e.
>>> Strict-Transport-Security: max-age=8888; includeSubDomains; preload),
>>> will we be able to do this in the above scenario.
>>
>> Yes. Provided you can get rid of that redirect/rewrite script. The
>> background things cache_peer logic does to the traffic will be needed
>> for the HTTPS transition.
> 
> We will get rid of the script, but, not sure I understand the rest of
> the statement.  Can you elaborate?

By "background things" I mean the code inside Squid. reverse-proxy logic
does things to the request and reply when sending to a peer that are not
done on DIRECT requests to servers.

> Since  HSTS is only set when there
> is a secure connection it seems that I would have send to the backend
> via https and set the Strict-Transport . . . header on the backend
> Apache servers (ssl.conf) so the reply would be sent back to the
> Internet user via Squid?

No. The reply is sent back along the same TCP connection the request was
received over. Always.

For a reverse-proxy it does not matter if that connection happens to be
TLS encrypted or not.

If the cache_peer line in squid.conf says to use port 80 that will be
the server port used. Likewise it could say port 443 and use TLS to get
there. The server connection is completely independent from the client
connections.

HSTS simply tells clients to not bother using http:// to contact the
domain. Always to try https:// first. A properly setup reverse-proxy
does not care about HSTS. It will simply listen on the port it is
configured to listen on and send to the server it is configured to send to.



>>
>>> Also, we will initially be providing both http and https, but will need
>>> to stop http at some point.  Is there a way to redirect the clients that
>>> try to connect via http to use https with squid?  Something like the
>>> rewrite engine in apache?
>>
>> cache_peer can be configured to contact the peer over TLS. This can be
>> done individually, and before the HSTS gets added for public viewing.
> 
> I'm sure I'm missing something here.  What I will need to do is force
> Internet users who come to us over via http to use https instead. 
> Something like what happens when someone types http://www.google.com
> they get sent to https://www.google.com. This is pretty simple going
> straight to an Apache server, but I haven't seen a way to do it directly
> with Squid.  In a very quick test on some non-production systems I sent
> a http request through the squid and did the redirect on the backend
> Apache server.  I assume in the Apache config I would do something like
> this:
> 
> VirtualHost *:80>
>    ServerName www.example.com
>    Redirect permanent / https://SquidPublicIP/
> </VirtualHost>
> 
>  Just trying to understand how this would work.  Thanks Again. 

Squid would listen on port 80 and 'deny' any traffic arriving in that
port with a 30x redirect pointing at the relevant https:// URL.

 http_port 80 accel
 acl HTTP proto HTTP
 deny_info 301:https://%H%R HTTP
 http_access deny HTTP

Zero involvement from the server.

The current releases of Squid should be able to also add a static STS
header to the denial reply if you want to use HSTS.

But that is all for later. First get the proxy connected to the server
working with the traffic (HTTP-only?) that your site receives _right now_.

Amos