Database of private SSL keys for embedded devices | Hacker News Reader

Database of private SSL keys for embedded devices

code.google.com

80 pointsbensummers19 comments

  select * from firmare
  [...]
  [4:08pm:~] RIDGELAND:tqbf [0:6]% pbpaste | egrep '[0-9]+\|[0-9]+\|[0-9]+' 
  | cut -d\| -f4-5 | cut -d\  -f1 | sort | uniq

Wireless access points.

I don't get why this post keeps getting up voted: it's mostly just a list of DD-WRT firmware, small percentage of the market most likely. And wouldn't that be the most likely candidate for the appropriate fix, i.e. uniquely generated Keys on each device, not preprogrammed, and a way to import your own?

Probably because it takes the 1.7 minutes required to download the stupid database, dump it, and sum it up for everyone else?

This is why I have my own CA. Too bad the router manufacturers don't do the same; let the router generate a key-signing request, paste it into the manufacturer's site (with a "real" SSL cert), download file suitable for providing to the router, enjoy secure VPN.

Oh yeah, but that would add like fifty cents to the cost of every $150 VPN router, and we can't have that!

Fifty cents and another ten dollars or more to deal with the extra tech support.

When you unpack and plug-in a router, it automatically gets the current time without any tech support. Why not get an SSL cert too?

That works, but unless the router manufacturer has a sub-CA of a CA present in all browsers, the above "extra tech support" is very true. And those sub-CAs are expensive.

Cisco can probably afford it.

But remember, we're only talking about SSL-based VPN boxes here. Joe Average does not buy these, and the people that do are willing to pay; handling more than one connection does require some not-tiny hardware. (I have a Soekris router, and Gigabit Ethernet makes pf max-out the CPU at around 300Mbps. OpenVPN... sooner. And this thing was $300. :)

Maybe it'd be a one time fee for somebody like Cisco that can afford the intermediate CA process, but I've looked into this for my own company and there's no way we can afford this. Nor is there any affordable option to prepurchase device certificates that I can find. If anybody actually has an idea on how to ship devices with unique certificates signed by a CA accepted by the majority of browsers, I'd love to hear it.

This would only allow you to sniff/MITM SSL connections made by/to the router itself, right? Not connections made by users of the router to servers on the Internet. What do these routers use SSL for, anyway? Update checks? Admin control panels?

I use SSL for my admin control panel. I don't know if it's really useful but I feel better :-)

Great article. So what's the fix? What should the right approach have been? Let's see a solution!

And yes, I read the blog post associated with it and didn't see a solution: http://www.devttys0.com/2010/12/breaking-ssl-on-embedded-dev...

The devices should've generated their keys (and provided a legit key import and cert generation function) once initialised at home instead of pre-generating them.

Of course, I'm waiting for the inevitable mashup with this and firesheep.

That would protect against passive attacks with known keys, but it would do little to stop MitM attacks, since your freshly-generated certs haven't been signed by a CA.

Is there a way to add a unit-specific salt to a cert?

That's why I'm suggesting a key import function. You have to balance security with an element of pragmatism. I appreciate it's not the optimal solution (you submit your FQDN for the IP, they verify and give you a free cert) but that's never going to happen. This is the next best thing. WPA2 it, dump your key in then enable HTTP and shut down HTTP, that seems to be the way forward (unless someone can tell me otherwise, but I have just come back from the pub)...

Well, in this particular case you could just use the "SSH model" - save the certificate in your browser the first time you access the admin control panel, and if it ever changes, you're being MITM'd.

The easy way (and I'm not saying it's the right way, because it's not, but it's probably the easiest way of getting it more right than it is now without getting it right if that makes sense) is to generate a self-signed cert on initialisation. Make everything needed available for import and alert on changes. A unit specific salt isn't necessarily the right way forward. What you want is to import the private key (generated and confirmed on setup) to import a certificate.

Good to see Hacker News living up to its name.

Mostly used for home vpns and router admin https it looks like. Also dd-wrt is fairly niche.

Reply on news.ycombinator.com