Geotrust/Symantec has revoked all SSL certificates for .pw domains(colin.keigher.ca)
colin.keigher.ca
Geotrust/Symantec has revoked all SSL certificates for .pw domains
http://colin.keigher.ca/2015/09/geotrustsymantec-has-revoked-all-ssl.html
98 comments
Wait. I'm the last person to defend Symantec (see [1] [2]) but the headline seems to be a load of rubbish, or at least certainly isn't backed by the content of the article.
Here are the only two reseller quotes from the article:
> Reseller rep.:
> We regret to inform you that certificate [number] for www.canary.pw domain has been revoked by the Certificate Authority due to the site being flagged as potentially containing malware in a recent site scanning by Symantec (owner of GeoTrust). Unfortunately we were not warned of the upcoming revocation, so we apologize for any inconvenience that this may cause.
A single website, that allows people to search stolen data, eg the Ashley Madison hack, and asks people to submit stolen data, has had it's certificate revoked.
and:
> Reseller rep.:
> As per our check with Symantec, they will no longer be issuing SSL certs to .PW domains. You are advised to remove the SSL certificate from the server to avoid security errors related to a revoked certificate.
> And furthermore Symantec are no longer issuing certificates for the .pw TLD.
Neither quote equates to Symantec having 'revoked all SSL certificates for .PW TLD domains' as mentioned in the headline and this HN submission.
As much as I dislike Symantec - and I really dislike Symantec - I think this article's headline is false.
[1]. https://certsimple.com/blog/seal-in-search
[2]. https://certsimple.com/blog/sgc-ssl-certificates
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
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.
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...
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...
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.
This report may be bogus, or a hoax.
For everybody else who was wondering, .pw is Palau, a tiny island nation (pop. 17k) in Micronesia:
https://en.wikipedia.org/wiki/.pw
And apparently its sole decent hotel is smart enough to use a .com instead:
http://www.palauppr.com/default-en.html
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
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.
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. :(
"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.
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 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.
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'd much sooner support adoption of Marlinspike's Convergence or something similarly distributed: http://convergence.io/
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.
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.
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.
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.
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.
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?
That's true; what cropped up after Convergence was TACK: http://tack.io/index.html
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.
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.
There seems to be this mistaken belief that DNSSEC/DANE are intended to replace CAs. There is no such idea.
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."
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."
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.
[1] http://www.blackhat.com/presentations/bh-usa-09/ZUSMAN/BHUSA... [2] http://www.geekwire.com/2015/amazon-wants-to-be-your-ssl-cer...
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...
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?)
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.
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.
You really think that giving Libya the keys to bit.ly, for example, is a step forward?
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.
No! Choosing a .LY name for your website does not give the government of Libya your TLS keys. With DNSSEC, that could change.
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 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.
CAs are insecure. Nobody is arguing otherwise.
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.
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.
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?
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?
So after all those years of x509/asn1/openssl bugs and ca breaches we are left with... ~/.ssh/known_hosts reimplemented, poorly? :-}
That's what HPKP and certificate transparency are for.
Google also require certificate transparency for all EV certs.
Google also require certificate transparency for all EV certs.
Why on earth should any CA be getting involved in what a site hosts? They need to validate ownership and stop.
This wasn't even a single site - it was an entire TLD that got revoked. There's no excuse for that kind of action unless the private key for that TLD was compromised.
Breach notification in 3..2..1...
Breach notification in 3..2..1...
In the current SSL system there is no such concept as a "private key for a TLD". Every single one of the roots can sign anything. :(
Some browsers do restrict CAs, see e.g. http://googleonlinesecurity.blogspot.ca/2013/12/further-impr...
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???
Explain why they aren't permanently blacklisted and banned from ever being in the root store for any purpose again???
[deleted]
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.
What has happened here feels very similar to vigilantism.
If a site is blatantly criminal, should a CA revoke its cert?
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?
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?
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.
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.
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?
If the website did not do anything wrong, they can sue for breach of contract. I explicitly addressed this point in my above comment.
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 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 ...
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?
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.
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".
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".
[deleted]
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.
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.
>CAs should never intercede without a court order.
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.
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.
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.
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.
>No. Why would they?
Because they don't want to do business with a criminal.
Because they don't want to do business 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.
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.
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.
When I say "this", I mean what I asked above: "If a site is blatantly criminal, should a CA revoke its cert?"
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.
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.
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. 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?
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.
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.
[deleted]
> But CAs aren't government entities
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.
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.
No. Separation of concerns and all....
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.
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.
No of course not. The certificate is to prove ownership, nothing more. Criminal activity doesn't alter that. There are other laws to cover that.
"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.
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.
sounds like they were hacked and had to revoke all certs for that TLD
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.
This happened last Monday morning incidentally. So the authors certs have actually been suspended for at least a week already.
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...
Hopefully dealing with bad CAs will be a thing of the past.
[1] https://letsencrypt.org/2015/08/07/updated-lets-encrypt-laun...
I think DNS signing authorities are a bunch of outlaws. They charge for trust, yet don't establish it themselves.
Btw, can someone explain to me how revocation interacts with certificate pinning?
Quick search turns up a proposal to deal with it https://www.ietf.org/mail-archive/web/websec/current/msg0050... (but hasn't been implemented in the actual standard, see below).
Revocation
In the event of pin mismatch, clients MUST check whatever revocation mechanism is available, and attempt to discover whether the certificate with the mismatching fingerprint has been revoked. For example:
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].
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].
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
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.
In that case; ouch!
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.
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.
[0] https://www.cloudflare.com/ssl
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
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.
So I'd assume that this is kind of a "bulletproof" - if you don't pay, they won't revoke.
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.
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.
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.
Anybody care to comment rather than just downvote? I wouldn't mind hearing some thoughts regarding this part of the project.
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.
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.
Please resist commenting about being downvoted. It never does any good, and it makes boring reading.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
[deleted]
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
People who considered the possibility of private keys for certs getting compromised.
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!)
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