7 ms·

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?

by kylec 12y ago

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.

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?

by 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.