Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Router manufacturers do not know what IP address their device will be assigned and therefore should not be able to register a TLS certificate for a router. However, some routers have HTTPS web-interfaces which do not trigger un-trusted certificate warnings when accessed.
How do router manufacturers achieve this?
Sadly most of them do not use https at all.
If no https is used no certificate check needs to be done. This is actually more insecure than having TLS with manually verified certificates, but I guess the vendors try to avoid scaring people and getting support backlash.
In the future when Browser will alert form submissions, this might change.
BTW, the actual problem is not the changing IP address, as most routers make themselves known under a local constant name. The actual problem is that the manufacturers have a hard time actually distributing a certificate for such a name in a way that malicious owners cannot retrieve the secret key. (Would require a HSM/TPM Protection)
The other answer is not completely right, hence I‘ll try and fix that.
There are two different types of web interfaces for routers: The internal and the external web interface.
While the external should be disabled for many reasons, the internal one does not need https to be deployed: as you are accessing the router from your LAN (let‘s just assume, CRACK might be fixed some day and WiFi is considered secure again), a MITM can only operate locally, which is not a big threat in most consumer cases.
Yet, generally it would be desirable to have https on COTS routers. This poses significant problems. While the IP itself would not be a huge problem as the actual IP is only checked when accessing directly via IP (as the IP is taken to be the domain), there is another problem: most SOHO routers either have no DNS zone for the devices or they can be configured.
Even if all routers of one model were to be configured with a not-changeable local domain name like „routerxy.local“, .local is a domain no CA would ever create a certificate for. This is the point the other answers misses. It’s not the storage of the certificate and key that is the deal breaker (it is one as well though, but could be mitigated with an HSM), it is the local domain and how CAs work.
There would be a way to mitigate this problem as well:
Maker x can create routery.x.tld and obtain a certificate for that - and distribute that in the HSM of every box they ship. If this gets leaked (by a vulnerability in the HSM, for example - they are now in the hands of the potential attacker), you are in huge trouble all over again.
Additionally, most CAs might revoke the certificate when they see abuse like that (as the entity the certificate is for is not the one using it)
All in all: there are technical difficulties that hinder usability (we do not want certificate warnings on our COTS router) and there is little benefit from using TLS on a connection that is merely within the LAN.
For HTTPS certificate, IP address don't matter, what matters is the DNS domain name that the device is assigned to. As long as the device is provisioned with a certificate and private key matching the DNS name that the router is assigned, then it can serve HTTPS for that domain name.
Since routers generally also acts as the DNS for the network it's serving, it's capable of adding any DNS name to the network. So all that's left is obtaining a publicly trusted certificate for that domain name.
Publicly trusted CA are restricted from issuing public certificates for DNS names that aren't registered in the public DNS system. According to my search, a number of sites claims to have some ASUS routers that have automatic HTTPS administration page on a domain name that looks like https://router.asus.com:8443, which is a publicly registered DNS address that belongs to the router manufacturers. The router manufacturers, ASUS in this case, can obtain a valid, publicly trusted certificate for that domain name as they own the asus.com domain name.
All that's needed now is for the router manufacturer to include the private key for the publicly trusted certificate in the devices they sell. This suggest that, when using the default certificate, a sufficiently advanced attacker may be able to extract the private key from the device to spoof the router admin page. Hopefully this shouldn't be straightforward as the router should not have allowed its admin domain name to be hijacked by other users.
