Don't use sshkeygen.com to generate keys!

diff --git a/2008-06-23-ssh-keygen.txt b/2008-06-23-ssh-keygen.txt
new file mode 100644 (file)
index 0000000..9e1be7e
--- /dev/null
+++ b/2008-06-23-ssh-keygen.txt
@@ -0,0 +1,70 @@
+Don't use sshkeygen.com to generate keys!
+
+<p>To my horror, I recently saw <a href="http://www.sshkeygen.com/">this
+online SSH key generator</a>.</p>
+
+<p>I hope nobody reading this needs to be told why this is a bad idea.
+However, in case you do, here are a few reasons:</p>
+
+<ul>
+ <li>
+  Every SSH implementation I know of - certainly all the major ones - that
+  support public key authentication also provide a key generation utility.
+  Even aside from all the good reasons not to, there is simply no reason why
+  you should need to use a web-based tool in the first place.
+ </li>
+ <li>
+  How can you trust the person running this site? Without implying that I
+  know he or she is untrustworthy (I don't), and with the best will in the
+  world, it's a big Internet with a lot of nasty people on it. Do you really want somebody you don't know in a position to keep a copy of all your
+  private keys?
+ </li>
+ <li>
+  Even if the person is trustworthy, the server running sshkeygen.com is now
+  a giant blinking target. If lots of people use it, there is every
+  incentive in the world for the bad guys to try to take control of it so
+  that they can keep a copy of all your private keys. (Or, as we know from
+  recent bitter experience, they can just give out keys from a limited set
+  and it will probably take a couple of years before anyone notices ...)
+ </li>
+ <li>
+  The front page of sshkeygen.com says that the keys are escrowed. The plain
+  English meaning of this would be that the operator of that site keeps a
+  copy of the private key, to be held in trust in case (presumably) you lose
+  it and need to retrieve it. Normally this sort of thing depends on a legal
+  trust relationship, perhaps linked to a contract. What does it mean here?
+  Is it just a buzzword? If it isn't, then this just makes sshkeygen.com
+  even more of a target.
+ </li>
+ <li>
+  sshkeygen.com delivers keys to you over unencrypted HTTP. Yes, this is on
+  its <a href="http://www.sshkeygen.com/about.php">to-do list</a>. That
+  isn't really an excuse.
+ </li>
+ <li>
+  Even if keys were delivered over HTTPS, that still relies on people
+  diligently checking the authenticity of the certificate. A self-signature
+  (as suggested as an alternative in the to-do list) would be impossible to
+  check with any reliability; and will people who have trouble with
+  non-web-based key generation software really be able or inclined to
+  confirm the signature chain? Browsers typically don't enforce this very
+  strictly, or if they do they provide fairly simple ways to bypass the
+  enforcement, simply because so many sites have broken or poorly-signed SSL
+  certificates, and keeping up with all the CAs is pretty hard work too.
+ </li>
+ <li>
+  Furthermore, delivering private keys over HTTPS makes that SSL certificate
+  a single giant blinking target. Might it be compromised? How would you
+  tell? What servers would need to be compromised in order to get a copy of
+  the private SSL key?
+ </li>
+ <li>
+  Sure, Debian is in an awkward position here given the recent OpenSSL
+  random number generation vulnerability. However, how do you know that
+  sshkeygen.com is running on a system that doesn't suffer from this?
+ </li>
+</ul>
+
+<p>I <em>think</em> this is probably being done in innocent seriousness
+(although I kind of hope it's a joke in poor taste), and have e-mailed the
+contact address offering to explain why it's a bad idea.</p>