I saw the announcement for TLS certs for IP addresses. Even if just issued for a few short days, how is that going to work for the apparently still quite common providers where you can immediately get a new IP address by just reconnecting, or often are force-assigned a new one every 24 hours or such?
It seems like in such an ecosystem, you would have to basically assume a TLS cert for an IP address is owned by somebody who doesn't actually own the IP and therefore can do man in the middle, more often than not.
Or are such short-lived IP addresses excluded somehow?
I would like to understand how this doesn't significantly weaken the trustworthiness of let's encrypt certificates. (I'm not an expert however, so I'm happy to accept that it doesn't, this is more of a curious question than anything.)
Update: this sub point isn't really a problem, see response below.
I just realized there is another scenario where this could be a problem: there is a known pattern of some hosters employing MitM presumably due to state requests, which probably has a lower legal barrier in many places than actually accessing the machine for data. (I'm not a lawyer, this isn't legal advice, assume I'm wrong.) This MitM could so far be avoided, apparently, by adding to the CAA record of a domain that the certificates need to be tied to a specific let's encrypt account.
However, I don't think the average IP address allows a CAA entry, and even if it did, it would be controlled by the hoster in question. So now the hoster could simply get an IP address cert via let's encrypt instead, intercept the traffic, and answer any TLS requests with that cert. While browsers may insist on the correct vhost, I assume many other TLS software will not.
Or am I mistaken, and most software won't allow this? If I'm not mistaken, then:
I understand perhaps Let's Encrypt isn't the reason this is possible, since apparently IP certs existed before. But if anything, I would expect people to lobby for software to just reject IP certs under most circumstances, rather than expand this sort of use.
The browser would have to request the IP address. If you request https://google.com but get served a certificate for the IP address, you will receive an error because google.com is not a listed SAN
If software doesn't properly check SANs I would consider that a catastrophic vulnerability
I see, so this only affects the security of TLS requests done to an actual IP address in the first place? I suppose that does limit the problem surface, that's good to hear.
Still, that any average IP cert may be of way less value if it happens to point to a fast-changing IP, does seem confusing for end users at best. Or are those addresses denied after all?
While that is true, my concern is if a user will understand if a TLS URL goes to an IP, the cert may apparently not prevent impersonation to a remotely comparable degree.
I disagree, since when gooogle.com shows you a cert, you at least know you likely speak with whoever that set up. Due to super short lived IPs, with an IP cert that may not be true.
You would have to explicitly connect to an IP address like https://8.8.8.8. That URI would appear in the browser address bar or connection window of whatever software you are using
In this case Google redirects that to dns.google. Much like https://1.1.1.1
Yes it is true that an IP address could change owners, which is why they are unlikely to be used for business websites, etc.
But you would think if you know that IP address from a trusted source, you can trust you're connected with the current IP owner. You know, like, the point of a cert.
I'm not sure what else to say then. Domains can also change hands rapidly with only the DNS TTL to inform you.
Running publicly facing services with an IP address certificate on a dynamic address is ill advised and anyone doing so should be aware of the drawbacks
It was pointed out in another thread domains are usually blocked from fast re-registration.
Running publicly facing services with an IP address certificate on a dynamic address is ill advised and anyone doing so should be aware of the drawbacks
Right. But how would the user know if that is what is being done? That's my point.
A user would have to enter something like https://111.222.333.444 in their browser. The cert used in the response to that IP would need that IP as an identifier so it would validate. Otherwise the browser shows the same "not secure" as it would for an incorrect domain cert.
So, who is instructing the user to use that IP? That service would need a stable IP to have a hope of getting the user to connect to their service. What kind of service would tell a user to use an IP address knowing the IP might change at any moment?
Kind of the point of DNS is so that users have a consistent name they can use even for changing infrastructure.
What kind of service would tell a user to use an IP address knowing the IP might change at any moment?
It's heard of for smaller self-hosted services to use a domain with short DNS TTY. These people might try to save on a domain and just get an IP cert now, if browsers commonly show it as valid, actual safety be damned. (You could redirect to that IP for example, from somewhere.)
Some services only care that it's cheap and looks safe and official. This also happened before browsers began showing warnings for HTTP sites.
If anything, I'm worried this'll be a regression into that behavior, without visitors being aware.
Sure, if it's a small enough user base (like a family) I could see that happening. But, it also seems like little security risk given those users would know what they are expecting to see. Such as if I was checking out my cousin's trip photos via an IP address but instead saw a spam site I'd text my cousin
The industry CA/B Baseline Requirements set the terms for what short-lived certs and IP identifiers are allowed. This has been discussed amongst that security group for a long time. There are benefits to a number of services for IP based certs.
But you have no control whether it's just presented to a family! Or do you?
Just being "allowed" doesn't make it a good idea. It baffles me since 1. Let's Encrypt has gotten out of niche use cases in the past. 2. You dropped OCSP, which arguably makes this worse. 3. Automated issuing also makes dynamic case abuse more likely.
Just because there is some use for IP certs, doesn't mean it's a good fit for Let's Encrypt.
This thread reminds me a lot of the discussion ten years ago about the 90-day cert lifetime, where people would invent increasingly-improbable scenarios to illustrate why those certs just couldn't be used for them. With ten years' history behind us, it's evident that the vast majority of those concerns were, at best, exaggerated.
Similarly here--it seems the "vulnerability" you're envisioning would require a pretty strange series of coincidences. Most significantly, someone hosting a service on a dynamic IP address, advertising that dynamic IP address as its address, while knowing that IP address wouldn't be very stable. People do foolish things all the time, but this still seems like a bit of a stretch.
I feel like I gave an example above incentivizing (some) small sites to use this when they shouldn't. Would be more vulnerable to real attacks, e.g. by the hoster, that have happened, see here. Visitors can't predict this.
There would also be multiple fix possibilities:
e.g. have all TLS libraries reject IP-based certs always, unless the app tells them on a case-by-case that this is for DNS over HTTPS or user-wanted. Advanced users could e.g. enable this in their browser if they need it for some cloud admin page.
Or Let's Encrypt could charge for this use, not incentivizing use over a domain.
The loss of hosting default pages still showing an error wouldn't be big, I imagine.
