
Industry-Wide HTTPS Certificate and SSH Key Reuse - pjf
http://blog.sec-consult.com/2015/11/house-of-keys-industry-wide-https.html
======
jamiesonbecker
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_
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
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.

