Closed Bug 774769 Opened 9 years ago Closed 6 years ago

strict transport security can be defeated by using a FQDN


(Core :: Networking, defect)

Not set





(Reporter: keeler, Unassigned)


Say a user visits "" and receives an sts header. If they later visit "", their connection will not be upgraded to https. For a real-world example, try with "".
well, ok, but internally Gecko treats the two as completely different domains. "" will not share cookies, auth, or anything with "".

I guess you could fool someone into logging in? Of course you'd have to completely intercept and re-route all their communication, because once they connect to the real "" then that version, too, will have the STS upgrade applied on subsequent connections.
I'm not convinced this is a real issue, but if it is it's probably inherent to the spec so I'm unhiding the bug.
Group: core-security
An attack would be tricking the user into clicking a link from a wireless hotspot promising free wireless for sharing their email and actually serving up content that ends up stealing their credentials.
I stumbled across this bug while searching for something else and it explains what I thought was a failure of HSTS. 

I have my bookmarks/favorites/shortcuts set to use https but sometimes there are links from other sources that don't. I've noticed that sometimes I click on an http link to a site that uses HSTS and http appears briefly before changing to https. Since my bookmarks go directly to https and I may have never visited the http site or it may have been so long ago it's past the STS setting TTL.

I wish the setting applied at the domain level regardless of http or https. Ideally I'd like the ability to manage the setting per site like in bug 572803.
This seems to bug 134402.
Unless I'm misunderstanding something, the immediate issue here seems to have been fixed in Bug 1065909.
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: CVE-2015-0832
You need to log in before you can comment on or make changes to this bug.