
Websites Must Use HSTS in Order to Be Secure - zoowar
https://www.eff.org/deeplinks/2014/02/websites-hsts
======
ggreer
If you operate a website and want to enable HSTS, you should know about a few
caveats:

1\. You can't go back! As soon as a browser sees Strict-Transport-Security
"max-age=31536000", it will refuse to load your site over HTTP for the next
year.

2\. The includeSubDomains option can cause problems in hard-to-predict ways.
For example, Mailgun lets you set a CNAME for unsubscribe links. If a browser
tries to load the HTTPS version, they'll get mailgun.com's cert, which is
invalid for your domain.

3\. Secure transport doesn't stop XSS, CSRF, etc. There are other headers such
as Content-Security-Policy that can ameliorate some of these attacks. Also,
sanitize!

4\. HSTS is just one part of ensuring secure transport. It's also important to
check your cipher suites. Not all TLS is created equal. SSL Labs is an
extremely useful tool for testing your config:
[https://www.ssllabs.com/ssltest/analyze.html?d=floobits.com](https://www.ssllabs.com/ssltest/analyze.html?d=floobits.com)

If you're curious what the final result of all this paranoia looks like, take
a look at the httpd config for floobits.com:
[https://gist.github.com/ggreer/9984770](https://gist.github.com/ggreer/9984770)

You'll also notice mod_authn_yubikey. We require multi-factor auth (YubiKey +
password) for our admin interface. There's tons of other stuff I could go
into, but the real lesson is that security is like raking pine needles: You
will never be done.

~~~
jackpirate
_You can 't go back! As soon as a browser sees Strict-Transport-Security "max-
age=31536000", it will refuse to load your site over HTTP for the next year._

This sounds like a powerful way to DOS a site if you can set up a temporary
https server on the domain and send this signal.

~~~
schoen
This DoS risk is documented in section 14.5 of the HSTS standard.

[https://tools.ietf.org/html/rfc6797#section-14.5](https://tools.ietf.org/html/rfc6797#section-14.5)

It's true that HSTS could be a way for someone who can set up a seemingly
valid but nonetheless fake HTTPS listener on a domain to prevent people from
later communicating with a genuine HTTP service on that domain.

Three remedies for this, with different degrees of applicability to different
sites:

* Put a CAA record for your domain into your DNS (see [https://tools.ietf.org/html/rfc6844](https://tools.ietf.org/html/rfc6844)) to prevent legitimate certificate authorities from issuing the cert to the impostor. (This only provides protection if the attacker doesn't control your DNS zone.)

* Actually switch to HTTPS!

* If this attack happens to you and you don't want to switch to HTTPS, run a legitimate HTTPS listener on your domain that clears the HSTS status and then redirects users back to HTTP.

------
marcosdumay
Of course, it would help if browsers stopped letting sites put an image at the
same place they show the locker (like they used to)... But that would require
a few more pixels for canvas, and security is a secondary concern (just like
usability).

~~~
agwa
Firefox stopped showing favicons in the URL bar. For HTTP you see a globe; for
HTTPS, a padlock.

~~~
marcosdumay
That's good, and I didn't notice.

------
dazbradbury
Can't a MITM (as described in the article) strip out any HSTS headers
automatically, thus thwarting this quite simply?

As with HTTPS, you need a shared secret _before_ communication begins for
anything like this to combat MITM attacks. Unless the browser communicates
with a secure server to assess whether the website should be sending HSTS
headers... Is that the idea?

~~~
agwa
On the very first connection from the browser to the website, yes. But the
browser saves the HSTS setting (for the time specified by the HSTS header's
max-age value) so future connections go straight to HTTPS.

Chrome and Firefox also ship with a baked-in HSTS preload list containing
sites that should always use HTTPS, without depending on the HSTS header:
[http://src.chromium.org/viewvc/chrome/trunk/src/net/http/tra...](http://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json)

~~~
regecks
It seems silly that Chromium and Firefox now have separate HSTS lists (though
Firefox's was seeded using the Chromium list [1]).

At the moment, these lists appear to be b) tied to specific browsers 2) tied
to specific releases of those browsers.

Would it be viable to run some kind of global open registry where any website
can be registered for mandatory HSTS? That way, every individual website owner
doesn't need to submit a bug to Chromium and Mozilla - the browser just needs
to securely connect to the registry and download the latest list. Or maybe
DNSSEC can help ...

Maybe work on this is already underway, but I was reading some MLs a few weeks
ago and I didn't see any forthcoming solutions ...

1\. [https://blog.mozilla.org/security/2012/11/01/preloading-
hsts...](https://blog.mozilla.org/security/2012/11/01/preloading-hsts/)

~~~
agwa
I believe that Firefox is still generating its HSTS preload list from
Chromium's - a few months ago I got a site added to Chromium's HSTS list and a
few weeks later it showed up in Firefox. I couldn't even figure out how to
submit directly to Firefox.

I agree that a global registry would be better, but it should probably be
updated using the browser's normal update channel, to avoid re-inventing the
wheel. (And DNSSEC has way too many issues.) It's true that ties the list to
specific releases, but since browsers have good, and frequent, auto-updating,
I think that's OK.

------
derefr
One interesting thing I've noticed about HSTS (which is probably a good thing
in the long run, but kind of painful for now): it breaks wi-fi capture-portal
redirects. Try to load
[https://news.ycombinator.com/](https://news.ycombinator.com/) on a fresh
connection to a wi-fi hotspot, and you just get a connection error.

~~~
hdevalence
There's no functional difference between craptive portals and a MITM attack,
so this definitely seems like a feature...

~~~
schoen
Some people have been thinking about creating a standard to distinguish
between the two so that captive portals won't have to do a MITM attack (that
browsers currently correctly defend against). One idea might be to have a
different protocol through which the captive portal can indicate its presence
and declare itself as a captive portal, entirely or almost entirely outside of
the HTTP or HTTPS session.

Getting the UI right is pretty challenging, though. It's not even completely
clear what getting it right would mean. Even if the user clearly understands
that they're interacting with some network operator rather than, say, Gmail or
their organizational webmail server, the user still has no way to know whether
the portal they're talking to is actually operated by the operator of the
network that they think they're connecting to!

~~~
deathanatos
I've wondered this too. Doesn't DHCP support extensible options? Couldn't you
just send an option that said, "hey, crappy portal welcome site at {URL}"?
It'd be fixed to a particular webpage (so, you can't use another protocol),
but that's the state of things today.

~~~
derefr
It seems like there are only two things captive-portals are "for", though:
accepting EULAs, and presenting a login form for the proxy. Both of these
could be _better_ if built into browser/OS chrome.

------
conductor
I would like to point out that HSTS is not compatible with private browsing
because by saving the information that the particular site must be accessed by
HTTPS the browser exposes the fact that the said site was previously accessed.
I hope we will eventually come to required secure HTTP by default with the
next versions of the protocol.

~~~
borplk
Is it not effectively like someone hand-typing the address with HTTPS? how
does it expose anything?

~~~
agwa
Briefly: a page can embed a hidden image with a [http://](http://) URL (with a
different hostname, used just for tracking purposes). If that image gets
loaded over HTTPS, it means the site has been visited before. If it loads over
HTTP, the site hasn't been visited before; it then redirects to the HTTPS
version and sends a HSTS header so on the next visit it goes straight to
HTTPS.

That stores one bit of information. Repeat 32 times (with 32 different host
names) and you can store a unique 32-bit tracking number that persists even
when cookies are cleared.

------
WhiteDawn
For anyone wondering general best practices for setting up HTTPS on
Apache/nginx I found this to be a really great resource

[https://wiki.mozilla.org/Security/Server_Side_TLS](https://wiki.mozilla.org/Security/Server_Side_TLS)

------
wglb
One drastic solution if your web site has lots of IE users: Simply don't
answer the phone on port 80.

[Edit] Duh. As agentS points out, this won't work.

~~~
sliverstorm
I don't think that's helpful. Perhaps more along the lines of putting a flat
redirect on port 80, with no content.

(It sounds like this attack depends on a complete version of the website being
available over port 80)

~~~
agwa
> (It sounds like this attack depends on a complete version of the website
> being available over port 80)

No, it doesn't. An attacker can always connect to the website over HTTPS and
proxy the content to the victim over port 80.

~~~
sliverstorm
Hmm, yes, of course you are correct. I'm not sure why I was thinking that
wouldn't be a risk.

------
tootie
My current client is insisting that all https traffic be served over a
separate subdomain.

------
chris_mahan
Alternatively, make a plain html website and don't ask users to log in and
don't track them with cookies, etc. If you want to collect money from them,
make a real product and mail it to them after they sent you a postal money
order.

Any attempt to defeat that model will be handled by the US Postal Inspection
Service, (see also
[https://postalinspectors.uspis.gov/aboutus/mission.aspx](https://postalinspectors.uspis.gov/aboutus/mission.aspx))

~~~
chris_mahan
Note that if you take their money and don't ship their product as described,
the US Postal Inspection Service will come after you. It protects both sides
from fraud.

------
mch0lic
HTTPS sounds great and s __t but HTTPS won 't help you if you dumb enough to
execute shell commands as a root on your server based on unfiltered user form
inputs... Unfortunately, I noticed that lots of 'idea guys' trust the dev they
hire first even if they have absolutely no skills whatsoever. lOOOl

