I know what I'm doing. I'll reset the option when the underlying issue is resolved, and overall it's a great feature for the browser, but I need to have the ability to be responsible for myself.
Then, the proxy makes its certificate available to users, you download it, and add it to your CA certs via the UI that browsers provide for that; HTTPS magically appears to work again.
HTTPS shouldn't magically appear to 'work' again, considering it is completely broken when a forced mitm is introduced.
If you want privacy against the administrators of your employer, don't use your employer's network to do things that need privacy.
The problem isn't necessarily what the employer sees, it's what the might employer keep around.
But even if reasonable people could disagree about that policy decision: the reality is that people operating large corporate networks require the ability to control SSL/TLS sessions; for instance, there are whole industry verticals where accessing a private email server not controlled by your employer is grounds for automatic termination, because regulations require them to track and archive email messages.
Finally, and I'm repeating myself: I am describing the reality of most Fortune-500 enterprise networks. In most corporate networks, you cannot simply talk from your desktop out to the Internet; you are required to use a proxy. You're also almost certainly on an 10/8 IP address.
In which case I end up shit creek without a paddle because there's no way to temporarily disable the security feature.
And I do not have control over the Proxy server because I'm not in the fucking security team.
You can disable all certificate checking with --ignore-certificate-errors but it is as bad as it sounds.
Rather, to correctly support MITM proxies you should install their CA certificate locally.
This is the problem.
> ... and it makes Chrome practically unusable when they happen
This is not the problem.
There is a clean solution to this problem: the proxies should serve as just-in-time CAs for the traffic they proxy. The big proxy products all do that. This simply isn't Chrome's problem.
Considering your use of the word "breakage": DannoHung is talking about a button that is actively being disabled in certain situations, not something bad being enabled. This is extra code in a security critical part of the browser. Thus, we can assume that there were meetings that discussed this "feature" and its implications, the actual coding, code reviews and QA, adding up to quite a bit of opportunity cost. That begs the question: Would this time have been better spent on something that adds more security?
Disabling manual overrides may seem like a good idea, but it can go horribly wrong. http://en.wikipedia.org/wiki/Lufthansa_Flight_2904
If he wants to disable TLS security, there's a right way to do it: by installing the proxy's cert.
If you read 'agl's talk, you'd see that the reason the button is hidden is that it is one of the Internet's great security flaws: a workflow embedded into most browsers that demands users to learn to disable TLS security.
So, I find this argument you're making to be more or less entirely bankrupt.
Of course, I would still only run with "--ignore-certificate-errors" for the limited time the proxy has broken certificates or whatever...
Companies have their firewall infrastructure locked down (hopefully), but lan segments (except in high-security environments) not as much.
When connecting to a Known HSTS Server, the UA MUST terminate the
connection with no user recourse if there are any errors (e.g.
certificate errors), whether "warning" or "fatal" or any other error
level, with the underlying secure transport.
chrome://net-internals/#hsts
Are you looking for something else?