7 ms·

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

157 points by afreak 11y ago

deleted 11y ago
[deleted]
0x0 11y ago
The current CA PKI system is pure madness. Everyone in the CA club can issue certificates for anything - and you are at their mercy for not revoking. And what's worse, even if you pick a decent vendor, you can't prevent shadier outfits from also issuing parallel certs. :(
- inopinatus 11y ago
  In the short term - by which I mean, the next ten years - my hopes are on DNSSEC with DANE/TLSA for DNS-based certificate assurance. This is not a great solution: firstly, adoption of DNSSEC has yet to snowball; and secondly, DNS remains a tree with a single root controlled by a governmental authority, and it's tough to argue that's any better than the CAs. The longer dream of a universally federated, decentralized trust mesh depends on a substrate protocol emerging for which I think Bitcoin is only the first glimmer of hope; timeframe ca.10-50 years.
  - thezilch 11y ago
    Except DNSSEC is just as sketch (and maybe more so) a trust chain. We replace CAs with registrars (OH GOD), TLDs (and for .com, that's just CAs again or governments, OH GOD), and ICANN (subject to government seizures!!!). I'd much sooner support adoption of Marlinspike's Convergence or something similarly distributed: http://convergence.io/ http://convergence.io/
    - superuser2 11y ago
      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.
      - michaelbuckbee 11y ago
        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.
    - viraptor 11y ago
      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?
      - thezilch 11y ago
        That's true; what cropped up after Convergence was TACK: http://tack.io/index.html 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.
    - 0x0 11y ago
      But even with today's SSL CA system, those entities (registars, TLDs, ICANN) have full control. They could easily override the NS records and/or WHOIS for a domain targeting a domain-validating CA, and receive a valid certificate. Might as well place the CA authorities with the TLDs, then. At least that would limit their authority to their subtree, instead of the free-for-all that is the current CA club. It might even let end-users make a semi informed trust decision: ".be seems to run a tight shop and appears trustworthy, .ly not so much" (random TLDs picked for example purposes only). It would even make it worthwhile for site owners to pick a more reliable/valuable/expensive TLD (and thus CA), since it would bring a generally-accepted-to-be higher level of trust.
      - bro-stick 11y ago
        Exactly. The challenges with convergence are akin to a simplified gpg+keybase... increasing its popularity needs further development and proponents to gather a critical mass of users and providers. Trust is hard. For top-down TLS CA to work, the net needs a fewer trustworthy, sensible, well-secured/geo ip'd/leadership nonprofits to be the systems-of-record far out of reach of govt and corporate dictatorships. (icann, iana are a good start, but they could be better. ssl cert cert authority as another type common-good org.). Also, having a zillion CAs able to independently issue endless wildcard certs for the same domain is lunacy... only the domain owner can be issued certs. It should be tied to common global record-keeping system as domain name registrars do and/or domain registrar-mediated challenge to prove ownership (control panel login / authenticated API calls, not just adding some spoofable TXT record cookie or link in an email). End MITM by rogue certs, at a minimum.
        0x0 11y ago
        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.
    - nly 11y ago
      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.
    - AndyMcConachie 11y ago
      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/ 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."
      - inopinatus 11y ago
        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/BHUSA09-Zusman-AttackExtSSL-SLIDES.pdf http://www.blackhat.com/presentations/bh-usa-09/ZUSMAN/BHUSA... [2] http://www.geekwire.com/2015/amazon-wants-to-be-your-ssl-certificate-provider-applies-to-be-a-root-certifcate-authority/ http://www.geekwire.com/2015/amazon-wants-to-be-your-ssl-cer...
        realityking 11y ago
        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?)
  - idlewords 11y ago
    You really think that giving Libya the keys to bit.ly, for example, is a step forward?
    - toast0 11y ago
      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.
      - tptacek 11y ago
        No! Choosing a .LY name for your website does not give the government of Libya your TLS keys. With DNSSEC, that could change.
        toast0 11y ago
        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.
        tptacek 11y ago
        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.
        toast0 11y ago
        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?
- aianus 11y ago
  https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning https://developer.mozilla.org/en-US/docs/Web/Security/Public...
  - 0x0 11y ago
    So after all those years of x509/asn1/openssl bugs and ca breaches we are left with... ~/.ssh/known_hosts reimplemented, poorly? :-}
- nailer 11y ago
  That's what HPKP and certificate transparency are for. Google also require certificate transparency for all EV certs.
- chetanahuja 11y ago
  "The current CA PKI system is pure madness. Everyone in the CA club can issue certificates for anything" It boggles the mind that all these security experts (including those frequenting these forums) take such pains over obscure, hard to exploit things (like about half the CVE vulns), and come down with the fury of a thousand suns on anyone daring to come up with, say a new secure messaging protocols without their permission (remember the Telegram brouhaha) and yet blithely go on endorsing and even encouraging this totally broken third party trust system, this house of cards that the entire web security framework is built on. Just baffling.
  - Zigurd 11y ago
    Many security consultants sell "security" out one door and surveillance/forensics out the other door. Only one of those businesses sells a working product/service.
daurnimator 11y ago
Btw, can someone explain to me how revocation interacts with certificate pinning?
- ikeboy 11y ago
  Quick search turns up a proposal to deal with it https://www.ietf.org/mail-archive/web/websec/current/msg00506.html https://www.ietf.org/mail-archive/web/websec/current/msg0050... (but hasn't been implemented in the actual standard, see below). Revocation In the event of pin mismatch, clients MUST check whatever revocation mechanism is available, and attempt to discover whether the certificate with the mismatching fingerprint has been revoked. For example: offending_certificate = cert in certificate_chain where cert.public_key.fingerprint == mismatched_fingerprint revoked = offending_certificate.serial_number in revoked_serials If the offending certificate has been revoked, it is unpinned and the UA can re-evaluate the pin list. If there are no pinned fingerprints left on the pin list, the browser downgrades the host from Known Pinned HSTS Host to Known HSTS Host. The revocation mechanism could be an extant mechanism such as CRL or OCSP, or a new one such as browser updates, whitelists, blacklists, or an in-built CRL. This document is agnostic about the revocation mechanism(s) UAs may use. Un-pinning Certificates that are invalidated for any reason and by any means -- revocation by extant or future means, expiration, blacklisting -- are effectively removed from the pin list. Certificates whose intermediary or root signers are revoked are also effectively invalidated and removed from the pin list. HSTS Hosts can un-set pins in clients (un-pin) by setting a pins directive that contains no pins. UAs MUST NOT obey the un-pinning directive unless the empty pins directive is set on a response in a TLS connection that was authenticated with one of the previously pinned public keys. This doesn't seem to have made it into the standard, though: https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-02#section-7.3 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 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].
jqm 11y ago
"But here's the thing: why did Geotrust just go ahead and revoke the certificates for all .PW domains without any warning?" Why indeed? My first notice of this was a client unable to use the app even though the cert was issued less than 6 months ago and was a 2 year cert. Like the author I also initially thought client configuration issue until I tried. I contacted the reseller who didn't have an answer right off the bat but had to contact Geotrust. After 15 minutes of fooling around I got an answer and a refund. So yes, they issued me a refund. Great. My clients had downtime. I had to drop what I was doing "right then" and install new certs. Finally I had to walk clients through clearing old certs from their browser as they were getting the scary "Untrusted!" popup. Fortunately this is a private app for a specific client so there weren't a bunch of calls. Geotrust's handling of this was ridiculous. No email, no notification... I'll certainly never get a cert from then again over this incident.
- rosege 11y ago
  sounds like they were hacked and had to revoke all certs for that TLD
  - jqm 11y ago
    This happened last Monday morning incidentally. So the authors certs have actually been suspended for at least a week already.
  - nindalf 11y ago
    I don't think GeoTrust was hacked. If they had been, their response was "sorry guys, we're working on fixing this soon. You'll have to do x,y,z to fix your domain". Their actual response was "[we] will no longer be issuing SSL certs to .PW domains", so they have some problem with .PW that doesn't seem to be technical.
MichaelGG 11y ago
Why on earth should any CA be getting involved in what a site hosts? They need to validate ownership and stop.
- ikeboy 11y ago
  If a site is blatantly criminal, should a CA revoke its cert?
  - jqm 11y ago
    No. Separation of concerns and all....
    - jrockway 11y ago
      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.
  - MichaelGG 11y ago
    A: Seems like they got it wrong here if that was indeed their reason. That alone is good enough to say no. B: Criminal for who? I certainly don't want Geotrust deciding what's allowed. Does that mean they can e.g. block sites donating to Wikileaks?
    - ikeboy 11y ago
      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.
kordless 11y ago
I think DNS signing authorities are a bunch of outlaws. They charge for trust, yet don't establish it themselves.
jpatokal 11y ago
For everybody else who was wondering, .pw is Palau, a tiny island nation (pop. 17k) in Micronesia: https://en.wikipedia.org/wiki/.pw https://en.wikipedia.org/wiki/.pw And apparently its sole decent hotel is smart enough to use a .com instead: http://www.palauppr.com/default-en.html http://www.palauppr.com/default-en.html
- Canada 11y ago
  http://www.cc.com/video-clips/xzhg3v/the-colbert-report-meet-an-ally---palau http://www.cc.com/video-clips/xzhg3v/the-colbert-report-meet...
- nmcfarl 11y ago
  Also truly stunningly beautiful place to visit - though a bit difficult to get to. And it certainly has significantly more decent hotels than just that one. Tourism is definitely it's biggest industry.
Aldo_MX 11y ago
Let's encrypt it's starting to issue the first certificates[1]. Hopefully dealing with bad CAs will be a thing of the past. [1] https://letsencrypt.org/2015/08/07/updated-lets-encrypt-launch-schedule.html https://letsencrypt.org/2015/08/07/updated-lets-encrypt-laun...
bcoates 11y ago
I've had issues with other registrars revoking certificates for questionable reasons (i.e., any reason other than obvious loss of control of the private key). Is there a "bulletproof" registrar that doesn't revoke? If my client loses thousands of dollars per day of downtime I'm sure they'd be willing to pay through the nose for it. I understand the reasons for having a revocation system but it's often not a benefit to me on balance-of-risks basis.
- biot 11y ago
  How about getting certificates from multiple, geopolitically diverse providers up front? It'll be an extra expense but lets you monitor your certs' revocation status and, should cert #1 get revoked, update your configs to use cert #2 and so on. That might even be a good idea for CloudFlare to implement in their SSL offerings[0] if they don't already. They could offer multiple SSL certs from various providers (for an extra fee even) and the whole process would be completely transparent to your origin server, which can run its own self-signed cert. [0] https://www.cloudflare.com/ssl https://www.cloudflare.com/ssl
- krishna_k 11y ago
  startssl.com has a different business model - you pay for verification (fairly cheaply), not for the certificates themselves. BUT, they charge you $25 for revocation. So I'd assume that this is kind of a "bulletproof" - if you don't pay, they won't revoke.
kruhft 11y ago
I just developed a browser to server based crytpo channel meant to replace the SLL certificate mess on a side project I'm working on. I know that there's a bad rap for browser based crytpo and rolling your own but I've got some knowledge and thought I would give it a shot. The code is not public (yet) but uses DH key exchange (using the JS BigInt library) to exchange a 2048 bit token key and then uses sjcl to perform encryption on each packet/request using the resulting key. It's lacking host validation (am I talking to the correct server?), but I'm still working getting that piece together.
- kruhft 11y ago
  Anybody care to comment rather than just downvote? I wouldn't mind hearing some thoughts regarding this part of the project.
  - stephengillie 11y ago
    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
  - mikekchar 11y ago
    Complaint about complaint about downvoting notwithstanding, my guess as to why nobody commented was: there is no meaningful way to comment on it. There is no link with a detailed description of what you have done, or demonstration of how it works. There is also no source code to look at yet. While I am sure it is an exciting project for you, without something that people can try (or at least source code to look at), it doesn't add anything valuable to the reader of the comment. It just adds to the noise of the conversation. If you wait until you are ready to show people the code, then I'm sure many people will be interested to discuss it. Before that, it's not time yet. That's my perspective, anyway. I hope it is useful to you.
Animats 11y ago
This is strange. An entire TLD? Symantec hasn't issued an announcement. There's nothing on the CA/Browser Forum mailing list. Nothing on the Symantec Security Response Blog. Nothing on Symantec's Twitter feeds. Symantec stopped issuing certs in .PW six days ago, according to a blog post.[1] But there appears to have been no public announcement. Even if there was a major security breach justifying this, Symantec has botched the revocation and has lost much trust. [1] https://www.reddit.com/r/sysadmin/comments/3j9iyk/just_a_heads_up_symantec_is_cancelling_ssl/ https://www.reddit.com/r/sysadmin/comments/3j9iyk/just_a_hea...
- Animats 11y ago
  24 hours later, I'm not seeing any reliable source reporting this. No hits in Google News. Nothing on TechDirt. Nothing on security blogs. Nothing on CA/Browser mailing list. Most hits in Google are to scraper spam blogs that scraped HN. This report may be bogus, or a hoax.
mahouse 11y ago
I don't know who thought that having the possibility of revoking certificates was a good idea, especially when that possibility is controlled by CAs
- andrewflnr 11y ago
  People who considered the possibility of private keys for certs getting compromised.
  - schoen 11y ago
    It's an interesting question whether it would be a good idea to require revocations to be signed by the subject key rather than by the issuer key. I guess it depends on the threat model! Conceptually, the idea is that if the issuer makes an assertion about what's true, they want to later be able to stop making that assertion. That seems to make basic sense. (But in some threat models, the issuer might have been coerced, and maybe it's easier to coerce authorities to revoke than to misissue. For one thing, browsers are unlikely to kick CAs out of their trust lists for improper revocation, but they might for misissuance!)
flashman 11y ago
Could this be anything like the DigiNotar hack?[0] If it came out that Symantec's certificate authority was used to issue fraudulent certificates, the damage to their business could be in the hundreds of millions. What if the silence is because Symantec is trying to figure out the best way to break the news to us? Edit: After a bit more reading, Symantec has some history of monitoring .pw for malware and spam.[1][2][3] Perhaps someone just decided they wanted nothing more to do with PW issuer Directi, which apparently has a poor reputation.[4] [0]https://en.wikipedia.org/wiki/DigiNotar https://en.wikipedia.org/wiki/DigiNotar [1]http://www.symantec.com/connect/blogs/rise-pw-urls-spam-messages http://www.symantec.com/connect/blogs/rise-pw-urls-spam-mess... [2]http://www.symantec.com/connect/blogs/pw-hit-and-run-spam-royal-baby-trend http://www.symantec.com/connect/blogs/pw-hit-and-run-spam-ro... [3]http://www.symantec.com/connect/blogs/rig-exploit-kit-used-recent-website-compromise http://www.symantec.com/connect/blogs/rig-exploit-kit-used-r... [4]http://www.jl.ly/Email/palau.html http://www.jl.ly/Email/palau.html
- nailer 11y ago
  Wait. I'm the last person to defend Symantec (see [1] [2]) but the headline seems to be a load of rubbish, or at least certainly isn't backed by the content of the article. Here are the only two reseller quotes from the article: > Reseller rep.: > We regret to inform you that certificate [number] for www.canary.pw domain has been revoked by the Certificate Authority due to the site being flagged as potentially containing malware in a recent site scanning by Symantec (owner of GeoTrust). Unfortunately we were not warned of the upcoming revocation, so we apologize for any inconvenience that this may cause. A single website, that allows people to search stolen data, eg the Ashley Madison hack, and asks people to submit stolen data, has had it's certificate revoked. and: > Reseller rep.: > As per our check with Symantec, they will no longer be issuing SSL certs to .PW domains. You are advised to remove the SSL certificate from the server to avoid security errors related to a revoked certificate. > And furthermore Symantec are no longer issuing certificates for the .pw TLD. Neither quote equates to Symantec having 'revoked all SSL certificates for .PW TLD domains' as mentioned in the headline and this HN submission. As much as I dislike Symantec - and I really dislike Symantec - I think this article's headline is false. [1]. https://certsimple.com/blog/seal-in-search https://certsimple.com/blog/seal-in-search [2]. https://certsimple.com/blog/sgc-ssl-certificates https://certsimple.com/blog/sgc-ssl-certificates
Animats 11y ago
Is this for real? All we have is one unknown blogger, Colin Keigher, picked up by other sources. It's Tuesday afternoon, so everyone is back at work. A takedown of an entire TLD should have hit news sources and major security blogs by now. I'm not seeing anything other than echos of the original blog post. It hasn't even come up on the CA/Browser forum mailing list or security blogs.

157 points by afreak 11y ago

deleted 11y ago

[deleted]

0x0 11y ago

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

inopinatus 11y ago
In the short term - by which I mean, the next ten years - my hopes are on DNSSEC with DANE/TLSA for DNS-based certificate assurance. This is not a great solution: firstly, adoption of DNSSEC has yet to snowball; and secondly, DNS remains a tree with a single root controlled by a governmental authority, and it's tough to argue that's any better than the CAs. The longer dream of a universally federated, decentralized trust mesh depends on a substrate protocol emerging for which I think Bitcoin is only the first glimmer of hope; timeframe ca.10-50 years.
- thezilch 11y ago
  Except DNSSEC is just as sketch (and maybe more so) a trust chain. We replace CAs with registrars (OH GOD), TLDs (and for .com, that's just CAs again or governments, OH GOD), and ICANN (subject to government seizures!!!). I'd much sooner support adoption of Marlinspike's Convergence or something similarly distributed: http://convergence.io/ http://convergence.io/
  - superuser2 11y ago
    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.
    - michaelbuckbee 11y ago
      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.
  - viraptor 11y ago
    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?
    - thezilch 11y ago
      That's true; what cropped up after Convergence was TACK: http://tack.io/index.html 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.
  - 0x0 11y ago
    But even with today's SSL CA system, those entities (registars, TLDs, ICANN) have full control. They could easily override the NS records and/or WHOIS for a domain targeting a domain-validating CA, and receive a valid certificate. Might as well place the CA authorities with the TLDs, then. At least that would limit their authority to their subtree, instead of the free-for-all that is the current CA club. It might even let end-users make a semi informed trust decision: ".be seems to run a tight shop and appears trustworthy, .ly not so much" (random TLDs picked for example purposes only). It would even make it worthwhile for site owners to pick a more reliable/valuable/expensive TLD (and thus CA), since it would bring a generally-accepted-to-be higher level of trust.
    - bro-stick 11y ago
      Exactly. The challenges with convergence are akin to a simplified gpg+keybase... increasing its popularity needs further development and proponents to gather a critical mass of users and providers. Trust is hard. For top-down TLS CA to work, the net needs a fewer trustworthy, sensible, well-secured/geo ip'd/leadership nonprofits to be the systems-of-record far out of reach of govt and corporate dictatorships. (icann, iana are a good start, but they could be better. ssl cert cert authority as another type common-good org.). Also, having a zillion CAs able to independently issue endless wildcard certs for the same domain is lunacy... only the domain owner can be issued certs. It should be tied to common global record-keeping system as domain name registrars do and/or domain registrar-mediated challenge to prove ownership (control panel login / authenticated API calls, not just adding some spoofable TXT record cookie or link in an email). End MITM by rogue certs, at a minimum.
      - 0x0 11y ago
        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.
  - nly 11y ago
    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.
  - AndyMcConachie 11y ago
    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/ 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."
    - inopinatus 11y ago
      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/BHUSA09-Zusman-AttackExtSSL-SLIDES.pdf http://www.blackhat.com/presentations/bh-usa-09/ZUSMAN/BHUSA... [2] http://www.geekwire.com/2015/amazon-wants-to-be-your-ssl-certificate-provider-applies-to-be-a-root-certifcate-authority/ http://www.geekwire.com/2015/amazon-wants-to-be-your-ssl-cer...
      - realityking 11y ago
        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?)
- idlewords 11y ago
  You really think that giving Libya the keys to bit.ly, for example, is a step forward?
  - toast0 11y ago
    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.
    - tptacek 11y ago
      No! Choosing a .LY name for your website does not give the government of Libya your TLS keys. With DNSSEC, that could change.
      - toast0 11y ago
        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.
        tptacek 11y ago
        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.
        toast0 11y ago
        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?
aianus 11y ago
https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning https://developer.mozilla.org/en-US/docs/Web/Security/Public...
- 0x0 11y ago
  So after all those years of x509/asn1/openssl bugs and ca breaches we are left with... ~/.ssh/known_hosts reimplemented, poorly? :-}
nailer 11y ago
That's what HPKP and certificate transparency are for. Google also require certificate transparency for all EV certs.
chetanahuja 11y ago
"The current CA PKI system is pure madness. Everyone in the CA club can issue certificates for anything" It boggles the mind that all these security experts (including those frequenting these forums) take such pains over obscure, hard to exploit things (like about half the CVE vulns), and come down with the fury of a thousand suns on anyone daring to come up with, say a new secure messaging protocols without their permission (remember the Telegram brouhaha) and yet blithely go on endorsing and even encouraging this totally broken third party trust system, this house of cards that the entire web security framework is built on. Just baffling.
- Zigurd 11y ago
  Many security consultants sell "security" out one door and surveillance/forensics out the other door. Only one of those businesses sells a working product/service.

daurnimator 11y ago

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

ikeboy 11y ago
Quick search turns up a proposal to deal with it https://www.ietf.org/mail-archive/web/websec/current/msg00506.html https://www.ietf.org/mail-archive/web/websec/current/msg0050... (but hasn't been implemented in the actual standard, see below). Revocation In the event of pin mismatch, clients MUST check whatever revocation mechanism is available, and attempt to discover whether the certificate with the mismatching fingerprint has been revoked. For example: offending_certificate = cert in certificate_chain where cert.public_key.fingerprint == mismatched_fingerprint revoked = offending_certificate.serial_number in revoked_serials If the offending certificate has been revoked, it is unpinned and the UA can re-evaluate the pin list. If there are no pinned fingerprints left on the pin list, the browser downgrades the host from Known Pinned HSTS Host to Known HSTS Host. The revocation mechanism could be an extant mechanism such as CRL or OCSP, or a new one such as browser updates, whitelists, blacklists, or an in-built CRL. This document is agnostic about the revocation mechanism(s) UAs may use. Un-pinning Certificates that are invalidated for any reason and by any means -- revocation by extant or future means, expiration, blacklisting -- are effectively removed from the pin list. Certificates whose intermediary or root signers are revoked are also effectively invalidated and removed from the pin list. HSTS Hosts can un-set pins in clients (un-pin) by setting a pins directive that contains no pins. UAs MUST NOT obey the un-pinning directive unless the empty pins directive is set on a response in a TLS connection that was authenticated with one of the previously pinned public keys. This doesn't seem to have made it into the standard, though: https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-02#section-7.3 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 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].

jqm 11y ago

"But here's the thing: why did Geotrust just go ahead and revoke the certificates for all .PW domains without any warning?" Why indeed? My first notice of this was a client unable to use the app even though the cert was issued less than 6 months ago and was a 2 year cert. Like the author I also initially thought client configuration issue until I tried. I contacted the reseller who didn't have an answer right off the bat but had to contact Geotrust. After 15 minutes of fooling around I got an answer and a refund. So yes, they issued me a refund. Great. My clients had downtime. I had to drop what I was doing "right then" and install new certs. Finally I had to walk clients through clearing old certs from their browser as they were getting the scary "Untrusted!" popup. Fortunately this is a private app for a specific client so there weren't a bunch of calls. Geotrust's handling of this was ridiculous. No email, no notification... I'll certainly never get a cert from then again over this incident.

rosege 11y ago
sounds like they were hacked and had to revoke all certs for that TLD
- jqm 11y ago
  This happened last Monday morning incidentally. So the authors certs have actually been suspended for at least a week already.
- nindalf 11y ago
  I don't think GeoTrust was hacked. If they had been, their response was "sorry guys, we're working on fixing this soon. You'll have to do x,y,z to fix your domain". Their actual response was "[we] will no longer be issuing SSL certs to .PW domains", so they have some problem with .PW that doesn't seem to be technical.

MichaelGG 11y ago

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

ikeboy 11y ago
If a site is blatantly criminal, should a CA revoke its cert?
- jqm 11y ago
  No. Separation of concerns and all....
  - jrockway 11y ago
    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.
- MichaelGG 11y ago
  A: Seems like they got it wrong here if that was indeed their reason. That alone is good enough to say no. B: Criminal for who? I certainly don't want Geotrust deciding what's allowed. Does that mean they can e.g. block sites donating to Wikileaks?
  - ikeboy 11y ago
    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.

kordless 11y ago

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

jpatokal 11y ago

For everybody else who was wondering, .pw is Palau, a tiny island nation (pop. 17k) in Micronesia: https://en.wikipedia.org/wiki/.pw https://en.wikipedia.org/wiki/.pw And apparently its sole decent hotel is smart enough to use a .com instead: http://www.palauppr.com/default-en.html http://www.palauppr.com/default-en.html

Canada 11y ago
http://www.cc.com/video-clips/xzhg3v/the-colbert-report-meet-an-ally---palau http://www.cc.com/video-clips/xzhg3v/the-colbert-report-meet...
nmcfarl 11y ago
Also truly stunningly beautiful place to visit - though a bit difficult to get to. And it certainly has significantly more decent hotels than just that one. Tourism is definitely it's biggest industry.

Aldo_MX 11y ago

Let's encrypt it's starting to issue the first certificates[1]. Hopefully dealing with bad CAs will be a thing of the past. [1] https://letsencrypt.org/2015/08/07/updated-lets-encrypt-launch-schedule.html https://letsencrypt.org/2015/08/07/updated-lets-encrypt-laun...

bcoates 11y ago

I've had issues with other registrars revoking certificates for questionable reasons (i.e., any reason other than obvious loss of control of the private key). Is there a "bulletproof" registrar that doesn't revoke? If my client loses thousands of dollars per day of downtime I'm sure they'd be willing to pay through the nose for it. I understand the reasons for having a revocation system but it's often not a benefit to me on balance-of-risks basis.

biot 11y ago
How about getting certificates from multiple, geopolitically diverse providers up front? It'll be an extra expense but lets you monitor your certs' revocation status and, should cert #1 get revoked, update your configs to use cert #2 and so on. That might even be a good idea for CloudFlare to implement in their SSL offerings[0] if they don't already. They could offer multiple SSL certs from various providers (for an extra fee even) and the whole process would be completely transparent to your origin server, which can run its own self-signed cert. [0] https://www.cloudflare.com/ssl https://www.cloudflare.com/ssl
krishna_k 11y ago
startssl.com has a different business model - you pay for verification (fairly cheaply), not for the certificates themselves. BUT, they charge you $25 for revocation. So I'd assume that this is kind of a "bulletproof" - if you don't pay, they won't revoke.

kruhft 11y ago

I just developed a browser to server based crytpo channel meant to replace the SLL certificate mess on a side project I'm working on. I know that there's a bad rap for browser based crytpo and rolling your own but I've got some knowledge and thought I would give it a shot. The code is not public (yet) but uses DH key exchange (using the JS BigInt library) to exchange a 2048 bit token key and then uses sjcl to perform encryption on each packet/request using the resulting key. It's lacking host validation (am I talking to the correct server?), but I'm still working getting that piece together.

kruhft 11y ago
Anybody care to comment rather than just downvote? I wouldn't mind hearing some thoughts regarding this part of the project.
- stephengillie 11y ago
  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
- mikekchar 11y ago
  Complaint about complaint about downvoting notwithstanding, my guess as to why nobody commented was: there is no meaningful way to comment on it. There is no link with a detailed description of what you have done, or demonstration of how it works. There is also no source code to look at yet. While I am sure it is an exciting project for you, without something that people can try (or at least source code to look at), it doesn't add anything valuable to the reader of the comment. It just adds to the noise of the conversation. If you wait until you are ready to show people the code, then I'm sure many people will be interested to discuss it. Before that, it's not time yet. That's my perspective, anyway. I hope it is useful to you.

Animats 11y ago

This is strange. An entire TLD? Symantec hasn't issued an announcement. There's nothing on the CA/Browser Forum mailing list. Nothing on the Symantec Security Response Blog. Nothing on Symantec's Twitter feeds. Symantec stopped issuing certs in .PW six days ago, according to a blog post.[1] But there appears to have been no public announcement. Even if there was a major security breach justifying this, Symantec has botched the revocation and has lost much trust. [1] https://www.reddit.com/r/sysadmin/comments/3j9iyk/just_a_heads_up_symantec_is_cancelling_ssl/ https://www.reddit.com/r/sysadmin/comments/3j9iyk/just_a_hea...

Animats 11y ago
24 hours later, I'm not seeing any reliable source reporting this. No hits in Google News. Nothing on TechDirt. Nothing on security blogs. Nothing on CA/Browser mailing list. Most hits in Google are to scraper spam blogs that scraped HN. This report may be bogus, or a hoax.

mahouse 11y ago

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

andrewflnr 11y ago
People who considered the possibility of private keys for certs getting compromised.
- schoen 11y ago
  It's an interesting question whether it would be a good idea to require revocations to be signed by the subject key rather than by the issuer key. I guess it depends on the threat model! Conceptually, the idea is that if the issuer makes an assertion about what's true, they want to later be able to stop making that assertion. That seems to make basic sense. (But in some threat models, the issuer might have been coerced, and maybe it's easier to coerce authorities to revoke than to misissue. For one thing, browsers are unlikely to kick CAs out of their trust lists for improper revocation, but they might for misissuance!)

flashman 11y ago

Could this be anything like the DigiNotar hack?[0] If it came out that Symantec's certificate authority was used to issue fraudulent certificates, the damage to their business could be in the hundreds of millions. What if the silence is because Symantec is trying to figure out the best way to break the news to us? Edit: After a bit more reading, Symantec has some history of monitoring .pw for malware and spam.[1][2][3] Perhaps someone just decided they wanted nothing more to do with PW issuer Directi, which apparently has a poor reputation.[4] [0]https://en.wikipedia.org/wiki/DigiNotar https://en.wikipedia.org/wiki/DigiNotar [1]http://www.symantec.com/connect/blogs/rise-pw-urls-spam-messages http://www.symantec.com/connect/blogs/rise-pw-urls-spam-mess... [2]http://www.symantec.com/connect/blogs/pw-hit-and-run-spam-royal-baby-trend http://www.symantec.com/connect/blogs/pw-hit-and-run-spam-ro... [3]http://www.symantec.com/connect/blogs/rig-exploit-kit-used-recent-website-compromise http://www.symantec.com/connect/blogs/rig-exploit-kit-used-r... [4]http://www.jl.ly/Email/palau.html http://www.jl.ly/Email/palau.html

nailer 11y ago
Wait. I'm the last person to defend Symantec (see [1] [2]) but the headline seems to be a load of rubbish, or at least certainly isn't backed by the content of the article. Here are the only two reseller quotes from the article: > Reseller rep.: > We regret to inform you that certificate [number] for www.canary.pw domain has been revoked by the Certificate Authority due to the site being flagged as potentially containing malware in a recent site scanning by Symantec (owner of GeoTrust). Unfortunately we were not warned of the upcoming revocation, so we apologize for any inconvenience that this may cause. A single website, that allows people to search stolen data, eg the Ashley Madison hack, and asks people to submit stolen data, has had it's certificate revoked. and: > Reseller rep.: > As per our check with Symantec, they will no longer be issuing SSL certs to .PW domains. You are advised to remove the SSL certificate from the server to avoid security errors related to a revoked certificate. > And furthermore Symantec are no longer issuing certificates for the .pw TLD. Neither quote equates to Symantec having 'revoked all SSL certificates for .PW TLD domains' as mentioned in the headline and this HN submission. As much as I dislike Symantec - and I really dislike Symantec - I think this article's headline is false. [1]. https://certsimple.com/blog/seal-in-search https://certsimple.com/blog/seal-in-search [2]. https://certsimple.com/blog/sgc-ssl-certificates https://certsimple.com/blog/sgc-ssl-certificates

Animats 11y ago

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