Request: ipv6/64 subnets added to a wildcard certificate (example: *.ideafarm.com).
Application: Before the end of 2025, I expect to be able to show you a prototype of a new kind of web server that will require this. What you will see will use http (not https), and when you see it, you will understand why such certs are needed.
Discussion: People who wonder how to validate such certs misunderstand the purpose of the cert. I propose that such certs be validated using DNS1 to establish that the requestor controls the domain (e.g. *.ideafarm.com). When an https request is made using a literal ipv6 address, e.g. https://[11:22:33:44:55:66:77:88]/foo.html, the server will handshake presenting the cert (e.g. for *.ideafarm.com), and the client will accept the validation since that subnet is listed within the cert. The connection then proceeds to securely transmit the content. If the user asks, the client (browser) can inform the user that the ipv6 address is listed in the certificate presented, which is a certificate for "ideafarm.com". The user then knows that whoever controls "ideafarm.com" also "acknowledges responsibility for" that ipv6 subnet, normally because that domain owner controls that subnet. There is no need for, and no benefit from, validating that claim. In the scenario that we will demonstrate, the user will know that the content should be validated by an ideafarm.com certificate.
To clarify, the benefit of such a certificate is that it reveals the domain that claims responsibility for the content being transmitted to the user, and the CA validates that whoever controls that domain authorized the certificate for that ipv6 subnet.
While the idea of certs for subnets is not a bad idea, we are explicitly forbidden from issuing such certs both by the Baseline Requirements (which do not allow for validating control of subnets) and by X.509/RFC 5280 itself (which does not provide a way to encode a subnet in a Subject Alternative Name).
5 Likes
Validating control of subnets isn't part of my feature request. The cert would only be validated using DNS1, which only tests whether the certificate requestor controls the domain.
Scenario: The X.509/RFC 5280 "no can do" issue is history; IPv6 subnets can now be added to a certificate such as one for "*.goodguy.com". For a request such as "https://[11:22::88]/foo.html", the browser initiates a TLS handshake and receives a certificate for *.goodguy.com that contains a matching IPv6 subnet. This establishes that the owner of the goodguy.com domain controls that particular IPv6 address. The browser indicates this to the user by displaying a padlock, followed by something like, "(goodguy.com) [11:22::88]/foo.html", in the URL window.
Now consider what a bad actor can do: Let's say that a bad actor controls the "badguy.net" domain, and he obtains a certificate for "*.badguy.net" that contains the same IPv6 subnet. There is no way for the bad guy to cause "goodguy.com" to appear in a browser, for two reasons: First, his certificate is for badguy.net, so even if he controls an IPv6 address within that subnet, all he can do is get browsers to display "(badguy.net) [...]/...". Second, the owner of the goodguy.com domain can easily ensure that he controls the entire subnet that he puts into his certificate.
From an end user POV, what we are doing is making it possible for browsers to display the domain that it knows (from the certificate received) controls the literal IPv6 address in the request.
I've split this discussion into its own thread.
3 Likes
All information included in a certificate must be validated.
Using certificates to bind non-human-readable identifiers (like IPv6 addresses, or .onion domains) to human-readable DNS names is a good idea, and one that has been discussed in various forums for many years.
However, this is not the primary purpose of a certificate. Its primary purpose is to bind those identifiers to the public key contained in the cert. Therefore it is unacceptable to include any identifiers which haven't been validated.
Your scheme relies on humans observing the URL bar to detect if a bad guy has gotten a cert for the IP address they're visiting. But we know from EV certs that humans are very bad at inspecting the contents of the URL bar and acting upon the info shown there. And even if they were perfect at it, that doesn't work for iframes, content loaded via javascript, POST requests, or non-browser clients.
So unfortunately figuring out validation of the subnet is a non-optional step if you want your scheme to become a reality.
4 Likes
I kind of agree and will look into how BGP might be used to validate an entire subnet without challenging every address. The basic idea would be to challenge a single address and then ask the BGP system whether it currently routes the entire subnet to the same final router. That would do the trick, since the owner of the subnet can control how it is routed (e.g. by running his own BGP server to do that final routing).
One issue is that only subnets /48 or larger are actually routable by BGP, in order to constrain the size of routing tables. A /64 subnet is routed internally within a datacenter. For example, I have a BGP router within a Vultr datacenter that advertises a /64 subnet that Vultr has allocated to me. My router delivers incoming packets to a "virtual private cloud" LAN. My proposed validation approach (above) would work if, and only if, Vultr would not allow my BGP router to advertise a false subnet, one that has not been allocated to me and/or is not actually routed to my router.
In fact, end users never care what IP address the websites they visit run on, nor do they care who issued the certificate, who it was issued to, or what validation level it has. If it weren't for browsers forcefully pushing it, they would be happy to accept HTTP websites.
Security for BGP and domain names should be addressed by other parts of the ecosystem, such as RPKI / DNSSEC / Encrypted DNS, rather than X.509 certificates.
1 Like