In [http://www.debian.org/security/2008/dsa-1571 Debian Security Advisory 1571] (New openssl packages fix predictable random number generator), the Debian Security Team disclosed a vulnerability in the openssl package that makes many cryptographic keys that are used for authentication (e.g. through SSH) or signing (e.g. web server certificates) potentially vulnerable.

End User Summary

The scope of the problem includes:

The following cryptographic tools are unaffected:

Identifying Weak Keys

Characteristics of potentially vulnerable keys:

Additionally, some DSA keys may be compromised in the following situations:

Applications/protocols known to use these keys:

To fix this, first aptitude update && aptitude upgrade to install the new version of the openssl package (the vulnerability is fixed in openssl version 0.9.8c-4etch3 for etch and version 0.9.8g-9 for lenny/sid).

Then, regenerate and distribute any potentially vulnerable keys. Instructions for how to regenerate the keys for these applications are below. You can also test to see if keys are vulnerable using the dowkd.pl utility as described below.

OpenSSH (Server)

{{{ rm /etc/ssh/ssh_host_* dpkg-reconfigure openssh-server}}} Note that your users will see a "IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!" warning when they next log on to your ssh server because the key has changed. They will need to edit $HOME/.ssh/known_hosts to remove the offending line before continuing; checking that the key fingerprint is correct, of course (the fingerprint of your new key can be found with ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key). You can remove the key from known_hosts by running "ssh-keygen -R hostname"

Also, note that your existing ssh connections shouldn't be interrupted.

OpenSSH (Client)

You will need to have a list of the openssh keys that you currently have and where they have been copied to. For each key that is vulnerable: {{{ cd ~/.ssh ssh-keygen -t rsa -f filename ssh-copy-id -i filename hostname }}} Replacing rsa by dsa if you prefer dsa keys and replacing filename and hostname with appropriate values.

Generic PEM Generation

This is just a reminder for those who generate PEM encoded certificates. Your site probably has other policies in place about how to manage keys which you should follow. Additionally, you may need to get the certificates signed again by a 3rd party Certificate Authority rather than by using a self-signed certificate as shown below:

cd /etc/ssl/private
openssl genrsa 1024 > mysite.pem
cd /etc/ssl/certs
openssl req -new -key ../private/mysite.pem -x509 -days 9999 -out mysite.pem

OpenVPN

BIND9

dovecot

Generate a new PEM as shown in "Generic PEM Generation" above (making sure that it is placed in the correct place according to your dovecot configuration, then restart dovecot:  invoke-rc.d dovecot restart .

postfix

Generate a new PEM as shown in "Generic PEM Generation" above (making sure that it is placed in the correct place according to your postfix configuration, then restart postfix:  invoke-rc.d postfix restart .

cyrus imapd

Apache2 SSL

Testing keys using dowkd.pl

The security team has prepared a utility for you to test your keys to see if they have a fingerprint that matches a list of known-weak finger prints. Download [http://security.debian.org/project/extra/dowkd/dowkd.pl.gz dowkd.pl.gz ] ([http://security.debian.org/project/extra/dowkd/dowkd.pl.gz.asc gpg signature]):

{{{cd /tmp wget http://security.debian.org/project/extra/dowkd/dowkd.pl.gz wget http://security.debian.org/project/extra/dowkd/dowkd.pl.gz.asc gpg --verify dowkd.pl.gz.asc gunzip dowkd.pl.gz }}}

/!\ Note that dowkd.pl produces many false positives and that the authors suggest that it may also produce false negatives. On that basis, you might decide that it is simply easier to regenerate your keys as described above.

Use dowkd.pl in the following ways:

SSH Server Host Key

Key is OK:

{{{ perl dowkd.pl host localhost # localhost SSH-2.0-OpenSSH_4.3p2 Debian-9 # localhost SSH-2.0-OpenSSH_4.3p2 Debian-9 }}}

Key is weak: {{{ perl dowkd.pl host localhost # localhost SSH-2.0-OpenSSH_4.3p2 Debian-9 # localhost SSH-2.0-OpenSSH_4.3p2 Debian-9 localhost: weak key localhost: weak key }}}

SSH User Key

To check one user (username):

perl dowkd.pl user username
/home/username/.ssh/authorized_keys:1: warning: unparsable line
/home/username/.ssh/authorized_keys:3: warning: unparsable line
/home/username/.ssh/authorized_keys:4: weak key
/home/username/.ssh/authorized_keys:5: weak key

Notes:

Other keys?

The tool is unable to parse PEM files at present.

Technical Summary

(If you want to add more technical details that an end-user doesn't need to know or isn't likely to understand, please add them here rather than making the above summary impossible for the average user to understand.)

Causes

It is important to understand that this problem was caused by trying to remove valgrind warnings related to the use of uninitialised memory within the openssl libraries. This was done to try to make it easier to debug C applications that use the openssl libraries which is a good thing to do.

A discussion of why this change was made can be found at [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 #363516] and also on the [http://marc.info/?t=114651088900003&r=1&w=2 openssl-dev list] although it appears that a certain [http://www.links.org/?p=327 revisionist attitude] is being held with regards to that conversation.

Acknowledgements

This document was put together by the folks on [wiki:DebianIRC #debian] to help with user support. It would have been nice to have had the chance to prepare this (and the key rollover page) in the 5 days between the commit being made to pkg-openssl and the DSA being released. Particular credit to themill, dondelelcaro, stew, Maulklin, iobound for reading, writing and suggesting bits for this page.