That's unrealistic. I don't think you appreciate the scope of what that means in practice. As an example, not quite the same thing, but we waited decades for OCSP revocation and stapling to work well and it never did.
I think your concern is more of browser users. Is that fair? If so, you could make the case to Chrome, Safari, Firefox and the like that they ought to block people from using URL with an IP address without some extra confirmation. That's pretty much what you are suggesting for all TLS libraries which serve a much more diverse audience.
That would allow the sensible uses of IP certs to remain and protect the most vulnerable.
Wget or curl you might get redirected to IPs where there's no CAA and you might not notice either. But yes, the browser user extra confirm solution sounds helpful.
As for: "that's unrealistic", are IP certs so vital to offer before this is sorted out? Anybody could e.g. pull request OpenSSL to change defaults. Could work to reach most infrastructure users, and an easier change than e.g. stapling or OCSP.
However, unless a big party argues for this solution, it'll probably get rejected.
I'm having a hard time seeing the threat vector. You can only ever end up at a service running TLS secured by an IP address certificate if you either access it initially, or are redirected to it from another service you initially accessed.
There's no scenario where a user ends up there suddenly, unless they do so intentionally, are compromised, or the web service they are accessing has been compromised and redirected them.
Maybe I'm off, but I'm getting the idea that your argument pins on a TLS library accepting a certificate for the underlying website's IP address as valid as an alternative for the domain. Which isn't the case. Just because someone may have a certificate for an IP address has no bearing on any domain pointed to that IP address and you will never end up accessing that IP address directly unless the service at the domain redirects you to it.
STARTTLS is inherently vulnerable. HTTPS / DoH / DoT and most protocols do not support it. I am only aware of it in old mail configurations or XMPP.
That link describes lawful wire tapping. It is possible that a government agency could seize control of a DNS provider, server, or racked system in a datacenter to issue certificates for court ordered wiretapping
or are redirected to it from another service you initially accessed.
This would be pretty common for wget or curl or other infrastructure tools. So I don't think my argument pins on what you say it does.
I'm just concerned Let's Encrypt IP cert availability will some hosters use IPs where they should use domains out of convenience, and invite new attack vectors.
I recommend bringing your concerns to the CA/B forum which governs certificate issuers and trust stores. Not much to do here and I'm not going to go in circles.
Hi @ell1e, LE dev here. I think your concern is valid and understandable. You're absolutely right that IP addresses change hands frequently and silently, compared to DNS names. You're likely aware, as we are, of "IP-squatting" attacks where a malicious user of a cloud service rapidly recycles instances, hoping to get assigned an IP address that used to belong to one of their neighboring tenants so they can capture traffic intended for that other service. And there is no mechanism for checking CAA for IP addresses, since CAA is a DNS-based protocol, and IP addresses obviously don't have entries in the DNS (yes, the .arpa reverse-address zone exists, but that's not the quite same thing -- I'd be happy to discuss that elsewhere). All of this gives reasonable cause for concern.
This is exactly why our IP address certificates are only available under the "shortlived" profile, with a validity of approximately 6 days. We have been continuously receiving feature requests for IP issuance over the last ten years, and have refused to launch this feature until we had the ability to restrict IP certs to a much shorter lifetime.
In some ways, you can think of this as a negotiation between what would provide the most security and what provides the most usability. It sounds to me like you're thinking about this negotiation with 7 days on the one hand, zero seconds on the other, and coming to the conclusion that some even shorter lifetime would be more appropriate. We're thinking about the same problem with 90 days on the one hand, zero second on the other, and coming to the conclusion that 6-day certificates strike the right balance between expiring quickly when an IP changes hands and not requiring IP subscribers to renew every few hours.
Thank you. I just don't think a 7 days limit fixes the problem, but I appreciate the notion. I have however e-mailed the CA/B forum now, whether it'll do anything or not.
Great, I look forward to that thread. It hasn't shown up yet, but perhaps it's just caught in the moderation queue for now (which address did you send it to?). In the mean time, I'll add a few other notes.
It's important to maintain the distinction between "owner" and "controller". Certificates do not say anything about ownership. The point of a certificate is to say "the entity which controls this domain name / IP address wants to use this public key for encryption".
If you connect to a domain name that has recently been sold, it's totally possible (likely, even) that the old owner still has a valid cert for that name. This is the "stale certificate" threat studied and detailed in this paper by Zane Ma (as well as elsewhere). There are two primary mitigations against this threat: ensuring that the old domain owner cannot intercept traffic intended for the new domain owner, and shortening certificate lifetimes. We can't control the former, but we can control the latter.
The same threat of course exists for IP address certs; that's the whole point you're making here. So, we're taking the appropriate steps to mitigate the threat by enforcing very short certificate lifetimes. But the other mitigation still exists also: the holder of the stale IP certificate can't do anything with it without executing some other attack to intercept traffic, such as a BGP hijack.
So the situation you're concerned about requires several things to happen:
Clients are accessing a site directly by IP, not by domain name
That site has an IP address certificate
That IP address changes hands
Within the next 7 days, the previous owner executes a BGP hijack to intercept traffic intended for the new owner
This situation is possible, for sure. There's no denying that. It's just that it's unclear to me that the threat here is much larger than the similar situation for a DNS name changing hands. Or at least not so much larger that the lifetime reduction from 90 days to 7 days is not a commensurate increase in mitigation.
Two quick clarifications here: first, the person you were replying to is a member of the helpful community here on the forum, but is not an employee or representative of Let's Encrypt; second, it's not clear to me how the lack of OCSP makes this situation worse. OCSP as a revocation protocol had already failed due to lack of enforcement at the client layer. Our removal of OCSP did not increase the number of TLS handshakes that will be trusted when they should be recognized as revoked.
As a small non-profit, we are unwilling and unable to take on the PII burden of accepting payments for this service. We have already removed all contact information from CA databases; adding a way to tie ACME accounts to payment accounts would be the antithesis of that work. We also don't believe that certificates should cost money, period. Asking for payment for IP certs would just mean that IP address sites remain unencrypted, as they largely are today.
I think HTTP-layer redirects to bare IP addresses are not actually very common; most infrastructure tools resolve IP addresses via the exact same mechanism (A/AAAA lookups in the DNS) as the rest of the web. This is why all the infrastructure coordination systems (kubernetes, consul, etc) do service discovery via DNS.
Possible attacks seem to be BGP hijack, hoster MITM or ISP MITM, and others. The problem I think is that static IP risk is probably not that high, but due to CAA still higher, but for 24 hours dynamic IP seems fairly high. That's the case I find concerning, and which doesn't seem to be present for domains.
"[...] redirects to bare IP addresses are not actually very common" My concern was they'll become more incentivized now.
"[...]IP address sites remain unencrypted[...]" I think that could be a good thing, sometimes.
Anyway, I don't think I have anything more to add.
Maybe not for the registered-domain level, but I suspect there are "dynamic DNS" services out there that allow you to get a subdomain of theirs, release it, and then let another user get that same subdomain. Those do allow one to use CAA to mitigate that to some degree, though I don't know how often those kinds of services would do so in practice.
I do see the concern, that just because IP certificates have been "allowed" for some time, it may lead to some "interesting" activity to make them now free and easier. Definitely worth keeping an eye on how it works out in practice.
It's also worth noting that browsers can, and probably should, do a lot more to help users understand who they're connecting to, and that a certificate isn't indicative of reliability or trustworthiness. We'd had occasional conversations around here about how browsers might be able to inform users if a domain ownership changed. I could see them doing something similar for IP-based connections, where if an IP is in a range known to be short-term-leased that they could help ensure the user knew that in some fashion.
While I can see being cautious and ensuring that clients don't treat a cert as being more than they should, isn't "securely communicating with someone who proved control within the past week" better than "forcing communications to be unencrypted"? Like, with or without a cert, one would need to intercept traffic in order for a client to think they're talking to the "right" controller of an IP but actually talking with someone else. At least in the case where it's protected by a cert, there's some evidence that the other side had control over it at some point in the past to somewhere else on the Internet, whereas if unencrypted there's no evidence of having had control at any other point or when viewed from any other Internet route.
Like I said, it's worth watching how the ecosystem evolves with IP certs being free and easier. And it's surprising to me how much interest there seems to be for them, since the main use case I would expect them to be for would be for encrypted DNS servers which I wouldn't expect there to be a whole ton of. But, given that people want to connect to a system by IP instead of name, isn't having some evidence of recent control and allowing encryption better than having none and not allowing for encryption?
I mean, I could certainly understand there are good arguments to be made that browsers/clients/libraries should block (or warn about, or otherwise make more obvious and/or difficult) connections to IP addresses, especially ones that might change control frequently. I just don't see why the arguments are any different for unencrypted connections vs. encrypted ones.
As much as people might wish it to be otherwise, CAs (even paid CAs, and even with OV/EV certs) are just authenticating that control over the name (or IP) was demonstrated at some relatively-recent time by the holder of the presented public key, not that making the connection is wise, trustworthy, or in any way a good idea. Many people try put some responsibility onto CAs that really isn't the CA's role.
I think people had similar concerns when Let's Encrypt first started, that having some sort of cost to getting a certificate might help prevent (or at least slow down) some cheap ne'er-do-wells from executing certain kinds of attacks or scams. And that's probably true! Let's Encrypt issues certificates for sites that are doing all sorts of naughty nefarious things. But in general, the advantages to allowing anybody to secure their traffic seem, to me at least, to outweigh the disadvantages of doing so. It's entirely possible that opening that ability to secure their traffic to certs including IPs in addition to domain names will help enable bad actors to do bad things. I think the goal here is that hopefully, on balance, it will do more good than harm. I'm honestly a little nervous about it myself; we may have to wait a bit and see how it all turns out. One advantage to short-lived certs is that if it turns out that Let's Encrypt issuing them is a mistake, they can just turn it off and those certs will all expire within a week.