5 ms·

Unfortunately there's a giant category of devices that can't serve TLS. Like pretty much every consumer router in existence that you connect to through a webpag

Unfortunately there's a giant category of devices that can't serve TLS. Like pretty much every consumer router in existence that you connect to through a webpage. Someone needs to come up with a solution for that. Ideally one that works with free and open source projects and not just well funded companies.

jMyles 7y ago
> Unfortunately there's a giant category of devices that can't serve TLS. Like pretty much every consumer router in existence that you connect to through a webpage. Come on now. Of course those devices can use TLS - they just can't do so in the capricious constraints imposed by the system of "certificate authorities". It's not a fundamental limitation of the technology. If we were using something like noise protocol, nobody would be saying that tiny devices are incapable of proper security at the transport layer. There's just no clear way to assess the validity of a self-signed cert in the browser given today's political constraints.
- smabie 7y ago
  I'm not familiar with this problem, could someone explain? Thanks!
  - lonelappde 7y ago
    There is no problem. Routers can use a self signed cert.
    - zeven7 7y ago
      Could you expand on that a little? What do you mean? Won't my browser complain if the cert if self signed?
      - etatoby 7y ago
        Yes, it will complain and for good reason: it has no way of knowing whether the kid next door is spoofing your router's IP or Mac address and presenting their own self-signed certificate. I wouldn't go as far as calling it «capricious constraints imposed by the system of "certificate authorities"» but at the same time, I agree that it's not a fundamental limitation of the technology. Better protocols could be developed to allow a browser to trust a server without (all) the limitations of the current system.
        therealjumbo 7y ago
        My harebrained idea for this: - let companies register a wild card domain in the .local (or a newlocal) namespace: .acme.local - designate the acme company with the ability to issue certs that never expire for any name in ".acme.local" but the browser will refuse to use certs signed with that key for anything outside "*.acme.local" pros: - the acme company can now make equipment that the users browser can connect to over an encrypted channel with zero config on the user's part - the equipment can live off the internet indefinitely - if the acme company is breached, and their signing key is stolen, the attackers can only use that key to impersonate acme company, it doesn't allow them to impersonate any other domains cons: - the browser manufacturers don't care about this use case so its never gonna happen - the cert on the device never expires... and can never be replaced automatically somehow. I think the only workaround is acme could enable users to load their own certs if they are so inclined, but that shouldn't be required.
        thw0rted 7y ago
        You should only have to store the self-signed cert exception once, at least on a given device. Now, if you're being targeted by a state-sponsored actor they might somehow be able to get you onto a honeypot network within the 2-minute window between plugging in your router and making your first connection to its web interface, but for everybody else a self-signed cert that you accept once during initial setup should be plenty good enough.
- geofft 7y ago
  Why do they have to use self-signed certs? Ship the device with a valid cert for $last_three_octets_of_mac_address.$vendor.com to the device, and print it clearly on the setup instructions. Typing in something like d63d15.ui.com isn't onerous. The CA/Browser Forum allows certs up to 27 months - do routers sit on store shelves for 27 months before being configured? Do they even sit for 12 months? (Once they're online, they can renew their cert, possibly with the help of the vendor who can track the private key or something.)
  - londons_explore 7y ago
    No need for even that. TLS should have an extension which says "I don't know how to verify my identity, but send this data to vendor.com and then they'll verify my identity". Vendor.com can then look at the opaque blob forwarded from their hardware and decide if they want to deligate trust to it.
    - geofft 7y ago
      That doesn't quite work, because the premise of accessing a router setup page is that your internet connection doesn't work yet. So your router has to be able to prove its identity to the client entirely offline. (You cannot special-case "This server is untraceable", else a repressive government could blackhole that server and trigger the relaxed validation rules.)
  - jeroenhd 7y ago
    That would require significant effort for the vendor to set up and most internet devices such as routers are an absolutely minimal cost device. Literally every cent counts in production and vendors rather remove some features than shell out the 2 cents extra to add another 64mb of storage. Furthermore, this would require either not being able to change the IP for your device (bad) or sending information about the layout of your network to the vendor (I wouldn't trust them with that info). Very few people care about this and the effort of maintaining a custom DNS and a CA certificate system (which, by the way, would need to be subjected to rigorous security testing) just isn't worth it. Lastly, what's the point? Adding a little padlock isn't worth it if anyone can get a certificate for the router ip anyway. How do you ensure that the router connecting to your IP really has the mac address it claims? It only takes one person to get root on their router to invalidate the entire security system and given how somehow router vendors are still shipping command injection vulnerabilities, I wouldn't assume that they can prevent that as much as they'd like. What I want is the option to give a router my own security certificate instead of the self signed one. Let me use my own CA or let me mess around with letsencrypt, split-horizon DNS and Selenium scripts if that's what I need. Consumers don't care about TLS on their router and this would be the cheapest option to solve it for prosumers.
greggman2 7y ago
Found out there's a w3 working group trying to come up with solutions https://www.w3.org/community/httpslocal/ https://www.w3.org/community/httpslocal/

jMyles 7y ago

> Unfortunately there's a giant category of devices that can't serve TLS. Like pretty much every consumer router in existence that you connect to through a webpage. Come on now. Of course those devices can use TLS - they just can't do so in the capricious constraints imposed by the system of "certificate authorities". It's not a fundamental limitation of the technology. If we were using something like noise protocol, nobody would be saying that tiny devices are incapable of proper security at the transport layer. There's just no clear way to assess the validity of a self-signed cert in the browser given today's political constraints.

smabie 7y ago
I'm not familiar with this problem, could someone explain? Thanks!
- lonelappde 7y ago
  There is no problem. Routers can use a self signed cert.
  - zeven7 7y ago
    Could you expand on that a little? What do you mean? Won't my browser complain if the cert if self signed?
    - etatoby 7y ago
      Yes, it will complain and for good reason: it has no way of knowing whether the kid next door is spoofing your router's IP or Mac address and presenting their own self-signed certificate. I wouldn't go as far as calling it «capricious constraints imposed by the system of "certificate authorities"» but at the same time, I agree that it's not a fundamental limitation of the technology. Better protocols could be developed to allow a browser to trust a server without (all) the limitations of the current system.
      - therealjumbo 7y ago
        My harebrained idea for this: - let companies register a wild card domain in the .local (or a newlocal) namespace: .acme.local - designate the acme company with the ability to issue certs that never expire for any name in ".acme.local" but the browser will refuse to use certs signed with that key for anything outside "*.acme.local" pros: - the acme company can now make equipment that the users browser can connect to over an encrypted channel with zero config on the user's part - the equipment can live off the internet indefinitely - if the acme company is breached, and their signing key is stolen, the attackers can only use that key to impersonate acme company, it doesn't allow them to impersonate any other domains cons: - the browser manufacturers don't care about this use case so its never gonna happen - the cert on the device never expires... and can never be replaced automatically somehow. I think the only workaround is acme could enable users to load their own certs if they are so inclined, but that shouldn't be required.
      - thw0rted 7y ago
        You should only have to store the self-signed cert exception once, at least on a given device. Now, if you're being targeted by a state-sponsored actor they might somehow be able to get you onto a honeypot network within the 2-minute window between plugging in your router and making your first connection to its web interface, but for everybody else a self-signed cert that you accept once during initial setup should be plenty good enough.
geofft 7y ago
Why do they have to use self-signed certs? Ship the device with a valid cert for $last_three_octets_of_mac_address.$vendor.com to the device, and print it clearly on the setup instructions. Typing in something like d63d15.ui.com isn't onerous. The CA/Browser Forum allows certs up to 27 months - do routers sit on store shelves for 27 months before being configured? Do they even sit for 12 months? (Once they're online, they can renew their cert, possibly with the help of the vendor who can track the private key or something.)
- londons_explore 7y ago
  No need for even that. TLS should have an extension which says "I don't know how to verify my identity, but send this data to vendor.com and then they'll verify my identity". Vendor.com can then look at the opaque blob forwarded from their hardware and decide if they want to deligate trust to it.
  - geofft 7y ago
    That doesn't quite work, because the premise of accessing a router setup page is that your internet connection doesn't work yet. So your router has to be able to prove its identity to the client entirely offline. (You cannot special-case "This server is untraceable", else a repressive government could blackhole that server and trigger the relaxed validation rules.)
- jeroenhd 7y ago
  That would require significant effort for the vendor to set up and most internet devices such as routers are an absolutely minimal cost device. Literally every cent counts in production and vendors rather remove some features than shell out the 2 cents extra to add another 64mb of storage. Furthermore, this would require either not being able to change the IP for your device (bad) or sending information about the layout of your network to the vendor (I wouldn't trust them with that info). Very few people care about this and the effort of maintaining a custom DNS and a CA certificate system (which, by the way, would need to be subjected to rigorous security testing) just isn't worth it. Lastly, what's the point? Adding a little padlock isn't worth it if anyone can get a certificate for the router ip anyway. How do you ensure that the router connecting to your IP really has the mac address it claims? It only takes one person to get root on their router to invalidate the entire security system and given how somehow router vendors are still shipping command injection vulnerabilities, I wouldn't assume that they can prevent that as much as they'd like. What I want is the option to give a router my own security certificate instead of the self signed one. Let me use my own CA or let me mess around with letsencrypt, split-horizon DNS and Selenium scripts if that's what I need. Consumers don't care about TLS on their router and this would be the cheapest option to solve it for prosumers.

greggman2 7y ago

Found out there's a w3 working group trying to come up with solutions https://www.w3.org/community/httpslocal/ https://www.w3.org/community/httpslocal/