←back to thread

Getting ready to issue IP address certificates

(community.letsencrypt.org)
314 points Bogdanp | 5 comments | 25 Jun 25 16:21 UTC | HN request time: 0.335s | source
Show context
lq9AJ8yrfs ◴[25 Jun 25 17:56 UTC] No.44380076[source]▶
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.

replies(8): >>44380307 #>>44380480 #>>44380529 #>>44381336 #>>44381990 #>>44382179 #>>44383267 #>>44385523 #
1. gruez ◴[25 Jun 25 20:05 UTC] No.44381336[source]▶
>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?

I don't see how this is any different than custom/vanity domains you can get from cloud providers. For instance on azure you can assign a DNS name to your VMs in the form of myapp.westus.cloudapp.azure.com, and CAs will happily issue certificates for it[1]. There's no cooloff for those domains either, so theoretically someone else can snatch the domain from you if your VM gets decommissioned.

[1] https://crt.sh/?identity=westus.cloudapp.azure.com&exclude=e...

replies(4): >>44381604 #>>44382746 #>>44383648 #>>44383915 #
2. eddythompson80 ◴[25 Jun 25 20:38 UTC] No.44381604[source]▶
There is in fact weird cool off times for these cloud resources. I’m less familiar with AWS, but I know in azure once you delete/release one of these subdomains, it remains tied to your organization/tenant for 60 or 90 days.

You can reclaim it during that time, but any other tenant/organization will get an error that the name is in use. You can ping support to help you there if you show them you own both organizations. I was doing a migration of some resources across organizations and ran into that issue

3. Throwaway123129 ◴[25 Jun 25 23:26 UTC] No.44382746[source]▶
AWS sets CAA records for their domains and thus you can’t issue certs for them
4. briHass ◴[26 Jun 25 02:15 UTC] No.44383648[source]▶
This is why Azure now uses a unique hash appended to the hostname by default (can be changed if desired.) You can't attack a dangling CNAME subdomain record if it points to a hashed-appended hostname, and Azure allows you to control the uniqueness either globally/tenant/region so you can have common names in that tenant/region if you wish.
5. akerl_ ◴[26 Jun 25 03:21 UTC] No.44383915[source]▶
The difference is the directionality.

The attack here isn't "snatch a domain from somebody who previously got a cert for it", it's "get an IP, get a cert issued, then release it and let somebody interesting pick it up".

In practice, this seems relatively low risk. You'd need to get a certificate for the IP, release it, have somebody else pick it up, have that person actually be doing something that is public-facing and also worth MITMing, then hijack either BGP or DNS to MITM traffic towards that IP. And you have ~6 days to do it. Plus if you can hijack your target's DNS or IPs... you can just skip the shenanigans and get a valid fresh cert for that target.