Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Netgear Signed TLS Cert Private Key Disclosure

gist.github.com

Post reply on HN
Print view View original

101–110 of 158 posts

Re: Netgear Signed TLS Cert Private Key Disclosure

#101

Post by tialaramex »

vbezhenar wrote: post #73
pjc50 wrote: post #64

Earlier quoted context omitted.

Define "secure". If you've "stuffed the key in there" in such a way that other people can get it out again, and it works across all routers of that model, then it's possible for an active attacker on your network to MITM your connection to your router. So it's slightly more secure than cleartext but not much; about the same as a random self-signed certificate. It is definitely a hard problem because there's no easy w…

AFAIK CA can't issue certificate for more than two years. So if you've bought the device two years after it was manufactured, you're getting error and it's even worse than HTTP for user.

825 days is the limit. It's enforced in, for example, Chrome, if a certificate claims to have been issued after this rule changed and it lasts longer than 825 days Chrome considers the certificate bogus immediately.

Certificate Authorities use the difference between 825 days and two years to offer certificate renewal weeks prior to the expiry date while keeping your "extra" days. e.g. your certificate expires 17 February 2020 but you renew today for two years, they can issue a cert which expires 17 February 2022 because that's less than 825 days in the future, if the rule was a hard two years they couldn't do that.

As to how you'd fix this: One option is firmware updates. After all a device which goes two years without firmware updates is also not in good shape, so you could arrange with a CA to bake certificate renewal into the firmware update process. At scale it would totally make sense for a CA to offer to issue renewals at say 10¢ per device renewal for up to ten years from inception date.

The certificate issuance does not require knowledge of the private key, that stays on each individual device, renewal just issues a newer cert periodically to the same device for use with its existing key.

Re: Netgear Signed TLS Cert Private Key Disclosure

#102

Post by lima »

josteink wrote: post #58

To all the people shitting on Netgear and security in this thread, just how do you propose one deliver a secure network appliance to end customers which they can deploy on their network? And which is user-accessible to common users in modern browsers rejecting everything not touched by a proper CA? Really. Please educate the world with your ingenious insight. I’ll be waiting. The unavoidable truth is: You have to stu…

This. Yes, Netgear has a bad track record with security, but this is likely a calculated trade-off.

Alternatives:

- Self signed certificates. Users will learn to acknowledge the error and an attacker can just present their own self-signed cert. This what most vendors do.

- Plain HTTP. Worst option, no security, not even against a passive listener (but no bad PR because of "security disclosures"... hooray!).

- Something similar to Keyless SSL, as suggested on GitHub and in this thread. Will at best slightly inconvenience the attacker, who can still extract any device key and impersonate the device. It also introduces a single point of failure. Server is down, nobody can log into their devices (and HN would not be happy).

- Secure enclaves and hardware key management for the shared key. This would be workable and reasonably secure, but the implementation costs likely won't fit the threat model.

- Issue an individual SSL cert for each domain and print the domain on the box. That would work, but be very complex to manage (plus certificate costs, and plenty of failure cases around renewal).

- Reverse proxy through vendor servers. Single point of failure, and the most likely time to log into your router is the internet is down.

Hardcoding a valid SSL cert for a single-purpose domain (routerlogin.net) is similar to a self-signed cert in terms of security, provides a better user experience and does not teach them to blindly acknowledge TLS errors. The threat model requires an attacker doing a MitM attack on the local link. Also, compromising a router provides very little access to an attacker in today's TLS-by-default world.

Anyone downvoting the parent post should offer a better solution.

Re: Netgear Signed TLS Cert Private Key Disclosure

#103

Post by lima »

vbezhenar wrote: post #12
mschuster91 wrote: post #10

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…

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

Re: Netgear Signed TLS Cert Private Key Disclosure

#104

Post by lima »

CiPHPerCoder wrote: post #93
lima wrote: post #90

Earlier quoted context omitted.

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.

Re: Netgear Signed TLS Cert Private Key Disclosure

#105

Post by lima »

tinus_hn wrote: post #40
ploxiln wrote: post #28

Earlier quoted context omitted.

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.

How did security get worse?

Re: Netgear Signed TLS Cert Private Key Disclosure

#106

Post by jniedrauer »

gene91 wrote: post #88

Netgear picked a terrible and clearly unacceptable approach. I I read through this discussion, trying to understand if there exists a good solution. Using plain http isn't a good solution because it involves telling the user to ignore the "not secure" warnings by browsers. This seems like the best available solution. Without network connectivity, the traffic can not be tunneled through a remote server with proper cer…

When I can control the client configuration, I just set up my own trusted root CA and then have the distributed systems automatically submit a CSR on initialization. This doesn't work when you have to support end user's web browsers though (unless you're somehow lucky enough to own a public CA and don't care about ICANN rules). It really does seem like there should be an encryption-only option for TLS. Maybe anything that resolves by IP address and not name should display the green padlock even if the SAN doesn't match the name?

Re: Netgear Signed TLS Cert Private Key Disclosure

#107

Post by josteink »

tialaramex wrote: post #101
vbezhenar wrote: post #73

Earlier quoted context omitted.

AFAIK CA can't issue certificate for more than two years. So if you've bought the device two years after it was manufactured, you're getting error and it's even worse than HTTP for user.

825 days is the limit. It's enforced in, for example, Chrome, if a certificate claims to have been issued after this rule changed and it lasts longer than 825 days Chrome considers the certificate bogus immediately. Certificate Authorities use the difference between 825 days and two years to offer certificate renewal weeks prior to the expiry date while keeping your "extra" days. e.g. your certificate expires 17 Febr…

So now your local, trusted device depends on untrusted, ephemeral cloud-services to be trustable by you on your local network?

That sounds like the worst of both worlds.

Re: Netgear Signed TLS Cert Private Key Disclosure

#108

Post by gdm85 »

JshWright wrote: post #63
gdm85 wrote: post #19

Earlier quoted context omitted.

There is another reason why responsible disclosure would have been better (and less short-sighted): vendor might make an internal audit, find root cause and invalidate a bunch of certificates at once (think about similarly leaked certificates due to a bug in some deployment tool). Now it's an open race with the bad guys, and surely a lot of them all at once; hardly an advantageous scenario for end users.

That's an awfully big (and awfully optimistic) "might" in your first paragraph there...

It's not optimistic, it's what a responsible vendor is supposed to do. By not following responsible disclosure the researcher has lifted the vendor from the possibility of organizing a proper response.

Re: Netgear Signed TLS Cert Private Key Disclosure

#109

Post by gdm85 »

StavrosK wrote: post #78
JshWright wrote: post #63

Earlier quoted context omitted.

That's an awfully big (and awfully optimistic) "might" in your first paragraph there...

Not to mention that all the bad guys had to do to get the private key was unpack the firmware image, so they've probably noticed long ago.

If what you said were true then zero-days would be always ignored and not a concern.

Re: Netgear Signed TLS Cert Private Key Disclosure

#110

Post by gene91 »

jniedrauer wrote: post #106
gene91 wrote: post #88

Netgear picked a terrible and clearly unacceptable approach. I I read through this discussion, trying to understand if there exists a good solution. Using plain http isn't a good solution because it involves telling the user to ignore the "not secure" warnings by browsers. This seems like the best available solution. Without network connectivity, the traffic can not be tunneled through a remote server with proper cer…

When I can control the client configuration, I just set up my own trusted root CA and then have the distributed systems automatically submit a CSR on initialization. This doesn't work when you have to support end user's web browsers though (unless you're somehow lucky enough to own a public CA and don't care about ICANN rules). It really does seem like there should be an encryption-only option for TLS. Maybe anything…

Encryption-only TLS doesn't protect MITM. It prevents sniffing.

At a higher level, TLS provides integrity and privacy when the network linked is not trustworthy. As a result, I'm not sure what your proposal achieves.

Similarly, resolution by IP address does not provide privacy or integrity unless you trust the network link.

Post reply on HN