
Geotrust/Symantec has revoked all SSL certificates for .pw domains - afreak
http://colin.keigher.ca/2015/09/geotrustsymantec-has-revoked-all-ssl.html
======
flashman
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](https://en.wikipedia.org/wiki/DigiNotar)

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

[2][http://www.symantec.com/connect/blogs/pw-hit-and-run-spam-
ro...](http://www.symantec.com/connect/blogs/pw-hit-and-run-spam-royal-baby-
trend)

[3][http://www.symantec.com/connect/blogs/rig-exploit-kit-
used-r...](http://www.symantec.com/connect/blogs/rig-exploit-kit-used-recent-
website-compromise)

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

~~~
nailer
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](https://certsimple.com/blog/seal-in-search)

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

~~~
nailer
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.

------
Animats
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...](https://www.reddit.com/r/sysadmin/comments/3j9iyk/just_a_heads_up_symantec_is_cancelling_ssl/)

~~~
Animats
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.

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

[https://en.wikipedia.org/wiki/.pw](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](http://www.palauppr.com/default-
en.html)

~~~
nmcfarl
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.

------
0x0
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. :(

~~~
inopinatus
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.

~~~
thezilch
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/](http://convergence.io/)

~~~
0x0
But even with today's SSL CA system, those entities (registars, TLDs, ICANN)
have full control. They could easily override the NS records and/or WHOIS for
a domain targeting a domain-validating CA, and receive a valid certificate.

Might as well place the CA authorities with the TLDs, then. At least that
would limit their authority to their subtree, instead of the free-for-all that
is the current CA club. It might even let end-users make a semi informed trust
decision: ".be seems to run a tight shop and appears trustworthy, .ly not so
much" (random TLDs picked for example purposes only).

It would even make it worthwhile for site owners to pick a more
reliable/valuable/expensive TLD (and thus CA), since it would bring a
generally-accepted-to-be higher level of trust.

~~~
bro-stick
Exactly. The challenges with convergence are akin to a simplified
gpg+keybase... increasing its popularity needs further development and
proponents to gather a critical mass of users and providers.

Trust is hard. For top-down TLS CA to work, the net needs a fewer trustworthy,
sensible, well-secured/geo ip'd/leadership nonprofits to be the systems-of-
record far out of reach of govt and corporate dictatorships. (icann, iana are
a good start, but they could be better. ssl cert cert authority as another
type common-good org.).

Also, having a zillion CAs able to independently issue endless wildcard certs
for the same domain is lunacy... only the domain owner can be issued certs. It
should be tied to common global record-keeping system as domain name
registrars do and/or domain registrar-mediated challenge to prove ownership
(control panel login / authenticated API calls, not just adding some spoofable
TXT record cookie or link in an email). End MITM by rogue certs, at a minimum.

~~~
0x0
Yes, exactly. The registrar would be the obvious place for CA issuance - by
definition your account there proves your ownership.

Heck, make it a requirement that registrars issue free SSL certificates as
part of the domain registation service and we might even get to the https-
everywhere world that seems to be in vogue. Double bonus if this can be
engineered with a technical guarantee/verification that only the proper
registrar for a domain is a valid CA for it.

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

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

~~~
MichaelGG
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?

~~~
ikeboy
B: criminal in that country. If donating to Wikileaks was declared illegal in
the US (it hasn't), then I'd be fine with Geotrust revoking certs for websites
blatantly violating that.

~~~
thanksgiving
Does Geotrust then accept full legal responsibility of guaranteeing that the
contents of a site is legal in the US? If we find cp on a site with a Geotrust
SSL certificates, will we send the Geotrust board to prison for it? If the
answer is no, then they cannot do what you said.

~~~
ikeboy
_If the answer is no, then they cannot do what you said._

Uh, no. Plenty of companies already censor certain content without accepting
liability for parts that they miss. There is no law preventing a company from
not hosting content they find problematic, whether it's illegal or for any
other reason. That doesn't give up their protection under DMCA. (CAs wouldn't
even need DMCA, because they aren't hosting content or redistributing it).

Similarly, there is no law I know of that would disallow a CA from revoking a
cert they issued. Maybe breach of contract, but generally their terms will
prohibit illegal activities, so the other side will have breached contract
first.

~~~
thanksgiving
Do you think it should be legal for a fictional company called Goober to pay
the CA for its fictional competitor Drift so that the CA revokes certificates
"in the interest of public safety while the CA expeditiously researches the
issue" within 10 to 15 business days?

~~~
ikeboy
If the website did not do anything wrong, they can sue for breach of contract.
I explicitly addressed this point in my above comment.

~~~
thanksgiving
So maybe the CA should not proactively do anything but rather await a court
order to disrupt their customer's service? I would be completely OK with
disruption if service after a court order that requires it. I am not OK with
proactive and speculative shutdown of service (even with "infallible"
evidence, it still remains proactive and speculative until the clients are
proven guilty of illegal activities in court).

ikeboy 3 minutes ago

> I'm fine with a CA doing that. I'm also fine with them choosing to revoke
> specific certs after deciding those are clearly illegal. If they are later
> shown to be legal, then sue the CA for breach of contract or whatever.

> If you were a CA, and people were using your certs for a cp site or trading
> in stolen credit cards, how would you like being told you couldn't revoke
> the cert unless some court asked you to?

I'd tell them that I'm not responsible for what my clients do or don't do.

The CA root supply isn't big enough for the Free market to do is job by
itself.

~~~
ikeboy
I'm fine with a CA doing that. I'm also fine with them choosing to revoke
specific certs after deciding those are clearly illegal. If they are later
shown to be legal, then sue the CA for breach of contract or whatever.

If you were a CA, and people were using your certs for a cp site or trading in
stolen credit cards, how would you like being told you couldn't revoke the
cert unless some court asked you to?

>I'd tell them that I'm not responsible for what my clients do or don't do.

Hm, I wonder how well the media will take that ...

~~~
fredkbloggs
We already have a mechanism for determining that something is illegal, called
the criminal justice system. We don't need every private company in the world
passing its own judgment on that with respect to its customers, employees, or
anyone else. It is highly unlikely that even the largest and most diligent
corporation is going to be as effective at that as the public system, despite
the latter's flaws. Centuries (millennia, really) of experience and billions
of dollars go into solving this problem. If you're not satisfied with that
solution, we need to improve it, not reimplement it badly in 50,000 different
places.

~~~
ikeboy
So what exactly are you proposing? Should companies be banned from enforcing
their own standards? Should every company be required to treat any and all
customers alike, without doing a "legal risk analysis", because that prejudges
the law?

~~~
thanksgiving
Ban is a strong word. What I'm saying is that if I were a CA, it is against my
interest to project the idea that I take proactive effort against my
customers. I'm warmer to the idea of being picky on which clients to take but
even that is a picky topic.

Like you said, it doesn't matter what is legal. Media will have a field day
talking about my CA should someone like Ashley Madison be my client. But
that's just the beginning.

There will be cases against me because well f#$% me, right? I mean I took
steps in case A and was unable tondonsonin case B. It doesn't matter if the
case has no merit. If there are enough of them, it still distracts me
significantly from my job.

At least that's my perspective. I've never run a CA so I'm sure I don't
understand the subtleties but the way I understsnd it, perhaps CAs would be
better served to restrict themselves to authentication.

Now, that's not to say that CAs should do nothing. For example, if your own
private keys are compromised I can imagine a scenario where you'd move quickly
to invalidate everything underneath. But I guess these are technical and
security reasons not fear of a media backlash.

~~~
ikeboy
_What I 'm saying is that if I were a CA, it is against my interest to project
the idea that I take proactive effort against my customers._

That's fine. It's also fine for another CA to analyse the situation and come
to a different conclusion.

------
jqm
"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
sounds like they were hacked and had to revoke all certs for that TLD

~~~
nindalf
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.

------
Aldo_MX
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...](https://letsencrypt.org/2015/08/07/updated-lets-encrypt-launch-
schedule.html)

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

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

~~~
ikeboy
Quick search turns up a proposal to deal with it [https://www.ietf.org/mail-
archive/web/websec/current/msg0050...](https://www.ietf.org/mail-
archive/web/websec/current/msg00506.html) (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...](https://tools.ietf.org/html/draft-ietf-websec-strict-transport-
sec-02#section-7.3) 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](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]._

~~~
daurnimator
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

~~~
ikeboy
In case you didn't see my edit, this behavior (revoke key pin if cert was
revoked) is not in the standards, only proposed. The standards say the
opposite.

~~~
daurnimator
In that case; ouch!

------
bcoates
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
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](https://www.cloudflare.com/ssl)

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

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

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

~~~
mikekchar
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.

------
mahouse
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
People who considered the possibility of private keys for certs getting
compromised.

~~~
schoen
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!)

