[squid-users] reply_header_access for Strict-Transport-Security doesn't work
Amos Jeffries
squid3 at treenet.co.nz
Tue Mar 12 16:45:54 UTC 2019
On 13/03/19 3:57 am, leomessi983 wrote:
> Hi
> I compiled squid with this options:
>
>
> ./configure \
> --with-openssl \
> --enable-ssl-crtd \
> --prefix=/usr \
> --enable-linux-netfilter \
> --with-netfilter-conntrack \
> --exec-prefix=/usr \
> --includedir=/usr/include \
> --datadir=/usr/share/squid \
> --libdir=/usr/lib64 \
> --libexecdir=/usr/lib64/squid \
> --localstatedir=/var \
> --sysconfdir=/etc/squid/ \
> --sharedstatedir=/var/lib/ \
> --with-logdir=/var/log/squid/ \
> --enable-ltdl-convenience \
> --enable-http-violations
>
> but when i use "request_header_access Strict-Transport-Security deny
> all" in my squid.conf its doesnt work?
>
> What is wrong?
Strict-Transport-Security is an instruction from the server to the
client. That makes it a *response* header.
> I want to block https request and show block page for them,but for some
> sites like bing.com or google.com i got "HSTS Error" in my client!!
> What can i do?
>
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.
Please be aware the HSTS header have a time period associated. Once a
client has received the header via *any* connection (including non-HTTP
connections). It will complaining about HSTS errors until the period
expires, maybe a bit longer.
That means you need to test it with clients that can erase their HSTS
information cache explicitly. Find a site with short HSTS timeout to
test with. OR wait up to 7 days between each test request.
Amos
More information about the squid-users
mailing list