path: root/german/security/key-rollover/index.wml

#use wml::debian::template title="Schlüsselaustausch"
#use wml::debian::translation-check translation="5011f532637dc7820b79b151eecfda4ab65aa22f" maxdelta="1"

<p>
In der <a href="$(HOME)/security/2008/dsa-1571">Debian-Sicherheitsankündigung 1571</a>,
deckte das Debian-Sicherheitsteam eine Schwäche im Zufallszahlengenerator auf,
der von OpenSSL in Debian und seinen Derivaten verwendet wird. Als ein Ergebnis
dieser Schwäche sind bestimmte Verschlüsselungsschlüssel sehr viel einfacher,
als sie sein sollten, so dass ein Angreifer den Schlüssel mittels einer
Brute-Force-Attacke mit minimalem Wissen über das System erraten kann. Dies
betrifft insbesondere die Verwendung von Verschlüsselungsschlüsseln in
OpenSSH, OpenVPN und SSL-Zertifikaten.
</p>

<p>
Diese Seite dokumentiert, wie die Schlüssel für Pakete, deren Schlüssel durch
die OpenSSL-Verwundbarkeit betroffen sind, ausgetauscht werden können.
</p>

<ul>
<li><b><a href="#openssh">OpenSSH</a></b></li>
<li><b><a href="#openssl">OpenSSL: Allgemeine PEM-Schlüsselerzeugungsinstruktionen</a></b></li>

<li><a href="#bincimap">Bincimap</a></li>
<li><a href="#boxbackup">Boxbackup</a></li>
<li><a href="#cryptsetup">Cryptsetup</a></li>
<li><a href="#dropbear">Dropbear</a></li>
<li><a href="#ekg">Ekg</a></li>
<li><a href="#ftpd-ssl">Ftpd-ssl</a></li>
<li><a href="#gforge">Gforge</a></li>
<li><a href="#kerberos">MIT-Kerberos (krb5)</a></li>
<li><a href="#nessus">Nessus</a></li>
<li><a href="#openswan">OpenSWAN / StrongSWAN</a></li>
<li><a href="#openvpn">OpenVPN</a></li>
<li><a href="#proftpd">Proftpd</a></li>
<li><a href="#puppet">Puppet</a></li>
<li><a href="#sendmail">Sendmail</a></li>
<li><a href="#ssl-cert">Ssl-cert</a></li>
<li><a href="#telnetd-ssl">Telnetd-ssl</a></li>
<li><a href="#tinc">Tinc</a></li>
<li><a href="#tor">Tor</a></li>
<li><a href="#xrdp">Xrdp</a></li>
</ul>

<p>
Andere Software verwendet kryptographische Schlüssel, ist aber
<a href="notvuln">nicht verwundbar</a>, da OpenSSL nicht verwendet wird,
um deren Schlüssel zu erzeugen oder zu übermitteln.
</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>
Für Anleitungen zum Schlüsselaustausch für andere Software wird auf die
von Benutzern zusammengetragenen Informationen unter
<url https://wiki.debian.org/SSLkeys> verwiesen.
</p>

<h1><a name="openssh">OpenSSH</a></h1>

<p>
Ein aktualisiertes Paket wurde mit <a href="$(HOME)/security/2008/dsa-1576">DSA-1576</a>
herausgegeben, das die Schlüsseltransformation vereinfacht.
</p>

<p>1. Installieren Sie die Sicherheitsaktualisierungen aus DSA-1576</p>

<p>Sobald die Aktualisierung eingespielt wurde, werden schwache
Benutzerschlüssel, wenn möglich, automatisch zurückgewiesen (diese können
aber nicht in allen Fällen erkannt werden). Falls Sie solche Schlüssel
für die Benutzerauthentifizierung verwenden, werden sie ab sofort nicht
mehr funktionieren und müssen ersetzt werden (siehe Schritt 3).</p>

<p>OpenSSH-Rechner-Schlüssel können automatisch neu erzeugt werden, wenn
    die OpenSSH-Sicherheitsaktualisierung eingespielt wurde. Die
    Aktualisierung wird nach Bestätigung fragen, bevor dieser Schritt
    durchgeführt wird.</p>

<p>2. Aktualisierung der OpenSSH-Dateien <tt>known_hosts</tt></p>

<p>Die Neuerzeugung der Rechnerschlüssel wird eine Warnung ausgeben, wenn
    auf das System mit SSH zugegriffen wird, bis der Rechnerschlüssel in
    der Datei known_hosts auf dem Klient aktualisiert wurde. Die Warnung
    wird wie folgt aussehen:</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>

Auf Deutsch lautet diese Meldung in etwa wie folgt:

<pre>
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: IDENTIFIZIERUNG DES ENTFERNTES RECHNERS HAT SICH GEÄNDERT @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ES IST MÖGLICH, DASS JEMAND ETWAS BÖSES TUT!
Jemand könnte Sie zurzeit abhören (man-in-the-middle-(Mann in der Mitte)-Angriff)!
Es ist auch möglich, dass der RSA-Rechnerschlüssel vor kurzem geändert wurde.
</pre>

<p>In diesem Fall wurde der Rechnerschlüssel einfach geändert und Sie
    sollten die entsprechende Datei <tt>known_hosts</tt>, wie in der
    Meldung beschrieben, aktualisieren.

Es wird empfohlen, dass Sie einen vertrauenswürdigen Kanal zum Austausch
des Server-Schlüssels verwenden. Er befindet sich in der Datei
<tt>/etc/ssh/ssh_host_rsa_key.pub</tt> auf dem Server;
sein Fingerabdruck kann mit dem folgenden Kommando gedruckt werden:</p>

    <p><code>ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub</code></p>

<p>Zusätzlich zu benutzerspezifischen <tt>known_hosts</tt>-Dateien, kann
    eine systemweite Datei <tt>/etc/ssh/ssh_known_hosts</tt> existieren. Diese
    Datei wird sowohl vom ssh-Klient als auch von sshd für die
    <tt>hosts.equiv</tt>-Funktionalität verwendet. Diese Datei muss auch
    aktualisiert werden.</p>

<p>3. Überprüfen aller OpenSSH-Benutzerschlüssel</p>

<p>Der sicherste Weg ist es, alle OpenSSH-Benutzerschlüssel neu zu
    erzeugen, es sei denn, es kann mit ausreichender Bestimmtheit
    sichergestellt werden, dass der Schlüssel auf einem nicht betroffenen
    System erstellt wurde.</p>

<p>Um zu testen, ob Ihr Schlüssel betroffen ist, können Sie
    <tt>ssh-vulnkey</tt> starten, was in der Sicherheitsaktualisierung enthalten ist.
    Standardmäßig wird <tt>ssh-vulnkey</tt> den Standardort für Benutzerschlüssel
    (<tt>~/.ssh/id_rsa</tt>, <tt>~/.ssh/id_dsa</tt> und <tt>~/.ssh/identity</tt>), Ihre Datei
    <tt>authorized_keys</tt> (<tt>~/.ssh/authorized_keys</tt> und
    <tt>~/.ssh/authorized_keys2</tt>) und die Rechnerschlüssel des Systems
    (<tt>/etc/ssh/ssh_host_dsa_key</tt> und <tt>/etc/ssh/ssh_host_rsa_key</tt>) überprüfen.</p>

<p>Sie können alle Ihre eigenen Schlüssel wie folgt testen, unter der
    Voraussetzung, dass sie sich an den Standardorten (<tt>~/.ssh/id_rsa</tt>,
    <tt>~/.ssh/id_dsa</tt> oder <tt>~/.ssh/identity</tt>) befinden:</p>

    <p><code>ssh-vulnkey</code></p>

<p>Um alle Schlüssel auf Ihrem System zu überprüfen:</p>

    <p><code>sudo ssh-vulnkey -a</code></p>

<p>Um einen Schlüssel an einem nicht standardmäßigem Ort zu testen:</p>

    <p><code>ssh-vulnkey <var>/Pfad/zum/Schlüssel</var></code></p>

<p>Falls <tt>ssh-vulnkey</tt> die Meldung <q>Unknown (no blacklist information)</q>
    ausgibt, hat es keine Informationen darüber, ob der Schlüssel betroffen ist.
    Im Zweifelsfall sollte der Schlüssel zerstört und ein neuer erzeugt
    werden.
</p>

<p>4. Neuerzeugen beliebiger betroffener Benutzerschlüssel</p>

<p>Für die Benutzerauthentifizierung verwendete OpenSSH-Schlüssel müssen
manuell neu erzeugt werden, inklusive derjenigen, die nach der
Erzeugung auf ein anderes System übertragen wurden.</p>

<p>Neue Schlüssel können mit <tt>ssh-keygen</tt> erzeugt werden, z.B.:</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. Aktualisierung der <tt>authorized_keys</tt>-Dateien (falls nötig)</p>

<p>Sobald die Benutzerschlüssel neu erzeugt wurden, müssen die relevanten
    öffentlichen Schlüssel in <tt>authorized_keys</tt>-Dateien (und eventuell
    <tt>authorized_keys2</tt>-Dateien) auf entfernten Systemen übertragen
    werden. Stellen Sie sicher, dass die betroffenen Schlüssel gelöscht werden.</p>

<h1><a name="openssl">OpenSSL: Allgemeine PEM-Schlüsselerzeugungsinstruktionen</a></h1>

<p>
Dies ist nur eine Erinnerung für jene, die PEM-kodierte Zertifikate
(neu)erzeugen. Ihre Site hat wahrscheinlich andere Richtlinien dafür, wie
Schlüssel verwaltet werden, denen Sie folgen sollten. Zusätzlich müssen Sie
die Zertifikate eventuell erneut durch eine weitere Zertifikatsautorität
signieren lassen, anstatt ein selbst zertifiziertes Zertifikat, wie im
Folgenden gezeigt, verwenden:
</p>

<pre>
cd /etc/ssl/private
openssl genrsa 1024 &gt; 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>
  Das Paket bincimap erstellt mittels des Openssl-Programms automatisch 
  selbst-signierte Zertifikate für den Bincimap-ssl-Dienst und legt diese
  in /etc/ssl/certs/imapd.pem ab. Für die Neuerzeugung führen Sie Folgendes
  aus:
</p>

<pre>
rm -f /etc/ssl/certs/imapd.pem
dpkg-reconfigure bincimap
</pre>

<h1><a name="boxbackup">Boxbackup</a></h1>

<p>
  Boxbackup ist nicht in Debian Stable vorhanden, nur in Testing/Lenny.
</p>

<p>
  Die Originalautoren haben eine erste Auswirkungsanalyse des mit unzureichend
  zufälligem PRNG erstellten Schlüsselmaterials erstellt. Sie können die Details
  <a 
  href="http://lists.warhead.org.uk/pipermail/boxbackup/2008-May/004476.html">\
  hier</a> nachlesen.
</p>

<p>
   Falls der PRNG in Ihrer OpenSSL unzureichend zufällig war, müssen Sie:
</p>

<ul>
  <li>alle betroffenen Zertifikate, die auf betroffenen Systemen erstellt oder 
      signiert wurden, neu erstellen</li>
  <li>alle Datenschlüssel (*-FileEncKeys.raw) neu erstellen</li>
  <li>alle auf Ihrem Server gespeicherten Daten bis zu einem angemessenen Niveau
      zerstören (zumindest mit Nullen überschreiben, mehr falls Sie paranoid
      sind)</li>
  <li>alles erneut hochladen</li>
  <li>angemessene Maßnahmen unter der Annahme, dass Sie alle Daten als reinen
      Text auf einem öffentlichen Server ohne Authentifizierung gespeichert 
      haben, treffen (d.h. von Null anfangen, alle Spuren der gesicherten Daten
      vernichten und andere Maßnahmen treffen, um die Bloßstellung Ihrer
      Geheimnisse abzuschwächen).</li>
</ul>

<h1><a name="cryptsetup">Cryptsetup</a></h1>

<p>
  Cryptsetup verwendet selbst nicht Openssl für die Verschlüsselung (dies
  trifft sowohl auf LUKS- als auch Dm-crypt-Geräte zu).
</p>

<p>
  <em>Falls</em> Cryptsetup konfiguriert wurde, SSL-verschlüsselte 
  Schlüsseldateien zu verwenden (eine nicht-Standard-Konfiguration, die vom
  Benutzer explizit konfiguriert worden sein muss) und eine defekte Version
  von Openssl wurde zur Erstellung der Schlüsseldatei verwandt, dann kann die
  Schlüsseldatei schwächer als erwartet sein (da das Salz nicht wirklich
  zufällig ist).
</p>

<p>
Die Lösung besteht entweder darin, die Schlüsseldatei erneut zu verschlüsseln
(falls Sie sich halbwegs sicher sein können, dass der verschlüsselte 
Schlüssel nicht dritten Parteien bekannt geworden ist) oder die betroffene(n)
Partition(en) zu überschreiben und mit einem neuen Schlüssel neu zu 
installieren.
</p>

<p>
  Anweisungen zur Neuverschlüsselung einer Schlüsseldatei:
</p>

<p>
  Führen Sie das Folgende für jede SSL-verschlüsselte Schlüsseldatei durch,
  wobei Sie &lt;ssl_encrypted_key_path&gt; durch den Pfad zur eigentlichen
  Schlüsseldatei ersetzen:
</p>

<pre>
tmpkey=\$(tempfile)
openssl enc -aes-256-cbc -d -salt -in &lt;ssl_encrypted_key_path&gt; -out "$tmpkey"
shred -uz &lt;ssl_encrypted_key_path&gt;
openssl enc -aes-256-cbc -e -salt -in "$tmpkey" -out &lt;ssl_encrypted_key_path&gt;
shred -uz "$tmpkey"
</pre>

<h1><a name="dropbear">Dropbear</a></h1>

<p>
  Falls Sie über /etc/ssh/*host*-Schlüssel verfügen, entfernen Sie diese 
  entweder oder folgen Sie zuerst den <a href="#openssh">Openssh-Anweisungen</a>
  bevor Sie die Schlüssel von Dropbear aktualisieren.
</p>

<p>
  Dropbears Postinst konvertiert existierende Openssh-Schlüssel in das
  Dropbear-Format, falls es nicht die Host-Schlüssel von Dropbear finden kann.
</p>

<pre>
rm /etc/dropbear/*_host_key
dpkg-reconfigure dropbear
</pre>

<p>
  Beachten Sie, dass die von Dropbear selbst generierten Schlüssel nicht
  verwundbar sind (es verwendet libtomcrypt statt OpenSSL).
</p>

<h1><a name="ekg">Ekg</a></h1>

<p>
  Benutzer des Programms Ekg oder Ekg2 (letzteres ist nur in Experimental), die
  die <q>SIM</q>-Verschlüsselungsfunktionalität verwenden und ihr 
  Schlüsselpaar mittels des Befehls <q>/key [-g|--generate]</q> erstellt
  haben (der libssl zur Erledigung verwendet), sollten ihren Schlüssel neu
  erstellen, nachdem Sie das Upgrade von libssl eingespielt und das Programm
  neu gestartet haben.
</p>

<p>
  Die Originalautoren haben einen Hinweis auf ihre Website gestellt:
  <a href="http://ekg.chmurka.net/index.php">\
     http://ekg.chmurka.net/index.php</a>
</p>

<p>
  Falls Sie weitere Hilfe benötigen, fragen Sie bitte auf 
  ekg-users@lists.ziew.org oder auf ekg2-users@lists.ziew.org (beide auf
  Englisch und Polnisch).
</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>
  behandelt die Standard-Installation. Falls der Administrator darüber hinaus
  weitere SSL-Infrastruktur eingerichtet hat, müssen diese Schlüssel ebenfalls
  neu erstellt werden.
</p>

<h1><a name="gforge">Gforge</a></h1>

<p>
  Das Paket gforge-web-apache2 in Sid und Lenny richtet die Website mit einem
  Pseudo-Zertifikat ein, falls kein existierendes Zertifikat gefunden wird. 
  Die Benutzer werden dann ermutigt, es mit einem <q>echten</q> zu ersetzen. 
  Das besagte Pseudo-Zertifikat ist zudem ein reines Quacksalber-Produkt, 
  daher sollte es bereits als schwach bekannt sein (selbst ohne den 
  SSL-Fehler), aber einige Benutzer könnten es ohne weiteres Nachdenken 
  akzeptieren.
</p>

<h1><a name="kerberos">MIT-Kerberos (krb5)</a></h1>

<p>
  Kein Teil von <acronym lang="en" 
  title="Massachusetts Institute of Technology">MIT</acronym>-Kerberos in Debian
  4.0 (<q>Etch</q>) verwendet OpenSSL, und daher ist Kerberos in Debian 4.0 in
  keinster Weise betroffen.
</p>

<p>
  In Lenny verwendet das separate Binärpaket krb5-pkinit OpenSSL. MIT-Kerberos
  selbst generiert keine langlebigen Schlüsselpaare, selbst wenn die 
  PKINIT-Erweiterung verwandt wird, daher müssten alle verwundbaren langlebigen
  Schlüsselpaare außerhalb der MIT-Kerberos-Software selbst erstellt worden
  sein. Die PKINIT-Erweiterung referenziert nur existierende Schlüsselpaare
  und ist nicht für die Schlüsselverwaltung verantwortlich.
</p>
<p>
  Langlebige Schlüsselpaare, die mit PKINIT verwandt werden, könnten betroffen
  sein, falls sie auf einem betroffenen Debian-System erzeugt wurden, aber
  diese Erstellung liegt außerhalb von MIT-Kerberos.
</p>
<p>
  Allerdings wird die <q>random key</q>-Funktion von OpenSSL für den
  DH-Austausch verwandt, wenn die PKINIT-Authentifizierung verwandt wird.
  Dies bedeutet, dass ein Angreifer in der Lage sein könnte, mit roher
  Gewalt Zugriff auf die Antwort des KDC auf eine PKINIT-Authentifizierung
  zu erlangen und folgerichtig Zugriff auf alle Sitzungen, die mit diesem
  Dienst-Ticket von dieser Authentifizierung erstellt wurden, zu erlangen.
</p>
<p>
  Alle KDCs, die die PKINIT-Erweiterung aus Lenny einsetzen, sollten sofort
  ein Upgrade des libssl0.9.8-Pakets bekommen. Anschließend sollte der
  Kerberos-KDC wie folgt neu gestartet werden:
</p>
<pre>
/etc/init.d/krb5-kdc restart
</pre>
<p>
  Jedes <q lang="en">Kerberos ticket-granting ticket</q> (TGT) und alle
  verschlüsselten Sitzungen, die aus einer PKINIT-Authentifizierung mittels
  eines Kerberos KDC mit einer betroffenen libssl erfolgten, sollten als
  suspekt betrachtet werden. Es ist möglich, dass Angreifer, die Pakete
  abfangen können, diese Schlüssel und Sitzungen kompromittieren könnten.
</p>

<h1><a name="nessus">Nessus</a></h1>

<p>Das Post-Installations-Skript des Nessus-Serverpakets (nessusd) erstellt
   SSL-Schlüssel für die sichere Kommunikation zwischen einem Nessus-Server und
   -Client. Dieser Kommunikationskanal sollte als kompromittiert betrachtet 
   werden, da ein böswilliger Benutzer in der Lage wäre, die zwischen dem 
   Server und dem Client ausgetauschten Informationen (die Informationen über die 
   Verwundbarkeiten des entfernten Systems enthalten) abzufangen und 
   möglicherweise Befehle als der angemeldete Benutzer an den Server senden
   könnte.</p>

<p>Falls der Administrator zusätzlich entweder den Nessus-<acronym lang="en"
   title="Certification Authority">CA</acronym>-Schlüssel oder ein 
   Benutzer-Zertifikat (mit nessus-mkcert-client) für die entfernte 
   Authentifizierung auf einem Server erstellt hat, auf dem die von diesem
   Sicherheitsproblem betroffene OpenSSL-Version installiert war, dann sollten
   diese Schlüssel als kompromittiert angesehen werden. Beachten Sie, dass
   entfernte Benutzer mit Zugriff auf den Nessus-Server von diesem Server aus
   Angriffe gegen Server fahren können, die sie angreifen dürfen und, falls
   in der lokalen Konfiguration aktiviert (standardmäßig bei Debian auf 
   <q>nein</q>) Erweiterungen hochladen können, die vom Nessus-Server mit
   Root-Rechten ausgeführt werden würden.</p>

<p>Die Konfigurationsskripte des Betreuers werden das OpenSSL-Zertifikat (wenn
   konfiguriert) neu erstellen, falls sie es nicht finden können. Sie müssen die
   Zertifikate entfernen und dann neue erstellen lassen, indem Sie Folgendes
   ausführen:</p>

<pre>
rm -f /var/lib/nessus/CA/cacert.pem
rm -f /var/lib/nessus/CA/servercert.pem
rm -f /var/lib/nessus/private/CA/cakey.pem
rm -f /var/lib/nessus/private/CA/serverkey.pem
dpkg-reconfigure nessusd
</pre>

<p>Sobald dies erledigt ist, müssen Sie die alten Benutzerschlüssel unter
   /var/lib/nessus/users/USERNAME/auth entfernen und sie mit 
   <q>nessus-mkcert-client</q> neu erstellen. Sobald der CA-Schlüssel
   entfernt wurde, werden alte Schlüssel ungültig.</p>

<p>Nachdem der CA-Schlüssel neu erstellt wurde, werden Sie auch den neuen
   CA-Schlüssel an Ihre Benutzer verteilen müssen und Ihre Benutzer müssen
   das neue Zertifikat von dem Nessus-Server nach dem Verbindungsaufbau
   akzeptieren. Die Zertifikatseinstellungen für den alten Server sollten
#FIXME alten Server??
   automatisch entfernt werden, aber Sie können sie auch manuell entfernen, indem Sie
   <code>.nessusrc.cert</code> (falls Sie den Nessus-Client verwenden) oder
   <code>.openvasrc.cert</code> (falls Sie den OpenVAS-Client verwenden) 
   bearbeiten.</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>
Vorsicht: Neustarten des Dienstes ipsec beendet alle aktuell offenen
IPSec-Verbindungen. Diese müssen eventuell vom anderen Ende neu gestartet werden.
</p>

<h1><a name="openvpn">OpenVPN</a></h1>

<p>
  Sichern Sie Ihre geheimen Dateien. Während Schlüsselnamen beliebig sein
  können, können sie mittels des Befehls
</p>
<pre>grep secret /etc/openvpn/*.conf</pre>
<p>
  erkannt werden.
</p>

<p>
  Erstellen Sie sie erneut mittels
</p>
<pre>openvpn --genkey --secret GEHEIMER_DATEINAME</pre>

<p>
  Kopieren Sie dann den gemeinsamen geheimen Schlüssel auf den entfernten
  Rechner und starten Sie das <acronym lang="en" 
  title="Virtual Private Network">VPN</acronym> auf jedem Rechner mittels
</p>
<pre>/etc/init.d/openvpn force-reload</pre>
<p>
neu.
</p>

<h1><a name="proftpd">Proftpd</a></h1>

<p>
  Das Debian-Paket enthält keine Schlüsselerzeugung, daher sollten die folgenden
  Schritte nur notwendig sein, falls SSL-Schlüssel extern erstellt wurden.
</p>

<p>
  Ein zukünftiger Upload von Proftpd nach Unstable wird eine tls.conf-Vorlage
  mit dem Kommentar unten enthalten.
</p>

<p>
  Beachten Sie, dass die Erstellung selbst-signierter Zertifikate sich etwas
  vom allgemeinen Abschnitt von Openssl unterscheidet, um die Verwendung eines
  expliziten Passworts beim Starten des Daemons zu vermeiden.
</p>

<p>
  Sie können das selbst-signierte Zertifikat mit einem Befehl der folgenden
  Art erstellen:
</p>
<pre>
 openssl req -x509 -newkey rsa:1024 \
         -keyout /etc/ssl/private/proftpd.key -out /etc/ssl/certs/proftpd.crt \
	 -nodes -days 365
</pre>

<p>
  Beide Dateien dürfen nur von Root lesbar sein. Die Pfade der Dateien können
  mit den folgenden Konfigurationsdirektiven überprüft/konfiguriert werden:
</p>
<pre>
TLSRSACertificateFile                   /etc/ssl/certs/proftpd.crt
TLSRSACertificateKeyFile                /etc/ssl/private/proftpd.key
TLSCACertificateFile                    /etc/ssl/certs/CA.pem
TLSOptions                              NoCertRequest
</pre>

<h1><a name="puppet">Puppet</a></h1>

<p>
  Es gibt zwei Methoden, Puppet-Zertifikate zu handhaben. Die eine ist via
  capistrano, die zweite ist manuell.
</p>

<p>
  Die Neuerstellung der SSL-Zertifikate von Puppet mittels capistrano ist
  hier beschrieben:
  <a href="http://reductivelabs.com/trac/puppet/wiki/RegenerateSSL">\
  http://reductivelabs.com/trac/puppet/wiki/RegenerateSSL</a>
</p>

<p>
  Die manuellen Schritte sind wie folgt:
</p>

<ol>
<li>Sie müssen die CA-Information löschen und neu generieren:
<pre>
/etc/init.d/puppetmaster stop
rm -rf $vardir/ssl/*
/etc/init.d/puppetmaster start
</pre>
<p>
  Falls Sie allerdings Mongrel betreiben statt Puppetmaster aus dem Init-Skript
  zu starten, müssen Sie erst am Web auf Anfragen wartende Oberflächen
  (Apache, Nginx, usw.) stoppen und dann das Folgende durchführen:
</p>
<pre>
puppetmasterd --daemonize ; sleep 30 ; pkill -f 'ruby /usr/sbin/puppetmasterd'
</pre>
<p>
  Der obige Befehl ist notwendig, da aus irgend einem Grund Puppetmaster seine
  CA nicht neu erstellen wird, falls es unter Mongrel läuft.
</p>
</li>
<li>Löschen Sie alle Client-Zertifikate
<pre>
/etc/init.d/puppet stop
rm $vardir/ssl/*
</pre> 
</li>
<li>Lassen Sie jeden Client ein neues Zertifikat erstellen
<pre>
puppetd --onetime --debug --ignorecache --no-daemonize
</pre> 
</li>
<li>Sobald alle Anfragen eingetroffen sind, können Sie sie alle auf einmal
    signieren:
<pre>
puppetca --sign --all
</pre> 
</li>
<li>Starten Sie Ihre Puppet-Clients:
<pre>
/etc/init.d/puppet start
</pre>
</li>
</ol>

<p>
  Sie könnten auch temporär das automatische Signieren aktivieren, falls Ihnen
  das zusagt.
</p>

<h1><a name="sendmail">Sendmail</a></h1>

<p>
Sendmail (sowohl in Etch als auch in Lenny) erstellt optional bei der
Installation vorgegebene OpenSSL-Zertifikate.
</p>

<p>
  Die Schlüsselaustauschprozedur ist trivial:
</p>
<pre>
/usr/share/sendmail/update_tls new
</pre>

<p>
  Falls Sie die Vorlagen in /etc/mail/tls angepasst haben, werden die Werte
  dort erneut zum Erstellen der neuen Zertifikate verwandt.
</p>

<h1><a name="ssl-cert">ssl-cert</a></h1>

<p>
  Das Quacksalber-Zertifikat /etc/ssl/certs/ssl-cert-snakeoil.pem kann mittels
  folgendem Befehl neu erstellt werden:
</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>
  behandelt die Standard-Installation. Falls der Administrator darüber hinaus
  weitere SSL-Infrastruktur eingerichtet hat, müssen diese Schlüssel ebenfalls
  neu erstellt werden.
</p>

<h1><a name="tinc">Tinc</a></h1>

<p>
  Entfernen Sie alle verdächtigen öffentlichen und privaten Schlüsseldateien:
</p>
<ol>
<li>Entfernen Sie rsa_key.priv.</li>
<li>Bearbeiten Sie alle Dateien im Verzeichnis hosts/ und entfernen Sie die
    öffentlichen Schlüsselblöcke.</li>
</ol>

<p>
  Erstellen Sie ein neues (öffentlich/privates) Schlüsselpaar:
</p>
<pre>
tincd -n &lt;netname&gt; -K
</pre>

<p>
  Tauschen Sie die Host-Konfigurationsdatei mit den neuen öffentlichen
  Schlüsseln mit anderen Mitgliedern Ihres VPN. Vergessen Sie nicht, den
  Tinc-Daemon neu zu starten.
</p>

<h1><a name="tor">tor</a></h1>

<p>
Tor ist nicht in Stable, aber in Lenny betroffen.
</p>

<p>
Clients mit Version 0.1.2.x sind nicht betroffen. Tor-Knoten oder versteckte
Diensteanbieter, die eine beliebige Version verwenden, ebenso wie 0.2.0.x, sind
betroffen.
</p>

<p>
Bitte lesen Sie die
<a href="http://archives.seul.org/or/announce/May-2008/msg00000.html">\
Verwundbarkeitsankündigung</a> auf der Tor-Ankündigungs-Mailingliste.
</p>

<p>
Eine Aktualisierung zu 0.1.2.19-3 (verfügbar in Testing, Unstable, backports.org
und dem üblichen <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorOnDebian">\
noreply.org-Depot</a>) oder 0.2.0.26-rc-1 (verfügbar in Experimental und
dem üblichen <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorOnDebian">\
noreply.org-Depots</a>) wird empfohlen. Falls Sie einen Relay laufen haben,
#HK: Relay -> Weiterleitung?
werden diese Versionen neue Server-Schlüssel (/var/lib/tor/keys/secret_*)
erzeugen.
</p>

<p>
Sollten Sie einen Tor-Knoten ohne die Paketinfrastruktur (Benutzer debian-tor,
/var/lib/tor als DataDirectory usw.) verwenden, müssen Sie betroffene Schlüssel
manuell entfernen. Schauen Sie in den oben aufgeführten Ankündigungs-Link.
</p>

<p>
Falls Sie ein versteckter Diensteanbieter sind und Ihren Schlüssel im
entsprechenden Zeitfenster mit einer unzureichenden libssl erstellt haben,
löschen Sie bitte Ihren privaten Schlüssel des versteckten Dienstes.
Dies wird den Rechnernamen Ihres versteckten Dienstes ändern und könnte eine
Neukonfiguration Ihrer Server erfordern.
</p>

<p>
Falls Sie Version 0.2.0.x verwenden, wird eine Aktualisierung dringend
empfohlen &ndash; 3 der 6 v3-Autoritäts-Server haben kompromittierte
Schlüssel. Alte 0.2.0.x Versionen werden in ein oder zwei Wochen nicht
mehr länger funktionieren.
</p>

<h1><a name="xrdp">xrdp</a></h1>

<p>
  Xrdp verwendet generierte Schlüssel. Die meisten Clients überprüfen diese
  Schlüssel standardmäßig nicht, daher ist der Austausch schmerzlos. Sie müssen
  nur Folgendes ausführen:
</p>

<pre>
rm /etc/xrdp/rsakeys.ini
/etc/init.d/xrdp restart
</pre>

<p>
  Xrdp ist nicht in Stable.
</p>