Many months ago, I reported a vulnerability to Linksys/Cisco regarding the WRT54G. The vulnerability is simple: SSL is used to secure communications with the router. That is a good thing. However, SSL is not secure when you just implement part of it. SSL was implemented in a miserably insecure manner. All routers used the same certificate and private key. The certificate and private key were part of the software load. Thus, anyone who works at it a very small amount and who records the SSL entire session can decrypt it. The software writers are caught between a rock and a hard place in terms of how to implement certificates. Self signed certificates are at risk for MITM (Man In The Middle) attacks. Anyone can dynamically self sign a certificate and present it. Certificates that are signed by a well known certifying agency or even using a common signing certificate programmed into a browser (where the signing certificate's private key is properly protected) help prevent MITM attacks due to details of SSL. But you need a different certificate/key pair for every presenter, and you need to secure the key. Installing a different certificate signed by a well known certifying agency into each separate software load would require that EVERY different router have a unique software load. It might well also increase the cost of the router significantly. These routers are $49.99, quantity 1, through Amazon.com. The cost of a certificate would be a significant fraction of that amount. So you have three possibilities: 1. A common certificate. 2. Individual software loads. 3. dynamically built, randomly generated self-signed certificates. I was assured shortly after I reported this, that the newer versions of the router software would be changed to build a random private key and use a self-signed certificate. I have not installed the latest version of my software in my router, so I can't attest to this. They didn't answer my last few e-mails. Many people configure these routers by simply accessing a wired directly connected router using a browser. Arguably, it does not matter whether that initial encryption is secure or not, since the wire is arguably secure. If a random, self-signed certificate is used, then the certificate fingerprint can be recorded. If you then tell your browser to keep accepting that certificate, you should be notified if, later, a MITM attack is undertaken - the MITM attacker should present some other certificate. You should assume that if you are using ssl to access a router where the path to the router is in an adverse environment, and you are using a version of the software where a shared private key and shared certificate are used, that your communication might be intercepted and decoded. If you are using a randomly generated key, you should record the key fingerprint, either using a browser facility or manually, and then, when you contact the router, you should verify that you are using the same certificate. If these routers are used in an adverse environment, administrators might consider installing a different private key and certificate in each software load. In that case, the private key and associated certificate could be used with a single signing key and the browser used to access those routers could accept that signing key.
