5 ms·

Netgear picked a terrible and clearly unacceptable approach. I I read through this discussion, trying to understand if there exists a good solution. Using plai

by gene91 7y ago

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 cert. Nor can the box request a cert in realtime at the time of setup. Pre-provisioned cert won't work if the box is purchased more than 27 months after manufacturing (the current max validity period). For home network equipment, I suppose this isn't unusual. I see TLS-SRP mentioned in comments. But the commenter hinted at its limited adoption in browsers.

jniedrauer 7y ago
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?
- gene91 7y ago
  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.
  - jniedrauer 7y ago
    The green padlock indicates two things about the server to the user: "This is really my name" and "no one can snoop on our conversation." It doesn't indicate anything about the trustworthiness of the server. The first one is meaningless in the context of an IP address. If a user is going to get pished by an IP address, then they could just as well get phished by 123.sketchydomain.com. The important part when communicating directly with a device by IP address, is that the payload is encrypted end to end. > Similarly, resolution by IP address does not provide privacy or integrity unless you trust the network link. That's a fair point. It's certainly no worse than our current situation where you have to trust a self signed certificate on a case-by-case basis. The router could forge a self signed certificate even more easily than it could forge a certificate signed by a trusted CA.
    - nybble41 7y ago
      > The important part when communicating directly with a device by IP address, is that the payload is encrypted end to end. Which you can't be certain of unless you can verify where the "end" actually is. The IP address is no help here; the ARP cache can't be trusted. Packets can be redirected to any host on the local network regardless of the official IP address assignments. If you aren't authenticating the other end of the link then you can't be sure no one is snooping. Active MitM attacks on local networks are trivial. You don't even need to compromise the router—any peer on the network will do. > The router could forge a self signed certificate even more easily than it could forge a certificate signed by a trusted CA. Sure. As a form of TLS without authentication, one-time-use self-signed certificates would be worse than useless, offering only a false sense of security. The options here are "trust on first use" (betting against a malicious actor being present during initial setup) or offering some way to manually verify the fingerprint of the device's private key. Both approaches require authentication, not just encryption. For the second, more secure option, the cheapest way would be to permanently provision each device with a unique private key and print the key's fingerprint on the device's exterior. For more flexibility, store the key in a small removable HSM (similar to a SIM card) and print the fingerprint on the HSM itself and/or the accompanying documentation.
mook 7y ago
Unfortunately this is a problem that's mostly a result of the browser vendors (who are in control of the validation/UI), and can't be fixed by Netgear / etc. They've decided that security trumps usability. I suspect at done point the router manufacturers will give up and just force setup through a phone app (assuming you could download it over a cellular connection). That makes me sad, though.

by gene91 7y ago

jniedrauer 7y ago

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?

gene91 7y ago
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.
- jniedrauer 7y ago
  The green padlock indicates two things about the server to the user: "This is really my name" and "no one can snoop on our conversation." It doesn't indicate anything about the trustworthiness of the server. The first one is meaningless in the context of an IP address. If a user is going to get pished by an IP address, then they could just as well get phished by 123.sketchydomain.com. The important part when communicating directly with a device by IP address, is that the payload is encrypted end to end. > Similarly, resolution by IP address does not provide privacy or integrity unless you trust the network link. That's a fair point. It's certainly no worse than our current situation where you have to trust a self signed certificate on a case-by-case basis. The router could forge a self signed certificate even more easily than it could forge a certificate signed by a trusted CA.
  - nybble41 7y ago
    > The important part when communicating directly with a device by IP address, is that the payload is encrypted end to end. Which you can't be certain of unless you can verify where the "end" actually is. The IP address is no help here; the ARP cache can't be trusted. Packets can be redirected to any host on the local network regardless of the official IP address assignments. If you aren't authenticating the other end of the link then you can't be sure no one is snooping. Active MitM attacks on local networks are trivial. You don't even need to compromise the router—any peer on the network will do. > The router could forge a self signed certificate even more easily than it could forge a certificate signed by a trusted CA. Sure. As a form of TLS without authentication, one-time-use self-signed certificates would be worse than useless, offering only a false sense of security. The options here are "trust on first use" (betting against a malicious actor being present during initial setup) or offering some way to manually verify the fingerprint of the device's private key. Both approaches require authentication, not just encryption. For the second, more secure option, the cheapest way would be to permanently provision each device with a unique private key and print the key's fingerprint on the device's exterior. For more flexibility, store the key in a small removable HSM (similar to a SIM card) and print the fingerprint on the HSM itself and/or the accompanying documentation.

mook 7y ago

Unfortunately this is a problem that's mostly a result of the browser vendors (who are in control of the validation/UI), and can't be fixed by Netgear / etc. They've decided that security trumps usability. I suspect at done point the router manufacturers will give up and just force setup through a phone app (assuming you could download it over a cellular connection). That makes me sad, though.