4 ms·

The ISP would still be untrusted. They're just running a database/discovery service for your public key. Now you might say, what stops them announcing the wron

The ISP would still be untrusted. They're just running a database/discovery service for your public key. Now you might say, what stops them announcing the wrong public key to the world, and then decrypting/re-encrypting a connection when it flows inbound to that IP across its wires. And the answer is the same as with TLS/SSL: not much, so you have to do lots of double checking and pinning. Recall that nothing in today's internet really rigorously stops an ISP obtaining a certificate for a website it hosts, or even one that it doesn't! A CA like LetsEncrypt will automatically probe an IP from several vantage points as part of validating a domain->IP mapping but that process can be triggered at any point, and the vantage points can be easily discovered. So an ISP that can 'catch' all the vantage points, can just redirect IP traffic from the CA to its own server to obtain a cert, and then MITM traffic heading towards a website. It's the same problem when doing it at the IP level. However, there is still a lot of value because you can get public keys in a variety of ways. For instance you could try to connect to yourself back via Tor, or a variety of other services, to verify that your public key the rest of the internet sees is what you think it is.

bawolff 5y ago
I disagree, incentives would be very different imo. > Now you might say, what stops them announcing the wrong public key to the world, and then decrypting/re-encrypting a connection when it flows inbound to that IP across its wires. And the answer is the same as with TLS/SSL: not much, so you have to do lots of double checking and pinning. in WebPKI: - CA's have struct rules (CAB and individual browser vendors) and have to go through audits to verify they follow them (how much an audit is worth is debatable) - certificate transparency ensures that CA's can't misbehave without being detected, which if they do, they get kicked out as a CA. If an isp misbehaves in this scenario, how do we punish them? Can we kick them out of the internet? Seems unlikely. If a CA refues to do something, we can kick them out. > and pinning I personally think pinning is generally a bad solution to pki problems, but for the sake of argument: how do you do pinning (or even something simpler like TOFU) with only a transient identifier like a dynamic IP address? What do you pin to? Its even worse if you still want to support NAT. > A CA like LetsEncrypt will automatically probe an IP from several vantage points as part of validating a domain->IP mapping but that process can be triggered at any point, and the vantage points can be easily discovered. So an ISP that can 'catch' all the vantage points, can just redirect IP traffic from the CA to its own server to obtain a cert, and then MITM traffic heading towards a website. It's the same problem when doing it at the IP level. Which can be immediately noticeable via certificate transparency. More to the point, there is no single attacker who is on path for all of lets encrypt's vantage points (and you don't have a relationship with any of lets encrypt's isps so they are less likely to care about you), which wouldn't be true for this new scheme. I guess you could argue that the web host in the webpki case (when not using dns validation) is the most likely point of attack, but they could just attack directly since they own the hardware. > However, there is still a lot of value because you can get public keys in a variety of ways. For instance you could try to connect to yourself back via Tor, or a variety of other services, to verify that your public key the rest of the internet sees is what you think it is. Its easy to come by lists of public proxies. Tor itself publishes a list of all ips participating in the tor network. Ultimately the biggest problem is enforcement incentives. Much of the security of web pki relies on being able to detect and punish misbehaving CA's (of which there are only a small number of). I don't see a politically viable way of doing that for ISPs.
- native_samples 5y ago
  WebPKI doesn't really solve these problems. CA Audits are mostly about ensuring they're following the rules. However, the rules cannot stop an ISP or hosting provider just issuing themselves a cert and a fully audit compliant CA is not expected to stop this. Cert transparency is mostly unused. For it to work people have to proactively search the logs to find certs they didn't issue, but in reality nobody does this outside of maybe big tech firms. Moreover, in the ISP/colo interception case, the CA wouldn't be revoked because they wouldn't have done anything wrong. Re: pinning. You can't pin if your IP isn't stable. However you can if you're a server. Then you don't need the fragile link of DNS in the loop at all. For instance, mobile apps can just have a cached public key (of course you can do that today, but we're talking about a system that is more deeply integrated with the internet). "there is no single attacker who is on path for all of lets encrypt's vantage points" No? AWS isn't on path for all the websites they host? Even in the case where the hardware isn't owned, any site that has one internet uplink (i.e. most of them) can be targeted in this way.
  - bawolff 5y ago
    Hmm. You make some good points.

bawolff 5y ago

I disagree, incentives would be very different imo. > Now you might say, what stops them announcing the wrong public key to the world, and then decrypting/re-encrypting a connection when it flows inbound to that IP across its wires. And the answer is the same as with TLS/SSL: not much, so you have to do lots of double checking and pinning. in WebPKI: - CA's have struct rules (CAB and individual browser vendors) and have to go through audits to verify they follow them (how much an audit is worth is debatable) - certificate transparency ensures that CA's can't misbehave without being detected, which if they do, they get kicked out as a CA. If an isp misbehaves in this scenario, how do we punish them? Can we kick them out of the internet? Seems unlikely. If a CA refues to do something, we can kick them out. > and pinning I personally think pinning is generally a bad solution to pki problems, but for the sake of argument: how do you do pinning (or even something simpler like TOFU) with only a transient identifier like a dynamic IP address? What do you pin to? Its even worse if you still want to support NAT. > A CA like LetsEncrypt will automatically probe an IP from several vantage points as part of validating a domain->IP mapping but that process can be triggered at any point, and the vantage points can be easily discovered. So an ISP that can 'catch' all the vantage points, can just redirect IP traffic from the CA to its own server to obtain a cert, and then MITM traffic heading towards a website. It's the same problem when doing it at the IP level. Which can be immediately noticeable via certificate transparency. More to the point, there is no single attacker who is on path for all of lets encrypt's vantage points (and you don't have a relationship with any of lets encrypt's isps so they are less likely to care about you), which wouldn't be true for this new scheme. I guess you could argue that the web host in the webpki case (when not using dns validation) is the most likely point of attack, but they could just attack directly since they own the hardware. > However, there is still a lot of value because you can get public keys in a variety of ways. For instance you could try to connect to yourself back via Tor, or a variety of other services, to verify that your public key the rest of the internet sees is what you think it is. Its easy to come by lists of public proxies. Tor itself publishes a list of all ips participating in the tor network. Ultimately the biggest problem is enforcement incentives. Much of the security of web pki relies on being able to detect and punish misbehaving CA's (of which there are only a small number of). I don't see a politically viable way of doing that for ISPs.

native_samples 5y ago
WebPKI doesn't really solve these problems. CA Audits are mostly about ensuring they're following the rules. However, the rules cannot stop an ISP or hosting provider just issuing themselves a cert and a fully audit compliant CA is not expected to stop this. Cert transparency is mostly unused. For it to work people have to proactively search the logs to find certs they didn't issue, but in reality nobody does this outside of maybe big tech firms. Moreover, in the ISP/colo interception case, the CA wouldn't be revoked because they wouldn't have done anything wrong. Re: pinning. You can't pin if your IP isn't stable. However you can if you're a server. Then you don't need the fragile link of DNS in the loop at all. For instance, mobile apps can just have a cached public key (of course you can do that today, but we're talking about a system that is more deeply integrated with the internet). "there is no single attacker who is on path for all of lets encrypt's vantage points" No? AWS isn't on path for all the websites they host? Even in the case where the hardware isn't owned, any site that has one internet uplink (i.e. most of them) can be targeted in this way.
- bawolff 5y ago
  Hmm. You make some good points.