1. Just let it be HTTP. Stupid browsers are stupid, but at least they don't prevent this page from working yet.

2. Router coordinates with company server to get its own hostname like n-123123123.netgear.com (which points to 192.168.1.1 or whatever), generates private key and company server issues certificate for that key. HTTP requests to 192.168.1.1 return HTTP 302 to this address. It requires Netgear to operate CA or make some extended agreement with existing CA to let them issue certificates. I know that Plex does something similar, so it should be possible.

3. Company server creates hostname which points to a public router IP address and router uses letsencrypt to get a certificate for that hostname. But that requires public IP and some providers are using NAT nowadays, so it won't work universally.

4. To configure a device you're talking with company server, rather than your device and your device is talking with that server as well. It requires working Internet, so not a complete solution as well.

I don't believe that HSM chip would work. You would just extract that chip and use it as a private key and that's about it. You won't be able to extract private key bits, but you don't need them. May be it might work with very secure device like iPhone, where everything is signed, but yeah, $10 device and someone will still hack it, causing bad situation.

All but one make for an undesirable UX during initial setup before WAN is up, which is probably the only time most users login to their router.

Yeah, that's why I think that movement to HTTPS everywhere must at least exclude private IP addresses. While it's expected to have HTTPS on public resources, what happens in my local network is my business and should not be considered insecure.

The problem is, that someone setting up a public wifi (in a restaurant for example), will be vulnerable to sniffing attacks (if they don't know what they're doing).

So get a cert before setting up wifi. This is not a hard problem. 1. Connect to AP with random key from the box 2. Open admin panel over HTTP 3. Follow instructions to get Internet access 4. As soon as it has a connection, the router obtains a cert and redirects you to HTTPS 5. Now you can make all your poor security decisions

Have you met ‘normals’?

Everything is a hard problem if it’s any steps at all.

I meant that "how to make router setup secure without making it more difficult" is not a hard problem. My system is no more difficult than the currently most common ones and about as secure as it gets.

Although, one could argue that setting up a router really shouldn't be left to people who don't understand how they work...

#3 is why IPv6 needs universally pushed out by all ISPs.

The issue is you're going to have the ignorant customers calling Netgear to complain their brand new router is not secure if their browser highlights it for situation #1. Same for an untrusted certificate.

The risk with #2 is then an attacker could potentially probe the firmware to figure out that process, and phish from that domain? The other is we need to trust Netgear to run HA infrastructure to support that. (lol)

So it sounds like pretty much marketing/sales runs the company and the product people have no say at Netgear?

In case number 2, it's possible to ask CA to reissue n-123123123.netgear.com, and if it's not possible (due to uniqueness verification during key issuing process), to ask n-123132123.netgear.com and the system administrator may not notice.

With CAA Netgear gets to decide which CA is authorized for netgear.com and they can cut a deal with that CA for any rules they want.

Facebook, for example, has a deal with their preferred CA which says that all certificates for names under fb.com and facebook.com are only to be issued with authorization from Facebook's central security team.

So even if you can fulfil that CA's normal checking perfectly for fake-bank.facebook.com, if you haven't got someone on the inside of the Facebook security team you can't get a working certificate for your fake bank social media scam.

> 1. Just let it be HTTP. Stupid browsers are stupid, but at least they don't prevent this page from working yet.

This would be categorically worse than hardcoding the SSL key.

The other way this could be done is if TLS-SRP was more widely supported. This variant of TLS doesn't depend on certificates at all and instead uses mutual knowledge of a password to authenticate the connection in both directions. In the case of a router this would be written on a sticker on the device for initial configuration.

Ubiquiti do this by tunnelling it through their servers. You can still get insecure access by going direct to the IP, but going to the Unifi site gives you full HTTPS.

Plex do it with a wildcard and generate a new one for each server: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...

We could change the standards to facilitate client apps using a private network's own PKI. This would solve about a million problems that currently exist with most private orgs that need to enforce policy on content on secure networks, as well as allowing consumers to securely browse self-hosted private services. I don't know what that would look like or what would need to change, but it could definitely be done.

Ideas:

1) An extension to PKI that browsers support. If you browse a service with a certain type of cert on a certain TLD, a) it won't work except on private networks, b) it will prompt the user to enter a key, such as a key printed on the backside of a router (this is already used to get consumers onto WPA routers, so we know it's reasonable). The device with the cert creates the cert itself. If the key is right, you can browse the service, and your browser caches the key with the cert. If an attacker learns the key they can try to make a new fake cert, but the browser would know it's not the same as the old cert and block it. Replacing these should be quite infrequent, as often as people replace their home network devices.

2) A TLD that browsers will only ever respond to if its names resolve to private address ranges. If a service wants to serve HTTPS privately, it will request a cert be signed by a device that is auto-detected on the local network. The device will return signed certs for a particular host on the local-only TLD. The device can have any logic it wants to restrict what can get a cert and how. The trick is how to make the client trust the device, which I think 1) would solve. This device can, for example, only ever create a given FQDN's cert once; if an attacker tries to generate a duplicate, it will fail. If the cert ever needs to be refreshed, the memory/flash of the device needs to be reset. This makes it possible to have a captive portal request a cert from a local router, and no attacker can generate an identical cert unless the router was reset and they triggered the cert generation before the captive portal did. (Also for captive portals, the admin of the router could just hard-code what clients could request what certs, so the captive portal could always request particular local certs for itself, while no attacker could). It's still tricky to determine trust on first connection in the case of things like coffee shops, but maybe you could receive a public key via WPA or something (then again that's kinda kicking the can down the road to WPA)

Or you know - don't use TLS at all since all your efforts will be moot anyway. You could always make a self-signed certificate and print the fingerprint on the device itself, but that costs money, for very little gain.

https://en.wikipedia.org/wiki/TLS-SRP as an example.

Number 2: already dealt with:

  * .test
  * .example
  * .invalid
  * .localhost

http://www.rfc-editor.org/rfc/rfc2606.txt

What? No. While those are meant to be reserved, nothing stops you from configuring your resolver to answer for them.

Yes, but users will not be happy if they see ".example" on the URL bar. And you can't get a trusted cert for them either.

Not confusing users is why the fiasco with the https certificate problem here was initially created. And to be honest I do not have any idea how all needs (users have a trusted HTTPS certificate, a domain name and no "insecure" oe other warnings in the browser, while hackers don't get access to the certificate, and all of it works without internet uplink) can be met...

"How" is that they only inlude the private key for that specific router, and then that key/cert itself is certified by the real CA cert, the key for which is not kept on the router itself?

That requires generating and burning keys to devices during manufacturing. This process will be hacked by NSA & all, exactly like Gemalto https://www.theguardian.com/us-news/2015/feb/19/nsa-gchq-sim...

Haha that's a tall order...

Constructing a scheme where NSA is an active agent in the threat model was not an original requirement :)

You are welcome to introduce any way to produce any part of a router or a PC for that matter that would protect from NSA, it seems that the biggest players in the field are still working out and it is very much a work in progress. When you have an adversary that is able to intercept hardware in transit and spend endless amounts of dollars on devising clever hacks or undetectable hardware exploits, then yes, you're right, some TLS scheme, regardless of where the certs are, is not going to be enough.

Delegated Credentials for TLS I guess ?

but this requires internet access so barely a solution. https://engineering.fb.com/security/delegated-credentials/

I don't think that the fact that private keys for routerlogin.net are bundled with the router are an issue. It's very logical to do so, and BETTER than plain HTTP in most real-life scenarios.

routerlogin.net is a local server (when you are using the router) and not a remote website so it's expected that you can trust the content as much as trustable your local network is.

It’s impossible, they need to try something else. They could get dedicated domain names for each router, for instance.

No, you can do something like CloudFlare does for TLS for their enterprise customers, where the TLS session is signed by a key held by Netgear.

https://www.cloudflare.com/ssl/keyless-ssl

The fallback would have to be self-signed TLS with random keys for initial local router configuration, which is hopefully done over an Ethernet connection rather than WiFi.

You don't need a secure enclave or HSM to solve this problem. It just requires caring about security and provisioning enough time to engineer and test the obvious solution. From what I can tell, that doesn't line up with Netgear's MO.

You need a working internet connection. In most cases you go to the webinterface because you are either setting it up, or something (most likely connection) doesn't work.

That would be a central point of failure and a ton of extra complexity without providing any kind of meaningful security benefit.

What do you mean "without providing any kind of meaningful security benefit"?

It prevents a bored kid who dumps the private key from one router from being able to reliably impersonate thousands of consumers' routers, the world over.

That's a meaningful security benefit.

The attacker would just dump the individual router's key instead and use the remote signer as a signing oracle to impersonate devices.

The owner/operator of the router could do that to their own device, yes.

The idea is that each router would get a certificate signed with a distinct subdomain unique to that router. So you still can't impersonate other devices. It wouldn't be a generic domain or wildcard certificate.

The remote signer would furthermore suspend suspicious connections (i.e. from multiple public IP addresses).