[Pkg-openssl-devel] [SECURITY] [DSA 1571-1] New openssl packages fix predictable random number generator

[Rene Mayrhofer]

On Dienstag, 13. Mai 2008, Vincent Bernat wrote:
>  - As a  maintainer of a package that  have generated certificates using
>    OpenSSL, how should we handle the issue?
I'm in the same situation (maintaining openswan and strongswan, and both 
packages may automatically create X.509 certificates in postinst).

> For the last question, I see several solutions:
>  - an helper package  will be provided and each  package should register
>    key  locations (in  a bug  report against  the package  for example);
>    those keys  will be checked  and the user  will be warned  about weak
>    keys.  Moreover, each  package  will generate  a  short help  message
>    explaining  how  to regenerate  keys.  This  helper  package will  be
>    shipped in security and uploaded with a libssl depending on it
I agree that this would be the best (i.e. quickest) solution to the problem. 
The updated libssl should pull in a "fixer" package that can recognize broken 
keys and - based on debconf questions - automatically re-create these keys, 
warning the user of potential breakage (i.e. the need to redistribute the new 
public key).

This whole issue is _very_ bad for Debian, so we need to make it as simple and 
painless as possible to fix it on individual machines.

For reference, openswan and strongswan can re-create their automatically 
generated keys with (if these files exist, as there are other ways of 
authentication as well):

rm /etc/ipsec.d/private/`hostname`Key.pem /etc/ipsec.d/certs/`hostname`Cert.pem
dpkg-reconfigure (open|strong)swan
/etc/init.d/ipsec restart

(where the last command terminates currently open IPSec connections, which may 
need to be restarted from the other end...).

This seems similar enough to how openssh-server, as suggested by Dererk:

rm /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server
/etc/init.d/ssh restart

(where the last command should not influence currently open SSH connections).

Each package that auto-generates keypairs with libssl should provide commands 
like these along with a short description of how this re-creation affects 
users. The detection script should of course be called before automatically 
removing weak keys - but if and only if it is 100% accurate in identifying 
them!

The same detection script should also be run on all known key locations where 
user-generated keys may be stored. For open/strongswan, the respective 
directories are /etc/ipsec.d/private, /etc/ipsec.d/certs, 
and /etc/ipsec.d/cacerts, similar to the openssl 
directories /etc/ssl/private, /etc/ssl/certs, and /etc/ssl/cacerts (the 
latter may not exist). open/strongswan may also use /etc/ipsec.d/*certs, but 
not automatically based on maintainer scripts. Other packages will most 
certainly also have well-known directories that may contain user-generated 
keys (such as ~/.ssh/).

Who is currently responsible for updating the (currently empty) 
http://www.debian.org/security/key-rollover/? Please add these instructions 
for openssh and (open|strong)swan as soon as possible. 
http://www.ubuntu.com/usn/usn-612-2 contains a nice text which may be used as 
the basis for how to deal with openssh keys.

Maybe I haven't understood the DSA correctly, but is it currently known if 
both private/public and secret keys are affected, and which schemes (DH, RSA, 
DSA, EC, etc.)? If even DH is affected, then e.g. also ZRTP and other key 
continuity based approaches may also need to discard their broken key 
material. More details would help in determining the potential effects of 
this serious vulnerability and in decreasing breakage due to rollover. I.e. 
the detection script should be as specific as possible. Re-creating keys can 
be a great pain for users, and we should therefore be careful not to discard 
good keys. However, the priority must be on replacing _all_ broken ones, in 
favor of discarding a few good ones.

PS: Unfortunately, I'll be off to a conference on the other side of the world 
by tomorrow morning, so I won't have any connectivity in the next roughly 3 
days and thus can't help with fixing open/strongswan keys at the moment. I 
hope the text above contains everything necessary to create a "fixer" package 
and ship it with the libssl update via security.

best regards,
Rene

-- 
-------------------------------------------------
Gibraltar firewall       http://www.gibraltar.at/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/pkg-openssl-devel/attachments/20080514/4cebfedc/attachment-0001.pgp