3 ms·

Thanks for clarifying. My research there is a couple years old, but before posting I did some spot checking on CF-hosted domains and did see several using 1:1 c

by oskapt 7y ago

Thanks for clarifying. My research there is a couple years old, but before posting I did some spot checking on CF-hosted domains and did see several using 1:1 certificates. They were all financial institutions, so I figured that there was a way to get Cloudflare to not lump them in with the unwashed masses. I did also still see domains secured by certs for dozens of domains. I'm not sure I understand the 2nd caveat that you list. If Cloudflare issues a cert for a dozen different domains, there's one private key, right? Anyone with that private key could decrypt traffic going to any endpoint secured by that certificate?

tialaramex 7y ago
Nope. Assuming you're using a modern client that's never how it works. Let's take TLS 1.3 where it's designed from the outset for this use case rather than retro-fitted. The effects are similar even in TLS 1.2 (with a modern client) but it's easier to follow in TLS 1.3 1. Client says "Hi, I'm guessing you are willing to use this elliptic curve key agreement method X, I picked a random number and so now I need to tell you a number I got based on that choice which is A" 2. Server says "OK method X works for me, I also picked a random number and I tell you B" 3. At this moment, Server knows an Ephemeral Secret Key for this TLS session, and as soon as it receives message (2) the Client will also know this key, but an eavesdropper won't know this key. Notice that nothing happened with any Private Keys or Certificates or anything yet! 4. Using the now Encrypted Channel with the Ephemeral Secret Key, the Server can present a Certificate, and prove its identity using the corresponding Private Key (optionally the client can do likewise). Now, an _Active_ attacker can use the Private Key to impersonate a server and then proxy everything. But that's quite a step up from passively decrypting traffic. In Channel Binding scenarios the attacker would need to proxy the binding too, which will get out of hand pretty fast, since in TLS both parties have a per-channel secret and that secret won't match between the proxied and real channels.

by oskapt 7y ago

tialaramex 7y ago

Nope. Assuming you're using a modern client that's never how it works. Let's take TLS 1.3 where it's designed from the outset for this use case rather than retro-fitted. The effects are similar even in TLS 1.2 (with a modern client) but it's easier to follow in TLS 1.3 1. Client says "Hi, I'm guessing you are willing to use this elliptic curve key agreement method X, I picked a random number and so now I need to tell you a number I got based on that choice which is A" 2. Server says "OK method X works for me, I also picked a random number and I tell you B" 3. At this moment, Server knows an Ephemeral Secret Key for this TLS session, and as soon as it receives message (2) the Client will also know this key, but an eavesdropper won't know this key. Notice that nothing happened with any Private Keys or Certificates or anything yet! 4. Using the now Encrypted Channel with the Ephemeral Secret Key, the Server can present a Certificate, and prove its identity using the corresponding Private Key (optionally the client can do likewise). Now, an _Active_ attacker can use the Private Key to impersonate a server and then proxy everything. But that's quite a step up from passively decrypting traffic. In Channel Binding scenarios the attacker would need to proxy the binding too, which will get out of hand pretty fast, since in TLS both parties have a per-channel secret and that secret won't match between the proxied and real channels.