Closed Bug 1085091 Opened 10 years ago Closed 10 years ago

FQDN host in URL does not match names in the HSTS preload list

Categories

(Firefox :: Untriaged, defect)

Product:
Firefox
Component:
Untriaged
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1065909

People

(Reporter: u520957, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.104 Safari/537.36

Steps to reproduce:

I began capturing traffic with WireShark on my local machine.

I started a fresh instance of the latest version of FireFox (33 at this time) and submitted a request to "http://stripe.com./" by simply typing that address into the location bar and hitting the enter key.

Please note that my test uses the fully qualified domain name (FQDN) with the trailing dot. Technically, "stripe.com" is a relative domain name.

"stripe.com" is listed in the HSTS preload list. The latest version of Chrome (38 at this time) does not send the plain HTTP request for this test scenario.

FireFox made a plain HTTP request to "stripe.com." and that was captured in WireShark (request + response shown below).
This effectively subverts the HSTS preload that was made with the intention to avert such plain HTTP traffic (which could be intercepted and tampered with by, for example, a WIFI evil twin MITM attack).

Captured request + response:

GET / HTTP/1.1
Host: stripe.com.
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Sun, 19 Oct 2014 11:56:17 GMT
Content-Type: text/html
Content-Length: 178
Location: https://stripe.com/

<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>


Actual results:

HSTS preload list entry for stripe.com did not affect a request to "stripe.com.".
Chrome handles this case inconsistently with how FireFox handles it.
I believe the intention of the preload list is to force all Stripe traffic over HTTPS. It's a sticky situation because technically, "stripe.com" != "stripe.com.". But, many people overlook this fact. In practice, FireFox may want to behave similarly to Chrome in this case.
FireFox's certificate name matching also displays a warning where Chrome does not in similar FQDN test cases. Technically, FireFox may be more correct in that the FQDN does not match the relative name, but, I think that is leaving people in a state that they were not realizing/expecting.


Expected results:

FireFox should have not made the request to Stripe's servers over plain HTTP. By getting into the preload list, Stripe is signalling that they want only HTTPS traffic. By using plain HTTP, users are at risk of MITM style attacks.
Also, I just want to be clear that this affects more than just Stripe. I verified that sites corresponding to other entries in the HSTS preload list exhibited the same behavior.
Yes, this is a bug in the name matching. For other things in Firefox the stricter exact matching leads to better security (for example, the same-origin policy: why are the names different? is it an attack taking advantage of a case where relative foo.com is actually different than foo.com. ?). In cases where the browser is trying to apply policy to domains it's the wrong approach.

This bug was previously reported (see bug 1065909 comment 7)
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Flags: sec-bounty-
Resolution: --- → DUPLICATE
Yep, you're right, thanks! Also, thanks for adding "HSTS" to the subject of 1065909; that must be why I didn't find it before I submitted this ticket.
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.