A social media post was asking about the hassle of a secure connection to an ISP router (using TLS), and it reminded me of the early 1990s when we used to hand-craft TCP/IP networks on 3Com, Cayman, etc. as if it was serious engineering. All that’s ancient history because everything has been made so easy that anyone can connect securely.
That being said, vendors today aren’t really doing their part to make the easy stuff easy. For example, the German company FRITZ! still tells its customers to click through a certificate warning on their own router login.
That’s just nuts.
Its help page walks users through clicking past the certificate warning in every major browser and assures them that from the home network “This does not pose a security risk.” The same page tells them to ignore the browser warnings about an unencrypted login as well, because the interface opens inside the home network and the password stays off the internet.
Matthew Wallace and I covered this attack in Securing the Virtual Environment: How to Defend the Enterprise Against Attack, published by Wiley in 2012. That’s 15 years ago! Certificate warnings and operator fatigue were among the easiest attack vectors in the book. An operator who clicks through the same warning on every login will click through an attacker’s certificate the same way, because the two warnings look identical.
Come on vendors, what are you doing?
The certificate authorities way back in November 2011 (CA/Browser Forum) adopted Baseline Requirements that phased out publicly trusted certificates for internal names and reserved IP addresses, with November 1, 2015 as the latest permitted expiry. That’s a decade gone already since everyone was supposed to be doing internal networking the right way. Look at how Let’s Encrypt now issues IP address certificates, limited to public addresses it can reach for validation. A router at 192.168.178.1 can present only a certificate its owner chose to trust, so the vendor has to give the router a public name.
All of the pieces of this puzzle have been public for years.
| Year | What happened |
|---|---|
| 2011 | CA/Browser Forum phases out public certificates for internal names and reserved IPs |
| 2012 | Our book Securing the Virtual Environment shows how certificate warnings and operator fatigue are among the easiest attack vectors |
| 2015 | Plex issues every home media server its own trusted certificate |
| 2020 | Netgear’s shared router certificates are revoked because the private key is found in public firmware |
| 2024 | An attacker registers fritz.box |
| 2026 | Let’s Encrypt issues IP address certificates, and FRITZ! still tells users to ignore the warning |
Using bland generic marketing for internal name resolution has drawbacks. FRITZ! routers answer fritz.box from their own resolver, and .box is a public top-level domain. At the end of January 2024 an attacker registered fritz.box, and heise reported that the domain redirected to various websites and intercepted SSH connection attempts. AVM, now FRITZ!, won control of the domain through WIPO arbitration in May 2024. Because, duh. But also, why didn’t they think of this before? The name the vendor thought of as private had a public registration sitting open.
Netgear, by comparison, tried to shortcut the safety of real public names with a certificate. It procured a certificate for routerlogin.com and shipped the private key in its router firmware, where anyone could extract it from a router or from the firmware downloads on Netgear’s own site. The certificates were revoked after the key was exposed for being in the public. A shared key makes every router the same router, and anyone holding the firmware can impersonate it.
Plex solved the same problem in 2015 for home media servers. Plex bought DigiCert certificates for every server. Each server holds a wildcard for its own hash-named subdomain of plex.direct, and a name such as 192-168-1-7.hash.plex.direct resolves to the LAN address written into it. The key is only on a single device and the operator’s browser can verify the certificate against the name.
A router has the easier version of this, so it makes no sense why router vendors are delaying the proper solution. Plex had to tell users to switch off DNS rebinding protection, because resolvers filter public names that point at private addresses. The router is the actual resolver that DHCP assigns to every client on the network, so it can answer its own name with its LAN address directly.
Any vendor could ship this today, and regulators should demand it already.
- The router generates its own key pair on first boot and keeps the private key on the device.
- The vendor assigns each router a random, unique hostname under a domain the vendor owns and answers the DNS-01 challenge in its own zone, so the router stays closed to inbound traffic.
- The router’s resolver answers that hostname with the router’s LAN address.
- The friendly name and the bare IP serve a plain HTTP redirect to the unique HTTPS name, and the login form appears only there.
- The router renews through the vendor automatically and falls back to its own individual self-signed certificate if renewal fails.
FRITZ! is sitting on all the pieces and just needs to put them together. Each box that registers with MyFRITZ! receives a random, unique address ending in .myfritz.net. Since FRITZ!OS 7 the box can obtain a Let’s Encrypt certificate for that address and renew it on its own. Each box also carries an individual self-signed certificate, so FRITZ! avoided Netgear’s shared key.
FRITZ! currently points at the Internet. The Let’s Encrypt certificate requires a MyFRITZ! account, and the box opens a port to the internet during validation. AVM’s release notes state that HTTPS to fritz.box or the local IP keeps the self-signed certificate.
The FRITZ! example is useful because the change is so trivial for them and so powerful for their customers. AVM issues the myfritz.net names under its own domain, so it can answer DNS-01 for every box in its own zone. The certificate belongs in the default setup, separate from remote access, with the box answering its myfritz.net name with its LAN address and fritz.box serving a redirect to it.
First setup remains the one exception. A new router reaches setup before its WAN connection is up, and a certificate installed at the factory would expire (public certificates are already capped at 200 days and drop to 47 days in March 2029). So the first session would be on the box’s own self-signed certificate, and the vendor can print its fingerprint on the label next to the Wi-Fi key it already prints.
Speaking of printing keys, here’s a fun history fact: when I met with 3Com in 1999 to evaluate their very first ever WEP-capable access point, the plastic case had the passwords embossed into it (AirConnect at Networld+Interop). Literally four hard-printed passwords in the white plastic. “What were you thinking” I asked with my mouth open in shock. “Nobody will ever use WEP if it’s not easy enough” they said. I’m not sure they were right, but I remember one of the worst concepts of secret keys ever. See also CVE-2001-0352.
SNMP agents in 3Com AirConnect AP-4111 and Symbol 41X1 Access Point allow remote attackers to obtain the WEP encryption key by reading it from a MIB when the value should be write-only…
Like, nobody at 3Com said “maybe a sticker would be better than designing the hardcase mold for the same four WEP keys to be fixed forever for everyone”. Talk about planned obsolescence. Sad history fact: 3Com is no more.
FRITZ! gets the Internet side right but still hasn’t closed the gap on the home network. They have had the solution since FRITZ!OS 7 and it’s long past time to get it done right, the easy way.