[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
security/key-rollover/index.wml
小林です。
かねこさんからいただいた訳をベースに翻訳しました。
チェックをお願いいたします。
# かねこさんのときのリビジョンは 1.16 だったのですが、様々なソフトウェ
# アに関する記述が追加されてもう 1.33 になっています……。
--
|: Noritada KOBAYASHI
|: Dept. of General Systems Studies,
|: Graduate School of Arts and Sciences, Univ. of Tokyo
|: E-mail: nori1@xxxxxxxxxxxxxxxxxxxxxxx (preferable)
|: nori@xxxxxxxxxxxxxxxxxxx
|: Key fingerprint = AB26 9533 81DA 997B 3C06 4380 19BB ADA0 695C 9F53
#use wml::debian::template title="Key Rollover"
<p>
In <a href="$(HOME)/security/2008/dsa-1571">Debian Security Advisory 1571</a>,
the Debian Security Team disclosed a weakness in the random number generator used
by OpenSSL on Debian and its derivatives. As a result of this weakness,
certain encryption keys are much more common than they should be, such that an
attacker could guess the key through a brute-force attack given minimal knowledge
of the system. This particularly affects the use of encryption keys in OpenSSH,
OpenVPN and SSL certificates.
</p>
<p>
This page documents how to perform key rollover procedures for packages
whose keys are affected by the OpenSSL vulnerability.
</p>
<ul>
<li><b><a href="#openssh">OpenSSH</a></b>
<li><b><a href="#openssl">OpenSSL: Generic PEM key generation instructions</a></b>
<li><a href="#bincimap">bincimap</a>
<li><a href="#boxbackup">boxbackup</a>
<li><a href="#cryptsetup">cryptsetup</a>
<li><a href="#dropbear">dropbear</a>
<li><a href="#ftpd-ssl">ftpd-ssl</a>
<li><a href="#gforge">gforge</a>
<li><a href="#kerberos">MIT Kerberos (krb5)</a>
<li><a href="#openswan">OpenSWAN / StrongSWAN</a>
<li><a href="#openvpn">OpenVPN</a>
<li><a href="#puppet">puppet</a>
<li><a href="#sendmail">sendmail</a>
<li><a href="#ssl-cert">ssl-cert</a>
<li><a href="#telnetd-ssl">telnetd-ssl</a>
<li><a href="#tinc">tinc</a>
<li><a href="#tor">tor</a>
<li><a href="#xrdp">xrdp</a>
</ul>
<p>
Other software uses cryptographic keys, but is
<a href="notvuln">not vulnerable</a> as OpenSSL is not used to generate
or exchange its keys.
</p>
<ul>
<li><a href="notvuln#ckermit">ckermit</a>
<li><a href="notvuln#gnupg">GnuPG</a>
<li><a href="notvuln#iceweasel">Iceweasel</a>
<li><a href="notvuln#mysql">MySQL</a>
</ul>
<p>
For key rollover instructions for other software, you might want to check
the user-submitted information in <url http://wiki.debian.org/SSLkeys>
</p>
<h1><a name="openssh">OpenSSH</a></h1>
<p>
An updated package has been released via
<a href="$(HOME)/security/2008/dsa-1576">DSA-1576</a>, which eases key transformation.
</p>
<p>1. Install the security updates in DSA-1576</p>
<p>Once the update is applied, weak user keys will be automatically
rejected where possible (though they cannot be detected in all
cases). If you are using such keys for user authentication, they
will immediately stop working and will need to be replaced (see
step 3).</p>
<p>OpenSSH host keys can be automatically regenerated when the OpenSSH
security update is applied. The update will prompt for confirmation
before taking this step.</p>
<p>2. Update OpenSSH known_hosts files</p>
<p>The regeneration of host keys will cause a warning to be displayed when
connecting to the system using SSH until the host key is updated in the
known_hosts file on the client. The warning will look like this:</p>
<pre>
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
</pre>
<p>In this case, the host key has simply been changed, and you should update
the relevant known_hosts file as indicated in the warning message.
It is recommended that you use a trustworthy channel to exchange the
server key. It is found in the file /etc/ssh/ssh_host_rsa_key.pub on
the server; it's fingerprint can be printed using the command:</p>
<p>ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub</p>
<p>In addition to user-specific known_hosts files, there may be a
system-wide file /etc/ssh/known_hosts. This file is
used both by the ssh client and by sshd for the hosts.equiv
functionality. This file needs to be updated as well.</p>
<p>3. Check all OpenSSH user keys</p>
<p>The safest course of action is to regenerate all OpenSSH user keys,
except where it can be established to a sufficient high degree of certainty that the
key was generated on an unaffected system.</p>
<p>Check whether your key is affected by running the ssh-vulnkey tool, included
in the security update. By default, ssh-vulnkey will check the standard
location for user keys (~/.ssh/id_rsa, ~/.ssh/id_dsa and ~/.ssh/identity),
your authorized_keys file (~/.ssh/authorized_keys and
~/.ssh/authorized_keys2), and the system's host keys
(/etc/ssh/ssh_host_dsa_key and /etc/ssh/ssh_host_rsa_key).</p>
<p>To check all your own keys, assuming they are in the standard
locations (~/.ssh/id_rsa, ~/.ssh/id_dsa, or ~/.ssh/identity):</p>
<p>ssh-vulnkey</p>
<p>To check all keys on your system:</p>
<p>sudo ssh-vulnkey -a</p>
<p>To check a key in a non-standard location:</p>
<p>ssh-vulnkey /path/to/key</p>
<p>If ssh-vulnkey says <q>Unknown (no blacklist information)</q>, then it has no
information about whether that key is affected. If in doubt, destroy the
key and generate a new one.
</p>
<p>4. Regenerate any affected user keys</p>
<p>OpenSSH keys used for user authentication must be manually regenerated,
including those which may have been transferred to a different system
after being generated.</p>
<p>New keys can be generated using ssh-keygen, e.g.:</p>
<pre>
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 user@host
</pre>
<p>5. Update authorized_keys files (if necessary)</p>
<p>Once the user keys have been regenerated, the relevant public keys
must be propagated to any authorized_keys files (and authorized_keys2
files, if applicable) on remote systems. Be sure to delete the
affected key.</p>
<h1><a name="openssl">OpenSSL: Generic PEM key generation instructions</a></h1>
<p>
This is just a reminder for those who (re-)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:
</p>
<pre>
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
</pre>
<h1><a name="bincimap">bincimap</a></h1>
<p>
The bincimap package automatically creates a self-signed certificate
through the openssl program for the bincimap-ssl service, and puts it
into /etc/ssl/certs/imapd.pem. To regenerate, run:
</p>
<pre>
rm -f /etc/ssl/certs/imapd.pem
dpkg-reconfigure bincimap
</pre>
<h1><a name="boxbackup">boxbackup</a></h1>
<p>
Boxbackup is not present in Debian stable, only in testing/Lenny.
</p>
<p>
Upstream has published a first impact analysis of key material created
on system with insufficient random PRNG. You can read the details
<a href="http://lists.warhead.org.uk/pipermail/boxbackup/2008-May/004476.html";>here</a>.
</p>
<p>
If the PRNG in your OpenSSL was insufficiently random, you need to:
</p>
<ul>
<li>Regenerate all affected certificates, which have been generated or
signed on an affected system</li>
<li>Regenerate all the data keys (*-FileEncKeys.raw)</li>
<li>Destroy the data stored on your server to an appropriate level of
security (overwrite with zeros at the least, more if you're paranoid)</li>
<li>Upload everything again</li>
<li>Take appropriate measures under the assumption that you have been
storing your data in plain text on a public server without authentication.
(ie, start from scratch, destroying all trace of the backed up
data, and take other measures to mitigate the exposure of your
secrets)</li>
</ul>
<h1><a name="cryptsetup">cryptsetup</a></h1>
<p>
Cryptsetup itself does not use openssl for encryption (this applies to
both LUKS and dm-crypt devices).
</p>
<p>
<em>If</em> cryptsetup has been configured to use SSL-encrypted keyfiles (a
non-default setup which must be explicitly configured by the user)
and a broken version of openssl was used to generate the keyfile, the
keyfile encryption may be weaker than expected (as the salt is not
truly random).
</p>
<p>
The solution is either to re-encrypt the keyfile (if you are
reasonably certain that the encrypted key has not been disclosed to
any third parties) or to wipe and reinstall the affected partition(s)
using a new key.
</p>
<p>
Instructions for re-encrypting a keyfile:
</p>
<p>
Do the following for each SSL-encrypted keyfile, replacing
<ssl_encrypted_key_path> with the path to the actual keyfile:
</p>
<pre>
tmpkey=\$(tempfile)
openssl enc -aes-256-cbc -d -salt -in <ssl_encrypted_key_path> -out "$tmpkey"
shred -uz <ssl_encrypted_key_path>
openssl enc -aes-256-cbc -e -salt -in "$tmpkey" -out <ssl_encrypted_key_path>
shred -uz "$tmpkey"
</pre>
<h1><a name="dropbear">dropbear</a></h1>
<p>
If you have /etc/ssh/*host* keys, either remove them, or follow the
<a href="#openssh">openssh instructions</a> first, before updating dropbear's
keys.
</p>
<p>
Dropbear's postinst converts existing openssh keys to dropbear format,
if it cannot find the dropbear host keys.
</p>
<pre>
rm /etc/dropbear/*_host_key
dpkg-reconfigure dropbear
</pre>
<p>
Note that keys that have been generated by Dropbear itself are not
vulnerable (it uses libtomcrypt rather than OpenSSL).
</p>
<h1><a name="ftpd-ssl">ftpd-ssl</a></h1>
<pre>
rm -f /etc/ftpd-ssl/ftpd.pem /etc/ssl/certs/ftpd.pem
dpkg-reconfigure ftpd-ssl
</pre>
<p>
this covers the default setup. if the local admin has setup further
ssl infrastructure beyond that, these keys will need to be regenerated
as well.
</p>
<h1><a name="gforge">gforge</a></h1>
<p>
The gforge-web-apache2 package in sid and lenny sets up the website
with a dummy certificate if no existing certificate is found. Users are then
encouraged to replace it with a "real" one. The dummy certificate in
question is the Snake Oil one, so it should already be known as a weak
one (even without the SSL bug), but some users may accept
it without a second thought.
</p>
<h1><a name="kerberos">MIT Kerberos (krb5)</a></h1>
<p>
No part of MIT Kerberos in Debian 4.0 ("Etch") uses OpenSSL, and so Kerberos
in Debian 4.0 is not affected at all.
</p>
<p>
In Lenny the separate binary package krb5-pkinit uses OpenSSL. MIT
Kerberos itself does not generate long-term key pairs even when the PKINIT
plugin is used, so any vulnerable long-term key pairs would have been
generated outside of the MIT Kerberos software itself. The PKINIT plugin
only references existing key pairs and isn't responsible for key
management.
</p>
<p>
Long-term key pairs used with PKINIT may be affected if generated on an
affected Debian system, but such generation is external to MIT Kerberos.
</p>
<p>
However, the OpenSSL random key functions are used for the DH exchange
when PKINIT authentication is used, which means that an attacker may be
able to use brute-force to gain access to the KDC response to a PKINIT
authentication and subsequently gain access to any sessions created using
service tickets from that authentication.
</p>
<p>
Any KDCs using the PKINIT plugin from Lenny should have their libssl0.9.8
packages upgraded immediately and the Kerberos KDC restarted with:
</p>
<pre>
/etc/init.d/krb5-kdc restart
</pre>
<p>
Any Kerberos ticket-granting tickets (TGTs) or encrypted sessions resulting
from PKINIT authentication using a Kerberos KDC with the affected libssl
should be treated as suspect; it's possible that attackers with packet
captures will be able to compromise those keys and sessions.
</p>
<h1><a name="openswan">OpenSWAN / StrongSWAN</a></h1>
<pre>
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
</pre>
<p>
Beware: Restarting the ipsec services terminates all currently open IPSec
connections, which may need to be restarted from the other end.
</p>
<h1><a name="openvpn">OpenVPN</a></h1>
<p>
Backup your secret key files. While key names are arbitrary, they can
be detected by running
</p>
<pre>grep secret /etc/openvpn/*.conf</pre>
<p>
Recreate them using
</p>
<pre>openvpn --genkey --secret SECRET_FILENAME</pre>
<p>
Then copy the shared secret keys to the remote hosts and restart the VPN
on each host with
</p>
<pre>/etc/init.d/openvpn force-reload</pre>
<h1><a name="puppet">puppet</a></h1>
<p>
There are two methods to handle puppet certificates, one is via capistrano,
the second is manually.
</p>
<p>
Regenerating Puppet SSL Certificates using capistrano is detailed here:
<a href="http://reductivelabs.com/trac/puppet/wiki/RegenerateSSL";>http://reductivelabs.com/trac/puppet/wiki/RegenerateSSL</a>
</p>
<p>
The manual steps are as follows:
</p>
<ol>
<li>You need to wipe and regenerate your CA info:
<pre>
/etc/init.d/puppetmaster stop
rm $vardir/ssl/*
/etc/init.d/puppetmaster start
</pre>
<p>
However, if you are running mongrel, instead of starting puppetmaster from
the init script, you will need to first stop the front-end web listener
(apache, nginx, etc.) and then do the following:
</p>
<pre>
puppetmasterd --daemonize ; sleep 30 ; pkill -f 'ruby /usr/sbin/puppetmasterd'
</pre>
<p>
The above is necessary because for some reason when running with mongrel,
puppetmaster will not regenerate its CA.
</p>
</li>
<li>Wipe all the client certs
<pre>
/etc/init.d/puppet stop
rm $vardir/ssl/*
</pre>
</li>
<li>Have each client request a new cert:
<pre>
puppetd --onetime --debug --ignorecache --no-daemonize
</pre>
</li>
<li>Once all the requests have rolled in, you can sign them all at once:
<pre>
puppetca --sign --all
</pre>
</li>
<li>Start up your puppet clients:
<pre>
/etc/init.d/puppet start
</pre>
</li>
</ol>
<p>
You could also enable autosign temporarily, if you are comfortable with that.
</p>
<h1><a name="sendmail">sendmail</a></h1>
<p>
Sendmail (both in Etch and in Lenny) optionally creates default OpenSSL
certificates at install time.
</p>
<p>
The key rollover procedure is trivial:
</p>
<pre>
/usr/share/sendmail/update_tls new
</pre>
<p>
If you have customized the templates in /etc/mail/tls, those
values will be re-used to create the new certificates.
</p>
<h1><a name="ssl-cert">ssl-cert</a></h1>
<p>
The snakeoil certificate /etc/ssl/certs/ssl-cert-snakeoil.pem can be
recreated with:
</p>
<pre>make-ssl-cert generate-default-snakeoil --force-overwrite</pre>
<h1><a name="telnetd-ssl">telnetd-ssl</a></h1>
<pre>
rm -f /etc/telnetd-ssl/telnetd.pem /etc/ssl/certs/telnetd.pem
dpkg-reconfigure telnetd-ssl
</pre>
<p>
This covers the default setup. If the local admin has setup further
SSL infrastructure beyond that, these keys will need to be regenerated
as well.
</p>
<h1><a name="tinc">tinc</a></h1>
<p>
Remove all suspect public and private key files:
</p>
<ol>
<li>Remove rsa_key.priv.</li>
<li>Edit all files in the hosts/ directory and remove the public key blocks.</li>
</ol>
<p>
Generate a new public/private key pair:
</p>
<pre>
tincd -n <netname> -K
</pre>
<p>
Exchange your host config file with the new public key with other
members of your VPN. Do not forget to restart your tinc daemons.
</p>
<h1><a name="tor">tor</a></h1>
<p>
Tor is not in stable, but affected in Lenny.
</p>
<p>
Clients running 0.1.2.x are not affected. Tor nodes or hidden service
providers running any version, as well as everyone on 0.2.0.x are
affected.
</p>
<p>
Please see the
<a href="http://archives.seul.org/or/announce/May-2008/msg00000.html";>vulnerability
announcement</a> on the Tor announce mailing list.
</p>
<p>
Upgrading to 0.1.2.19-3 (available in testing, unstable, backports.org, and
the usual <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorOnDebian";>noreply.org
repository</a>) or 0.2.0.26-rc-1 (available in experimental and the usual <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorOnDebian";>noreply.org
repository</a>) is recommended. If you run a relay these versions will force
new server keys (/var/lib/tor/keys/secret_*) to be generated.
</p>
<p>
Should you run a Tor node without using the package's infrastructure
(debian-tor user, /var/lib/tor as DataDirectory etc.) you manually need
to remove bad keys. See the advisory link posted above.
</p>
<p>
If you are hidden service provider, and have created your key in
the affected timeframe with a bad libssl then please delete your hidden
service's private key. This will change your hidden service's host name
and may require reconfiguring your servers.
</p>
<p>
If you are running 0.2.0.x, an upgrade is highly recommended -- 3 of the
6 v3 authority servers have compromised keys. Old 0.2.0.x versions
will stop working in a week or two.
</p>
<h1><a name="xrdp">xrdp</a></h1>
<p>
xrdp uses generated keys. Most clients do not check those keys by
default, therefore changing them is painless. You just have to:
</p>
<pre>
rm /etc/xrdp/rsakeys.ini
/etc/init.d/xrdp restart
</pre>
<p>
xrdp is not in stable.
</p>
#use wml::debian::template title="鍵のロールオーバー"
#use wml::debian::translation-check translation="1.33"
<p>
<a href="$(HOME)/security/2008/dsa-1571">Debian セキュリティ勧告 1571</a>
で、Debian セキュリティチームは、Debian およびその派生ディストリビューションの OpenSSL
で使用されている乱数生成器の欠陥を修正しました。この欠陥によって、一部の暗号鍵は、
本来あるべき姿よりも遥かに一般的なものとなってしまっているため、攻撃者は、
システムに関するごくわずかな知識を持っていれば、
総当たり攻撃を通じて鍵を推測できてしまう可能性があります。この問題は、
特に OpenSSH、OpenVPN、SSL 証明書の使用に影響します。
</p>
<p>
このページの文書は、鍵の総交換 (ロールオーバー) の手順を、OpenSSL
の欠陥に影響される鍵を持つ各パッケージ別に示したものです。
</p>
<ul>
<li><b><a href="#openssh">OpenSSH</a></b>
<li><b><a href="#openssl">OpenSSL: 一般的な PEM 鍵生成手順の説明</a></b>
<li><a href="#bincimap">bincimap</a>
<li><a href="#boxbackup">boxbackup</a>
<li><a href="#cryptsetup">cryptsetup</a>
<li><a href="#dropbear">dropbear</a>
<li><a href="#ftpd-ssl">ftpd-ssl</a>
<li><a href="#gforge">gforge</a>
<li><a href="#kerberos">MIT Kerberos (krb5)</a>
<li><a href="#openswan">OpenSWAN / StrongSWAN</a>
<li><a href="#openvpn">OpenVPN</a>
<li><a href="#puppet">puppet</a>
<li><a href="#sendmail">sendmail</a>
<li><a href="#ssl-cert">ssl-cert</a>
<li><a href="#telnetd-ssl">telnetd-ssl</a>
<li><a href="#tinc">tinc</a>
<li><a href="#tor">tor</a>
<li><a href="#xrdp">xrdp</a>
</ul>
<p>
他のソフトウェアも暗号鍵を用いますが、鍵生成や交換に OpenSSL を使っていないため
<a href="notvuln">欠陥はありません</a>。
</p>
<ul>
<li><a href="notvuln#ckermit">ckermit</a>
<li><a href="notvuln#gnupg">GnuPG</a>
<li><a href="notvuln#iceweasel">Iceweasel</a>
<li><a href="notvuln#mysql">MySQL</a>
</ul>
<p>
これ以外のソフトウェアでのキーロールオーバの手順については、ユーザからの情報
<url http://wiki.debian.org/SSLkeys> が参考になります。
</p>
<h1><a name="openssh">OpenSSH</a></h1>
<p>
更新版のパッケージが <a href="$(HOME)/security/2008/dsa-1576">DSA-1576</a>
を通じてリリースされており、鍵の変換が楽になっています。
</p>
<p>1. DSA-1576 のセキュリティ更新をインストールする</p>
<p>更新の適用が終わったならば、可能な場合には脆弱なユーザ鍵は自動的に拒絶されます。
但し全部の検出は行えません。ユーザの個人認証にこのような鍵を使っている場合は、鍵は
直後に動作しなくなり、新しい鍵で更新しなければならなくなります
(手順 3 参照)。</p>
<p>OpenSSH ホスト鍵は、OpenSSH セキュリティ更新を適用後自動的に再作成さ
れます。更新時には、この処理の前にユーザへの確認問い合わせが行われま
す。</p>
<p>2. OpenSSH known_hosts ファイルを更新する</p>
<p>ホスト鍵を再生成した場合、SSH を使っているシステムに接続の際、
known_hosts のホスト鍵の更新がすんでいない場合には以下の警告画面が表示されます</p>
<pre>
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
</pre>
<p>この場合、実際にホスト鍵が変更されているので、警告メッセージにあるよ
うに対象の known_hosts を更新する必要があります。
サーバ鍵の交換には、信用できる通信路を使用することを勧めます。鍵はサ
ーバ上の /etc/ssh/ssh_host_rsa_key.pub に置かれます。鍵のフィンガー
プリントは以下のコマンドで見ることができます。</p>
<p>ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub</p>
<p>ユーザ別の known_hosts ファイル以外に、システム全体で有効なホストフ
ァイル /etc/ssh/known_hosts が存在しているかもしれません。このファ
イルは ssh クライアントと sshd の両方で hosts.equiv 機能を提供するた
めに使われています。このファイルも同様に更新する必要があります。</p>
<p>3. すべての OpenSSH ユーザ鍵をチェックする</p>
<p>一番安全な手順は、欠陥のないシステムで作成された鍵だと強く確信できる
場合を除いて全ての OpenSSH 鍵を再作成することです。</p>
<p>鍵が安全かどうかは、この更新に含まれている ssh-vulnkey ツールでチ
ェックできます。既定では、ssh-vulnkey はユーザ鍵の標準の格納場所
(~/.ssh/id_rsa, ~/.ssh/id_dsa と ~/.ssh/identity) と、authorized_keys
ファイル (~/.ssh/authorized_keys と ~/.ssh/authorized_keys2)、およ
びシステムのホスト鍵 (/etc/ssh/ssh_host_dsa_key と
/etc/ssh/ssh_host_rsa_key) をチェックします。</p>
<p>自分の全ての鍵が標準の場所 (~/.ssh/id_rsa, ~/.ssh/id_dsa, または
~/.ssh/identity) に格納されている場合、それらをチェックするには以下
のコマンドを使います。</p>
<p>ssh-vulnkey</p>
<p>システムの全ての鍵をチェックするには以下のようにします</p>
<p>sudo ssh-vulnkey -a</p>
<p>非標準の場所での鍵をチェックするには以下のようにします</p>
<p>ssh-vulnkey /path/to/key</p>
<p>もし ssh-vulnkey が <q>"Unknown (no blacklist information)"</q>
と答えた場合、キーが脆弱かどうかの情報がないということです。
疑わしい場合は、新しい鍵を作成して、全部のサーバから古い鍵を削除して
ください。
</p>
<p>4. 影響を受けるユーザ鍵を再作成する</p>
<p>ユーザの個人認証に使用する OpenSSH 鍵は、手動で再生成する必要があり
ます。これは生成後に他のシステムに移動した鍵を含みます。</p>
<p>新しい鍵は ssh-keygen を使って作成します。</p>
<pre>
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 user@host
</pre>
<p>5. authorized_keys ファイルを更新する (必要に応じて実行)</p>
<p>ユーザ鍵を再作成した後、対応する公開鍵は必要なリモートシステムの
authorized_keys (または authorized_keys2) に配布する必要があります。
当該ファイルから古い鍵を削除することを忘れないようにしてください。</p>
<h1><a name="openssl">OpenSSL: 一般的な PEM 鍵生成手順の説明</a></h1>
<p>
以下の記述は、PEM で符号化された証明書を (再) 生成するユーザのための、
単なるリマインダです。この手順の他にも、
おそらくサイトには鍵の管理方法に関する取り決めがあるので、それにも従うべきでしょう。
さらに、下記の方法で自己証明を用いるよりも、
第三者の証明機関に再度署名してもらう必要があるかもしれません。
</p>
<pre>
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
</pre>
<h1><a name="bincimap">bincimap</a></h1>
<p>
bincimap パッケージでは、自動的に openssl プログラムを用いて bincimap-ssl
サービス用の自己署名証明書を作成し、それを /etc/ssl/certs/imapd.pem に配置します。
再生成するには、以下のコマンドを実行してください。
</p>
<pre>
rm -f /etc/ssl/certs/imapd.pem
dpkg-reconfigure bincimap
</pre>
<h1><a name="boxbackup">boxbackup</a></h1>
<p>
boxbackup は Debian 安定版 (stable) には存在しません。テスト版 (testing)
である lenny にのみ存在します。
</p>
<p>
開発元は、ランダムさが不十分な疑似乱数生成器 (PRNG)
を用いて作成された鍵の最初の影響分析の結果を公開しました。詳細は<a
href="http://lists.warhead.org.uk/pipermail/boxbackup/2008-May/004476.html";>こちら</a>で読めます。
</p>
<p>
お使いの OpenSSL の PRNG のランダムさが不十分な場合は、以下のことをする必要があります。
</p>
<ul>
<li>問題のシステムで生成・署名された、影響のある証明書をすべて生成しなおす</li>
<li>データ鍵 (*-FileEncKeys.raw) をすべて生成しなおす</li>
<li>サーバに保存されているデータを適切なセキュリティレベルで破壊する (最低でもゼロ書き込みを行い、徹底的に破壊しないと気が済まない場合はさらなる作業をする)</li>
<li>すべてのものをアップロードしなおす</li>
<li>これまで公開サーバに認証なしでプレーンテキストのデータを保存していたという仮定のもとで、
適切な措置をとる (つまり、最初からやり直し、バックアップされたデータの痕跡をすべて消し、
さらに、あなたの秘密が暴露するのを和らげるためのその他の措置をとる)
</li>
</ul>
<h1><a name="cryptsetup">cryptsetup</a></h1>
<p>
cryptsetup 自体は暗号化に OpenSSL を使用していません (これは、LUKS と dm-crypt
の両方のデバイスに言えることです)。
</p>
<p>
<em>もし</em>、cryptsetup が SSL
で暗号化された鍵ファイルを使用するようという設定 (これは非デフォルトのセットアップで、
ユーザが明示的に設定しなければ使われることはありません) になっており、
欠陥のあるバージョンの OpenSSL が鍵ファイルの生成に使用されたのであれば、
(食塩が本当にランダムではないように) 鍵ファイルの暗号化は、
期待されるよりも弱い可能性があります。
</p>
<p>
解決策は、
鍵ファイルを暗号化しなおす (ただし暗号化された鍵が第三者に漏洩していないとある程度確信できる場合)
か、欠陥の影響を受けるパーティションを新たな鍵を用いて消去し、再インストールするか、
のどちらかです。
</p>
<p>
鍵ファイルを暗号化しなおす方法の説明は以下のとおりです。
</p>
<p>
SSL で暗号化された各鍵ファイルについて、以下のコマンドを実行してください。
ただし、<ssl_encrypted_key_path> は実際の鍵ファイルのパスで置き換えてください。
</p>
<pre>
tmpkey=\$(tempfile)
openssl enc -aes-256-cbc -d -salt -in <ssl_encrypted_key_path> -out "$tmpkey"
shred -uz <ssl_encrypted_key_path>
openssl enc -aes-256-cbc -e -salt -in "$tmpkey" -out <ssl_encrypted_key_path>
shred -uz "\$tmpkey"
</pre>
<h1><a name="dropbear">dropbear</a></h1>
<p>
/etc/ssh/*host* という鍵がある場合は、Dropbear の鍵を更新する前に、
まず /etc/ssh/*host* を削除するか、または <a href="#openssh">OpenSSH
に関する説明</a>に従ってください。
</p>
<p>
Dropbear の postinst は、dropbear のホスト鍵が見つからない場合、
既存の OpenSSH の鍵を dropbear 形式に変換します。
</p>
<pre>
rm /etc/dropbear/*_host_key
dpkg-reconfigure dropbear
</pre>
<p>
注意: Dropbear 自体が生成した鍵は脆弱ではありません (OpenSSL ではなく libtomcrypt
を使用しています)。
</p>
<h1><a name="ftpd-ssl">ftpd-ssl</a></h1>
<pre>
rm -f /etc/ftpd-ssl/ftpd.pem /etc/ssl/certs/ftpd.pem
dpkg-reconfigure ftpd-ssl
</pre>
<p>
この手順により、標準のセットアップはカバーされます。ローカルの管理者がこれ以上の ssl
インフラストラクチャに関する設定を行っている場合、それらに関する鍵の再作成も同様に必
要です。
</p>
<h1><a name="gforge">gforge</a></h1>
<p>
lenny と sid に収録された gforge-web-apache2 パッケージは、他にサイト証明書が存在してい
なかった場合にはダミーのサイト証明書を用いてウェブサイトを設定します。
ユーザはそれを追って正式な証明書に交換することが推奨されているわけです。
問題のダミーの証明書は名称が Snake Oil になっており、すでに脆弱だと (SSL のバグと関係
なしに) 明白なものとみなすべきものです。
しかしながら、一部のユーザは深く考えずこの証明書を受け入れてしまうかもしれません。
</p>
<h1><a name="kerberos">MIT Kerberos (krb5)</a></h1>
<p>
Debian 4.0 ("Etch") の MIT Kerberos は OpenSSL を全く使っていないため
Debian 4.0 の Kerberos には影響は全くありません。
</p>
<p>
lenny では、OpenSSL を使う別パッケージ krb5-pkinit があります。
MIT Kerberos 自体は、PKINIT プラグインを使っている場合でも、長期にわたって使用する鍵対
を生成しません。従って長期利用の鍵対に関する欠陥は、MIT Kerberos ソフトウェアとは別に作
成されたものです。PKINIT プラグインは、存在している鍵対を参照するだけで、鍵の管理に
は責任を持ちません。
</p>
<p>
PKINIT が用いる鍵対は、
欠陥のある Debian システムで生成されている場合、欠陥を持つかもしれません。
但し、このような生成は MIT Kerberos の枠組みの外の話です。
</p>
<p>
しかし、OpenSSL の乱数生成器は、PKINIT 認証が使用されている場合は DH
交換に使用されます。つまり、攻撃者が総当たり攻撃を用いて、PKINIT 認証に対する KDC
のレスポンスにアクセスし、
その後でその認証からのサービスチケットを用いて作成されたあらゆるセッションにアクセスできる可能性があります。
</p>
<p>
何らかの KDC で lenny の PKINIT プラグインを使用している場合は、すぐに KDC
の libssl0.9.8 パッケージをアップグレードし、以下のコマンドを実行して Kerberos KDC
を再起動してください。
</p>
<pre>
/etc/init.d/krb5-kdc restart
</pre>
<p>
欠陥のある libssl を使用している Kerberos KDC を用いた PKINIT 認証に由来する、
あらゆる Kerberos チケット保証チケット (TGT) や暗号化されたセッションは、
疑ってかかるべきです。パケットキャプチャを使用する攻撃者は、
これらの鍵やセッションを侵害できる可能性があります。
</p>
<h1><a name="openswan">OpenSWAN / StrongSWAN</a></h1>
<pre>
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
</pre>
<p>
注意: ipsec サービスを再起動すると、その時点でオープンされている全ての
IPSec コネクションが切断されます。
接続の反対側では再起動が必要になるかもしれません。
</p>
<h1><a name="openvpn">OpenVPN</a></h1>
<p>
秘密鍵ファイルをバックアップしてください。鍵の名前は好きにつけられ、
以下のコマンドを実行することで検出されます。
</p>
<pre>grep secret /etc/openvpn/*.conf</pre>
<p>
これらの鍵を以下のコマンドで再作成してください。
</p>
<pre>openvpn --genkey --secret SECRET_FILENAME</pre>
<p>
この後、共有の秘密鍵をリモートホストにコピーし、両端のホストで以下のコマンドを使って
VPN を再起動してください。
</p>
<pre>/etc/init.d/openvpn force-reload</pre>
<h1><a name="puppet">puppet</a></h1>
<p>
puppet の証明書を扱うには二つの方法があります。capistrano
を使う方法と、手動で行う方法です。
</p>
<p>
capistrano を使った場合の Puppet SSL 証明書を再作成する方法は、以下のページで詳しく説
明されています。
<a
href="http://reductivelabs.com/trac/puppet/wiki/RegenerateSSL";>http://reductivelabs.com/trac/puppet/wiki/RegenerateSSL</a>
</p>
<p>
手動で行うには、以下の手順をおこないます。
</p>
<ol>
<li>CA 情報を消し去って再作成しなければなりません
<pre>
/etc/init.d/puppetmaster stop
rm $vardir/ssl/*
/etc/init.d/puppetmaster start
</pre>
<p>
但し、init スクリプトから puppetmaster を起動する代わりに mongrel を実行している場合
は、まずフロントエンドのウェブリスナ (apache, nginx, etc.) を止めてから、以下の処理を
行う必要があるでしょう。
</p>
<pre>
puppetmasterd --daemonize ; sleep 30 ; pkill -f 'ruby /usr/sbin/puppetmasterd'
</pre>
<p>
このような処理が必要なのは、何らかの理由で mongrel を実行している場合、
puppetmaster が CA の再作成を行わないからです。
</p>
</li>
<li>全てのクライアント証明書を消去する
<pre>
/etc/init.d/puppet stop
rm $vardir/ssl/*
</pre>
</li>
<li>各クライアントから、新しい証明書を要求する。
<pre>
puppetd --onetime --debug --ignorecache --no-daemonize
</pre>
</li>
<li>全ての要求を取り込んだら、全部にまとめて署名できます
<pre>
puppetca --sign --all
</pre>
</li>
<li>puppet クライアントを起動する
<pre>
/etc/init.d/puppet start
</pre>
</li>
</ol>
<p>
その方が好きなら、autosign を一時的に有効にしておくこともできます。
</p>
<h1><a name="sendmail">sendmail</a></h1>
<p>
sendmail は、(etch においても lenny においても) インストール時に、
デフォルトの OpenSSL 証明書を作成することを選択できます。
</p>
<p>
鍵のロールオーバーの手順は、以下のとおりごく簡単です。
</p>
<pre>
/usr/share/sendmail/update_tls new
</pre>
<p>
/etc/mail/tls 内のテンプレートをカスタマイズした場合は、
そのテンプレートの値が新たな証明書の作成に再利用されます。
</p>
<h1><a name="ssl-cert">ssl-cert</a></h1>
<p>
snakeoil 証明書 /etc/ssl/certs/ssl-cert-snakeoil.pem
は、以下のようにして再作成できます。
</p>
<pre>make-ssl-cert generate-default-snakeoil --force-overwrite</pre>
<h1><a name="telnetd-ssl">telnetd-ssl</a></h1>
<pre>
rm -f /etc/telnetd-ssl/telnetd.pem /etc/ssl/certs/telnetd.pem
dpkg-reconfigure telnetd-ssl
</pre>
<p>
この手順により、標準のセットアップはカバーされます。ローカルの管理者がこれ以上の ssl
インフラストラクチャに関する設定を行っている場合、それらに関する鍵の再作成も同様に必
要です。
</p>
<h1><a name="tinc">tinc</a></h1>
<p>
次の方法で、疑わしい公開鍵・秘密鍵はすべて削除してください。
</p>
<ol>
<li>rsa_key.priv を削除する。</li>
<li>hosts/ ディレクトリ内のファイルをすべて編集して、公開鍵のブロックを削除する。</li>
</ol>
<p>
次の方法で、新たな公開鍵・秘密鍵の鍵対を生成してください。
<pre>
tincd -n <netname> -K
</pre>
</p>
<p>
VPN の他のメンバーと、新たな公開鍵とともにホストの設定ファイルを交換してください。
tinc デーモンを再起動するのをお忘れなく。
</p>
<h1><a name="tor">tor</a></h1>
<p>
Tor は安定版 (stable) には収録されていませんが、lenny では欠陥の影響を受けます。
</p>
<p>
バージョン 0.1.2.x を実行するクライアントは欠陥の影響を受けません。
あらゆるバージョンを実行する Tor ノードや秘匿サービス提供者、およびバージョン 0.2.0.x
を使用するユーザは、欠陥の影響を受けます。
</p>
<p>
Tor アナウンス用メーリングリスト上の<a
href="http://archives.seul.org/or/announce/May-2008/msg00000.html";>脆弱性のアナウンス</a>を参照してください。
</p>
<p>
バージョン 0.1.2.19-3 (テスト版 (testing) および不安定版 (unstable)、
backports.org、通常の <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorOnDebian";>noreply.org
のリポジトリ</a>から入手可能) またはバージョン 0.2.0.26-rc-1 (experimental
および通常の <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorOnDebian";>noreply.org
のリポジトリ</a>) へのアップグレードをお勧めします。これらのバージョンでリレーを実行すると、
強制的に新しいサーバ鍵 (/var/lib/tor/keys/secret_*) が生成されます。
</p>
<p>
パッケージのインフラストラクチャ (debian-tor というユーザや、/var/lib/tor
という DataDirectory など) を利用せずに Tor ノードを実行する場合は、
問題のある鍵を手で削除する必要があります。前述の勧告のリンクを参照してください。
</p>
<p>
秘匿サービス提供者であり、libssl に問題があった期間に鍵を生成した場合は、
秘匿サービスの秘密鍵を削除してください。それによって秘匿サービスのホスト名が変わり、
サーバの再設定が必要になるかもしれません。
</p>
<p>
バージョン 0.2.0.x を実行している場合は、アップグレードを強くお勧めします。
6 つの v3 認証サーバのうち 3 つが欠陥のある鍵を使用しているからです。
古いバージョン 0.2.0.x は、1 〜 2 週間で動作を停止する予定です。
</p>
<h1><a name="xrdp">xrdp</a></h1>
<p>
xrdp は生成された鍵を使用しています。
殆どのクライアントはデフォルトではこれらの鍵をチェックしないため、
鍵を交換しても大きな問題は出ません。単に以下のようにしてください。
</p>
<pre>
rm /etc/xrdp/rsakeys.ini
/etc/init.d/xrdp restart
</pre>
<p>
xrdp は安定版 (stable) には収録されていません。
</p>