Live data from Hacker News

Netgear Signed TLS Cert Private Key Disclosure

gist.github.com

31–40 of 158 posts

Re: Netgear Signed TLS Cert Private Key Disclosure

#31
post #14

Earlier quoted context omitted.

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…

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.

Re: Netgear Signed TLS Cert Private Key Disclosure

#32

The HTTPS cert is used for the router's login page - apparently putting an IP address on the box backside label confuses too many people. It makes sense to put it behind HTTPS because the browser will whine "this page is insecure"... but how is a router vendor supposed to include the neccessary certificate that won't get leaked? The only thing I can imagine here is a dedicated HSM chip... but that's overkill for a 10…

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. Ide…

Number 2: already dealt with:

  * .test
  * .example
  * .invalid
  * .localhost
http://www.rfc-editor.org/rfc/rfc2606.txt

Re: Netgear Signed TLS Cert Private Key Disclosure

#33

The HTTPS cert is used for the router's login page - apparently putting an IP address on the box backside label confuses too many people. It makes sense to put it behind HTTPS because the browser will whine "this page is insecure"... but how is a router vendor supposed to include the neccessary certificate that won't get leaked? The only thing I can imagine here is a dedicated HSM chip... but that's overkill for a 10…

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-...

Re: Netgear Signed TLS Cert Private Key Disclosure

#34

The HTTPS cert is used for the router's login page - apparently putting an IP address on the box backside label confuses too many people. It makes sense to put it behind HTTPS because the browser will whine "this page is insecure"... but how is a router vendor supposed to include the neccessary certificate that won't get leaked? The only thing I can imagine here is a dedicated HSM chip... but that's overkill for a 10…

"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?

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.

Re: Netgear Signed TLS Cert Private Key Disclosure

#35

The HTTPS cert is used for the router's login page - apparently putting an IP address on the box backside label confuses too many people. It makes sense to put it behind HTTPS because the browser will whine "this page is insecure"... but how is a router vendor supposed to include the neccessary certificate that won't get leaked? The only thing I can imagine here is a dedicated HSM chip... but that's overkill for a 10…

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…

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.

Re: Netgear Signed TLS Cert Private Key Disclosure

#36

The HTTPS cert is used for the router's login page - apparently putting an IP address on the box backside label confuses too many people. It makes sense to put it behind HTTPS because the browser will whine "this page is insecure"... but how is a router vendor supposed to include the neccessary certificate that won't get leaked? The only thing I can imagine here is a dedicated HSM chip... but that's overkill for a 10…

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.

Re: Netgear Signed TLS Cert Private Key Disclosure

#38
post #2

6 days is nowhere near a justifiable timeframe for full disclosure. Even if you disagree with that, you should have first reported Key Compromises to Entrust and Comodo before publicly posting the private keys. They are bound by BRs and their own CPS to revoke certificates such as this one - and they would have done so promptly. This is not what you should do as a security researcher - delete the gist until the CAs h…

Boo hoo. Netgear should have known better than to expose their keys like this in the first place, this is really amateur hour stuff.

They were reached out to and didn’t respond. It’s their own fault and they have to make do with what they’ve been granted. Now they get to pick up the pieces.

Re: Netgear Signed TLS Cert Private Key Disclosure

#39
post #16

Earlier quoted context omitted.

"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.

Re: Netgear Signed TLS Cert Private Key Disclosure

#40
post #28
post #22

I discovered this same thing in 2017. My bugcrowd report was shot down as dupe https://www.chaoswebs.net/blog/tls-key-reuse-on-popular-rout...

The difference is that these newly discovered certs with private keys were signed by real Certificate Authorities trusted by browsers by default.

So their security got worse. It’s a miracle people even bother attempting to do responsible disclosure to fools like this.
Post reply on HN