Closed Bug 969758 Opened 8 years ago Closed 8 years ago
Ignore "snionly" property of entries in Google's HSTS preload list
// snionly: (optional bool) if true then this entry is only enforced if TLS is // enabled because the site in question only serves the correct // certificate if SNI is sent. Note that this only covers the case where // TLS has been disabled by explicit configuration. If TLS was disabled // because of SSLv3 fallback, then the entry is still in force and a // fatal certificate error will result. Spurious certificate errors are // an unfortunate result of SSLv3 fallback. From: https://mxr.mozilla.org/mozilla-aurora/source/security/manager/tools/getHSTSPreloadList.js: 141 let forceInclude = (host.forceInclude || 142 (host.pins == "google" && !host.snionly)); we should remove the "&& !host.snionly". We don't need to worry about the case where the user has only enabled SSL 3.0.
> We don't need to worry about the case where the user has only enabled SSL 3.0. Is this because Firefox doesn't evince the option to disable TLS? (Chrome doesn't either any longer for that matter, although we did at the time.) These sites are likely to stop working until TLS is enabled, although perhaps that's reasonable.
I starred this because it's keeping gmail.com from getting *any* HSTS in Firefox unless Google starts sending the header. Lots of people type this into the URL bar to access gmail, so it's relatively easy to sslstrip.
Yeah, we don't expose disabling TLS (and thus SNI, which is my understanding of the issue), so hopefully this won't be a problem.
Assignee: nobody → dkeeler
Status: NEW → ASSIGNED
Attachment #8395041 - Flags: review?(cviecco)
Note that getHSTSPreloadList.js currently adds the non-Google snionly entries to the preload list anyway.
Attachment #8395041 - Flags: review?(cviecco) → review+
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
You need to log in before you can comment on or make changes to this bug.