5 ms·

I think that a good system would be that the key can be signed by multiple parties. For example if you are running a web shop, your certificate could be signed

by Puts 4y ago

I think that a good system would be that the key can be signed by multiple parties. For example if you are running a web shop, your certificate could be signed by Visa if you accept card payments, by your registrar to prove that you own the domain, by the tax office in your country to prove that you are a real company and so on. And then the browser would show these signatures as badges when clicking/hovering the padlock icon. So essentially the more signatures the more trustworthy.

mananaysiempre 4y ago
Right now, CAs in the Web PKI certify authenticity, not trustworthiness: when the system works correctly, a successful TLS handshake with satan.com tells you that you have connected to the actual satan.com and perhaps that it is operated by Satan, Inc (although it’s still on you to check whether it’s the Delaware one or the Kentucky one[1]). It does not, and is not supposed to, tell you whether it’s smart to sell your soul there, CA marketing materials (“users trust sites that ...”) notwithstanding. What you are proposing is an attempt at solving an entirely different problem that is, furthermore, largely orthogonal to ensuring the integrity and confidentiality of Internet traffic. It would be nice if that problem were solvable, but every time the Web PKI flirted with that it ended horribly[2]. (And now the EU authorities are trying to force it anyway, it seems[3].) Ensuring your bytes end up on the host you named, intact and unsnooped, is a comparatively easy problem that’s also pretty meaningful, and it seems smart to restrict ourselves to that. (I’d have advocated for DNSSEC+DANE instead of CAs, even, if I had any confidence at all in the DNS registrars’ ability to handle key material and willingness to give up domain control when that ability fails.) [1] https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/ https://arstechnica.com/information-technology/2017/12/nope-... [2] https://www.usenix.org/system/files/sec19-thompson.pdf https://www.usenix.org/system/files/sec19-thompson.pdf [3] https://scotthelme.co.uk/looks-like-a-duck-swims-like-a-duck-qwacs-like-a-duck-probably-an-ev-certifiacate/ https://scotthelme.co.uk/looks-like-a-duck-swims-like-a-duck...
- bandrami 4y ago
  Unfortunately TLS is already conflating two problems as it is: 1. Is the opposite party who they claim to be? 2. Did a third party alter or eavesdrop on the transmission? That is, am I simply being phished in private or is the government also listening to me being phished? It's trivially easy to solve the second problem and it doesn't require any PKI infrastructure whatsoever and we delayed secure transport by decades by tying it to the generally less-useful question in #1. There are few entities online I trust more than I would trust someone impersonating them: basically only if money is changing hands. But I don't need to know that e.g. ycombinator.com is actually ycombinator.com because I don't trust ycmonbinator.com any more than I would trust someone impersonating ycombinator.com.
  - jcranmer 4y ago
    It is not trivially easy to solve the second problem without solving the first problem. If you don't have proof of identity, all someone has to do to eavesdrop on you is pretend to be the person you're communicating with while actually communicating with them on your behalf.
    - cesarb 4y ago
      It's the difference between a passive attack and an active attack. Most people think only of passive eavesdroppers, and against them it could be true that "it's trivially easy to solve the second problem and it doesn't require any PKI infrastructure whatsoever". But against an active attacker, unless you can solve the "is the opposite party who they claim to be" problem, it's trivially easy to eavesdrop by pretending to be the other party (MITM attack). And then you find out there are ways to convert a passive eavesdropper into an active attacker (remotely injecting packets to manipulate the TCP connection state, based on observed sequence numbers), and the distinction becomes a bit fuzzy...
    - judge2020 4y ago
      It's trivially easy when that 'proof of identity' is purely a unique identifier shown to the user, and not actually tied to real-world identity. This is what a domain name is, ICANN ensures people can't register a domain name if someone already owns it, so with that guarantee, everyone trusts that 'google.com' showing up in their URL bar means that the certificate presented by the server they're connecting to is actually authorized to show 'google.com'.

by Puts 4y ago

mananaysiempre 4y ago

Right now, CAs in the Web PKI certify authenticity, not trustworthiness: when the system works correctly, a successful TLS handshake with satan.com tells you that you have connected to the actual satan.com and perhaps that it is operated by Satan, Inc (although it’s still on you to check whether it’s the Delaware one or the Kentucky one[1]). It does not, and is not supposed to, tell you whether it’s smart to sell your soul there, CA marketing materials (“users trust sites that ...”) notwithstanding. What you are proposing is an attempt at solving an entirely different problem that is, furthermore, largely orthogonal to ensuring the integrity and confidentiality of Internet traffic. It would be nice if that problem were solvable, but every time the Web PKI flirted with that it ended horribly[2]. (And now the EU authorities are trying to force it anyway, it seems[3].) Ensuring your bytes end up on the host you named, intact and unsnooped, is a comparatively easy problem that’s also pretty meaningful, and it seems smart to restrict ourselves to that. (I’d have advocated for DNSSEC+DANE instead of CAs, even, if I had any confidence at all in the DNS registrars’ ability to handle key material and willingness to give up domain control when that ability fails.) [1] https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/ https://arstechnica.com/information-technology/2017/12/nope-... [2] https://www.usenix.org/system/files/sec19-thompson.pdf https://www.usenix.org/system/files/sec19-thompson.pdf [3] https://scotthelme.co.uk/looks-like-a-duck-swims-like-a-duck-qwacs-like-a-duck-probably-an-ev-certifiacate/ https://scotthelme.co.uk/looks-like-a-duck-swims-like-a-duck...

bandrami 4y ago
Unfortunately TLS is already conflating two problems as it is: 1. Is the opposite party who they claim to be? 2. Did a third party alter or eavesdrop on the transmission? That is, am I simply being phished in private or is the government also listening to me being phished? It's trivially easy to solve the second problem and it doesn't require any PKI infrastructure whatsoever and we delayed secure transport by decades by tying it to the generally less-useful question in #1. There are few entities online I trust more than I would trust someone impersonating them: basically only if money is changing hands. But I don't need to know that e.g. ycombinator.com is actually ycombinator.com because I don't trust ycmonbinator.com any more than I would trust someone impersonating ycombinator.com.
- jcranmer 4y ago
  It is not trivially easy to solve the second problem without solving the first problem. If you don't have proof of identity, all someone has to do to eavesdrop on you is pretend to be the person you're communicating with while actually communicating with them on your behalf.
  - cesarb 4y ago
    It's the difference between a passive attack and an active attack. Most people think only of passive eavesdroppers, and against them it could be true that "it's trivially easy to solve the second problem and it doesn't require any PKI infrastructure whatsoever". But against an active attacker, unless you can solve the "is the opposite party who they claim to be" problem, it's trivially easy to eavesdrop by pretending to be the other party (MITM attack). And then you find out there are ways to convert a passive eavesdropper into an active attacker (remotely injecting packets to manipulate the TCP connection state, based on observed sequence numbers), and the distinction becomes a bit fuzzy...
  - judge2020 4y ago
    It's trivially easy when that 'proof of identity' is purely a unique identifier shown to the user, and not actually tied to real-world identity. This is what a domain name is, ICANN ensures people can't register a domain name if someone already owns it, so with that guarantee, everyone trusts that 'google.com' showing up in their URL bar means that the certificate presented by the server they're connecting to is actually authorized to show 'google.com'.