[konstruktor]

The latter is just as bad. Opinionated software, i.e. making things that are usually a bad choice hard, is a good thing. Making possible things deliberately impossible for the victims of other people's bad decision making is arrogant. So some idiot CIO chose to make https mandatory but their staff can't get it configured properly. I am sure the non-IT user's boss will be happy that, instead of, say, closing that one important deal, the user waits until the https issue is resolved. What a way to drive IE out of the enterprise...

[tptacek]

Random enterprises will always be breaking some part of the HTTP stack. It's not reasonable to degrade everyone's security, even the majority of people who don't have unnecessary breakage inflicted on them, just to accommodate those enterprises.

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.

[konstruktor]

Do you realize that it's not the abstract concept of an enterprise using a browser, but a human being? Which, usually, is not the person administering the server. I'm all for nudging people to change their own behaviour to the better, but this is driving your principles home on the back of the user.

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

[tptacek]

The button he's asking for is "disable TLS security".

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.

[codeka]

Anyway, I would say "--ignore-certificate-errors" is an acceptable workaround here. If your proxy is already intercepting all HTTPS traffic, then there's really no benefit in the client browser also verifying certificates.

Of course, I would still only run with "--ignore-certificate-errors" for the limited time the proxy has broken certificates or whatever...

[harshreality]

Even with a corporate proxy intercepting SSL connections, individual browsers are still protected against attacks on the local network involving SSL impersonation (rogue access points, DHCP or ipv6 neighbor announcement abuse...).

Companies have their firewall infrastructure locked down (hopefully), but lan segments (except in high-security environments) not as much.

[justinschuh]

The standard very explicitly states that Chrome's behavior is correct:

   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.

http://tools.ietf.org/html/draft-hodges-strict-transport-sec...

[Flimm]

It's not arrogant on Chrome's part to incrementally improve the user's security, while forcing companies to incrementally improve their security. It's incompetent on the IT department's side to ignore a problem that is both a genuine security risk and an obstacle to getting things done. (Besides, as other commenters have pointed out, the ignore option is only hidden if the server opts to send an HSTS header.)