[DannoHung]

Please for the love of god, if you're working at google and read this: Add a deeply set option to FORCIBLY enable that button in all situations where it might appear. We sometimes have certificate issues with our proxy server at my workplace and it makes Chrome practically unusable when they happen.

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.

[tptacek]

It's very straightforward for a proxy to have its own CA=YES certificate and mint/sign certs for every HTTPS site the proxy sees on the fly. If you have a corporate proxy that is intercepting HTTPS traffic, that is what it should be doing.

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.

[dekz]

So the proxy server acts as a forced man in the middle? This has to be one of the most atrocious things I have ever experienced. Forcing a man in the middle is insane especially in a large company where there may well be a lack in competency.

HTTPS shouldn't magically appear to 'work' again, considering it is completely broken when a forced mitm is introduced.

[tptacek]

Are you arguing with me, or with reality? I can't tell, because the system I described is how corporate proxies work pretty much everywhere.

If you want privacy against the administrators of your employer, don't use your employer's network to do things that need privacy.

[dekz]

I don't see how my comment may be interpreted as starting an argument. I was simply replying on your comment on HTTPS just 'work'ing once you ignore the man in the middle attack. It's not privacy from an employer that is the underlying issue. It is the practice itself which should be frowned upon. People didn't spend their time trying to come up with the ability to have secure communications from point A to point B just to have someone come in and break it.

The problem isn't necessarily what the employer sees, it's what the might employer keep around.

[tptacek]

Enterprises are making a policy decision to take advantage of the Internet security model from the border of their network outward, but to take responsibility for IP security inside their network. That is a reasonable policy decision.

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.

[codeka]

This is far more common than you might expect. You just need to push you're company's internal CA to all your client computers, and bam, MITM for everything!

[rondon1]

Yes enterprise customers want to decrypt and inspect all traffic, for legitimate and sometimes sketchy reasons.

[rurounijones]

HIPAA requires it as far as I know, and I am sure other regulatory frameworks probably do.

[tptacek]

HIPAA does not require traffic monitoring.

[DannoHung]

Yeah, that's what should be happening, but sometimes the software breaks, or the security restrictions on the certificates accepted by the browser changes and the vendor of the product doesn't update fast enough or the certificate that's installed is out of date or whatever.

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.

[agl]

The bypass button only disappears for HSTS sites. Do you have a proxy server that's intercepting these connections and has a broken certificate?

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.

[DannoHung]

I suppose I can use that the next time it happens, but that's a bit more overkill in terms of disabling warnings than I'm looking for :/

[tptacek]

Starting Chrome with a flag is more overkill than adding a whole feature to Chrome to allow users to ignore SSL security?

[flatline3]

> We sometimes have certificate issues with our proxy server at my workplace ...

This is the problem.

> ... and it makes Chrome practically unusable when they happen

This is not the problem.

[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...

[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.)

[Flimm]

Or fix the certificate issues. Don't train the staff to be blind to security warnings.

[jarek]

How exactly does "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." become "train the staff to be blind to security warnings"?

[tptacek]

If you know what you're doing, get the CA=YES cert from your proxy and install it in your browser.

[DannoHung]

The cert itself was broken in the most recent case.

[Flimm]

If you know what you're doing, you'd know how to get around this limitation, with the --ignore-certificate-errors option for example. Any knowledgeable front-end or back-end developer would know how to find this out by doing a Google search. As long as you don't train the rest of the staff to do the same, that's fine. Now, why isn't the IT department fixing this security and usability problem?

[harshreality]

You can remove HSTS on a per-domain basis using

chrome://net-internals/#hsts

Are you looking for something else?

[justinschuh]

You can't remove the preloaded ones, which is really how it should be.