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/
signature.asc
Description: This is a digitally signed message part.
