Hacker News Reader

Comment by ten7 | Hacker News Reader

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...

View on HN

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.

Reply on news.ycombinator.com