[squid-users] reply_header_access for Strict-Transport-Security doesn't work

[Amos Jeffries]

On 13/03/19 8:10 am, leomessi983 wrote:
> Hi Amos,tank you for your reply!
> 
>> Current Squid automatically erase that header to prevent HSTS breaking
>> web traffic. Where possible try to get clients to upgrade to Browsers
>> which have also dropped use of the feature.
> 
> My clients have last Firefox browser but when i use squid and bumb sites
> for my block sites my client get HSTS error and squid doesn't
> automatically erase that header!
> Should i enable some feature or something else in squid configuration?


If your Squid is not removing it then add config like you had earlier.

BUT use the reply header directive instead of the request one:

 reply_header_access Strict-Transport-Security deny all



> How can i know that squid does that automatically?!

The header named "Strict-Transport-Security" should not exist in HTTP
response messages delivered by Squid to any client.

Note that HTTPS messages delivered inside CONNECT tunnels are not
touched by Squid in any way unless SSL-Bump features are being used.

Also that modern web traffic can be using any one of 5 protocols for
messaging (SPDY, HTTP/2, QUIC, HTTP/3 and WebSockets) over which Squid
has no control. If any of those are in use they act as side-channels
where the HSTS header can be delivered to the client despite anything
Squid does.


> Is certificate and certificate type is important?!
> 

Not as far as I know. This HSTS is just a requirement to use secure
connections in place of plain=text HTTP connections.

Amos