Transparent Forward Proxies

Webmaster Discussion
#1

I just had a user tell me they couldn’t connect to my site, because my certificate was bad, but that wasn’t the problem at all…

[ATTACH=JSON]{“alt”:“Click image for larger version Name: bbbh-cert-problem.jpg Views: 1 Size: 28.0 KB ID: 297130”,“data-align”:“center”,“data-attachmentid”:“297130”,“data-size”:“custom”,“height”:“600”,“title”:“bbbh-cert-problem.jpg”,“width”:“337”}[/ATTACH]

I knew something was off because the site was working for me, and SSL Labs rates the cert as A+.

After investigating it, I’m pretty sure what’s happening is that the person’s network admin (or ISP) has a “transparent forward proxy” set up. Transparent forward proxies are supposed to be invisible to the user (hence “transparent”), but they let the network owner see what’s being transmitted over their network (more than just the domain name that’s transmitted in clear text thanks to SNI). Basically they’re content filters.

I have HSTS (HTTP Strict Transport Security) set up on my sites, and when a transparent forward proxy encounters a site with HSTS what they’re doing fails and when they try to give a faked cert back to the user it results in a message like the one above. The faked certificate is because, in a corporate environment, when corporation owns/manages the devices on the network they can set up the device so that it will accept the faked certificate. But when a user brings their own device onto the network that hasn’t been configured to accept the faked cert, you’ll get an error like the one above.

So if you care about the privacy of your users, you should absolutely set up HSTS. Otherwise they could get fired, etc. for viewing your site. And if it’s a government who’s set up the transparent forward proxy, they could go to jail or get killed for viewing your site.

[There’s still the SNI problem, but as I mentioned the other day, ESNI looks like it will eventually fix that problem.]

bbbh-cert-problem.jpg

#2

Have to check this one out. Thanks for the tip!

#3

One thing I should mention… Turning on HSTS commits you to always having the entire site encrypted. You can’t go back to not having the site encrypted or even serving a few pages without encryption – at least not for the length of time that you commit to in the HSTS declaration.

You can turn on HSTS via an Apache directive or in code. Here’s what it looks like in PHP code:

[I]header[/I]([B]'Strict-Transport-Security: max-age=10916298'[/B]); [I]//set it for 18 weeks – 1/3rd of a year[/I]

Here’s what it looks like in Apache (e.g. .htaccess):

Strict-Transport-Security: max-age=10886400; includeSubDomains; preload

The “includeSubDomains; preload” portion is optional. includeSubDomains does exactly what it sounds like. “preload” means Google can add it to lists it maintains. If you’re on the list browsers that use the list will never try to access your site with HTTP – they’ll always use HTTPS, even on the first request and even if they’re following a link that’s HTTP.

The max-age is important as well. When I said you can’t turn off HTTPS, even for one page, the max-age is the time period your committing to. It means that a browser who sees the HSTS directive will not send an HTTP request for that period of time into the future. There are standards for how long max-age should be. Setting it too short is seen as a problem. I think you have to do at least 18 weeks to get onto the preload list. That’s what I use (even though I’m not on the preload list).