[infogulch]

This is a step in the right direction but it's not perfect. The name of at least one domain that the responding server must host is still leaked. This can be a non issue if the same ip is hosting hundreds of domains (e.g. CloudFlare) or pointless if it's just hosting one site.

I just had an idea that might be able to work around this though:

1. Create a new TLD: .ip. All *.ip domains are valid ip addresses (in some encoding, e.g. 740-125-138-139.ip, or anything else) and they always resolve to the ip address specified. 2. Automatically issue certificates for each host for each of the ips that they serve on. (Thank you Lets Encrypt) 3. Every new connection made can just use the ip-domain as the esni originating host, because you can know that every host is serving https://ownip.ip.

This doesn't solve the fact that server ips are still fairly unique, and so a reverse dns might be enough to find the host, but it doesn't leak any more information than what the IP header already leaks, and it doesn't require leaning even more on increasingly centralized proxies like CloudFlare.

[dsl]

Certificates already support IP addresses. They just need to be public (i.e. not RFC1918 space) and for legacy browser compatibility the IP needs to be in the commonName and subjectAltName.

[tialaramex]

In terms of browser compatibility the situation is:

The address must appear as a SAN ipAddress to work in modern browsers like Chrome and Firefox

BUT

The address must appear as either a SAN dnsName or as the X500 series Common Name to work with older Microsoft SChannel implementations.

Key root programme rules and the Baseline Requirements mean that:

IP addresses must not appear as a SAN dnsName (they're IP addresses, writing them out as text doesn't mean now they're part of the DNS system) but only as a SAN ipAddress

The X500-series Common Name must be the textual representation of one of the SANs (doesn't matter which one).

As a result the only compliant certificates for IP addresses that also work in older IE / Edge releases do this:

1. Write exactly one IP address as a SAN ipAddress

2. Write the same IP address, but as a text string as the Common Name.

There are a LOT of certificates that do something else, some of them work but aren't compliant (and so get finger wagging from people like me) some are compliant and don't work in older Windows systems (which may be OK if you're building a new system for like CentOS users, who cares if it works in Windows?) but only the pair of traits I described above manage to be compliant while also working, and they're limited to a single IP address per certificate.

Hey, at least Windows 10 finally groks SAN ipAddresses, in another decade we might not need a workaround.

[infogulch]

Then I guess we just need Lets Encrypt to offer certificates for ips then. [0]

[0]: https://community.letsencrypt.org/t/certificate-for-public-i...

[stordoff]

> (i.e. not RFC1918 space)

Is this just a restriction on current CAs? I have a self-signed certificate on my router (more out of curiosity than any practical benefit), and it comes up fine on https://192.168.1.1/

[reaperhulk]

Yes, this restriction applies only to public CAs. The purpose is to prevent someone from getting, for example, a 192.168.1.1 cert and then using it on another network in a mitm attack.

[zamadatix]

If it's hosting one site there isn't much point in trying to obfuscate what that site is.