| |||||||||||||
HOWTOs please!HOWTOs please!Posted May 13, 2008 21:09 UTC (Tue) by endecotp (guest, #36428)Parent article: Cryptographic weakness on Debian systems
Since the Debian page linked from the advisory is still empty, perhaps LWN readers can help with advice about how to fix this. Maybe a checklist? Installing the new version of openssl doesn't seem to do anything automatically. How do I cause ssh host keys to be regenerated, for example?
(Log in to post comments)
HOWTOs please! Posted May 13, 2008 21:21 UTC (Tue) by droundy (subscriber, #4559) [Link] I believe you can just call: ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key and in each case say yes to overwrite the existing key, and leave the passphrase blank. I may be wrong though, in which case I hope someone will correct me...
HOWTOs please! Posted May 13, 2008 22:00 UTC (Tue) by jch (guest, #51929) [Link]
The following information is provided with no guarantee, not even of any kind.
I did the following:
1. On every machine I have an account on (Debian or not), revoke my old personal keys:
$ rm ~/.ssh/authorized_keys
2. Update libssl on all my Debian machines:
# apt-get update
# apt-get install libssl0.9.8
3. Generate new host keys for ssh:
# rm /etc/ssh/ssh_host_*
# dpkg-reconfigure openssh-server
4. Regenerate my personal keys, as RSA this time:
$ rm ~/.ssh/id_*
$ ssh-keygen -t rsa
5. Update my authorized_keys throughout the universe (don't forget sourceforge and any Git
or Darcs repository you can push to).
6. Regenerate all my SSL certs (web servers, VPNs, IMAP servers, etc.).
Yes, it's a pain.
HOWTOs please! Posted May 13, 2008 22:28 UTC (Tue) by man_ls (subscriber, #15091) [Link] Great info, thanks!Although I don't understand step 3: "Generate new host keys for ssh". I'm purging my system of DSA keys, and I find that by default my systems identify using RSA keys (as seen in ~/.ssh/known_hosts). This part should be safe then. Why regenerate all host keys? This will only create a new set of (still insecure) DSA keys, which as it seems are not used anyway. Yes, this specific step 3 leads to a lot of work I'm too lazy to do: erasing all known_hosts files and recreating them. And this is on a small home LAN; on a big network I can imagine it must be a real pain.
HOWTOs please! Posted May 13, 2008 22:40 UTC (Tue) by joey (subscriber, #328) [Link] The new host keys won't be insecure if you've upgraded openssl before generating them. Tomorrow's version of openssh-server (in unstable) will automate the host key regeneration, as well as blocking authentication using weak keys, which will remove some of the pain if you can stand to wait 8 hours for it to reach the mirrors, and are running unstable. (I hope these enhancements will later be pushed into stable?) This document has fairly complete instructions BTW, until the official www.debian.org page goes up: http://wiki.debian.org/SSLkeys
HOWTOs please! Posted May 13, 2008 22:46 UTC (Tue) by dskoll (subscriber, #1630) [Link] If you do not regenerate your host keys, an attacker could pose as your host, leading to a man-in-the-middle attack. Obviously, you need to regenerate the host keys after upgrading OpenSSL!
HOWTOs please! Posted May 14, 2008 0:49 UTC (Wed) by nix (subscriber, #2304) [Link] What's wrong with DSA keys anyway?
HOWTOs please! Posted May 14, 2008 1:34 UTC (Wed) by bboissin (subscriber, #29506) [Link] > What's wrong with DSA keys anyway? Even if they aren't weak, they are compromised if they were used (the ssh client) in a affected system (debian, ubuntu). According to the DSA this is due to the fact that "Digital Signature Algorithm relies on a secret random value used during signature generation".
HOWTOs please! Posted May 14, 2008 11:12 UTC (Wed) by nix (subscriber, #2304) [Link] Well, yes, but that's true of just about any encryption system's keys. The whole point of them is that they're meant to be unpredictable (hence random). If the randomness is bad, so is the key, always.
HOWTOs please! Posted May 14, 2008 13:40 UTC (Wed) by tialaramex (subscriber, #21167) [Link] Presumably (please, someone who remembers how this actually works chime in!) Suppose you create two signing keys, R (using RSA) and D (using DSA) on your nice RHEL 4 machine It seems like Debian's security people are saying that if you copied these good keys to a Debian system, and then used them to sign documents, the R key is still fine but the D key is compromised by the signing process, due to it having poor entropy. That is, a sophisticated attacker (or a script kiddie with software developed by someone else) could use your old signatures generated on Debian systems to figure out your DSA private key. It's certainly true that DSA's signature method explicitly requires unique cryptographically secure random numbers for each message to be signed. But I don't know whether these numbers protect the DSA private key, or just the signature itself. If the former, then Debian's advisory is correct. If we don't know, then we must act as if it is correct and invalidate the affected keys. Although DSA and RSA often appear interchangeable to us as end users, they are quite different in terms of their mathematical properties, so it could easily be true that this problem affects only DSA.
Re: DSA vs RSA Posted May 15, 2008 10:21 UTC (Thu) by ldo (subscriber, #40946) [Link] As I remember, DSA was invented back when the US government was trying to restrict the use of strong cryptography. The key thing about it was that it was supposedly usable only for digital signatures, not for encryption. This was later proven to be false. And yet people still use DSA today. So why bother any more? Why not just stick with RSA for both encryption and signing? Isn't this compromise a reason to stop using DSA altogether?
HOWTOs please! Posted May 14, 2008 10:24 UTC (Wed) by furball4 (guest, #52069) [Link] I updated openssl as soon as it was available and then ran ssh-keygen to replace /root/.ssh/id_rsa and /root/.ssh/id_rsa.pub. But that was before an ssh update was available. Was key creation fixed at this point, or are my new keys still potentially vulnerable? They are not flagged by the now-available ssh-vulnkey, but that won't necessarily catch everything. I also regenerated some SSL certificates, but since that is actually using the openssl command-line interface it would obviously have been fixed by that point. In any event, I need to figure out if I have to back and redo personal keys again. Additionally, the new ssh packages don't give me an option to regenerate host keys, as the email seemed allude to. I had to do that by hand.
HOWTOs please! Posted May 14, 2008 10:41 UTC (Wed) by endecotp (guest, #36428) [Link] I think you're OK. The new ssh packages primarily include stuff to check for (and reject?) vulnerable keys. The old ssh code itself did not have any problems.
HOWTOs please! Posted May 14, 2008 16:09 UTC (Wed) by furball4 (guest, #52069) [Link] Thanks. I also noticed that the new package did regenerate host keys when the existing ones ran afoul of the vulnerable key checker. I would have preferred if it had an option to regenerate them anyway, but oh well, it's easy enough to do by hand.
|
|||||||||||||