FRESH

Hacker News

Home

Getting ready to issue IP address certificates

328 points by Bogdanp

by Tepix

7 subcomments

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

by lq9AJ8yrfs

8 subcomments

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.

by mocko

13 subcomments

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

by sschueller

4 subcomments

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?

by 0xbadcafebee

1 subcomments

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 :)

by vkdelta

6 subcomments

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

by 1vuio0pswjnm7

0 subcomment

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

by OptionOfT

1 subcomments

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?

by richm44

1 subcomments

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

by zdw

2 subcomments

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?

by zaik

1 subcomments

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

by sgjohnson

0 subcomment

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

by smallnix

1 subcomments

Is this for ipv4 and ipv6?

by Hizonner

2 subcomments

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

by bufferoverflow

0 subcomment

[dead]

by msgodel

2 subcomments

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

by zipping1549

0 subcomment

Boy that doesn't sound good.

by timewizard

3 subcomments

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.

by foresto

2 subcomments

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.