|
|
About
Colin Watson's blog
cjwatson@debian.org
Subscribe
Subscribe to a syndicated feed of my blog.
Flavours
Powered by Blosxom
|
|
|
Don't use sshkeygen.com to generate keys!
To my horror, I recently saw this
online SSH key generator.
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:
-
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.
-
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?
-
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 ...)
-
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.
-
sshkeygen.com delivers keys to you over unencrypted HTTP. Yes, this is on
its to-do list. That
isn't really an excuse.
-
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.
-
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?
-
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? (As it
happens, I have checked, and it doesn't appear to suffer from this
vulnerability - but most people won't check and won't know how to check.)
I think 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.
[]
permanent link
|
|