HSTS preload for fastmail.com

rusl · 1 Oct 2015, 09:56 AM

There's a security feature of modern web browsers call HSTS preload. Website operators that want their site to only ever be loaded as HTTPS (not plain HTTP) can do some server tweaks and then submit a request to Chromium/Google for inclusion on a list called the HSTS preload list. This list is shared between the major browsers and it is actually pushed out to the browser through software updates. The browser enforces HTTPS and blocks all HTTP connections with no exceptions to the rule.

The preload list (which is maintained by Google/chromium) is currently about 4000 sites.

Last week I was reading the list to see if my own website had been added and I noticed fastmail.com right there at the bottom of the list - the newest addition. Future browser updates will add fastmail.com to their built-in preload list.

Thanks Team Fastmail. I look forward to the blog post.

BritTim · 1 Oct 2015, 11:40 AM

Very nice. I believe HSTS, besides enforcing https, also has some protections against m-i-t-m attacks.

rusl · 1 Oct 2015, 12:08 PM

I believe it reduces MITM attack surface because initial connection request which comes before the HTTP-to-HTTPS redirect is bypassed by the browser itself - goes straight for HTTPS out of the gate. Or something like that... I'm just a hobbyist computer geek

robn · 1 Oct 2015, 12:41 PM

So slightly repeating above, HTTP Strict Transport Security is a mechanism where a server can signal to a browser that it should only ever be accessed via HTTPS.

If, in a brand new browser profile, you type in "www.fastmail.com", the browser will do an unencrypted HTTP connection. The server will return a redirect:

Code:

HTTP/1.1 301 Moved Permanently
Location: https://www.fastmail.com/

So your browser makes a new request on an encrypted connection and gets (among other things):

Code:

HTTP/1.1 200 OK
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

The browser then remembers that for the next 365 days, all unencrypted requests to www.fastmail.com and its subdomains should automatically be converted to encrypted requests.

This protects against MITM attacks where an attacker intercepts the unencrypted response and redirects you somewhere else. Without HSTS, every time you follow a http:// link to FastMail or use a http:// bookmark or type fastmail.com into into the location bar without using the https:// prefix, there's a risk that this can happen.

So once that's in place, there's still one tiny gap a MITM attack is possible - the very first contact the browser has with the server, before it's ever seen the HSTS header.

That's what the preload list solves. Sites can add the "preload" flag to their HSTS header to indicate that they want to be included on the preload list, and then request to be added. Once the request is approved, future versions of browsers will have the domain in the list and will _never_ use an unencrypted connection, so that particular class attacks of attacks can never succeed.

More info at OWASP.

n5bb · 1 Oct 2015, 02:56 PM

Rob, could you come up with a system to force HSTS (ideally preloaded) for https: links to Fastmail file storage? Currently the user link becomes a subpath under https://user.fm/, and I don't think that any HSTS is used for that domain. See this EMD thread.

Bill

robn · 1 Oct 2015, 09:12 PM

Quote:

Originally Posted by n5bb

Rob, could you come up with a system to force HSTS (ideally preloaded) for https: links to Fastmail file storage? Currently the user link becomes a subpath under https://user.fm/, and I don't think that any HSTS is used for that domain. See this EMD thread.

All HSTS does is force a browser to use the HTTPS variant when HTTP is requested. In the scenario described in the other case, the concern is over a user fiddling the URL to go to the domain version of the site, which doesn't have a HTTPS variant. HSTS wouldn't help there.

We could set up HSTS to force http://user.fm/... to go to https://user.fm/..., but I'd need to think about it a bit first and study the access logs to understand what the impacts might be. That's not a high priority for me right now.

David · 2 Oct 2015, 01:30 AM

I used to use old Linux web browsers (such as Lynx & w3m) in the past, that did not support https (possibly some folk still do this) though I do not do this now.

kijinbear · 2 Oct 2015, 09:44 PM

Quote:

Originally Posted by David

I used to use old Linux web browsers (such as Lynx & w3m) in the past, that did not support https (possibly some folk still do this) though I do not do this now.

Recent versions of Lynx can open https websites just fine.

jhollington · 8 Oct 2015, 04:01 AM

So is there something specifically new about HSTS that I'm missing? It sounds like this isn't anything more than a simple 301 redirect on the web server instance running on port 80.... (something I've been doing for clients with webmail servers for over a decade now

)

neilj · 8 Oct 2015, 04:46 AM

HSTS means that after the first connection (where it receives the HSTS header), the browser will never allow a non-encrypted connection to FastMail again. If you click a non-HTTPS link, the browser will automatically rewrite it to https –*it won't bother to connect to FastMail over an unencrypted connection first (which would result in a redirect). This prevents man-in-the-middle attacks.

The HSTS preload list fixes the final risk of that first connection.

1 Oct 2015, 09:56 AM	#1
rusl Member Join Date: Mar 2015 Posts: 78	HSTS preload for fastmail.com There's a security feature of modern web browsers call HSTS preload. Website operators that want their site to only ever be loaded as HTTPS (not plain HTTP) can do some server tweaks and then submit a request to Chromium/Google for inclusion on a list called the HSTS preload list. This list is shared between the major browsers and it is actually pushed out to the browser through software updates. The browser enforces HTTPS and blocks all HTTP connections with no exceptions to the rule. The preload list (which is maintained by Google/chromium) is currently about 4000 sites. Last week I was reading the list to see if my own website had been added and I noticed fastmail.com right there at the bottom of the list - the newest addition. Future browser updates will add fastmail.com to their built-in preload list. Thanks Team Fastmail. I look forward to the blog post.

1 Oct 2015, 12:41 PM	#4
robn Master of the @ Join Date: May 2012 Location: Melbourne, Australia Posts: 1,007 Representative of: Fastmail.fm	So slightly repeating above, HTTP Strict Transport Security is a mechanism where a server can signal to a browser that it should only ever be accessed via HTTPS. If, in a brand new browser profile, you type in "www.fastmail.com", the browser will do an unencrypted HTTP connection. The server will return a redirect: Code: HTTP/1.1 301 Moved Permanently Location: https://www.fastmail.com/ So your browser makes a new request on an encrypted connection and gets (among other things): Code: HTTP/1.1 200 OK Strict-Transport-Security: max-age=31536000; includeSubDomains; preload The browser then remembers that for the next 365 days, all unencrypted requests to www.fastmail.com and its subdomains should automatically be converted to encrypted requests. This protects against MITM attacks where an attacker intercepts the unencrypted response and redirects you somewhere else. Without HSTS, every time you follow a http:// link to FastMail or use a http:// bookmark or type fastmail.com into into the location bar without using the https:// prefix, there's a risk that this can happen. So once that's in place, there's still one tiny gap a MITM attack is possible - the very first contact the browser has with the server, before it's ever seen the HSTS header. That's what the preload list solves. Sites can add the "preload" flag to their HSTS header to indicate that they want to be included on the preload list, and then request to be added. Once the request is approved, future versions of browsers will have the domain in the list and will _never_ use an unencrypted connection, so that particular class attacks of attacks can never succeed. More info at OWASP.

1 Oct 2015, 02:56 PM	#5
n5bb Intergalactic Postmaster Join Date: May 2004 Location: Irving, Texas Posts: 8,925	Could HSTS be added for file storage links? Rob, could you come up with a system to force HSTS (ideally preloaded) for https: links to Fastmail file storage? Currently the user link becomes a subpath under https://user.fm/, and I don't think that any HSTS is used for that domain. See this EMD thread. Bill

1 Oct 2015, 11:40 AM	#2
BritTim The "e" in e-mail Join Date: May 2003 Location: mostly in Thailand Posts: 3,090	Very nice. I believe HSTS, besides enforcing https, also has some protections against m-i-t-m attacks.

1 Oct 2015, 12:08 PM	#3
rusl Member Join Date: Mar 2015 Posts: 78	I believe it reduces MITM attack surface because initial connection request which comes before the HTTP-to-HTTPS redirect is bypassed by the browser itself - goes straight for HTTPS out of the gate. Or something like that... I'm just a hobbyist computer geek

2 Oct 2015, 01:30 AM	#7
David Ultimate Contributor Join Date: Dec 2001 Location: Canada. Posts: 10,355	I used to use old Linux web browsers (such as Lynx & w3m) in the past, that did not support https (possibly some folk still do this) though I do not do this now.

8 Oct 2015, 04:01 AM	#9
jhollington Essential Contributor Join Date: Apr 2008 Posts: 371	So is there something specifically new about HSTS that I'm missing? It sounds like this isn't anything more than a simple 301 redirect on the web server instance running on port 80.... (something I've been doing for clients with webmail servers for over a decade now )

8 Oct 2015, 04:46 AM	#10
neilj Cornerstone of the Community Join Date: Apr 2004 Location: Melbourne Posts: 971 Representative of: Fastmail.fm	HSTS means that after the first connection (where it receives the HSTS header), the browser will never allow a non-encrypted connection to FastMail again. If you click a non-HTTPS link, the browser will automatically rewrite it to https –*it won't bother to connect to FastMail over an unencrypted connection first (which would result in a redirect). This prevents man-in-the-middle attacks. The HSTS preload list fixes the final risk of that first connection.