4 ms·

Chrome quietly broke all self-signed SSL sites

18 points by aeontech 15y ago

aeontech 15y ago
I'm surprised that got through QA, seems like a rather critical bug.
- hellerbarde 15y ago
  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.
  - aeontech 15y ago
    I am able to reproduce in 17.0.963.83, which is not beta afaik.
JohnTHaller 15y ago
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.
- aeontech 15y ago
  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.
noduerme 15y ago
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!
- tptacek 15y ago
  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".
  - derefr 15y ago
    Isn't the behavior "site that just wants an encrypted channel to transfer, say, your login details, without making any claims about its authenticity"?
    - ataggart 15y ago
      Which is semantically equivalent to "site doesn't understand security."
      - yuhong 15y ago
        Yea, BTW RDP originally used "encryption" based on RSA using a hardcoded private key. They finally moved to TLS with Server 2003 SP1.
  - lawnchair_larry 15y ago
    There are many legitimate uses for self-signed certificates, especially those intended for trust-on-first-use.
    - bascule 15y ago
      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.
halefx 15y ago
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".
- aboodman 15y ago
  If you follow the link to the report, you can clearly see that it is considered a bug and is being worked on.
MitziMoto 15y ago
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.
- AjithAntony 15y ago
  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.
prewett 15y ago
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)
- deleted 15y ago
  [deleted]
- sixcorners 15y ago
  First google result: http://www.sitepoint.com/how-to-disable-google-chrome-updates/ http://www.sitepoint.com/how-to-disable-google-chrome-update... Does this not work anymore? Are you privy to something I don't know?
  - prewett 15y ago
    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?

18 points by aeontech 15y ago

aeontech 15y ago

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

hellerbarde 15y ago
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.
- aeontech 15y ago
  I am able to reproduce in 17.0.963.83, which is not beta afaik.

JohnTHaller 15y ago

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.

aeontech 15y ago
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.

noduerme 15y ago

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!

tptacek 15y ago
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".
- derefr 15y ago
  Isn't the behavior "site that just wants an encrypted channel to transfer, say, your login details, without making any claims about its authenticity"?
  - ataggart 15y ago
    Which is semantically equivalent to "site doesn't understand security."
    - yuhong 15y ago
      Yea, BTW RDP originally used "encryption" based on RSA using a hardcoded private key. They finally moved to TLS with Server 2003 SP1.
- lawnchair_larry 15y ago
  There are many legitimate uses for self-signed certificates, especially those intended for trust-on-first-use.
  - bascule 15y ago
    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.

halefx 15y ago

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

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

MitziMoto 15y ago

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.

AjithAntony 15y ago
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.

prewett 15y ago

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)

deleted 15y ago
[deleted]
sixcorners 15y ago
First google result: http://www.sitepoint.com/how-to-disable-google-chrome-updates/ http://www.sitepoint.com/how-to-disable-google-chrome-update... Does this not work anymore? Are you privy to something I don't know?
- prewett 15y ago
  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?