4 ms·

Industry-Wide HTTPS Certificate and SSH Key Reuse

19 points by pjf 11y ago

jamiesonbecker 11y ago
The worst part about this is that it's not even shocking. Even using something like https://Userify.com https://Userify.com (SSH key management) (disclaimer: CTO) can't help if you don't practice basic key management or publish your private key (client or host). It's easy to say "well, throw up a pfSense fw and done" but I can't tell my Dad to do that. Instead his router will probably get pwned and become part of some botnet. This is just the tip of the iceberg. What about obsolete devices? Do we really have to tell people to replace their devices (routers, phones, automobiles, drones?!) every few years? I'm against regulation in this space, but people need to get educated that security updates are required (forever?), or bad things will eventually happen. What's the answer here.. does it simply come down to a liability/lawsuit risk?
- dsr_ 11y ago
  No, go ahead and regulate it. Consumers should have the right to fitness for purpose and reasonable and foreseeable care. In this case, I would suggest that a manufacturer of a device with internet connectivity must prominently disclose an expected lifetime at the point of sale; and support the device for that lifetime, and notify all registered customers when a flaw is found, again when it is fixed, and finally when the device lifetime is ending. Your car shouldn't have internet access in the first place; it should have an access port that can talk to an internet connectivity device. Gigabit ethernet with PoE is a pretty good choice there, by the way. You'd think that people would demand clear interfaces for things like that, after going through the generations of aftermarket radios, cassette tape players, CD players, MP3-CD players, DVD players... and now we expect an AUX-in and, maybe, a Bluetooth receiver. Standardized interfaces are great.
patcheudor 11y ago
I think it's really easy to get excited about this and say it's bad, but we do need to consider the reality of the situation. Lets say these devices all do the perfect thing and when first fired up generate their very own device signed public / private key pair. So what? How does this make them more secure if the device cannot provide the public to the end-user so they can match it to the one they got in the SSH or HTTPS connection before they establish that connection? The problem here is a chicken or the egg one, plain and simple. You can't just ship root CAs on devices which will connect to other devices because you'd be distributing private keys on the device generating the certificate which could be used by a bad guy to make valid key material. As it stands with existing implementations, if the end users accepts the security warnings and connects to the device, a man in the middle can simply tamper with the encrypted traffic so that when they view the device cert, it's the one they see in the connection. This I'm afraid is the elephant in the room when it comes to device connectivity over protocols utilizing public / private key cryptography. Of course this problem can be solved, but I would propose that it wouldn't be cheap in many cases and doesn't really solve the problem. For devices with no display output the manufacturer could fire the device up on the product line and then obtain the public after it is generated. They could then print it out or save it to a USB drive and put it in the box with the device. Ultimately; however, the end user getting the device will have no idea what that paper or USB drive is and it will be promptly ignored anyway and browser or SSH security warnings will be accepted just as they are today. The assumption for all of these products should be that they are untrustworthy until made trustworthy, even if they are generating their own unique key material. With that in mind they should be configured on isolated, trusted networks until which point they are secured for environments which require this level of paranoia. The only way to make them secure is if they can generate unique key material or accept organizational key material and then the connections are validated before establishing encrypted communication with the devices. Ideally this means having an organizational PKI program that can issue certificates to devices which are then validated against an organizational root CA or exporting the device generated public and importing it into hosts which will be used to connect with the device. For NAT'd or firewalled networks this also necessitates local DNS. This I believe is the conversation we need to be having here. Are we in fact fooling ourselves on this one? As I look at the entire market of devices which implement HTTPS and SSH to connect to things like embedded web servers I don't see a solution which really allows anyone to secure anything unless you are in an organization with a solid PKI program and the device allows the use of organizational key material.

19 points by pjf 11y ago

The worst part about this is that it's not even shocking. Even using something like https://Userify.com https://Userify.com (SSH key management) (disclaimer: CTO) can't help if you don't practice basic key management or publish your private key (client or host). It's easy to say "well, throw up a pfSense fw and done" but I can't tell my Dad to do that. Instead his router will probably get pwned and become part of some botnet. This is just the tip of the iceberg. What about obsolete devices? Do we really have to tell people to replace their devices (routers, phones, automobiles, drones?!) every few years? I'm against regulation in this space, but people need to get educated that security updates are required (forever?), or bad things will eventually happen. What's the answer here.. does it simply come down to a liability/lawsuit risk?

dsr_ 11y ago
No, go ahead and regulate it. Consumers should have the right to fitness for purpose and reasonable and foreseeable care. In this case, I would suggest that a manufacturer of a device with internet connectivity must prominently disclose an expected lifetime at the point of sale; and support the device for that lifetime, and notify all registered customers when a flaw is found, again when it is fixed, and finally when the device lifetime is ending. Your car shouldn't have internet access in the first place; it should have an access port that can talk to an internet connectivity device. Gigabit ethernet with PoE is a pretty good choice there, by the way. You'd think that people would demand clear interfaces for things like that, after going through the generations of aftermarket radios, cassette tape players, CD players, MP3-CD players, DVD players... and now we expect an AUX-in and, maybe, a Bluetooth receiver. Standardized interfaces are great.

patcheudor 11y ago

I think it's really easy to get excited about this and say it's bad, but we do need to consider the reality of the situation. Lets say these devices all do the perfect thing and when first fired up generate their very own device signed public / private key pair. So what? How does this make them more secure if the device cannot provide the public to the end-user so they can match it to the one they got in the SSH or HTTPS connection before they establish that connection? The problem here is a chicken or the egg one, plain and simple. You can't just ship root CAs on devices which will connect to other devices because you'd be distributing private keys on the device generating the certificate which could be used by a bad guy to make valid key material. As it stands with existing implementations, if the end users accepts the security warnings and connects to the device, a man in the middle can simply tamper with the encrypted traffic so that when they view the device cert, it's the one they see in the connection. This I'm afraid is the elephant in the room when it comes to device connectivity over protocols utilizing public / private key cryptography. Of course this problem can be solved, but I would propose that it wouldn't be cheap in many cases and doesn't really solve the problem. For devices with no display output the manufacturer could fire the device up on the product line and then obtain the public after it is generated. They could then print it out or save it to a USB drive and put it in the box with the device. Ultimately; however, the end user getting the device will have no idea what that paper or USB drive is and it will be promptly ignored anyway and browser or SSH security warnings will be accepted just as they are today. The assumption for all of these products should be that they are untrustworthy until made trustworthy, even if they are generating their own unique key material. With that in mind they should be configured on isolated, trusted networks until which point they are secured for environments which require this level of paranoia. The only way to make them secure is if they can generate unique key material or accept organizational key material and then the connections are validated before establishing encrypted communication with the devices. Ideally this means having an organizational PKI program that can issue certificates to devices which are then validated against an organizational root CA or exporting the device generated public and importing it into hosts which will be used to connect with the device. For NAT'd or firewalled networks this also necessitates local DNS. This I believe is the conversation we need to be having here. Are we in fact fooling ourselves on this one? As I look at the entire market of devices which implement HTTPS and SSH to connect to things like embedded web servers I don't see a solution which really allows anyone to secure anything unless you are in an organization with a solid PKI program and the device allows the use of organizational key material.