GlobalSign screw-up cancels top websites' HTTPS certificates GlobalSign's efforts as a root certificate authority have gone TITSUP this afternoon – that's a total inability to support usual protocols. The result is that many websites big and small have had their HTTPS certificates incorrectly scrapped, meaning that for some people their browsers no longer trust websites and refuse or …
I spent half an hour looking at certs and using Firefox before this news story showed up and explained what was going on. It would have been nice if Safari had a slightly more informative error message.
Anyway, in MacOS it's easy if you have the "develop" menu enabled - selecting "empty caches" seemed to do the trick.
Anyway, in MacOS it's easy if you have the "develop" menu enabled - selecting "empty caches" seemed to do the trick.
1 - close Safari
2 - in terminal, enter sudo rm /var/db/crls/*cache.db, hit Enter and supply password
3 - resume browsing as before. You'll find sites like Wikipedia will work again.
I was SO expecting a 'Close Safari.... Use a real browser' type response.
No, ramming your own preferences down a user's throat is a Microsoft habit. Not only that, there would not have been a reason to create a similar list for Firefox because that continued to work on OSX, which raises questions about its ability to recognise cancelled certifications.
Even if it was erroneous in this case, the mechanism should have tripped, so that proved rather revealing in itself - by way of illustration, Opera did not open Wikipedia either until the problem was fixed and caches were cleared.
If you've upgraded to macOS Sierra this won't work. Instead you need to do:
sqlite3 ~/Library/Keychains/*/ocspcache.sqlite3 'DELETE FROM responses WHERE responderURI LIKE "%http://%.globalsign.com/%";'
And possibly a browser restart (I did on Chrome).
This doesn't seem to be well documented around the web - I found it on Apple Stack Exchange answer 257080.
I'm not at all sure that ANYONE actually verifies the certs in SMTP servers. The chain of trust is rarely investigated for such things, as they generally only want it for encryption and aren't checking endpoint authenticity. With things like DKIM, the certificate chain doesn't matter, only the certificate thumbprint, and DNS/DKIM is doing the endpoint verification for you.
A lot of Linux distros set up self-signed certs for SSH and SMTP when you install the relevant server packages.
In fact, I would suggest that using the SAME signed cert for SSL, SSH and SMTP might well be a risk, but I'd be hard-pushed to remember where I read that or what the reasoning was (it might be as simple as "things like SMTP servers sometimes use internal / older SSL libraries").
To sign something, the private key is needed. There is always a risk involved that the software using it has a vulnerability which can reveal it. Using it for more than one purpose means that the risk of private key exposure is the sum of the individual risks, which is necessarily greater than any individual risk.
It's similar to the reason why you should never use the same password for banking and facebook.
Now might be a good time for everyone to pressure the browser writers to finally include DANE capabilities, so website owners can take control of their own security and disconnect from this CA disaster.
Maybe Vulture Central could try to remember to put a little dig in about that everytime a CA TITSUP happens?
See...
###
Mozilla:
https://wiki.mozilla.org/SecurityEngineering/WorkingSessions/09-18-13-NetworkTeam
"I think we all agree it's not the right way forward. And slow"
https://wiki.mozilla.org/NSS:BurnDownList
"Nice to have, but doesn't solve all the problems, and there is no commitment that a majority will use it."
###
Chrome:
https://bugs.chromium.org/p/chromium/issues/detail?id=50874
"Closing this out as WontFix, as there are no plans.
The ISC number is not accurate for what real world users experience, and is biased by crawls that have a number of experimental limits.
DNSSEC and DANE (types 2/3) do not measurably raise the bar for security compared to alternatives, and can be negative for security.
DNSSEC+DANE (types 0/1) can be accomplished via HTTP Public Key Pinning to the same effect, and with a much more reliable and consistent delivery mechanism.
While not desiring to stifle discussion, we've continued to evaluate the security and usability benefits and costs of DNSSEC and DANE, and will continue to do so, but for now, this is neither something we plan to implement nor would support landing."
###
Now might be a good time for everyone to pressure the browser writers to finally include DANE capabilities, so website owners can take control of their own security and disconnect from this CA disaster.
Maybe Vulture Central could try to remember to put a little dig in about that everytime a CA TITSUP happens?
See...
###
Mozilla:
https://wiki.mozilla.org/SecurityEngineering/WorkingSessions/09-18-13-NetworkTeam
"I think we all agree it's not the right way forward. And slow"
https://wiki.mozilla.org/NSS:BurnDownList
"Nice to have, but doesn't solve all the problems, and there is no commitment that a majority will use it."
###
Chrome:
https://bugs.chromium.org/p/chromium/issues/detail?id=50874
"Closing this out as WontFix, as there are no plans.
The ISC number is not accurate for what real world users experience, and is biased by crawls that have a number of experimental limits.
DNSSEC and DANE (types 2/3) do not measurably raise the bar for security compared to alternatives, and can be negative for security.
DNSSEC+DANE (types 0/1) can be accomplished via HTTP Public Key Pinning to the same effect, and with a much more reliable and consistent delivery mechanism.
While not desiring to stifle discussion, we've continued to evaluate the security and usability benefits and costs of DNSSEC and DANE, and will continue to do so, but for now, this is neither something we plan to implement nor would support landing."
###
I'm a bit hazy about DNSSEC and DANE but as far as I can tell, DNSSEC still requires a chain of trust - it just starts in a different place - so from a technical point of view it's equally vulnerable to problems of this kind where an intermediary can simply make a mistake.
Whether it's more vulnerable in practice would seem to depend on whether you feel SSL-certificate-issuers are any more or less venal and/or incompetent than domain registrars. I'm not sure I'd want to have a dog in that fight.
For those that don't know, this issue primarily affected Internet Explorer and Edge. Most other browsers seemed to work fine with the borked cert chain.
IE did it's usual of hiding any overly useful information. Amazingly Edge provided a little more information in that it stated that the cert had been revoked (not identifying which cert of course) and even gave the option to proceed to the website. Which in true and traditional Edge style didn't work and simply redirected the user back to the same error page.
I noticed it first on Safari (on osx), after that on Edge. Chrome and Firefox never showed issues. But (apart from the lack of information), is that not a plus for Edge ? I am definitely not an expert in these matters, but I assume that it's a good thing that a browser is quick to alert you when there is a certificate issue ? Do Chrome and Firefox "know" in some way that this was not a major issue ?
I'm curious, can someone enlighten me ?
I'm intrigued by the difference in browsers as well - particularly if this was a browser implementation issue, a server side issue or some horrible combination of the two. From an experience point I'd usually lay the blame on the Microsoft front and their implementation of "standards" however on this one it feels a little muddier than that.
It seems that more information from the more knowledgeable Reg readers is not forthcoming. FWIW : I discussed it with a few colleagues, and apparently it depends : I noticed it first on osx safari, later on on win10 edge. On both machines never on chrome and firefox. But apparently, in the limited group I asked, experiences were not similar, but we were visiting the same websites in the same timeframe (between 3pm and 7pm cet). The only difference was that, depending on the user, different browsers were kept open.
So we pay (potentially) large amounts of money to some 3rd party so that someone else can trust that we are secure. That 3rd party can't be trusted to keep it's service running? Is the fact that we can pay someone else a wad of money to some arbitrary (foreign at that) third party any reason to trust us?
Can't we just switch wholesale to each organisation maintaining it's own CA. So I choose to trust The Register's HTTPS I can do so directly myself??
With DANE you can do away with the CA system altogether. DNSSEC is used to prove you are who you say you are.
As . .uk and .co.uk are already signed (dig +DNSSEC co.uk), Vulture Central would just need to sign theregister.co.uk, enter the keys into the appropriate fields at their registrar
Then, ONCE THE BROWSER WRITERS BAKE DANE INTO THEIR PRODUCTS, you no longer need CA's and you won't need to manually authorise self-generated certs.
I moved most of our sites over to Lets Encrypt, and in the last 9 months we have had some teething problems (cronjobs which are meant to automatically renew the SSL not actually running etc). About 5 months ago my boss asked if there was anything better, and I told him to keep the faith with Lets Encrypt.
What happens today? He comes in moaning about certain sites having the SSL certificate issue, and I told him what happened with one of the biggest providers in the world. He's happier we have Lets Encrypt now.
So, thanks GlobalSign.
I lost the ability to post messages on CiF about 15 minutes ago. Obviously I am mortified that some right-wing troll will now be able to spread lies about Russian hackers without me being able to skewer their paranoid shite with evidence.
Fix the problem! The world is minutes away from collapse!
I'm on a Mandriva 2011 machine but have a working opera.
One needs however to upgrade several things.
1. upgrade openssl to OpenSSL 1.0.2e 3 Dec 2015 where
the patch openssl-1.0.2-disable-sslv2v3.patch should be revoked.
So do NOT disable SSLv3.
2. upgrade rootcerts to rootcerts-20151029.00
3. upgrade wget to wget-1.14-4.2
4. upgrade curl to curl-7.28.1-8
5. upgrade nss3 to nss-3.21.0-1
for step 5 one needs to correct and patch a very serious
error inside libstdc++ which on Mandriva 2011 is a part
of gcc 4.6.1. The details of the bug are here :
ftp://ftp.crashrecovery.org/pub/linux/gcc/RPMS/mdv2011/3.1a/README.txt
the details of the upgrade of nss3 to nss-3.21.0 are here :
ftp://ftp.crashrecovery.org/pub/linux/nss3/RPMS/mdv2011/README.txt
After that opera will have no issues whatsoever connecting
to high profile websites using https.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
