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. :(
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.
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/
I think you're forgetting the 99% of internet users who are nowhere near computer-literate enough to make anything approaching not-insane decisions about who to trust. I'm not a fan of the CAs either, but trust is a really hard problem and surfacing it to people who would just as easily try to run viagra.exe on their Macs is unlikely to make the situation better.
Completely agreed - the current system of CAs is designed to blunt phishing attacks and secure cc transactions over the wire and it mostly succeeds at that.
Where it fails is as a protection against state sponsored scrutiny or a serious direct hacking attempt.
Unfortunately convergence is dead for 4 years now with no updates. Do you know if that's just enthusiasm running out, or was there some serious issue with the service?
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.
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.
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.
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.
It doesn't really matter. Most people are only getting their CA certs through domain validation anyhow, so you're already at the mercy of registrars and TLDs.
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.
If only intentions made the world go round. But how we use things, and build upon them, is often rather more interesting than what someone intended.
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.
How is it relevant that Enron or Ashley Madison could get EV certificates? They are intended to proof that you're communicating with whom you intended to communicate. They make no claim about the trustworthiness of the company itself (and how would you even test that?)
Doesn't Libya already have the keys? They can redelgate the zone and get a domain controlled cert. Or probably something more subtle with selective who is responses.
If the operator of .LY might takeover the domain to return DANE records that it controls, why wouldn't it takeover the domain and procure a domain validated certificate from a CA?
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.
For domain validated certificates, the DNS does essentially function as a sort of distributed CA; if you control the DNS for a domain, you can get the certificate issued: this isn't insecure, it's by design.
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?
"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.
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.
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.
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].
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
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.
"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.
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.
I tend to agree. There is so much that SSL/TLS doesn't validate that I don't have a strong security expectation. The web server could be some pre-release accidentally pushed to production. The software I'm talking to on the other end could be bug central. The employees at the company could be untrustworthy. The site could be compromised. Someone could be sniffing traffic between frontends and backends ("SSL added and removed here! :-)")
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 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.
What if it is declared illegal by the DOJ and declared legal by one of the lower level courts, and there is an appeal by the DOJ? Is it legal or illegal then?
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.
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.
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?
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.
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 ...
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.
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?
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.
If that's the only alternative to what's happening today, yes.
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.
I missed that article; thanks for the pointer. They mentioned several of the examples I had in mind as I was writing about this. In the future I'll just link to that.
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.
Maybe people shouldn't sell cell phones to drug dealers.
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.
I understand, and I'm not defending them. But the comment I originally replied to was going too far in the opposite direction, and saying CAs should never intercede.
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".
CAs should never intercede without a court order. That's how societies determine what is illegal: we let judges and courts sort it out. Otherwise you're making CAs ad-hoc courts which is a bad thing to do. It provides excuses to refuse to issue certificates based on how they feel.
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.
Nothing to do with law. CAs are bound by the requirements that Mozilla, MS, Google and others set out. These requirements obviously go far beyond the law. For instance they require that a CA issue certs to the public (IIRC), so you can't become a trusted CA if you're only issuing for your company.
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.
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.
> 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 verifying a certificate is the equivalent of checking someone's ID to make sure the name matches the face.
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.
You keep making it out like they suspended individual certs. That would have been bad enough but it isn't what happened. They revoked all certs including those they had previously sold (with certain implied expectations) to people (such as myself) who were not engaged in any illicit activity. They didn't even inform me before hand and I only found out when clients were unable to conduct their business through my app. I actually had to track the source of the problem down... because they were too lazy to inform me after being too lazy to only suspend offending certs in the first place and inconsiderate enough of their commitments and my business to honer the certs for the period they had taken money for rather than simply declining to further sell certs for this TLD. It caused me a good deal of hassle. Not enough of a hassle to sue, that isn't an option, but what they did is quite egregious and is, at very minimum laziness and bad business and up a level unethical and borderline scummy. They might, by some twisted definition, have a legal "right" to do this but they are still assholes and people should probably refrain from doing business with them.
There are no illegal activities involved here, because none of these certificates have been revoked following a criminal conviction related to their use.
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?
>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.
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?
> Let me ask you directly: if someone were to rob a bank and never get caught, did they do something illegal?
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.
If they use a legitimate and accurate ID card that I issued while they committed a crime, I'm not sure why I would be upset about it. All the easier to track them down. It's an ID card, not a seal of approval. You can copy seal of approval gifs without anyone's help.
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.
So a CA got caught red-handed having issued an intermediate CA that spoofed google domains ... and instead of throwing them out of the CA club, their response was to reluctantly limit them to *.fr and 12 other TLDs?
Explain why they aren't permanently blacklisted and banned from ever being in the root store for any purpose again???
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!)
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]
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.
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.
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.
103 comments
[ 5.3 ms ] story [ 183 ms ] threadThe 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.
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:
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].
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
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.
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???
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
Hopefully dealing with bad CAs will be a thing of the past.
[1] https://letsencrypt.org/2015/08/07/updated-lets-encrypt-laun...
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.
[0] https://www.cloudflare.com/ssl
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.
https://news.ycombinator.com/newsguidelines.html
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.
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.
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!)
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
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