Hacker News new | ask | show | jobs
by tptacek 5089 days ago
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.
1 comments
konstruktor 5089 days ago
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

link
tptacek 5089 days ago
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.

link
codeka 5089 days ago
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...

link
harshreality 5089 days ago
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.

link
justinschuh 5089 days ago
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...
link