11 ms·

Maintaining digital certificate security

295 points by ayrx 12y ago

mqzaidi 12y ago
The CCA is so aware of its own vulnerability, it refrains from the use of SSL on its own page http://cca.gov.in/cca/index.php http://cca.gov.in/cca/index.php - no https here :)
- hrjet 12y ago
  Indian govt websites have a pathetic sense of security. One prominent consumer facing website with logins and company data has a certificate issued to "Mohan Babu" (equivalent to John Doe) and expired 5 years back! I guess that's somewhat better than the other Indian govt websites that have no SSL at all!
kylec 12y ago
Once again, demonstration that the CA model is broken. Why does it make sense for any CA to be able to issue certificates for any domain?
- jonny_eh 12y ago
  What would the solution be?
  - wyager 12y ago
    A distributed secure key-value system a la Namecoin.
    - uwutnope 12y ago
      You have to store the blockchain on your computer to be able to browse website securely via namecoin, if you use 'light wallets' you will end up with the same DNS as today (trust a third party DNS server + CA or Namecoin node). You could use http://convergence.io/ http://convergence.io/ type of idea to connect to two trusted Namecoin nodes but do we really expect the average user to keep a list of trusted nodes?
      - wyager 12y ago
        You can have trustless namecoin without storing the blockchain, using techniques like SPV.
        uwutnope 12y ago
        According to https://en.bitcoin.it/wiki/Thin_Client_Security https://en.bitcoin.it/wiki/Thin_Client_Security SPV relies on the trust of your ISP. When nodes send you the blockchain data, is that an encrypted transfer or open to MITM?
      - ryan-c 12y ago
        If you only want to be able to resolve against Namecoin, it's possible to build a client that stores only the unspent transaction output set for names and a few dozen recent blocks and full security.
        uwutnope 12y ago
        How does that scale in filesize if Namecoin had 215 million~ domain names like we have in the current ICANN system? Also, what would the solution be for smartphones, downloading even just a few blocks isn't preferable with phone networks.
  - richardwhiuk 12y ago
    DANE TLSA is probably the best current option.
    - AlyssaRowan 12y ago
      On that note, it's worth taking a look at https://tools.ietf.org/html/draft-nygren-service-bindings-00 https://tools.ietf.org/html/draft-nygren-service-bindings-00 - the "B" record, which is in a very early speculative draft. One shot among several at gluing this stuff together.
  - exo762 12y ago
    Convergence by Moxie Marlinspike. Some argue that it does worse then CA in protecting against low-profile phishing attacks, but that's just bollocks.
  - rakoo 12y ago
    dnschain: https://github.com/okTurtles/dnschain https://github.com/okTurtles/dnschain
    - ryan-c 12y ago
      okTurtles is one of several middleware options that runs on top of Namecoin, implementing the domain record spec. It advocates using someone else's trusted server as a data source, but does not at this time implement any integrity protection for data in transit. http://www.freespeechme.org/ http://www.freespeechme.org/ is a more mature and more secure.
      - rakoo 12y ago
        > It advocates using someone else's trusted server as a data source Wrong; it advocates using your own server, but proposes public servers for tests. Here's an excerpt of the README: DNSChain is meant to be run by individuals! Yes, you can use a public DNSChain server, but it's far better to use your own because it gives you more privacy, makes you more resistant to censorship, and provides you with a stronger guarantee that the responses you get haven't been tampered with by a malicious server.
        ryan-c 12y ago
        I must have either misremembered or it has been changed since I last looked, then. It is still the case that using DNSChain will not get you validated SSL for .bit domains without additional software. It can serve DANE records, but the browser won't verify them and the existing browser extensions for adding DANE support require DNSSEC which DNSChain does not provide.
        itistoday2 12y ago
        > It is still the case that using DNSChain will not get you validated SSL for .bit domains without additional software. Yes, just like FreeSpeechMe it the SSL validation will initially work via a browser extension, but unlike FSM (heh) it does not carry the additional baggage of requiring you to run a Namecoin node on your [phone/laptop/etc.].
  - peterwwillis 12y ago
    A) Have the initial connection give the client all the domain verification info it needs for the future. Now secure connections can be established with or without a CA. Upside: independence, only one time you can exploit the connection. Downside: anyone can mitm the connection forever from the first connect onwards. B) Use a third party to register the information to secure the initial connection. This is what CAs were created for, and now people are suggesting DNS (and I would wager somebody might recommend whois at some point) as central trusted authorities for this data. Upside: no initial connection mitm, attack surface is minimized compared to number of CAs, distributed model. Downside: still a 3rd-party central authority, and due to smaller attack surface one successful attack could have much wider-ranging consequences, and it adds complication. C) Decentralized network of 3rd party peers to share authority information. Upside: decentralized, loosely organized, requires a bigger attack surface to disable. Downside: peers not held to as high a security standard, not necessarily businesses so no guarantees of integrity. D) Require the user get out-of-bounds information to verify the integrity of initial connection, and after that any connection between the source and destination is secured in any number of ways. Upside: total security not dependent on 3rd parties, no man in the middle. Downside: incredibly inconvenient and totally unscalable. E) All of the above. Support all possible schemes and allow the domain and the users to determine which of them they will use. Layer all different forms of verification so that the number of successful exploits to achieve a fake cert is so complicated that only a few dedicated state actors or elite hackers would spend enough time on it to be successful. Upside: users have choice, domain owners have choice, increased security overall. Downside: browsers have to figure out how to explain to the users what the fuck is going on when they get a warning about a cert now.
    - me1010 12y ago
      The problem is that a CA is issuing two things: 1. An identity. 2. A secure communications certificate. These do not need to be the same thing or issued by the same entity. I propose to modify the system as follows: 1. Register a domain name using an email address and a PGP key. 2. The registrar verifies that the applicant has the private key by requiring a clicked link in an encrypted mail. 3. A phone number is required for "full trust". 4. Thus with a private PGP key and a phone, trust that the applicant is the applicant has been established. It really doesn't matter who or what that applicant is -- just that the applicant and only that applicant has the required items. 5. The registrar passes the public key and the top domain to DNS servers. DNS validates against the registrar. And trust in the domain as an entity is now established. 6. Secure communications with the domain can now be established through the use of certs issued by the top level domain. And the domain becomes it's own authority. Any changes to registrar/domain information requires decrypting an email and answering a phone. Expensive and compromised CA's go away - Domain records become secure - Trust becomes decentralized - And domain owners hold all the keys... The only thing anyone else has is the domain holder's public key... SSL itself remains in place as is... Sure, if you lose your private key - you're screwed -- but that's just owning up being a responsible domain owner.
  - Qantourisc 12y ago
    DNS Dane, SSL singing with 2 CA's, peer-based trust, SSL pinning. We probably need a mix ... and none seems to be ideal. What would help is be more ruthless when CA's mess up, and no the pussy approach we are using now: do nothing.
- deleted 12y ago
  [deleted]
  - agl 12y ago
    Name constraints apply all the way down the chain - intermediates are implicitly limited by the constraints on their root. CAs have been name constrained in the past, see the update here about ANSSI: http://googleonlinesecurity.blogspot.com/2013/12/further-improving-digital-certificate.html http://googleonlinesecurity.blogspot.com/2013/12/further-imp...
    - deleted 12y ago
      [deleted]
      - agl 12y ago
        A Chrome update was needed because the constraint was applied retrospectively. A name constraint is usually an X.509 extension that is included in the certificate.
        deleted 12y ago
        [deleted]
        agl 12y ago
        > Every time you visit a page the OS/browser doesn't go up the entire chain of trust and check for constraints. Oh, certainly they do. Name constraints work just like that: https://tools.ietf.org/html/rfc5280#section-4.2.1.10 https://tools.ietf.org/html/rfc5280#section-4.2.1.10 So does Extended Key Usage in practice, although it's not defined that way. There are some platforms where name constraints aren't implemented, but CAPI (Windows) certainly does implement it and I believe that NSS does also.
  - claudius 12y ago
    Tie it to the DNS. Globally, there is one root CA which is authorised to only issue certificates for ?. Then, each top-level registry (DENIC, Nominet etc.) get a certificate from this CA which allows them to issue certificates on ?.tld. This is quite similar to DANE mentioned in the sibling, except that it doesn’t directly tie into the DNS and instead just merges the two organisations. Vendors could then either ship the root CA and/or each TLD certificate. Even when one NIC gets compromised, all it can do then is issue wrongful certificates for that given TLD (and rogue/untrusted ones are restricted to their namespace). There is still a SPOF in the “root” CA issuing TLD certs, but at least there is only one instead of 100 or so in the form of all root CAs plus the hundreds of intermediate CAs which, in theory, can issue certs for any domain just as well at the moment. Since it’s been a while that I heard of a case where TLD nameservers got wrongfully replaced in the root zone, this seems to be reasonable safe organisation.
- rakoo 12y ago
  I'd say it's not the CA model itself that's broken; it's the way we use these CAs that is too static to account for inevitable breaches in security. There is no easy way to add or remove a CA from our trusted sets. There is no way for a server to send multiple signatures to the client, so the client can choose any CA he actually trusts and silently discard the bad CAs. There is no problem in having any CA issue a certificate for any domain; the problem is that we have to trust these CAs and we can't move fast enough.
  - jorangreef 12y ago
    Sending multiple signatures and relying on a quorum of CAs might be a great solution.
- leccine 12y ago
  Exactly. It does not make any freakin sense, yet people are banging on implementation details like which cypher is better like you could not circumvent the entire process with a cert signed by a compromised CA.
michaelt 12y ago
Software vendors shouldn't list CAs as trusted when they prove they can't be trusted - but removing a CA from the trust store breaks things for innocent websites who just chose a crappy CA. Every CA should be required to publish a signed, public list of every certificate they have issued that is currently valid; and no certificate should be considered valid if it isn't on a CA's public list of certificates. That way, when a CA fucks up like this, vendors could remove their certificates from the root stores, but could grandfather in all their previous certificates so the CA's customers have a few months to get a certificate from a decent CA. We could even use the list to contact all the CA's customers and advise them of the upgrade deadline. If this CA isn't removed from the root store, it sends a message to other CAs: You can issue bad certificates with impunity, and there will be no negative consequences.
- agl 12y ago
  http://www.certificate-transparency.org/how-ct-works http://www.certificate-transparency.org/how-ct-works
  - bdamm 12y ago
    If only there was a blockchain for this.
    - jdfellow 12y ago
      Don't know about this Certificate Transparency thing but Namecoin does allow a certificate fingerprint to be associated with a domain, without using a CA, and it works rather well.
      - ryan-c 12y ago
        That does work for domains within Namecoin, but it cannot be used for ICANN TLDs. People have suggested pairing schemes to allow domains under other TLDs to be associated with Namecoin records but I have yet to see one that is secure (they all rely on honest miners).
    - 12y ago
korzun 12y ago
> At this time, India CCA is still investigating this incident. This event also highlights, again, that our Certificate Transparency project is critical for protecting the security of certificates in the future. What is there to investigate? If they had a proper system in place this should not require 'investigation'. While I embrace the global infrastructure, it's a bit weird to give authority rights within a country that has a pretty broken legal system (re: Avnish Bajaj, etc).
- mike_hearn 12y ago
  Presumably if they got hacked, they want to know how they got hacked. Perhaps there's a new zero day on the loose. It always makes sense to investigate these things.
bla2 12y ago
It's a scary thought that this probably has been going on mostly undetected for over a decade before Chrome added cert pinning.
y0ghur7_xxx 12y ago
This event also highlights, again, that our Certificate Transparency project is critical for protecting the security of certificates in the future. No! Certificate Transparency still relays on central authorities. We need to get rid of CAs. TACK + Convergence is the correct solution.
- cordite 12y ago
  I've never heard of TACK before. Are these what you are referring to? [1] [2] [1]: http://tack.io/ http://tack.io/ [2]: http://convergence.io/ http://convergence.io/
  - y0ghur7_xxx 12y ago
    Yes
- contingencies 12y ago
  I agree decentralization is desirable but haven't studied all of the proposals in depth. Over at http://www.certificate-transparency.org/comparison http://www.certificate-transparency.org/comparison Google claims: ...that their CT approach is superior to TACK because (T1) Servers can instantly roll out a new key if the previous one is lost (T2) Global (ie. whole internet sees evil server instead of good server) and targeted attack detection is superior (T3) There are no trusted third parties (T4) Newly issued keys on totally new sites can also be validated (to a greater extent) (T5) No server modification (ie. to deliver pinning headers) is required. ... that their CT approach is superior to Convergence because (C1) It is not known to introduce side-channel attacks due to changes in the SSL connection negotiation phase (C2) Servers can instantly roll out a new key if the previous one is lost (C3) Global attacks (ie. whole internet sees evil server instead of good server) are negated (C4) There are no trusted third parties (C5) Newly issued keys on totally new sites can also be validated (C6) No server modification (ie. to deliver pinning headers) is required. Can anyone refute these claims?
  - y0ghur7_xxx 12y ago
    Alexandra C. Grant wrote a paper comparing different methods of improving the current CA system: http://www.cs.dartmouth.edu/reports/TR2012-716.pdf http://www.cs.dartmouth.edu/reports/TR2012-716.pdf But unfortunately she does not take TACK/pinning + Convergence in consideration.
danielweber 12y ago
So when does the CA death penalty occur?
- exo762 12y ago
  Never. Once CA, forever CA. Can't remove particular CA on local level (too hard for users), can't remove particular CA globally - because all those legitimate certs signed by that CA.
  - cbr 12y ago
    DigiNotar went bankrupt and had their cert removed from browsers after they tried to cover up a hack: http://en.wikipedia.org/wiki/DigiNotar http://en.wikipedia.org/wiki/DigiNotar
higherpurpose 12y ago
> The India CCA certificates are included in the Microsoft Root Store and thus are trusted by the vast majority of programs running on Windows, including Internet Explorer and Chrome. Jesus Christ, the CA system is so broken.
blueplanet 12y ago
Moxie Marlinspike gave a talk at DEFCON 19 about how broken the CA model is and suggested an alternative. The talk - https://www.youtube.com/watch?v=pDmj_xe7EIQ https://www.youtube.com/watch?v=pDmj_xe7EIQ The alternative - http://convergence.io/ http://convergence.io/
- exo762 12y ago
  Had notary up and running, but was not able to force browser into using one. Unfortunately there is not enough attention from community to this project.
- Qantourisc 12y ago
  https://www.youtube.com/watch?feature=player_detailpage&v=Z7Wl2FW2TcA#t=1189 https://www.youtube.com/watch?feature=player_detailpage&v=Z7... <= seems like we should also block GeoTrust - GeoRoot !
IgorPartola 12y ago
I wonder if having your registrar be the only one able to issue you a cert for your domain would solve this. That way the user can verify that the cert was not only signed by a trusted CA but by a trusted CA for this specific domain.
- kiallmacinnes 12y ago
  The registrars would love this ;) DANE and DNSSEC feel to me like the only currently proposed replacement for the CA system that has a chance of succeeding, not necessarily because of technical superiority, but because of practicality and simply being "good enough".
  - marcosdumay 12y ago
    It's technically superior. Instead of trusting 600 CAs, with DNAE you only trust the TLD, second level if existent, and registrar. It's an incredibly smaller attack surface. You can also register in a second TLD, inserting redundancy into any system that knows your address beforehand.
ntakasaki 12y ago
The CA system is broken, so is BGP with routes being essentially hijacked by the word of mouth protocol. Wonder what the fixes or a reboot of the internet would look like.
- martindale 12y ago
  Like this: https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md#what https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepape...
eyeareque 12y ago
Maybe we need a browser add on that warns us when a shady/incompetent CA has signed the certificate of the current site we are on? As it sits today there is no repercussion for these terrible CAs that screw up like this.
- eli 12y ago
  If you don't trust the CA, you could just remove it from the root store of your OS or browser.
  - eyeareque 12y ago
    True, but that is a manual process that most users don't know how to carry out. We need to make it easy for the masses to "punish" the terrible CAs. If you can put pressure on the bad CAs, they will at least try to get better.
    - eli 12y ago
      Understanding SSL is already really hard. What is a user supposed to do with a warning about a valid cert from a questionable CA? The site is probably fine so you're mostly just teaching them to ignore SSL warning messages.
      - eyeareque 12y ago
        The idea is to cause at least a small percentage of users to distrust the cert/CA. This would cause the sites who buy CAs to avoid going with the shady CAs because of the user complaints they got after browser warnings were shown.
    - mike_hearn 12y ago
      The masses have no interest in fiddling with their browser settings. Ultimately the decision makers here are the browser makers (i.e. guys like agl).
Karunamon 12y ago
It's because of incidents like this why I call our PKI a scam and a racket. The fact that this is even a thing that can ever happen points to massive, systemic problems in the trust model.
- deleted 12y ago
  [deleted]
- hsod 12y ago
  > a scam and a racket Can you elaborate? I've heard a lot of people say it's broken or badly designed, but not that it's malicious or intentionally broken.
  - marcosdumay 12y ago
    Well, it's broken and there are people getting lots of money due to the fact that it's broken. Almost certainly the creation of the standard was not malicious, and almost certainly it currently gets support of people acting with malice. But I don't have anybody to point a finger at, even the most logical suspects aren't overtly trying to keep it broken.
- mike_hearn 12y ago
  No, it doesn't. You appear to believe that any security system that has any failure, ever, indicates "massive systemic problems". I assert that there are no security systems in history that would meet such a standard. There are an enormous number of sites and certificates out there. Studies have been carried out at scale on attacks on SSL and found that most MITM attacks come from locally installed virus scanners, malware, or company firewalls. Hacked CA's didn't even register. So if you represented the number of bad certs as a percentage it'd probably have a lot of zeros after the decimal point. That doesn't mean the world should sit on its hands. Although real world studies have been done, requiring all certs to be public will be a massive upgrade.
chris_mahan 12y ago
The Cathedral isn't finished and it's crumbling already. Back to the Bazaar!
elchief 12y ago
I wonder what those other domains were and why Google didn't pin them. Is it costly to pin a domain?
deleted 12y ago
[deleted]
AlyssaRowan 12y ago
I wonder if we can map every intermediate? Obviously Certificate Transparency (or any public audit log to some extent, really) helps a bunch with this sort of thing.

295 points by ayrx 12y ago

The CCA is so aware of its own vulnerability, it refrains from the use of SSL on its own page http://cca.gov.in/cca/index.php http://cca.gov.in/cca/index.php - no https here :)

hrjet 12y ago
Indian govt websites have a pathetic sense of security. One prominent consumer facing website with logins and company data has a certificate issued to "Mohan Babu" (equivalent to John Doe) and expired 5 years back! I guess that's somewhat better than the other Indian govt websites that have no SSL at all!

kylec 12y ago

Once again, demonstration that the CA model is broken. Why does it make sense for any CA to be able to issue certificates for any domain?

jonny_eh 12y ago
What would the solution be?
- wyager 12y ago
  A distributed secure key-value system a la Namecoin.
  - uwutnope 12y ago
    You have to store the blockchain on your computer to be able to browse website securely via namecoin, if you use 'light wallets' you will end up with the same DNS as today (trust a third party DNS server + CA or Namecoin node). You could use http://convergence.io/ http://convergence.io/ type of idea to connect to two trusted Namecoin nodes but do we really expect the average user to keep a list of trusted nodes?
    - wyager 12y ago
      You can have trustless namecoin without storing the blockchain, using techniques like SPV.
      - uwutnope 12y ago
        According to https://en.bitcoin.it/wiki/Thin_Client_Security https://en.bitcoin.it/wiki/Thin_Client_Security SPV relies on the trust of your ISP. When nodes send you the blockchain data, is that an encrypted transfer or open to MITM?
    - ryan-c 12y ago
      If you only want to be able to resolve against Namecoin, it's possible to build a client that stores only the unspent transaction output set for names and a few dozen recent blocks and full security.
      - uwutnope 12y ago
        How does that scale in filesize if Namecoin had 215 million~ domain names like we have in the current ICANN system? Also, what would the solution be for smartphones, downloading even just a few blocks isn't preferable with phone networks.
- richardwhiuk 12y ago
  DANE TLSA is probably the best current option.
  - AlyssaRowan 12y ago
    On that note, it's worth taking a look at https://tools.ietf.org/html/draft-nygren-service-bindings-00 https://tools.ietf.org/html/draft-nygren-service-bindings-00 - the "B" record, which is in a very early speculative draft. One shot among several at gluing this stuff together.
- exo762 12y ago
  Convergence by Moxie Marlinspike. Some argue that it does worse then CA in protecting against low-profile phishing attacks, but that's just bollocks.
- rakoo 12y ago
  dnschain: https://github.com/okTurtles/dnschain https://github.com/okTurtles/dnschain
  - ryan-c 12y ago
    okTurtles is one of several middleware options that runs on top of Namecoin, implementing the domain record spec. It advocates using someone else's trusted server as a data source, but does not at this time implement any integrity protection for data in transit. http://www.freespeechme.org/ http://www.freespeechme.org/ is a more mature and more secure.
    - rakoo 12y ago
      > It advocates using someone else's trusted server as a data source Wrong; it advocates using your own server, but proposes public servers for tests. Here's an excerpt of the README: DNSChain is meant to be run by individuals! Yes, you can use a public DNSChain server, but it's far better to use your own because it gives you more privacy, makes you more resistant to censorship, and provides you with a stronger guarantee that the responses you get haven't been tampered with by a malicious server.
      - ryan-c 12y ago
        I must have either misremembered or it has been changed since I last looked, then. It is still the case that using DNSChain will not get you validated SSL for .bit domains without additional software. It can serve DANE records, but the browser won't verify them and the existing browser extensions for adding DANE support require DNSSEC which DNSChain does not provide.
        itistoday2 12y ago
        > It is still the case that using DNSChain will not get you validated SSL for .bit domains without additional software. Yes, just like FreeSpeechMe it the SSL validation will initially work via a browser extension, but unlike FSM (heh) it does not carry the additional baggage of requiring you to run a Namecoin node on your [phone/laptop/etc.].
- peterwwillis 12y ago
  A) Have the initial connection give the client all the domain verification info it needs for the future. Now secure connections can be established with or without a CA. Upside: independence, only one time you can exploit the connection. Downside: anyone can mitm the connection forever from the first connect onwards. B) Use a third party to register the information to secure the initial connection. This is what CAs were created for, and now people are suggesting DNS (and I would wager somebody might recommend whois at some point) as central trusted authorities for this data. Upside: no initial connection mitm, attack surface is minimized compared to number of CAs, distributed model. Downside: still a 3rd-party central authority, and due to smaller attack surface one successful attack could have much wider-ranging consequences, and it adds complication. C) Decentralized network of 3rd party peers to share authority information. Upside: decentralized, loosely organized, requires a bigger attack surface to disable. Downside: peers not held to as high a security standard, not necessarily businesses so no guarantees of integrity. D) Require the user get out-of-bounds information to verify the integrity of initial connection, and after that any connection between the source and destination is secured in any number of ways. Upside: total security not dependent on 3rd parties, no man in the middle. Downside: incredibly inconvenient and totally unscalable. E) All of the above. Support all possible schemes and allow the domain and the users to determine which of them they will use. Layer all different forms of verification so that the number of successful exploits to achieve a fake cert is so complicated that only a few dedicated state actors or elite hackers would spend enough time on it to be successful. Upside: users have choice, domain owners have choice, increased security overall. Downside: browsers have to figure out how to explain to the users what the fuck is going on when they get a warning about a cert now.
  - me1010 12y ago
    The problem is that a CA is issuing two things: 1. An identity. 2. A secure communications certificate. These do not need to be the same thing or issued by the same entity. I propose to modify the system as follows: 1. Register a domain name using an email address and a PGP key. 2. The registrar verifies that the applicant has the private key by requiring a clicked link in an encrypted mail. 3. A phone number is required for "full trust". 4. Thus with a private PGP key and a phone, trust that the applicant is the applicant has been established. It really doesn't matter who or what that applicant is -- just that the applicant and only that applicant has the required items. 5. The registrar passes the public key and the top domain to DNS servers. DNS validates against the registrar. And trust in the domain as an entity is now established. 6. Secure communications with the domain can now be established through the use of certs issued by the top level domain. And the domain becomes it's own authority. Any changes to registrar/domain information requires decrypting an email and answering a phone. Expensive and compromised CA's go away - Domain records become secure - Trust becomes decentralized - And domain owners hold all the keys... The only thing anyone else has is the domain holder's public key... SSL itself remains in place as is... Sure, if you lose your private key - you're screwed -- but that's just owning up being a responsible domain owner.
- Qantourisc 12y ago
  DNS Dane, SSL singing with 2 CA's, peer-based trust, SSL pinning. We probably need a mix ... and none seems to be ideal. What would help is be more ruthless when CA's mess up, and no the pussy approach we are using now: do nothing.
deleted 12y ago
[deleted]
- agl 12y ago
  Name constraints apply all the way down the chain - intermediates are implicitly limited by the constraints on their root. CAs have been name constrained in the past, see the update here about ANSSI: http://googleonlinesecurity.blogspot.com/2013/12/further-improving-digital-certificate.html http://googleonlinesecurity.blogspot.com/2013/12/further-imp...
  - deleted 12y ago
    [deleted]
    - agl 12y ago
      A Chrome update was needed because the constraint was applied retrospectively. A name constraint is usually an X.509 extension that is included in the certificate.
      - deleted 12y ago
        [deleted]
        agl 12y ago
        > Every time you visit a page the OS/browser doesn't go up the entire chain of trust and check for constraints. Oh, certainly they do. Name constraints work just like that: https://tools.ietf.org/html/rfc5280#section-4.2.1.10 https://tools.ietf.org/html/rfc5280#section-4.2.1.10 So does Extended Key Usage in practice, although it's not defined that way. There are some platforms where name constraints aren't implemented, but CAPI (Windows) certainly does implement it and I believe that NSS does also.
- claudius 12y ago
  Tie it to the DNS. Globally, there is one root CA which is authorised to only issue certificates for ?. Then, each top-level registry (DENIC, Nominet etc.) get a certificate from this CA which allows them to issue certificates on ?.tld. This is quite similar to DANE mentioned in the sibling, except that it doesn’t directly tie into the DNS and instead just merges the two organisations. Vendors could then either ship the root CA and/or each TLD certificate. Even when one NIC gets compromised, all it can do then is issue wrongful certificates for that given TLD (and rogue/untrusted ones are restricted to their namespace). There is still a SPOF in the “root” CA issuing TLD certs, but at least there is only one instead of 100 or so in the form of all root CAs plus the hundreds of intermediate CAs which, in theory, can issue certs for any domain just as well at the moment. Since it’s been a while that I heard of a case where TLD nameservers got wrongfully replaced in the root zone, this seems to be reasonable safe organisation.
rakoo 12y ago
I'd say it's not the CA model itself that's broken; it's the way we use these CAs that is too static to account for inevitable breaches in security. There is no easy way to add or remove a CA from our trusted sets. There is no way for a server to send multiple signatures to the client, so the client can choose any CA he actually trusts and silently discard the bad CAs. There is no problem in having any CA issue a certificate for any domain; the problem is that we have to trust these CAs and we can't move fast enough.
- jorangreef 12y ago
  Sending multiple signatures and relying on a quorum of CAs might be a great solution.
leccine 12y ago
Exactly. It does not make any freakin sense, yet people are banging on implementation details like which cypher is better like you could not circumvent the entire process with a cert signed by a compromised CA.

michaelt 12y ago

Software vendors shouldn't list CAs as trusted when they prove they can't be trusted - but removing a CA from the trust store breaks things for innocent websites who just chose a crappy CA. Every CA should be required to publish a signed, public list of every certificate they have issued that is currently valid; and no certificate should be considered valid if it isn't on a CA's public list of certificates. That way, when a CA fucks up like this, vendors could remove their certificates from the root stores, but could grandfather in all their previous certificates so the CA's customers have a few months to get a certificate from a decent CA. We could even use the list to contact all the CA's customers and advise them of the upgrade deadline. If this CA isn't removed from the root store, it sends a message to other CAs: You can issue bad certificates with impunity, and there will be no negative consequences.

agl 12y ago
http://www.certificate-transparency.org/how-ct-works http://www.certificate-transparency.org/how-ct-works
- bdamm 12y ago
  If only there was a blockchain for this.
  - jdfellow 12y ago
    Don't know about this Certificate Transparency thing but Namecoin does allow a certificate fingerprint to be associated with a domain, without using a CA, and it works rather well.
    - ryan-c 12y ago
      That does work for domains within Namecoin, but it cannot be used for ICANN TLDs. People have suggested pairing schemes to allow domains under other TLDs to be associated with Namecoin records but I have yet to see one that is secure (they all rely on honest miners).
  - 12y ago

korzun 12y ago

> At this time, India CCA is still investigating this incident. This event also highlights, again, that our Certificate Transparency project is critical for protecting the security of certificates in the future. What is there to investigate? If they had a proper system in place this should not require 'investigation'. While I embrace the global infrastructure, it's a bit weird to give authority rights within a country that has a pretty broken legal system (re: Avnish Bajaj, etc).

mike_hearn 12y ago
Presumably if they got hacked, they want to know how they got hacked. Perhaps there's a new zero day on the loose. It always makes sense to investigate these things.

bla2 12y ago

It's a scary thought that this probably has been going on mostly undetected for over a decade before Chrome added cert pinning.

y0ghur7_xxx 12y ago

This event also highlights, again, that our Certificate Transparency project is critical for protecting the security of certificates in the future. No! Certificate Transparency still relays on central authorities. We need to get rid of CAs. TACK + Convergence is the correct solution.

cordite 12y ago
I've never heard of TACK before. Are these what you are referring to? [1] [2] [1]: http://tack.io/ http://tack.io/ [2]: http://convergence.io/ http://convergence.io/
- y0ghur7_xxx 12y ago
  Yes
contingencies 12y ago
I agree decentralization is desirable but haven't studied all of the proposals in depth. Over at http://www.certificate-transparency.org/comparison http://www.certificate-transparency.org/comparison Google claims: ...that their CT approach is superior to TACK because (T1) Servers can instantly roll out a new key if the previous one is lost (T2) Global (ie. whole internet sees evil server instead of good server) and targeted attack detection is superior (T3) There are no trusted third parties (T4) Newly issued keys on totally new sites can also be validated (to a greater extent) (T5) No server modification (ie. to deliver pinning headers) is required. ... that their CT approach is superior to Convergence because (C1) It is not known to introduce side-channel attacks due to changes in the SSL connection negotiation phase (C2) Servers can instantly roll out a new key if the previous one is lost (C3) Global attacks (ie. whole internet sees evil server instead of good server) are negated (C4) There are no trusted third parties (C5) Newly issued keys on totally new sites can also be validated (C6) No server modification (ie. to deliver pinning headers) is required. Can anyone refute these claims?
- y0ghur7_xxx 12y ago
  Alexandra C. Grant wrote a paper comparing different methods of improving the current CA system: http://www.cs.dartmouth.edu/reports/TR2012-716.pdf http://www.cs.dartmouth.edu/reports/TR2012-716.pdf But unfortunately she does not take TACK/pinning + Convergence in consideration.

danielweber 12y ago

So when does the CA death penalty occur?

exo762 12y ago
Never. Once CA, forever CA. Can't remove particular CA on local level (too hard for users), can't remove particular CA globally - because all those legitimate certs signed by that CA.
- cbr 12y ago
  DigiNotar went bankrupt and had their cert removed from browsers after they tried to cover up a hack: http://en.wikipedia.org/wiki/DigiNotar http://en.wikipedia.org/wiki/DigiNotar

higherpurpose 12y ago

> The India CCA certificates are included in the Microsoft Root Store and thus are trusted by the vast majority of programs running on Windows, including Internet Explorer and Chrome. Jesus Christ, the CA system is so broken.

blueplanet 12y ago

Moxie Marlinspike gave a talk at DEFCON 19 about how broken the CA model is and suggested an alternative. The talk - https://www.youtube.com/watch?v=pDmj_xe7EIQ https://www.youtube.com/watch?v=pDmj_xe7EIQ The alternative - http://convergence.io/ http://convergence.io/

exo762 12y ago
Had notary up and running, but was not able to force browser into using one. Unfortunately there is not enough attention from community to this project.
Qantourisc 12y ago
https://www.youtube.com/watch?feature=player_detailpage&v=Z7Wl2FW2TcA#t=1189 https://www.youtube.com/watch?feature=player_detailpage&v=Z7... <= seems like we should also block GeoTrust - GeoRoot !

IgorPartola 12y ago

I wonder if having your registrar be the only one able to issue you a cert for your domain would solve this. That way the user can verify that the cert was not only signed by a trusted CA but by a trusted CA for this specific domain.

kiallmacinnes 12y ago
The registrars would love this ;) DANE and DNSSEC feel to me like the only currently proposed replacement for the CA system that has a chance of succeeding, not necessarily because of technical superiority, but because of practicality and simply being "good enough".
- marcosdumay 12y ago
  It's technically superior. Instead of trusting 600 CAs, with DNAE you only trust the TLD, second level if existent, and registrar. It's an incredibly smaller attack surface. You can also register in a second TLD, inserting redundancy into any system that knows your address beforehand.

ntakasaki 12y ago

The CA system is broken, so is BGP with routes being essentially hijacked by the word of mouth protocol. Wonder what the fixes or a reboot of the internet would look like.

martindale 12y ago
Like this: https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md#what https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepape...

eyeareque 12y ago

Maybe we need a browser add on that warns us when a shady/incompetent CA has signed the certificate of the current site we are on? As it sits today there is no repercussion for these terrible CAs that screw up like this.

eli 12y ago
If you don't trust the CA, you could just remove it from the root store of your OS or browser.
- eyeareque 12y ago
  True, but that is a manual process that most users don't know how to carry out. We need to make it easy for the masses to "punish" the terrible CAs. If you can put pressure on the bad CAs, they will at least try to get better.
  - eli 12y ago
    Understanding SSL is already really hard. What is a user supposed to do with a warning about a valid cert from a questionable CA? The site is probably fine so you're mostly just teaching them to ignore SSL warning messages.
    - eyeareque 12y ago
      The idea is to cause at least a small percentage of users to distrust the cert/CA. This would cause the sites who buy CAs to avoid going with the shady CAs because of the user complaints they got after browser warnings were shown.
  - mike_hearn 12y ago
    The masses have no interest in fiddling with their browser settings. Ultimately the decision makers here are the browser makers (i.e. guys like agl).

Karunamon 12y ago

It's because of incidents like this why I call our PKI a scam and a racket. The fact that this is even a thing that can ever happen points to massive, systemic problems in the trust model.

deleted 12y ago
[deleted]
hsod 12y ago
> a scam and a racket Can you elaborate? I've heard a lot of people say it's broken or badly designed, but not that it's malicious or intentionally broken.
- marcosdumay 12y ago
  Well, it's broken and there are people getting lots of money due to the fact that it's broken. Almost certainly the creation of the standard was not malicious, and almost certainly it currently gets support of people acting with malice. But I don't have anybody to point a finger at, even the most logical suspects aren't overtly trying to keep it broken.
mike_hearn 12y ago
No, it doesn't. You appear to believe that any security system that has any failure, ever, indicates "massive systemic problems". I assert that there are no security systems in history that would meet such a standard. There are an enormous number of sites and certificates out there. Studies have been carried out at scale on attacks on SSL and found that most MITM attacks come from locally installed virus scanners, malware, or company firewalls. Hacked CA's didn't even register. So if you represented the number of bad certs as a percentage it'd probably have a lot of zeros after the decimal point. That doesn't mean the world should sit on its hands. Although real world studies have been done, requiring all certs to be public will be a massive upgrade.

chris_mahan 12y ago

The Cathedral isn't finished and it's crumbling already. Back to the Bazaar!

elchief 12y ago

I wonder what those other domains were and why Google didn't pin them. Is it costly to pin a domain?

deleted 12y ago

[deleted]

AlyssaRowan 12y ago

I wonder if we can map every intermediate? Obviously Certificate Transparency (or any public audit log to some extent, really) helps a bunch with this sort of thing.