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?
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!
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.
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?
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?
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.
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.
Wireless access points.