Firefox 4: HTTP Strict Transport Security (force HTTPS)

This article is about a new HTTPS header: Strict-Transport-Security, which force a website to be fetched through HTTPS. This feature will be part of Firefox 4.

How do you type URLs?

Do you prefix them with http:// or https:// systematically? Or do you just type example.com and let your browser add http://, like most of the people do?

If a web page provide has an https version but you access it through http, what happens? The http version of the Website re-direct you to the https, but you first talked to the non-encrypted version of the website.

These behaviors can be exploited to run a man-in-the-middle attack.

To avoid this, you may want to force your website to be visited through https to transform any http://x.com request to https://x.com (with no client-server dialog).

Sid Stamm recently integrated HTTP Strict Transport Security (HSTS) into
Firefox. HSTS, specified in an IETF draft, allows sites to specify when they wish to be accessed only over https.

A website can specify strict transport security for their domain via an HTTP header sent by the server set during an HTTPS response:

Strict-Transport-Security: max-age=15768000

Strict-Transport-Security: max-age=15768000 ; includeSubDomains

max-age sets how long to remember the forced HTTPS (seconds). If
includeSubDomains is set, then this rule will apply to all the sub-domains too.

In the future, any requests to x.com are modified to be via https if they are attempted through http before the request hits the network.

This header is not considered during a non-encrypted HTTP transaction because the User-Agent doesn’t know if the https actually exists and also because the header can be injected by an attacker.

Paul is a Firefox developer.

paulrouget.com

41 comments

zoonman

This is a really good idea, tell browser about HTTPS, but HTTPS is create greater load on server than regular HTTP. This no good decision for highload projects, social and media network.

August 26th, 2010 at 10:59
1. kl
  
  This has been debunked. Gmail switched to all-HTTPS and used only 1% extra CPU.
  
  http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
  
  July 12th, 2011 at 15:01
Ferdinand

@ zoonman Guess you didn’t read the article where they mention that the website has to choose to enable this feature.

August 26th, 2010 at 14:00
1. zoonman
  
  Your right!
  
  August 26th, 2010 at 22:51
Tomer

Why this is good for? I prefer, for example, the secured version of Twitter to be persistent. Why is it better than just forcing the site to serve us content over HTTPS?

August 26th, 2010 at 14:23
1. Sid
  
  @Tomer: I think you have in mind those security-savvy users who intentionally access a site over HTTPS because they wants to protect themselves. HSTS helps sites protect *all* their users (not just the security-savvy ones) by telling the browser to use HTTPS by default. The goal is to give a tool to the sites so they can silently protect their users from these MITM attacks.
  
  Perhaps in an ideal world all sites would use HTTPS, or that would be the default, but this is not the case. As @zoonman mentioned, it’s not always important or even sometimes impractical.
  
  August 26th, 2010 at 16:38
  1. Tomer
    
    I do prefer to choose HTTPS connection by myself, as some sites do not transfer us automatically to the secured version, and even doesn’t restrict cookies being set-up on the secured zone to only the secured zone. Telling people to access the regular version to see if the site suggest switching to HTTPS is less secured, as it require an HTTP request, which may transfer the user authentication cookie in plain text.
    
    How is it better than using HTTP 101 SWITCH status code?
    
    August 26th, 2010 at 23:53
    1. Sid
      
      @Tomer: The HTTP 101 SWITCH status code works most of the time, but when a user is on an unsafe network a man-in-the-middle attacker could intercept that response causing the user to instead see an HTTP copy of the site controlled by the attacker.
      
      With HSTS, the user only has to get to the HTTPS version of the site once (probably using the HTTP 101 reply you mention), where the Strict-Transport-Security header is provided to the browser. After that, the browser will automatically assume HTTPS for that site in the future greatly reducing chance of man-in-the-middle attacks and also reducing the number of insecure HTTP requests sent to their server.
      
      In general, *you* are going to be mostly protected already since you manually pick HTTPS, but for those users that don’t notice security indicators this is a way for the site to help them out.
      
      August 27th, 2010 at 07:47
James

@Tomer: HTTP 101 is issued as a request sent by the client to the server. HSTS is a request sent by the server to the client.

@Sid: Thanks for your hard work. I know that PayPal was involved in the development of the draft, but I wish you had used another example domain but x.com.

August 27th, 2010 at 00:28
annie

Will force HTTPS prevent the likes of the Palo Alto Application Firewall from performing a man in the middle attack so that it can decrypt and analyse the HTTPS traffic. As the Palo Alto Application Firewall can intercept all HTTPS traffic by providing its own certificate to the client browser, and then using its own certificate to connect to the website and thus perform a man in the middle attack for traffic analysis. Can DNS-Sec be used in conjunction with HTTPS for certificate verification, so that a browser can perform a DNS query to obtain to obtain the encrypted checksum of the valid certificate. If the HTTPS certificate checksum does not match the encrypted DNS-Sec record, the browser indicates a “Security Violation – Man in the middle attack detected”

August 29th, 2010 at 01:08
1. Sid
  
  @annie: I don’t know the specifics of how the firewall works, but the firewall will have to get valid certificates for each site it intercepts that chain up to the root certificates in Firefox. Self-signed certificates will result in the usual “connection error” page, but for HSTS hosts, the user won’t be able to ignore the warning and will have no way to access the site via the erroneous certificate.
  
  Potentially DNS-Sec could be useful, but we’re still exploring how that can be used to tighten site security in conjunction with features like HSTS.
  
  August 31st, 2010 at 08:55
Sten

Hi *

A simple DNS spoof will IMHO bypass HSTS.

Keep also in mind that a SSL connection based on server certificate only is also vulnerable for MiM attacks.

No, HSTS is not the solution. We must find something better.

g,
sten

August 29th, 2010 at 04:42
Mike

Since users are generally uneducated in the use of browsers and internet, I doubt HSTS will prevent Man-in-the-Middle.
Main reason being that users will frequently still trust an untrusted SSL certificate and simply click yes.

Also enforcing HTTPS will not solve the problem from an information point of view.
Frequently a website’s HTTP pages contain different information than the HTTPS version of the website.

August 30th, 2010 at 23:12
Sid

@Sten: While DNS spoofing will throw things off a bit, that attack still requires the attacker to get a valid certificate for the spoofed site that chains up to a CA in Firefox.

@Mike: for brevity and to not bore non-technical audiences, I omitted some technical details in the blog entries. If you look at the spec, HSTS means more than just “access me over https in the future”. It also requires the browser to drop the connection with *no recourse* if an invalid cert is encountered. This means if mozilla.org is an HSTS host, not only will HTTPS connections be automatic, but any self-signed, expired, or otherwise erroneous certificate will cause the connection to drop and the users won’t be presented with a prompt to get around the blockage.

In our specific implementation, the usual certificate error page has an “add exception” button for users who “know what they’re doing.” If the connection being stopped is for an HSTS host, that button won’t be there. (Also, if an invalid certificate exception was added in the past, it will be ignored once the host has been given HSTS status.)

August 31st, 2010 at 08:52
Sten

@sid: No, after spoofing DNS I will use vanilla HTTP connection.
Simple and effective.

@mike: I agree with you about the (ICT) ignorance of the end user.

September 1st, 2010 at 01:47
1. Sid
  
  @Sten: If you spoof the DNS record, you get to control the traffic, but the browser will still require HTTPS to all hosts (regardless of the IP address) that have HSTS set. For example, if I go to https://useshsts.com at home, where Firefox sees that the site wants HSTS. I then go to a cafe where you spoof DNS and redirect me to your site, my browser will refuse to let me connect to your site over HTTP since it requires a valid, secure HTTPS connection to useshsts.com.
  
  Maybe I misunderstand the attack, can you elaborate?
  
  September 1st, 2010 at 15:35
Sten

@sid: You discribe a cashed data from previous connection. In that case you might be protected.
My attack will work when this cache is non existing.
HSTS will lookup the DNS to determine if HSTS action is required.
Now if I spoof the DNS, and I mean DNS spoof, not IP spoofing using ARP spoof for example, I will gain control.
The browser will not use HSTS simply by the fact that the spoofed DNS will not ask the browser to do so.

How do you solve the following situation?
Website used HSTS in the past but wants to stop using it. The users are unable to connect? the HTTP site because of the cashed data?!

September 2nd, 2010 at 12:10
1. Sid
  
  @Sten, yes, for HSTS to work you have to successfully visit the real site via HTTPS once.
  
  HSTS isn’t tied into DNS at all, so I’m not sure how that ties into your attack. The server’s indication to use HSTS comes through HTTP.
  
  To prevent the bootstrapping need, we could pre-load sites that want HSTS when we ship Firefox — much like the CA roots, these are sites that will never be requested over HTTP. Additionally, we could add a UI so users can set up HTTPS-only-access for sites that they want to only access over HTTPS (and we’re working on this).
  
  A site’s Strict-Transport-Security header is considered from each HTTPS response that Firefox sees. The most recent data from that header is understood to be an update for the site’s preference. If a site wants to stop using HSTS, it can set “max-age=0” to tell the browser not to remember HSTS for the site.
  
  September 2nd, 2010 at 13:57
Sten

@sid: Sorry, somehow I mixed DNS sec and HSTS.

The preload described by you will solve the security issue we discussed previously. Also the attack scenario is less or more academical. The very first visit must be the spoofed one…The distribution will probably create more pain than it will cure.

Let’s look at the following situation:
The hacker will spoof the original website (DNS spoof) and provide the
max-age=0 when the browser request arrives at the evil web server page.

September 2nd, 2010 at 14:30
1. Sid
  
  @Sten: The situation you mention shouldn’t happen. Once HSTS is set for a site, connections will only be made via HTTPS and only if the HTTPS connection has no errors. Not only that, but the Strict-Transport-Security header is ignored unless the connection is over HTTPS and there are no certificate errors (regardless of whether or not the site already has HSTS set). That means the attacker will need to have a valid SSL certificate for the site he is spoofing in order to change the HSTS state of the site.
  
  September 2nd, 2010 at 14:36
Sten

@sid: Ok, this sounds good. The software in the browser takes actions in stead of the user. Good because the joe user is not a security expert.
HSTS looks promising, you convinced me… at least 4 now ;-)

September 2nd, 2010 at 14:55
Mike

@Sid

Thanks for the additional explanations.

Just wondering: HSTS is triggered server side and drops the connection when “something” is wrong. IE the certificate.

What will be the HSTS effect when the server has the correct certificate, yet the user does not?
I.e. the server requires a user to have a valid certificate to access the contents of the HTTPS site.
I’m assuming the first time you visit the site, it will drop the connection since “something” is wrong. Yet what happens when the user visits the 2nd time when he does have a valid certificate?

Slight variation 1: What happens when the certificate of the site expires while the user is visiting the site, after the HSTS verification?

Slight variation 2: What happens when the certificate of the user expires while the user is visiting the site, after the HSTS verification?

Would variation 1&2 follow regular behaviour as without HSTS, or will HSTS result in a different behaviour compared to what we are used to now?

September 2nd, 2010 at 15:28
1. Sid
  
  @Mike: HSTS doesn’t deal with client certificates.
  
  HSTS also does not remember what certs it has seen in the past; it only kicks in when the certificate being used for a connection does not chain up to a root in the browser _and_ the host has requested HSTS status. At that point, all that matters is that (1) the certificate chain is valid and (2) the certificate is authorized for encrypting communication for the given host.
  
  Variation 1 (server cert expiry during connection): results in the same behavior as without HSTS. HSTS is only enforced when a connection is being established.
  
  Variation 2 (client cert expiry during connection): results in the same behavior as without HSTS; HSTS doesn’t affect client cert behavior.
  
  September 2nd, 2010 at 16:35
Pat

With HSTS what is the best way for my wireless captive portal to handle users who have https as their home page? I need them to be redirected to the portal authentication page prior to accessing the network.

If my site intercepts with its own certificate what will firefox 4 do? Prior to HSTS the browser would give the certificate warning and users could click through.

September 6th, 2010 at 09:04
Pat

Is it part of beta 4?

September 6th, 2010 at 09:15
1. Sid
  
  @Pat: HSTS is in beta 5.
  
  Your captive portal will continue to work for https home pages that are not actively using HSTS, but for those that do, there will be no “add exception” button on the https error page.
  
  I would prefer alternatives to asking users to intercepting with your own certificate for a captive portal landing page, because that is effectively asking the user for rights to intercept their encrypted home page traffic. Instead, you could ask the users to initiate a connection to your portal site directly– which will work happily in parallel to home pages that use HSTS.
  
  September 8th, 2010 at 09:24
  1. Pat
    
    I agree that intercepting with our certificate is not a good method. In fact although we have tested and it “works” we have not deployed it as it is a bad practice.
    
    Our FAQ does let users know to use a non-secure web site to get redirected. Unfortunately some users never get passed the timeout with https. They assume it is a network issue.
    
    There are a couple of other options:
    
    – On the HSTS error page can you list something to the effect of “if you are connecting via a WiFi hotspot you may need to register before connecting to the network.” Possibly include a url to Mozilla FF FAQ. If the user selects the Mozilla FF url they will get redirected.
    
    – Could the browser detect the WISPr tags and let the user know they are connecting via a WiFi hotspot?
    
    September 8th, 2010 at 12:53
    1. Pat
      
      Just to clarify, in a wifi hotspot scenario, when the HTTPS request times out it would be very helpful if the browser error page implemented either of the above suggestions.
      
      September 8th, 2010 at 16:01
  2. Pat
    
    Sid,
    
    I tested beta5 and HSTS works as expected. When I intercepted with our certificated I received the warning page with no click through capability. In fact clicking the “get me out of here button” does cause the user to get redirected to the WiFi hotspot.
    
    It would be nice if the browser timeout page had a similar button.
    
    September 9th, 2010 at 12:11
    1. Audin Malmin
      
      Indeed, this is becoming more and more important. Captive portals are becoming more painful to develop and use as features such as these are implemented without forethought. “Enhanced Security” Certs are another feature which causes huge problems for captive portals. It will frequently simply cause the browser to apparently freeze up. Not the ideal UI treatment…
      
      November 2nd, 2010 at 16:44
Hans W.

@Pat: Intercepting like this is a bad idea for a number of reasons, you should stop doing it.

September 8th, 2010 at 05:36
1. Pat
  
  @Hans: This is testing only. We don’t do it in production. Still need a way to handle https users though. Many people do not know what to do when the https request times out.
  
  September 11th, 2010 at 07:29
zink

Is there any option in about:config to disable HSTS?

September 8th, 2010 at 12:30
steven olson

YOUR FIREFOX DOWNLOAD IS CROUPT NO GOOD SO CAN YOU FIX YOUR FIREFOX FILES
THEY DONT WORK

September 17th, 2010 at 08:08
Joshua

Is there an about:config option for disabling this feature? I’d like to use Firefox 4 beta 6 from behind a proxy, but this isn’t possible for HTTPS sites without entering private browsing.

October 20th, 2010 at 09:26
Doug Wright

Is there a way of telling Firefox to “forget” about any HSTS headers it’s seen for a particular site? Would seem to be quite important for QA/testing of a site.

November 4th, 2010 at 07:56
Ano Nym

It just took me two hours to figure out why all at once HTTP requests to my server were performed as HTTPS requests. I had to debug entries in permissions.sqlite.

Thank you for implementing this valuable feature.

December 19th, 2010 at 08:07
valchazzz

And what will be, when max-age runs out? If hacker present again hacked HTTP page, when max-age runs out? Browser will force check Strict-Transport-Security header in HTTPS site, or stays on hacked HTTP page?

January 6th, 2011 at 09:14
Jason

With the speed of today’s servers, the load for HTTPS is tiny.

March 16th, 2011 at 08:23
Leandro

The new Iframe-app tabs in facebook pages can´t been seen with Firefox 4 because of all this… I´m a big fan of FF, but going against facebook it has no future

April 1st, 2011 at 15:06
ouinonoui

Dont understand this weird attitude.

“””
If a web page provide has an https version but you access it through http, what happens? The http version of the Website re-direct you to the https, but you first talked to the non-encrypted version of the website.
These behaviors can be exploited to run a man-in-the-middle attack.”””

I do need to be explained a little more precisely that part?

https is secure or not? How because we ask a page http://x.com before https://x.com is not anymore secure?

How can this link to wikipedia article man_in_the_middle apply?

If reasons are so light, is HSTC secure too? What are we doing, always changing things with no reasons?

June 14th, 2011 at 03:29

Comments are closed for this article.

Hacks

By Paul Rouget

About Paul Rouget

41 comments

Firefox 4: HTTP Strict Transport Security (force HTTPS)

By Paul Rouget

About Paul Rouget

Discover great resources for web development

Thanks! Please check your inbox to confirm your subscription.