4 ms·

As someone suggested in a different comment: handshake with one certificate, then send a new ClientHello that contains the desired hostname and "re-handshake" w

As someone suggested in a different comment: handshake with one certificate, then send a new ClientHello that contains the desired hostname and "re-handshake" with the real cert?

shawnz 6y ago
How do you validate the authenticity of the first certificate without revealing any hostnames?
- ameshkov 6y ago
  If we're keeping this simple, then I'd say have IP address in subaltnames. Obtaining such certs shouldn't be a problem for CDNs, and possible for others as well (regarding free options: Let's Encrypt doesn't support that, but ZeroSSL does)
  - corty 6y ago
    You wouldn't even need a cert for an IP address (which is hard to get). You could just resolve the CNAME and A records until you arrive at an address, do a reverse lookup on that address. Then use the resulting "primary" PTR hostname for the encryption certificate. No additional info for an attacker, no new weird RRs, in the best case just one additional DNS query (but SVCB would need that as well).
    - parliament32 6y ago
      That means one-site-per-IP, which doesn't work with the way we currently do L3->L5.
      - johncolanduoni 6y ago
        One-site-per-IP also ruins much of the point of ESNI, since then anyone who wants to block or track what domain you are visiting can just lookup the domains they’re interested in and match them to IP addresses.
        corty 6y ago
        For the most part they can do that anyways, ESNI or ECH are only relevant for big hosters or proxy services.
      - corty 6y ago
        no, the per-ip key is just the one you would use for ECH, in the encrypted part you can use separate per-vhost certificates as usual
      - namibj 6y ago
        No, this is just a way to verify the Cert for the first handshake, so that one doesn't need to use one with the IP in the sub alt names.
  - shawnz 6y ago
    That would require coordination with a certificate authority any time your IP changes, which could be very inconvenient in some cases. Meanwhile, DNS records already need to be updated if your IP changes anyway, so it is a logical place to put the authenticity information
MathiasPius 6y ago
How do you know that the first certificate was not produced by the MitM?

As someone suggested in a different comment: handshake with one certificate, then send a new ClientHello that contains the desired hostname and "re-handshake" with the real cert?

shawnz 6y ago

How do you validate the authenticity of the first certificate without revealing any hostnames?

ameshkov 6y ago
If we're keeping this simple, then I'd say have IP address in subaltnames. Obtaining such certs shouldn't be a problem for CDNs, and possible for others as well (regarding free options: Let's Encrypt doesn't support that, but ZeroSSL does)
- corty 6y ago
  You wouldn't even need a cert for an IP address (which is hard to get). You could just resolve the CNAME and A records until you arrive at an address, do a reverse lookup on that address. Then use the resulting "primary" PTR hostname for the encryption certificate. No additional info for an attacker, no new weird RRs, in the best case just one additional DNS query (but SVCB would need that as well).
  - parliament32 6y ago
    That means one-site-per-IP, which doesn't work with the way we currently do L3->L5.
    - johncolanduoni 6y ago
      One-site-per-IP also ruins much of the point of ESNI, since then anyone who wants to block or track what domain you are visiting can just lookup the domains they’re interested in and match them to IP addresses.
      - corty 6y ago
        For the most part they can do that anyways, ESNI or ECH are only relevant for big hosters or proxy services.
    - corty 6y ago
      no, the per-ip key is just the one you would use for ECH, in the encrypted part you can use separate per-vhost certificates as usual
    - namibj 6y ago
      No, this is just a way to verify the Cert for the first handshake, so that one doesn't need to use one with the IP in the sub alt names.
- shawnz 6y ago
  That would require coordination with a certificate authority any time your IP changes, which could be very inconvenient in some cases. Meanwhile, DNS records already need to be updated if your IP changes anyway, so it is a logical place to put the authenticity information

MathiasPius 6y ago

How do you know that the first certificate was not produced by the MitM?