Chrome quietly broke all self-signed SSL sites | Hacker News Reader

Chrome quietly broke all self-signed SSL sites

code.google.com

18 pointsaeontech19 comments

That report is for the Dev and Beta channels of Chrome. It works as expected in the release channel. The Dev channel is equivalent to alpha quality. The Beta channel has changed recently and is now rebuilt nightly with features being enabled and disabled, so I'd wager more issues like this will get through.

The original ticket may have been filed for the beta, but if you read the reports, you will see that multiple people (myself included) are having the issue in 17.0.963.83, which is as far as I know supposed to be stable and was released on 3/22.

Chrome 17 added a "feature" that blocks http resources from loading on an https connection unless the user manually approves it every time. Sounds like a good idea, but it broke all sorts of Google sites and widgets because Google violates that rule everywhere.

This is probably just another "feature".

If you follow the link to the report, you can clearly see that it is considered a bug and is being worked on.

I've never been entirely sold on how awesome Chrome's invisible updates are and this is exactly why. It's great as long as they don't push any bugs through. But once they do (and it will happen), there's no way of using a known good version. So if I'm IT in charge of 10,000 users at MegaCorp, I cannot make any promises about reliability of internal web apps with Chrome, because at any point Google could break something.

(Obviously you can work around this by providing snapshots of Chromium, or Chrome binaries patched to not update or whatever)

First google result: http://www.sitepoint.com/how-to-disable-google-chrome-update...

Does this not work anymore? Are you privy to something I don't know?

I didn't know about this, but I don't think it solves the issue. Disabling updates allows you to stay at the current version (or, by enabling updates, go to the most recent version). But you can't get any particular version. Suppose I know that version 12.1.3.135 works perfectly for my internal application but that the current doesn't for some reason. How do I get that version? With versioned software this isn't so much of an issue, but with Chrome's continuous versions, it's a little harder. And how would one roll that out to 10,000 users? I'm sure it's not terribly difficult, but not as obvious as giving everyone Firefox 8. And what happens when the CEO decides to enable updates and it breaks your web app?

The way Chrome handles SSL certs on Linux has always driven me crazy. My company's firewall uses a man in the middle SSL certificate so on most SSL sites I have to "proceed anyway" everytime I restart my browser. Chrome on Linux can't seem to permanently store the exceptions, even with every certutil command known to man.

This in itself wouldn't be all that bad, the real problem is most sites (Facebook for example) use multiple SSL domains for things like images and other resources. So I'll get a page that half loads until I go an "proceed anyway" on each of the problem domains.

Is it the cert trust or other aspect of the validation? Your IT guys should have the CA cert for the appliance that is signing these available to add to your local cert store. The CA cert may be attached to the server cert you are presented too. Just extract that and add it to wherever linux keeps its certs.

I'm surprised that got through QA, seems like a rather critical bug.

well, it didn't. this is not a bug filed against the stable version, as far as i understand. This is in the dev/beta channel.

I am able to reproduce in 17.0.963.83, which is not beta afaik.

They should really tack on a few more warnings, anyway. Three or four clicks isn't enough of a penalty. People who start websites without paying tax to the SSL mafia need to be punished!

Three or four clicks really isn't good enough, since the behavior users are clicking to get is "site that claims to need security but doesn't actually have it".

Isn't the behavior "site that just wants an encrypted channel to transfer, say, your login details, without making any claims about its authenticity"?

Which is semantically equivalent to "site doesn't understand security."

Yea, BTW RDP originally used "encryption" based on RSA using a hardcoded private key. They finally moved to TLS with Server 2003 SP1.

There are many legitimate uses for self-signed certificates, especially those intended for trust-on-first-use.

Sure, and if you want to have a better user experience, manually add those certificates to the ones you trust, then you won't get the warnings.

Reply on news.ycombinator.com