Geotrust/Symantec has revoked all SSL certificates for .pw domains
colin.keigher.ca
colin.keigher.ca
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...
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.
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...
This report may be bogus, or a hoax.
https://en.wikipedia.org/wiki/.pw
And apparently its sole decent hotel is smart enough to use a .com instead:
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.
I'd much sooner support adoption of Marlinspike's Convergence or something similarly distributed: http://convergence.io/
Where it fails is as a protection against state sponsored scrutiny or a serious direct hacking attempt.
It too has seen not a lot of traction. However, Google has implemented a competing stack into Chrome (and Firefox supports it) in HPKP (HTTP Public Key Pinning) with sites having the ability to pin their cert, and these browsers will trust that bond all day.
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.
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.
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.
DANE actually reduces the people you need to trust. Hell, some CAs will issue a cert for a domain to anyone who can write to the docroot on the webserver it points to. Grabbing one before a malicious entity and deploying HSTS and HPKP is your only weak defence.
I wrote about this recently if you're interested. http://metafarce.com/adventures-in-dane/
"..the purpose of DANE is not to do away with the CA system. It is to provide another chain of trust based on the DNS hierarchy."
The commercial CAs will be a relic. It's only a matter of time before the whole house of cards collapses. The price pressure has been downwards for years. EV is not meaningful to most end-users, remaining a money-printing scam that provides little assurance of safety (if Enron, or Ashley Madison could get one, what's it worth?), and is vulnerable to MITM and rebinding attacks[1].
I anticipate that Amazon's CA[2] could undermine the profitability - and via desperation, the integrity - of the whole sector even further.
[1] http://www.blackhat.com/presentations/bh-usa-09/ZUSMAN/BHUSA... [2] http://www.geekwire.com/2015/amazon-wants-to-be-your-ssl-cer...
For extra sneakyness, they could probably return the regular glue records and whois information to most requestors, and poisoned values to the targeted CA, to get the certificate up an running in advance of hijacking the domain in general.
The problem is that you can't mitigate insecure CAs by adding a new set of irrevocable government-controlled CAs.
That's the point 'idlewords is making. Right now, the DNS does not function as a sort of distributed CA. But that's exactly what DNSSEC asks it to do.
Unless we're talking about removing domain validated certificates, I don't see why explicitly treating DNS as a CA, when it's a de facto CA is a problem. I'm not sure how we can get to HTTPS everywhere without domain validated certificates?
Google also require certificate transparency for all EV certs.
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.
All the lock icon says is "someone who made a request to the CA controls the other end of the connection". Usually this means you aren't being MITM'd by one of your ISP's or WiFi hotspot's ad insertion proxies. That's about it.
If the CAs start wanting to verify organization software engineering practices and issue different certificates based on the outcome of the audit, that's fine. But that's not my current expectation.
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?
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.
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.
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 ...
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.
That's fine. It's also fine for another CA to analyse the situation and come to a different conclusion.
It's not a practical solution, because there are many reasons a supplier might not want a particular piece of business, some of which are not harmful (lack of resources, customer with dubious credit, etc). But the arrogance of prejudging the law is very dangerous to free expression, especially when the vendor is a monopolist or oligopolist, as is the case with CAs. That danger is multiplied further when the scope of the judgment is widened beyond whether the vendor's (always overly conservative) lawyers suggest the company might be liable as a criminal accomplice if it accepted the business. It's becoming quite common for corporations to refuse to serve any customer, or to employ any person, that is not 100% inoffensive to 100% of the population. The slightest hint of controversy or any public (or often, sadly, private) statement that falls outside the Overton Window will result in being cut off. If you ask a corporate lawyer whether serving a particular customer is risky, you will always be told yes, no matter who it is. So allowing their involvement in that decision is problematic, regardless of the nominal reason offered for turning away business.
I don't know whether that's what happened here, because we don't have any kind of announcement, just an anecdote and some supposition. But I would be willing to take some pretty strong measures to make sure it can't. Extending common-carrier status to CAs would be a very modest and narrow place to start, but I would take this much farther, to the very outer edge of what's practical. The world is a horribly stifling place as it is; we don't need corporations contributing to the problem, especially since they are ill-equipped to determine whether something is illegal and will invariably default to the most conservative position.
There are hundreds of CAs. It's one of the least monopolist businesses in that regard.
As to your other points, have you seen http://slatestarcodex.com/2015/07/22/freedom-on-the-centrali...? It makes a similar point IMO.
As for how many CAs there are, it's certainly true that there are zero barriers to entry. All you need is some open source software and a couple of shell scripts. But in order to be an effective CA, you need all the major browser and OS vendors (at a minimum) to ship your root certificate in a trusted-by-default configuration. Otherwise almost no one is going to have their certificates issued by you. Looking at the list of CAs trusted by Firefox and Apple, to name but two, there aren't really that many. A couple dozen, of which many are governmental entities that don't serve the general public. I'm sure if I looked at Microsoft's and Red Hat's and Google's I would find the intersection dwindling to the same old handful we've been stuck with for years.
If it were really that simple to be an effective CA, there would be thousands of them, including many that might not even charge a fee as long as you're a member of a particular club, or that would be explicit about providing an authentication-only service. But there aren't, and that takes us back to the same problem.
But what Geotrust did was suspend all cell phones for a certain block of people. In my case, this caused me extra effort and is black mark on clients trust for me. This might be like disabling every minorities cell phone which they legitimately paid for because some minorities used the phones to arrange drug deals. It truly is ridiculous.
How about phone sellers just sell phones? We have other agencies tasked with catching drug dealers.
Never mind I was able to get a new cert from Commodo and was back in action anyway so at most they have annoyed and inconvenienced some folks.
Maybe people shouldn't sell cell phones to drug dealers.
There's no easy way to implement such a policy. There's an easy way to implement a policy of "revoke blatantly criminal websites that get reported to us".
If a site is "blatantly criminal" then it should be an easy thing to get a court to agree and issue an action against them.
I'm surprised that CA guidelines even allow CAs to take website content into issuing procedures.
Are you proposing a law to ban this? Would this apply to any company deciding not to do business with a customer for legal reasons?
>It provides excuses to refuse to issue certificates based on how they feel.
A CA is perfectly within its rights to do that, though! As far as I know, no law obligates CAs to serve everyone.
I'm not sure why you are trying to turn this into legal issue for companies. Of course they can do whatever they want. But then Mozilla and others should respond by revoking trust.
Specifically, no trusted CA should be revoking or refusing certs on non-identity issues. That seems like a perfectly reasonable requirement to hold CAs to as part of including them in default trust stores.
Because they don't want to do business with a criminal.
I don't either, most of the time. But verifying a certificate is the equivalent of checking someone's ID to make sure the name matches the face. It doesn't tell me whether someone is a criminal, nor do I expect it to. If it's that important to me, I'll check their ID and then head to the county courthouse to check public records before agreeing to anything. Whether someone is a criminal, what kind of criminal, and how recently are both too much data and too perishable and uncertain to put on someone's ID card. Which is why that's not done in most (any?) jurisdictions.
But CAs aren't government entities (well, some are, but that's besides the point). There's no right to get a cert.
This is the equivalent of a private company issuing ID cards, and deciding that they'll stop issuing cards to anyone who uses the cards for illegal activities.
That is the question I am debating. I agree that what was actually done is wrong.
See https://news.ycombinator.com/item?id=10183619, my previous response along these lines.
Nearly all developed Western countries have judicial systems that presuppose innocence until proven otherwise in a competent criminal court following established procedures. It seems like your cultural background is very different from that, which is why we're not communicating well. In my culture, asserting that someone was doing something illegal means that the person has been convicted by a criminal court with respect to that act. In many systems, saying that someone was doing something illegal without either a conviction or bearing witness under oath to the allegedly criminal act is itself a crime, that of slander or libel. It seems that you are using a very different definition, one that I don't understand. While I know little of Palau's legal traditions, in this case both the CA and its customer had no ties to Palau, and their business relationship was not governed by its laws. So even if that country and its legal culture does not follow the same principles as mine, it's not relevant to this case. Perhaps that's the confusion here?
This is a legal presumption of innocence. It doesn't mean the actions are legal.
When I say "illegal", I mean "breaks a law". This has nothing to do with cultures as far as I know; I'm an American citizen.
Whether you can tell if someone broke the law is a different question.
Let me ask you directly: if someone were to rob a bank and never get caught, did they do something illegal? If not, how would you express the claim that they did something against the law?
No conviction, no crime. I could, however, state that the bank was most likely robbed based on nothing more than accounting information. There's a crucial difference between stating that something happened and accusing a specific person of a criminal act.
> If not, how would you express the claim that they did something against the law?
As a witness to an act, I would state the facts as I observed them, without passing judgment myself. This is exactly what's done in court. "At time X I was at location Y, and I saw a person with features Z enter the bank, pass a piece of paper to a teller, and run out of the bank shortly thereafter with what appeared to be cash. I believe that person to be the defendant, who is sitting there (points)." The testimony of non-expert witnesses is limited to facts, not opinions. Because for all I know, the note could have been a valid withdrawal slip, the customer may have been in a hurry, and the money was actually stolen by a teller and an accomplice who used the rushed customer's large withdrawal as a cover (was the customer an accomplice? I don't know!).
If I were not a witness, I wouldn't make such a claim in the first place.
All the more reason that they have no particular responsibility to revoke certificates of "criminals".
We've absolutely got to get rid of the idea that a certificate is any sort of measure of probity. It isn't. It's simply a verification of identity.
Breach notification in 3..2..1...
Explain why they aren't permanently blacklisted and banned from ever being in the root store for any purpose again???
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.
Hopefully dealing with bad CAs will be a thing of the past.
[1] https://letsencrypt.org/2015/08/07/updated-lets-encrypt-laun...
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
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].
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
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.
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.
So I'd assume that this is kind of a "bulletproof" - if you don't pay, they won't revoke.
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.
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.
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!)