Geotrust/Symantec has revoked all SSL certificates for .pw domains

http://colin.keigher.ca/2015/09/geotrustsymantec-has-revoked-all-ssl.html

by afreak • 11 years ago

157 99 11 years ago

colin.keigher.ca

0x06• 11 years ago

The current CA PKI system is pure madness. Everyone in the CA club can issue certificates for anything - and you are at their mercy for not revoking. And what's worse, even if you pick a decent vendor, you can't prevent shadier outfits from also issuing parallel certs. :(

inopinatus2• 11 years ago

In the short term - by which I mean, the next ten years - my hopes are on DNSSEC with DANE/TLSA for DNS-based certificate assurance. This is not a great solution: firstly, adoption of DNSSEC has yet to snowball; and secondly, DNS remains a tree with a single root controlled by a governmental authority, and it's tough to argue that's any better than the CAs.

The longer dream of a universally federated, decentralized trust mesh depends on a substrate protocol emerging for which I think Bitcoin is only the first glimmer of hope; timeframe ca.10-50 years.

thezilch2• 11 years ago

Except DNSSEC is just as sketch (and maybe more so) a trust chain. We replace CAs with registrars (OH GOD), TLDs (and for .com, that's just CAs again or governments, OH GOD), and ICANN (subject to government seizures!!!).

I'd much sooner support adoption of Marlinspike's Convergence or something similarly distributed: http://convergence.io/

idlewords• 11 years ago

You really think that giving Libya the keys to bit.ly, for example, is a step forward?

aianus• 11 years ago

https://developer.mozilla.org/en-US/docs/Web/Security/Public...

0x06• 11 years ago

So after all those years of x509/asn1/openssl bugs and ca breaches we are left with... ~/.ssh/known_hosts reimplemented, poorly? :-}

nailer3• 11 years ago

That's what HPKP and certificate transparency are for.

Google also require certificate transparency for all EV certs.

chetanahuja• 11 years ago

"The current CA PKI system is pure madness. Everyone in the CA club can issue certificates for anything"

It boggles the mind that all these security experts (including those frequenting these forums) take such pains over obscure, hard to exploit things (like about half the CVE vulns), and come down with the fury of a thousand suns on anyone daring to come up with, say a new secure messaging protocols without their permission (remember the Telegram brouhaha) and yet blithely go on endorsing and even encouraging this totally broken third party trust system, this house of cards that the entire web security framework is built on. Just baffling.

Zigurd• 11 years ago

Many security consultants sell "security" out one door and surveillance/forensics out the other door. Only one of those businesses sells a working product/service.

daurnimator3• 11 years ago

Btw, can someone explain to me how revocation interacts with certificate pinning?

ikeboy17• 11 years ago

Quick search turns up a proposal to deal with it https://www.ietf.org/mail-archive/web/websec/current/msg0050... (but hasn't been implemented in the actual standard, see below).

Revocation

In the event of pin mismatch, clients MUST check whatever revocation mechanism is available, and attempt to discover whether the certificate with the mismatching fingerprint has been revoked. For example:

  offending_certificate = cert in certificate_chain where
      cert.public_key.fingerprint == mismatched_fingerprint


  revoked = offending_certificate.serial_number in revoked_serials

If the offending certificate has been revoked, it is unpinned and the UA can re-evaluate the pin list. If there are no pinned fingerprints left on the pin list, the browser downgrades the host from Known Pinned HSTS Host to Known HSTS Host.
The revocation mechanism could be an extant mechanism such as CRL or OCSP, or a new one such as browser updates, whitelists, blacklists, or an in-built CRL. This document is agnostic about the revocation mechanism(s) UAs may use.
Un-pinning
Certificates that are invalidated for any reason and by any means -- revocation by extant or future means, expiration, blacklisting -- are effectively removed from the pin list. Certificates whose intermediary or root signers are revoked are also effectively invalidated and removed from the pin list.

HSTS Hosts can un-set pins in clients (un-pin) by setting a pins directive that contains no pins. UAs MUST NOT obey the un-pinning directive unless the empty pins directive is set on a response in a TLS connection that was authenticated with one of the previously pinned public keys.

This doesn't seem to have made it into the standard, though: https://tools.ietf.org/html/draft-ietf-websec-strict-transpo... says

When connecting to a Known HSTS Host, the UA MUST terminate the connection (see also Section 10 "UA Implementation Advice", below) if there are any errors (e.g. certificate errors), whether "warning" or "fatal" or any other error level, with the underlying secure transport. This includes any issues with certificate revocation checking whether via the Certificate Revocation List (CRL) [RFC5280], or via the Online Certificate Status Protocol (OCSP) [RFC5280].

and https://tools.ietf.org/html/rfc6797#section-8.4 says

When connecting to a Known HSTS Host, the UA MUST terminate the connection (see also Section 12 ("User Agent Implementation Advice")) if there are any errors, whether "warning" or "fatal" or any other error level, with the underlying secure transport. For example, this includes any errors found in certificate validity checking that UAs employ, such as via Certificate Revocation Lists (CRLs) [RFC5280], or via the Online Certificate Status Protocol (OCSP) [RFC2560], as well as via TLS server identity checking [RFC6125].

daurnimator3• 11 years ago

Thanks :)

I wonder if this has actually been implemented correctly...

Sudden revocation of a TLD will probably result in a sudden hammering of the CA's revocation servers too. I imagine an icky failure cascade is happening for some unfortunate user

jqm5• 11 years ago

"But here's the thing: why did Geotrust just go ahead and revoke the certificates for all .PW domains without any warning?"

Why indeed? My first notice of this was a client unable to use the app even though the cert was issued less than 6 months ago and was a 2 year cert. Like the author I also initially thought client configuration issue until I tried.

I contacted the reseller who didn't have an answer right off the bat but had to contact Geotrust. After 15 minutes of fooling around I got an answer and a refund. So yes, they issued me a refund. Great. My clients had downtime. I had to drop what I was doing "right then" and install new certs. Finally I had to walk clients through clearing old certs from their browser as they were getting the scary "Untrusted!" popup. Fortunately this is a private app for a specific client so there weren't a bunch of calls.

Geotrust's handling of this was ridiculous. No email, no notification... I'll certainly never get a cert from then again over this incident.

rosege• 11 years ago

sounds like they were hacked and had to revoke all certs for that TLD

jqm5• 11 years ago

This happened last Monday morning incidentally. So the authors certs have actually been suspended for at least a week already.

nindalf• 11 years ago

I don't think GeoTrust was hacked. If they had been, their response was "sorry guys, we're working on fixing this soon. You'll have to do x,y,z to fix your domain". Their actual response was "[we] will no longer be issuing SSL certs to .PW domains", so they have some problem with .PW that doesn't seem to be technical.

MichaelGG4• 11 years ago

Why on earth should any CA be getting involved in what a site hosts? They need to validate ownership and stop.

ikeboy17• 11 years ago

If a site is blatantly criminal, should a CA revoke its cert?

jqm5• 11 years ago

No. Separation of concerns and all....

MichaelGG4• 11 years ago

A: Seems like they got it wrong here if that was indeed their reason. That alone is good enough to say no.

B: Criminal for who? I certainly don't want Geotrust deciding what's allowed. Does that mean they can e.g. block sites donating to Wikileaks?

bandrami2• 11 years ago

No. Why would they? The certificate simply guarantees that it is in fact that criminal with whom you are communicating. And there are perfectly valid reasons one might want to communicate with a criminal.

jbb555• 11 years ago

No of course not. The certificate is to prove ownership, nothing more. Criminal activity doesn't alter that. There are other laws to cover that.

djrogers• 11 years ago

This wasn't even a single site - it was an entire TLD that got revoked. There's no excuse for that kind of action unless the private key for that TLD was compromised.

Breach notification in 3..2..1...

0x06• 11 years ago

In the current SSL system there is no such concept as a "private key for a TLD". Every single one of the roots can sign anything. :(

kpcyrd• 11 years ago

Certification is tld agnostic. The only plausible reason to revoke certs by tld would be an error in the dns root for .pw, which would be bad for a company that verifies domain ownership as a business.

beefsack• 11 years ago

What has happened here feels very similar to vigilantism.

kordless• 11 years ago

I think DNS signing authorities are a bunch of outlaws. They charge for trust, yet don't establish it themselves.

jpatokal• 11 years ago

For everybody else who was wondering, .pw is Palau, a tiny island nation (pop. 17k) in Micronesia:

https://en.wikipedia.org/wiki/.pw

And apparently its sole decent hotel is smart enough to use a .com instead:

http://www.palauppr.com/default-en.html

Canada• 11 years ago

http://www.cc.com/video-clips/xzhg3v/the-colbert-report-meet...

nmcfarl• 11 years ago

Also truly stunningly beautiful place to visit - though a bit difficult to get to. And it certainly has significantly more decent hotels than just that one. Tourism is definitely it's biggest industry.

Aldo_MX• 11 years ago

Let's encrypt it's starting to issue the first certificates[1].

Hopefully dealing with bad CAs will be a thing of the past.

[1] https://letsencrypt.org/2015/08/07/updated-lets-encrypt-laun...

bcoates• 11 years ago

I've had issues with other registrars revoking certificates for questionable reasons (i.e., any reason other than obvious loss of control of the private key).

Is there a "bulletproof" registrar that doesn't revoke? If my client loses thousands of dollars per day of downtime I'm sure they'd be willing to pay through the nose for it.

I understand the reasons for having a revocation system but it's often not a benefit to me on balance-of-risks basis.

biot• 11 years ago

How about getting certificates from multiple, geopolitically diverse providers up front? It'll be an extra expense but lets you monitor your certs' revocation status and, should cert #1 get revoked, update your configs to use cert #2 and so on.

That might even be a good idea for CloudFlare to implement in their SSL offerings[0] if they don't already. They could offer multiple SSL certs from various providers (for an extra fee even) and the whole process would be completely transparent to your origin server, which can run its own self-signed cert.

[0] https://www.cloudflare.com/ssl

krishna_k• 11 years ago

startssl.com has a different business model - you pay for verification (fairly cheaply), not for the certificates themselves. BUT, they charge you $25 for revocation.

So I'd assume that this is kind of a "bulletproof" - if you don't pay, they won't revoke.

kruhft2• 11 years ago

I just developed a browser to server based crytpo channel meant to replace the SLL certificate mess on a side project I'm working on. I know that there's a bad rap for browser based crytpo and rolling your own but I've got some knowledge and thought I would give it a shot.

The code is not public (yet) but uses DH key exchange (using the JS BigInt library) to exchange a 2048 bit token key and then uses sjcl to perform encryption on each packet/request using the resulting key.

It's lacking host validation (am I talking to the correct server?), but I'm still working getting that piece together.

kruhft2• 11 years ago

Anybody care to comment rather than just downvote? I wouldn't mind hearing some thoughts regarding this part of the project.

stephengillie• 11 years ago

Please resist commenting about being downvoted. It never does any good, and it makes boring reading.

https://news.ycombinator.com/newsguidelines.html

mikekchar• 11 years ago

Complaint about complaint about downvoting notwithstanding, my guess as to why nobody commented was: there is no meaningful way to comment on it. There is no link with a detailed description of what you have done, or demonstration of how it works. There is also no source code to look at yet.

While I am sure it is an exciting project for you, without something that people can try (or at least source code to look at), it doesn't add anything valuable to the reader of the comment. It just adds to the noise of the conversation.

If you wait until you are ready to show people the code, then I'm sure many people will be interested to discuss it. Before that, it's not time yet.

That's my perspective, anyway. I hope it is useful to you.

Animats3• 11 years ago

This is strange. An entire TLD? Symantec hasn't issued an announcement. There's nothing on the CA/Browser Forum mailing list. Nothing on the Symantec Security Response Blog. Nothing on Symantec's Twitter feeds.

Symantec stopped issuing certs in .PW six days ago, according to a blog post.[1] But there appears to have been no public announcement. Even if there was a major security breach justifying this, Symantec has botched the revocation and has lost much trust.

[1] https://www.reddit.com/r/sysadmin/comments/3j9iyk/just_a_hea...

Animats3• 11 years ago

24 hours later, I'm not seeing any reliable source reporting this. No hits in Google News. Nothing on TechDirt. Nothing on security blogs. Nothing on CA/Browser mailing list. Most hits in Google are to scraper spam blogs that scraped HN.

This report may be bogus, or a hoax.

mahouse• 11 years ago

I don't know who thought that having the possibility of revoking certificates was a good idea, especially when that possibility is controlled by CAs

andrewflnr• 11 years ago

People who considered the possibility of private keys for certs getting compromised.

schoen• 11 years ago

It's an interesting question whether it would be a good idea to require revocations to be signed by the subject key rather than by the issuer key. I guess it depends on the threat model!

Conceptually, the idea is that if the issuer makes an assertion about what's true, they want to later be able to stop making that assertion. That seems to make basic sense. (But in some threat models, the issuer might have been coerced, and maybe it's easier to coerce authorities to revoke than to misissue. For one thing, browsers are unlikely to kick CAs out of their trust lists for improper revocation, but they might for misissuance!)

flashman• 11 years ago

Could this be anything like the DigiNotar hack?[0]

If it came out that Symantec's certificate authority was used to issue fraudulent certificates, the damage to their business could be in the hundreds of millions. What if the silence is because Symantec is trying to figure out the best way to break the news to us?

Edit: After a bit more reading, Symantec has some history of monitoring .pw for malware and spam.[1][2][3] Perhaps someone just decided they wanted nothing more to do with PW issuer Directi, which apparently has a poor reputation.[4]

[0]https://en.wikipedia.org/wiki/DigiNotar

[1]http://www.symantec.com/connect/blogs/rise-pw-urls-spam-mess...

[2]http://www.symantec.com/connect/blogs/pw-hit-and-run-spam-ro...

[3]http://www.symantec.com/connect/blogs/rig-exploit-kit-used-r...

[4]http://www.jl.ly/Email/palau.html

nailer3• 11 years ago

Wait. I'm the last person to defend Symantec (see [1] [2]) but the headline seems to be a load of rubbish, or at least certainly isn't backed by the content of the article.

Here are the only two reseller quotes from the article:

Reseller rep.:
We regret to inform you that certificate [number] for www.canary.pw domain has been revoked by the Certificate Authority due to the site being flagged as potentially containing malware in a recent site scanning by Symantec (owner of GeoTrust). Unfortunately we were not warned of the upcoming revocation, so we apologize for any inconvenience that this may cause.

A single website, that allows people to search stolen data, eg the Ashley Madison hack, and asks people to submit stolen data, has had it's certificate revoked.

and:

Reseller rep.:
As per our check with Symantec, they will no longer be issuing SSL certs to .PW domains. You are advised to remove the SSL certificate from the server to avoid security errors related to a revoked certificate.
And furthermore Symantec are no longer issuing certificates for the .pw TLD.

Neither quote equates to Symantec having 'revoked all SSL certificates for .PW TLD domains' as mentioned in the headline and this HN submission.

As much as I dislike Symantec - and I really dislike Symantec - I think this article's headline is false.

[1]. https://certsimple.com/blog/seal-in-search

[2]. https://certsimple.com/blog/sgc-ssl-certificates

nailer3• 11 years ago

If anyone's reading this later: I've confirmed this with an industry contact and it's true: ridiculous as it might seem, Symantec are indeed revoking all existing .pw certificates.

Animats3• 11 years ago

Is this for real? All we have is one unknown blogger, Colin Keigher, picked up by other sources. It's Tuesday afternoon, so everyone is back at work. A takedown of an entire TLD should have hit news sources and major security blogs by now. I'm not seeing anything other than echos of the original blog post. It hasn't even come up on the CA/Browser forum mailing list or security blogs.

Geotrust/Symantec has revoked all SSL certificates for .pw domains

Related Stories