4 ms·

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 ca

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 stuff the key in there somehow. There’s no way around that. Either browsers have to start accepting “local” certs more easily, or end-user network deployed appliances can’t have ssl. Take a pick.

zzzcpan 7y ago
On local networks TLS doesn't make things more secure, maybe even less in some scenarios given all the obtaining of certificates over public internet and leaking info to the public internet. So sane thing to do would be plain http. But really, browsers should stop the bullshit with https "security" and accept ssh-like behavior at least for local networks.
pjc50 7y ago
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 way to authenticate the router to the client, but on the other hand I'm not sure how important all of this is when it's on a local link anyway. A "best possible practice" solution would be to have the routers issued with individual certificates at factory programming time, and provide a rollover mechanism through the admin UI.
- vbezhenar 7y ago
  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.
  - pjc50 7y ago
    Indeed. So what was the expiry situation on this CA-signed certificate in the original article?
  - tialaramex 7y ago
    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.
    - josteink 7y ago
      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.
    - willhschmid 7y ago
      Can you please provide a reference to the "825 days" limitation.
oarsinsync 7y ago
This was answered on the Gist in a comment[0] linking to a tweet[1]: Things to do instead of shipping TLS certs and static private keys to consumer-grade routers you sell by the thousand: Generate a unique keypair per device. Use this keypair to communicate upstream, in a similar fashion to CloudFlare's Keyless SSL. This keypair you generate on the device would need to be preloaded at the factory, unique per device, and the public key would need to be stored in a database. When a TLS handshake comes in, you verify the entire request is signed by that keypair before signing it. Delegated online signing for a TLS handshake isn't even in the top 10 engineering challenges for cryptography in the 2020s. Oh, and, if you don't have connectivity to upstream and your need users to connect to configure something? Fallback to HTTP reachable via port 80 on the private IP for the server. [0] https://gist.github.com/nstarke/a611a19aab433555e91c656fe1f030a9#gistcomment-3145485 https://gist.github.com/nstarke/a611a19aab433555e91c656fe1f0... [1] https://twitter.com/CiPHPerCoder/status/1219228544548720640 https://twitter.com/CiPHPerCoder/status/1219228544548720640
- zonidjan 7y ago
  > Fallback to HTTP reachable via port 80 on the private IP for the server. How, exactly, is that better than using a common cert? What threat do you propose that applies to HTTPS with a shared cert, and not to HTTP?
- lima 7y ago
  An attacker can just dump the unique key, impersonate the device and use that for a MitM attack. There's just no way to do this securely without completely locking down the devices using hardware key management (which would be unreasonably expensive for a cheap router, plus bad for people who want to flash their own firmware). Same level of security, and a lot of extra complexity and cost.
  - oarsinsync 7y ago
    Yep, and that compromises that one device in the field. Not every device globally, today and tomorrow.
lima 7y ago
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.
- wbl 7y ago
  Plain HTTP is fine because the IP is a site-local.
  - creeble 7y ago
    Except for the browser complaint when filling out the form. I have to agree with the calls for allowing warning-less HTTP for LAN connections. Edit: Add last sentence.
    - gsich 7y ago
      This is not a hard-stop like the TLS warning pages. So not a "big" issue.

zzzcpan 7y ago

On local networks TLS doesn't make things more secure, maybe even less in some scenarios given all the obtaining of certificates over public internet and leaking info to the public internet. So sane thing to do would be plain http. But really, browsers should stop the bullshit with https "security" and accept ssh-like behavior at least for local networks.

pjc50 7y ago

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 way to authenticate the router to the client, but on the other hand I'm not sure how important all of this is when it's on a local link anyway. A "best possible practice" solution would be to have the routers issued with individual certificates at factory programming time, and provide a rollover mechanism through the admin UI.

vbezhenar 7y ago
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.
- pjc50 7y ago
  Indeed. So what was the expiry situation on this CA-signed certificate in the original article?
- tialaramex 7y ago
  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.
  - josteink 7y ago
    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.
  - willhschmid 7y ago
    Can you please provide a reference to the "825 days" limitation.

oarsinsync 7y ago

This was answered on the Gist in a comment[0] linking to a tweet[1]: Things to do instead of shipping TLS certs and static private keys to consumer-grade routers you sell by the thousand: Generate a unique keypair per device. Use this keypair to communicate upstream, in a similar fashion to CloudFlare's Keyless SSL. This keypair you generate on the device would need to be preloaded at the factory, unique per device, and the public key would need to be stored in a database. When a TLS handshake comes in, you verify the entire request is signed by that keypair before signing it. Delegated online signing for a TLS handshake isn't even in the top 10 engineering challenges for cryptography in the 2020s. Oh, and, if you don't have connectivity to upstream and your need users to connect to configure something? Fallback to HTTP reachable via port 80 on the private IP for the server. [0] https://gist.github.com/nstarke/a611a19aab433555e91c656fe1f030a9#gistcomment-3145485 https://gist.github.com/nstarke/a611a19aab433555e91c656fe1f0... [1] https://twitter.com/CiPHPerCoder/status/1219228544548720640 https://twitter.com/CiPHPerCoder/status/1219228544548720640

zonidjan 7y ago
> Fallback to HTTP reachable via port 80 on the private IP for the server. How, exactly, is that better than using a common cert? What threat do you propose that applies to HTTPS with a shared cert, and not to HTTP?
lima 7y ago
An attacker can just dump the unique key, impersonate the device and use that for a MitM attack. There's just no way to do this securely without completely locking down the devices using hardware key management (which would be unreasonably expensive for a cheap router, plus bad for people who want to flash their own firmware). Same level of security, and a lot of extra complexity and cost.
- oarsinsync 7y ago
  Yep, and that compromises that one device in the field. Not every device globally, today and tomorrow.

lima 7y ago

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.

wbl 7y ago
Plain HTTP is fine because the IP is a site-local.
- creeble 7y ago
  Except for the browser complaint when filling out the form. I have to agree with the calls for allowing warning-less HTTP for LAN connections. Edit: Add last sentence.
  - gsich 7y ago
    This is not a hard-stop like the TLS warning pages. So not a "big" issue.