4 ms·

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 da

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.

hk1337 1y ago
> I wonder how many IP certs you could get for how much money with the different cloud providers. I wonder if they'll offer wildcard certs at some point.
- qyrreqjh 1y ago
  if you're talking about lets encrypt, they started offering wildcards in 2018
  - DaSHacka 1y ago
    GP may have been talking about "wildcard IP certificates" Or, even if they weren't, now I'm curious about that possibility too.
    - bc569a80a344f9c 1y ago
      Doesn't seem like that's possible. RFC5280 (https://datatracker.ietf.org/doc/html/rfc5280 https://datatracker.ietf.org/doc/html/rfc5280) defines these fields. Section 4.2.1.6 defines SANs, and specifies: > When the subjectAltName extension contains an iPAddress, the address MUST be stored in the octet string in "network byte order", as specified in [RFC791]. The least significant bit (LSB) of each octet is the LSB of the corresponding byte in the network address. For IP version 4, as specified in [RFC791], the octet string MUST contain exactly four octets. For IP version 6, as specified in [RFC2460], the octet string MUST contain exactly sixteen octets. That's 32 bits for IPv4 and 128 bits for IPv6. You can't store anything other than a single unicast IP address of either format with that much space.
Hizonner 1y ago
> 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. ... or put multiple customers on the same IP address at the same time. But presumably they wouldn't be willing to complete the dance necessary to actually get certs for addresses they were using that way. Just in case, though, it's probably a good idea to audit basically all software everywhere to make sure that it will not use IP-based SANs to validate connections, even if somebody does, say, embed a raw IP address in a URL. This stuff is just insanity.
- schoen 1y ago
  There was a prior concern in the history of Let's Encrypt about hosting providers that have multiple customers on the same server. In fact, phenomena related to that led to the deprecation of one challenge method and the modification of another one, because it's important that one customer not be able to pass CA challenges on behalf of another customer just because the two are hosted on the same server. But there was no conclusion that customers on the same server can't get certificates just because they're on the same server, or that whoever legitimately controls the default server for an IP address can't get them. This would be a problem if clients would somehow treat https://example.com/ https://example.com/ and https://96.7.128.175/ https://96.7.128.175/ as the same identifier or security context just because example.com resolves to 96.7.128.175, but I'm not aware of clients that ever do so. Are you? If clients don't confuse these things in some automated security sense, I don't see how IP address certs are worse than (or different from) certs for different customers who are hosted on the same IP address.
  - Hizonner 1y ago
    Perhaps I didn't make myself clear. I don't think that IP certs will end up getting issued for shared servers, and definitely not in a way where tenants can impersonate one another. Not often enough to worry about, anyway. The point was that it affects the utility of the idea. ... and don't get me started on those "challenge methods". Shudder. You'll have me ranting about how all of X.509 really just needs to be taken out and shot. See, I'm already doing it. Time for my medication...
deleted 1y ago
[deleted]
gruez 1y ago
>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=expired&group=none https://crt.sh/?identity=westus.cloudapp.azure.com&exclude=e...
- eddythompson80 1y ago
  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
- Throwaway123129 1y ago
  AWS sets CAA records for their domains and thus you can’t issue certs for them
- briHass 1y ago
  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.
- akerl_ 1y ago
  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.
derefr 1y ago
> So all the addressing bodies (e.g., ISPs and cloud providers) are on board then right? My guess is that it's going to be approached the other way around. After all, it's not the ISPs' job to issue IP addresses in conformance with TLS; it's a TLS provider's job to "validate identity" — i.e. to issue TLS certificates in conformance with how the rest of the ecosystem attaches identity to varyingly-ephemeral resources (IPs, FQDNs, etc.) The post doesn't say how they're going to approach this one way or the other, but my intuition is that LetsEncrypt is going to have/maintain some gradually-growing whitelist for long-lived IP-issuer ASNs — and then will only issue certs for IPs that exist under those ASNs; and invalidate IP certs if their IP is ever sold to another ASN not on the list. This list would likely be a public database akin to Mozilla's Public Suffix List, that LetsEncrypt would expect to share (and possibly co-maintain) with other ACME issuers that want to do IP issuance.
- akerl_ 1y ago
  I've not seen any indication at all in LetsEncrypt's announcements that this is the case. Can you say more about how you're deriving that intuition?
jeroenhd 1y ago
You can renew your HTTPS certificate for 90 days the day before your domain expires. Your CA can't see if the credit card attached to your auto renewal has hit its limit or not. I don't think the people using IP certificates will be the same people that abandon their IP address after a week. The most useful thing I can think of is either some very weird legacy software, or Encrypted Client Hello/Encrypted SNI support without needing a shared IP like with Cloudflare. The former won't drop IPs on a whim, the latter wouldn't succeed in setting up a connection to the real domain.
nijave 1y ago
Iirc AWS Application Load Balancers (HTTP/L7) will cycle through IPs as fast as every 30 minutes (based on me tracking them ~5 years ago). I think they set a 10 minute ttl on their DNS records
- bigfatkitten 1y ago
  Even less - 60 second TTL.
mkagenius 1y ago
Even 1 day is enough for my use case, where I just want some tests to be done on a HTTPS url. All in all a great move.
- dewey 1y ago
  You need a public IP for these tests? Otherwise that’s already quite easy with mkcert and a lot of our dev toolings.
  - mkagenius 1y ago
    Something like google oauth and stuff needed that, and my goto was to get a domain and get https from letsencrypt. As that is also not that hard and eventually I do have to get a domain. But this is even better as it won't break my coding flow.

hk1337 1y ago

> I wonder how many IP certs you could get for how much money with the different cloud providers. I wonder if they'll offer wildcard certs at some point.

qyrreqjh 1y ago
if you're talking about lets encrypt, they started offering wildcards in 2018
- DaSHacka 1y ago
  GP may have been talking about "wildcard IP certificates" Or, even if they weren't, now I'm curious about that possibility too.
  - bc569a80a344f9c 1y ago
    Doesn't seem like that's possible. RFC5280 (https://datatracker.ietf.org/doc/html/rfc5280 https://datatracker.ietf.org/doc/html/rfc5280) defines these fields. Section 4.2.1.6 defines SANs, and specifies: > When the subjectAltName extension contains an iPAddress, the address MUST be stored in the octet string in "network byte order", as specified in [RFC791]. The least significant bit (LSB) of each octet is the LSB of the corresponding byte in the network address. For IP version 4, as specified in [RFC791], the octet string MUST contain exactly four octets. For IP version 6, as specified in [RFC2460], the octet string MUST contain exactly sixteen octets. That's 32 bits for IPv4 and 128 bits for IPv6. You can't store anything other than a single unicast IP address of either format with that much space.

Hizonner 1y ago

> 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. ... or put multiple customers on the same IP address at the same time. But presumably they wouldn't be willing to complete the dance necessary to actually get certs for addresses they were using that way. Just in case, though, it's probably a good idea to audit basically all software everywhere to make sure that it will not use IP-based SANs to validate connections, even if somebody does, say, embed a raw IP address in a URL. This stuff is just insanity.

schoen 1y ago
There was a prior concern in the history of Let's Encrypt about hosting providers that have multiple customers on the same server. In fact, phenomena related to that led to the deprecation of one challenge method and the modification of another one, because it's important that one customer not be able to pass CA challenges on behalf of another customer just because the two are hosted on the same server. But there was no conclusion that customers on the same server can't get certificates just because they're on the same server, or that whoever legitimately controls the default server for an IP address can't get them. This would be a problem if clients would somehow treat https://example.com/ https://example.com/ and https://96.7.128.175/ https://96.7.128.175/ as the same identifier or security context just because example.com resolves to 96.7.128.175, but I'm not aware of clients that ever do so. Are you? If clients don't confuse these things in some automated security sense, I don't see how IP address certs are worse than (or different from) certs for different customers who are hosted on the same IP address.
- Hizonner 1y ago
  Perhaps I didn't make myself clear. I don't think that IP certs will end up getting issued for shared servers, and definitely not in a way where tenants can impersonate one another. Not often enough to worry about, anyway. The point was that it affects the utility of the idea. ... and don't get me started on those "challenge methods". Shudder. You'll have me ranting about how all of X.509 really just needs to be taken out and shot. See, I'm already doing it. Time for my medication...

deleted 1y ago

[deleted]

gruez 1y ago

>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=expired&group=none https://crt.sh/?identity=westus.cloudapp.azure.com&exclude=e...

eddythompson80 1y ago
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
Throwaway123129 1y ago
AWS sets CAA records for their domains and thus you can’t issue certs for them
briHass 1y ago
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.
akerl_ 1y ago
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.

derefr 1y ago

> So all the addressing bodies (e.g., ISPs and cloud providers) are on board then right? My guess is that it's going to be approached the other way around. After all, it's not the ISPs' job to issue IP addresses in conformance with TLS; it's a TLS provider's job to "validate identity" — i.e. to issue TLS certificates in conformance with how the rest of the ecosystem attaches identity to varyingly-ephemeral resources (IPs, FQDNs, etc.) The post doesn't say how they're going to approach this one way or the other, but my intuition is that LetsEncrypt is going to have/maintain some gradually-growing whitelist for long-lived IP-issuer ASNs — and then will only issue certs for IPs that exist under those ASNs; and invalidate IP certs if their IP is ever sold to another ASN not on the list. This list would likely be a public database akin to Mozilla's Public Suffix List, that LetsEncrypt would expect to share (and possibly co-maintain) with other ACME issuers that want to do IP issuance.

akerl_ 1y ago
I've not seen any indication at all in LetsEncrypt's announcements that this is the case. Can you say more about how you're deriving that intuition?

jeroenhd 1y ago

You can renew your HTTPS certificate for 90 days the day before your domain expires. Your CA can't see if the credit card attached to your auto renewal has hit its limit or not. I don't think the people using IP certificates will be the same people that abandon their IP address after a week. The most useful thing I can think of is either some very weird legacy software, or Encrypted Client Hello/Encrypted SNI support without needing a shared IP like with Cloudflare. The former won't drop IPs on a whim, the latter wouldn't succeed in setting up a connection to the real domain.

nijave 1y ago

Iirc AWS Application Load Balancers (HTTP/L7) will cycle through IPs as fast as every 30 minutes (based on me tracking them ~5 years ago). I think they set a 10 minute ttl on their DNS records

bigfatkitten 1y ago
Even less - 60 second TTL.

mkagenius 1y ago

Even 1 day is enough for my use case, where I just want some tests to be done on a HTTPS url. All in all a great move.

dewey 1y ago
You need a public IP for these tests? Otherwise that’s already quite easy with mkcert and a lot of our dev toolings.
- mkagenius 1y ago
  Something like google oauth and stuff needed that, and my goto was to get a domain and get https from letsencrypt. As that is also not that hard and eventually I do have to get a domain. But this is even better as it won't break my coding flow.