HN Reader

Time for me to dust off CVE-2010-3170 again? :-)

I think certificates for IP addresses can be useful.

However, if Let‘s encrypt were to support S/MIME certificates, it would have a far greater impact. Since a few years, we have an almost comical situation with email encryption: Finally, most important mail user agents (aka mail clients) support S/MIME encryption out of the box. But you need a certificate from a CA to have a smooth user experience, just like with the web. However, all CAs that offer free trustworthy¹ S/MIME certificates with a duration of a year or more² have disappeared. The result: No private entities are using email encryption.

(PGP remains unused outside of geek circles because it is too awkward to use.)

Let‘s encrypt our emails!

¹ A certificate isn‘t trustworthy if the CA generates the secret key for you.

² With S/MIME you need to keep your old certificates around to decrypt old mails, so having a new one frequently is not practical

So all the addressing bodies (e.g., ISPs and cloud providers) are on board then right? They sometimes cycle through IP's with great velocity. Faster than 6 days at least.

Lots of sport here, unless perhaps they cool off IPs before reallocating, or perhaps query and revoke any certs before reusing the IP?

If the addressing bodies are not on board then it's a user responsibility to validate the host header and reject unwanted IP address based connections until any legacy certs are gone / or revoke any legacy certs. Or just wait to use your shiny new IP?

I wonder how many IP certs you could get for how much money with the different cloud providers.

Shame that IP address certificates can’t be done via the DNS challenge, but I completely understand why.

Nice, another exploit for TLS. The previous ones were all about generating valid certs for a domain you don't own. This one will be for generating a cert for an IP you don't own. The blackhats will be hooting and hollering on telegram :)

Interesting. I wonder if XMPP federation would work with such a certificate.

So does anybody have a pointer to the official justification for this insanity?

Does it help getting encrypted https (without self signed cert error) on my local router ? 192.168.0.1 being an example login page.

This is incredibly dumb. The three way handshake and initial key exchange is your certificate.

What about internal IPv4 addresses? Can we have browsers ignore 192.168.x.x, 172.16.x.x and 10.x.x.x if we can't get certs for those or can we get a public wildcard for internal networks?

Interesting, there is no subject in the example cert shown.

Is this because the certificate was requested for the IP, and other DNS entries were part of the SAN?

Is this for ipv4 and ipv6?

I can see how this would work on a technical level but what's the intended use case?

Boy that doesn't sound good.

This seems to be for public IP addresses, not private RFC1918 ipv4 range addresses.

The only challenges possible are HTTP and TLS-ALPN, not DNS, so the "proof" that you own the IP is that LetsEncrypt can contact it?

I've personally never felt comfortable using regexes to solve production problems. The certificate code referenced here shows why:

https://github.com/mozilla-firefox/firefox/blob/d5979c2a5c2e...

Yikes.

Why can't the internet regional registries issue certificates

Why can't local internet registries issue certificates

Why are third parties needed to verify RIR and LIR registrants

Apparently the job is too much for domainname registrars

Are the reasons the same

I expect SAN in this case means Subject Alternative Name, not Storage Area Network.

Sigh... I wish people would use their words before trotting out possibly-ambiguous (or obscure) acronyms. It would help avoid confusion among readers who don't live and breathe the topic on the writer's mind.