What if we could have first class SSL certs for IP addresses? You connect to the IP and verify the cert it presents you with your PKI, then switch to the desired host via SNI or some other mechanism after DHE is established. I suspect you could do this without any extra hops but I haven't really thought through how that would work.

tls certificates already work out of the box for ip addresses (at least on firefox, see https://1.1.1.1/), so that's actually a pretty neat solution.

> What if we could have first class SSL certs for IP addresses?

They're not routable.

What does this mean?

What's the next hop for a cryptographic hash? With IP addresses, you have a heirarchy: You match on a prefix to find the router to handle the next path, and that one matches on a longer prefix to find the next hop, and so on.

That allows you to have routing tables that don't include every single host on the internet. This is what allows efficient routing to happen.

Couldn't the client send SNI after the DH and then the server authenticate the secret? That way MITM would always be detectable at least.

> Couldn't the client send SNI after the DH and then the server authenticate the secret?

That means you can't use sni to route your request to a different server.

Yes, whatever is serving on that interface will have to terminate TLS. Or somehow pass the session information to the proxied server, or ask the client to reconnect, or do some kind of tls tunneling from the client to the real host. I don't think any of those are unreasonable options.

> But that’s vulnerable to MITM

It is if that’s all you’re trusting, but you get to check the validity of the cert, so someone could MITM a TLS 1.3, but it wouldn’t do them much good as all they would get is a request for a certificate, then the normal TLS certification steps must proceed. Without the certificate private key the rest of the handshake would fail.

sure, they're not going to MITM your http connection, but they will be able to MITM your certificate connection, which allows them to discover what site you visited, which is the same problem that SNI has.

They can do this, but your browser would retroactively notice that it happened and go "holy shit that was bad, you should complain to someone about it". This does not solve for all threat models, but it does avoid the "snoopy ISP".

There's domain fronting [1] and http/2 certificate frames [2] - they are conceptually similar.

[1]: https://www.bamsoftware.com/papers/fronting/

[2]: https://tools.ietf.org/html/draft-bishop-httpbis-http2-addit...

both of them seem to use the concept of "connect via a fake domain name, then connect to the real domain". i'm not sure how this is scaleable for everyday browsing. you might be able to find the fronting server for wikipedia, but how are you going to find the fronting server for every website you're visiting? this solves the problem of censorship, but not the problem of ISP surveillance.

> you can probably do some sort of DHE

Could the browser send a symmetric key encrypted in the public key of the target website, as part of the initial challenge?

The point is you don't know what the public key of the target website is. You find out by asking for it, and then you verify it's authenticity by checking the signature. Before you connect all you know is the domain and the keys of CA's you trust.

Ah, right. Thanks.