Closed Bug 594990 Opened 14 years ago Closed 14 years ago

Strict-Transport-Security header makes it impossible to disable ssl_redirect and makes entire domain strict

Categories

(Bugzilla :: Bugzilla-General, defect)

3.7.3
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Bugzilla 4.0

People

(Reporter: mkanat, Assigned: mkanat)

Details

Attachments

(1 file)

I have two problems with the Strict-Transport-Security header in Bugzilla, right now: * Once I've turned on ssl_redirect on one of my testing installations, I now effectively can't turn it off. * The entire domain becomes strict, not just the Bugzilla installation that I sent the header with. So, for example, now my browsers enforces SSL on every single page on landfill.bugzilla.org, not just my Bugzilla installation.
Flags: blocking4.0+
I'm leaning towards removing the STS header from Bugzilla and putting it back in as an extension, or making it enabled only via an Advanced parameter. There are still a lot of production installations that would benefit from it, but the behavior I've listed in comment 0 may be confusing for a lot of other installations.
Advanced parameter, please... Security should not require a separate extension. I can probably take this.
(In reply to comment #2) > Advanced parameter, please... Security should not require a separate extension. Well, we should first ask if there is really no way to have it per Bugzilla installation. I don't see why the entire domain becomes strict. If you get a page which hasn't the STS header, why would the server require SSL?
(In reply to comment #3) > Well, we should first ask if there is really no way to have it per Bugzilla > installation. I don't see why the entire domain becomes strict. If you get a > page which hasn't the STS header, why would the server require SSL? That's how STS works... An STS header on any page covers the entire FQDN. The point of STS is to force SSL over all pages for a FQDN and make the browser remember to always use SSL (so that even if you go to http, it redirects you). Once a browser has visited a page with the STS header, the browser caches that information for maxAge, meaning that it will only try to connect to the site over SSL. This protects users by keeping their data transmissions secure.
(In reply to comment #4) > That's how STS works... An STS header on any page covers the entire FQDN. Ah ok, good to know. Well, in that case, I would say we don't want STS, and that those who wants to use SSL for their Bugzilla should enable the ssl_redirect parameter. Even a parameter doesn't make sense as it would be a "toggle only once" parameter, and even worse, a parameter which also controls other web applications on the same server.
Most large, important Bugzilla instances live on their own subdomain by themselves (for various security reasons). As such, Bugzilla should support STS, as it is the only app on the FQDN. I think a parameter (off by default) is fine for this. We have plenty of other parameters that are "toggle only once", as you say, so not sure why this one would be any different.
STS is a more robust ssl_redirect: aside from redirecting to SSL it also 1. Makes sure the first hit to bugzilla is HTTPS (so network attackers can't perform downgrade-to-https MITM attacks). The redirect happens in the browser so no request is sent unencrypted to bugzilla. 2. Globally sets http->https redirect on the entire domain for all content (avoiding same-domain mixed content). 3. When STS's "includeSubDomains" feature is used, attachments will only be requested over HTTPS as well. I think STS is beneficial for bugzilla installs, but agree it should be off by default since there *could* be other sites served on the same host. For those common "bugzilla.foo.com" installs where the only thing at that domain is bugzilla, STS works quite well and is attractive for use since it will further reduce users' susceptibility to MITM attacks over using ssl_redirect.
Okay, an Advanced parameter would do it. I'd take a patch for that. And yes, it should be off by default. (Principle of Least Surprise.)
Attached patch v1 (deleted) — Splinter Review
This adds a parameter, default disabled, that adds the strict_transport_security parameter. I did not make the sending of the header also dependent upon the ssl_redirect setting, because there are some installations that use SSL in situations without ssl_redirect that still may want Strict-Transport-Security (like Mozilla).
Assignee: general → mkanat
Status: NEW → ASSIGNED
Attachment #476997 - Flags: review?(bugzilla)
Attachment #476997 - Flags: review?(bugzilla) → review+
Flags: documentation?
Flags: approval?
Flags: approval?
Flags: approval4.0+
Flags: approval+
Target Milestone: --- → Bugzilla 4.0
this needs to be documented in section 3.1.1
If someone attaches an HTML file to Bugzilla with the correct STS header in it, the STS feature will be enabled for the whole domain too, right? I'm just curious.
(In reply to comment #12) > If someone attaches an HTML file to Bugzilla with the correct STS header in it, > the STS feature will be enabled for the whole domain too, right? I'm just > curious. nope, STS is a HTTP response header field only: UAs must not heed http-equiv="Strict-Transport-Security" attribute settings on <meta> elements in received content.
Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/trunk/ modified Bugzilla/CGI.pm modified Bugzilla/Config/Advanced.pm modified template/en/default/admin/params/advanced.html.tmpl Committed revision 7490. Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/4.0/ modified Bugzilla/CGI.pm modified Bugzilla/Config/Advanced.pm modified template/en/default/admin/params/advanced.html.tmpl Committed revision 7418.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Flags: documentation?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: