11 ms·

> how about promoting a transparent decentralized system for certificate signing Honest question: with a decentralized system for certificate signing, what wou

by cesarb 12y ago

> how about promoting a transparent decentralized system for certificate signing Honest question: with a decentralized system for certificate signing, what would be the trust root? The current system has the browser makers as the root of trust; this trust is delegated to a set of certificate authorities through the list of root certificates which comes with the browser; these certificate authorities then delegate to their intermediates, which finally certify a server as trusted for a fully-qualified domain name. Without a root of trust, anyone could say "I'm example.gov, this is my certificate", and present "proof" of that. A trust root is necessary to prevent this. So far, the only working proposals I've seen for decentralized trust (which don't do away with the human readability side of Zooko's triangle) are based in distributed proof-of-work systems like Bitcoin's, where the trust root is the distributed "chain". Has anyone ever tried to apply a system like that for certificate signing for TLS?

fweespeech 12y ago
A block chain like structure could probably act as a record of trust for SSL by using SSL cert/IP address pairs in place of transaction data. https://namecoin.info/ https://namecoin.info/ is trying to solve a similar problem but by rebuilding the entire DNS system.
konklone 12y ago
Convergence and DNSChain are two interesting proposals to replace the CA system. IMO, it's more important to emphasize the idea of secure origins, and HTTPS hits that note. TLS could be swapped out, the CA system could be changed, but what matters is the expectation that connections across the web are expected to be secure by default.
- tracker1 12y ago
  Agreed.. it's a shame that I can't just publish a public-key as part of a DNS entry for a domain, and as long as the DNS chain is secure (DNSSEC) then that key can be trusted.
  - M2Ys4U 12y ago
    DNSSEC is just replacing one set of roots (the CAs) with another (the root servers). At least with CAs you can (theoretically) remove trust from a subset of them and things (mostly) keep working.
Karunamon 12y ago
Without a root of trust, anyone could say "I'm example.gov, this is my certificate", and present "proof" of that. Most SSL certs in the wild are legitimate and trust has already been established. So if you hit FooCo's corporate website and get one certificate, and some other guy hits the same website and they get another, it's likely something fishy is happening. Replace this model of two people with a few million, and you have a pretty decent verification system happening. Really, what we have now isn't okay. We're training users to click past SSL warnings which, 99.999% of the time, are due to misconfiguration or BS reasons (i.e. expiration).
- cesarb 12y ago
  > So if you hit FooCo's corporate website and get one certificate, and some other guy hits the same website and they get another, it's likely something fishy is happening. Replace this model of two people with a few million, and you have a pretty decent verification system happening. In this model, the trust root is the verification system which compares your "hit" with other people's "hits". If an attacker can pretend to be the verification system and tell you "everything's fine", the system won't work. Also, it's centralized: the verification system itself becomes the central component.
  - vidarh 12y ago
    Such a verification system does not need to be centralized. It can be a public, signed log that can be verified with other parties.
    - yuliyp 12y ago
      What's to stop an attacker from poisoning such a system: pretend to be a thousand different people all saying "Yep, the cert with signature 0xBADBADBAD was what I saw"? How does someone rotate certs without breaking all their existing clients?
      - vidarh 12y ago
        Nothing stops an attacker from pretending to be a thousand different people, but there are a couple of obvious improvements you can make: - Don't just check the certs you want to verify, but also check others, and publish your findings. - Check with multiple alternative systems, so that the chance of - Allow users to assign trust to third party monitors that checks the logs. Rotating certs is not really a different problem than issuing it in the first place - it just requires you to not trust a cert indefinitely.
pdkl95 12y ago
The problem with achieving real adoption of crypto had historically been made a lot harder than it should be because too many problems are trying to be solved at the same time. Separate the problems! It is much easier to find realistic solutions when the requirements are narrower. The remaining needs can be solved later on. Once some usable infrastructure has been established, it might be possible to leverage that infrastructure to add back in some of the missing features. For HTTPS, a good start would be PHK's suggestion of simply auto-generating self-signed certs in apache by default, as a replacement for plaintext. Authenticating those certs can happen later. After keys are everywhere, a potential solution might be t o allow both PKI authorities and some sort of web-of-trust (or other methods? blockchain? something new?), and exposing the source of trust to the user in way they can manage. There is no one-size-fits-all solution to the trust problem, so let the user decide because they know what their requirements are. If I'm browsing to some bank, a well-known PKI root might be a good trust source. If I'm chatting on some local forum, a web-of-trust auth might be better (it's a local forum, so fingerprints can be exchanged manually, friend-to-friend).
- tptacek 12y ago
  Encryption is not separable from authentication.
  - tbrownaw 12y ago
    Right. Because active MITM attacks -- at least if limited to cases where the attacker doesn't know how / if the connection is authenticated -- carry zero risk of alerting those being attacked.
    - tptacek 12y ago
      The thing that alerts you to MITM attacks is authentication!
      - tbrownaw 12y ago
        I am aware of that. An untargetted attacker cannot know that there is no authentication. Dragnetting connections where they don't recognize any authentication therefore risks detection. That risk to the attacker is not present when observing plaintext connections. . I'm not safe from muggers because I have eyes in the back of my head to see them trying to sneak up on me. I'm (largely) safe because someone else is likely to see them (or catch them on camera) and get them caught.

by cesarb 12y ago

fweespeech 12y ago

A block chain like structure could probably act as a record of trust for SSL by using SSL cert/IP address pairs in place of transaction data. https://namecoin.info/ https://namecoin.info/ is trying to solve a similar problem but by rebuilding the entire DNS system.

konklone 12y ago

Convergence and DNSChain are two interesting proposals to replace the CA system. IMO, it's more important to emphasize the idea of secure origins, and HTTPS hits that note. TLS could be swapped out, the CA system could be changed, but what matters is the expectation that connections across the web are expected to be secure by default.

tracker1 12y ago
Agreed.. it's a shame that I can't just publish a public-key as part of a DNS entry for a domain, and as long as the DNS chain is secure (DNSSEC) then that key can be trusted.
- M2Ys4U 12y ago
  DNSSEC is just replacing one set of roots (the CAs) with another (the root servers). At least with CAs you can (theoretically) remove trust from a subset of them and things (mostly) keep working.

Karunamon 12y ago

Without a root of trust, anyone could say "I'm example.gov, this is my certificate", and present "proof" of that. Most SSL certs in the wild are legitimate and trust has already been established. So if you hit FooCo's corporate website and get one certificate, and some other guy hits the same website and they get another, it's likely something fishy is happening. Replace this model of two people with a few million, and you have a pretty decent verification system happening. Really, what we have now isn't okay. We're training users to click past SSL warnings which, 99.999% of the time, are due to misconfiguration or BS reasons (i.e. expiration).

cesarb 12y ago
> So if you hit FooCo's corporate website and get one certificate, and some other guy hits the same website and they get another, it's likely something fishy is happening. Replace this model of two people with a few million, and you have a pretty decent verification system happening. In this model, the trust root is the verification system which compares your "hit" with other people's "hits". If an attacker can pretend to be the verification system and tell you "everything's fine", the system won't work. Also, it's centralized: the verification system itself becomes the central component.
- vidarh 12y ago
  Such a verification system does not need to be centralized. It can be a public, signed log that can be verified with other parties.
  - yuliyp 12y ago
    What's to stop an attacker from poisoning such a system: pretend to be a thousand different people all saying "Yep, the cert with signature 0xBADBADBAD was what I saw"? How does someone rotate certs without breaking all their existing clients?
    - vidarh 12y ago
      Nothing stops an attacker from pretending to be a thousand different people, but there are a couple of obvious improvements you can make: - Don't just check the certs you want to verify, but also check others, and publish your findings. - Check with multiple alternative systems, so that the chance of - Allow users to assign trust to third party monitors that checks the logs. Rotating certs is not really a different problem than issuing it in the first place - it just requires you to not trust a cert indefinitely.

pdkl95 12y ago

The problem with achieving real adoption of crypto had historically been made a lot harder than it should be because too many problems are trying to be solved at the same time. Separate the problems! It is much easier to find realistic solutions when the requirements are narrower. The remaining needs can be solved later on. Once some usable infrastructure has been established, it might be possible to leverage that infrastructure to add back in some of the missing features. For HTTPS, a good start would be PHK's suggestion of simply auto-generating self-signed certs in apache by default, as a replacement for plaintext. Authenticating those certs can happen later. After keys are everywhere, a potential solution might be t o allow both PKI authorities and some sort of web-of-trust (or other methods? blockchain? something new?), and exposing the source of trust to the user in way they can manage. There is no one-size-fits-all solution to the trust problem, so let the user decide because they know what their requirements are. If I'm browsing to some bank, a well-known PKI root might be a good trust source. If I'm chatting on some local forum, a web-of-trust auth might be better (it's a local forum, so fingerprints can be exchanged manually, friend-to-friend).

tptacek 12y ago
Encryption is not separable from authentication.
- tbrownaw 12y ago
  Right. Because active MITM attacks -- at least if limited to cases where the attacker doesn't know how / if the connection is authenticated -- carry zero risk of alerting those being attacked.
  - tptacek 12y ago
    The thing that alerts you to MITM attacks is authentication!
    - tbrownaw 12y ago
      I am aware of that. An untargetted attacker cannot know that there is no authentication. Dragnetting connections where they don't recognize any authentication therefore risks detection. That risk to the attacker is not present when observing plaintext connections. . I'm not safe from muggers because I have eyes in the back of my head to see them trying to sneak up on me. I'm (largely) safe because someone else is likely to see them (or catch them on camera) and get them caught.