Closed Bug 1334365 Opened 8 years ago Closed 8 years ago

it should be possible to add exception for hsts site

Categories

(Core :: Security: PSM, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: ephbase-moz, Unassigned)

Details

This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox may only connect to it securely. As a result, it is not possible to add an exception for this certificate. This is ultimately a user's decision. If you don't want to make it trivial, fine, but for the browser to deny without appeal access to a page that could be retrieved, is ridiculous.
Firefox implements a number of security features that cannot be overridden (e.g. the same origin policy, minimum key exchange/cipher requirements, etc.). HSTS is one of them. It sounds like this is a more specific issue, however. Are you developing a site that uses the HSTS header, or are you encountering this error on a production site?
Flags: needinfo?(ephbase-moz)
Given the recent proliferation of HTTPS and Google's encouragement of both HTTPS and HSTS, which is almost automatically and universally followed for SEO purposes, it's going to be increasingly likely to encounter neglected informational sites that don't necessarily need either, that are still up, but not accessible because the "user agent" refuses to load them (due to cert problems, like expiration). It's madness. The browser is acting against the user, and against the "open web" which you claim to love.
Flags: needinfo?(ephbase-moz)
Sites opt in to HSTS - they're not required to use it. If they do, breakage caused by an improper TLS configuration is their responsibility. It is the responsibility of the browser to protect the user if it can't determine that the endpoint it is communicating with is actually who it says it is. If there's a specific site or sites you're having an issue with, I'd be happy to help you debug it. If not, then I'll close this bug as wontfix.
Flags: needinfo?(ephbase-moz)
You did not even try to understand. > Given the recent proliferation of HTTPS and Google's encouragement of both > HTTPS and HSTS, which is almost automatically and universally followed for > SEO purposes, it's going to be increasingly likely to encounter neglected > informational sites that don't necessarily need either, that are still up, > but not accessible because the "user agent" refuses to load them (due to > cert problems, like expiration). > That doesn't register? Given that the browser is the user's agent (not the site's) and the above trend, the user must have the option to override this block. But yeah sure wontfix it, just another drop in the bucket of user hostile decisions.
The browser is still the user's agent. It's protecting the user by acting on information given to it by the site (that is, at some point in the past the site said to the browser, "if you ever can't connect to me securely, protect the user's information by not connecting at all"). If you still have concerns please start a discussion at https://groups.google.com/forum/#!forum/mozilla.dev.security.policy .
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Flags: needinfo?(ephbase-moz)
Resolution: --- → WONTFIX
(In reply to David Keeler [:keeler] (use needinfo?) from comment #5) > The browser is still the user's agent. Bull, if it were my agent I would have the ability to say, thank you for the protection, but in this case it is unnecessary, retrieving this page with an expired cert is acceptable, especially since I am not sending any private data. You want to deny me this right, and still claim the browser is my agent? What sophistry.
You need to log in before you can comment on or make changes to this bug.