# Heartbleed Bug - Details!?

## slick

Habe gerade bei Heise gelesen ... http://www.heise.de/newsticker/meldung/Der-GAU-fuer-Verschluesselung-im-Web-Horror-Bug-in-OpenSSL-2165517.html ... und irgendwie macht mich das doch leicht nervös da SSL auf (m)einem vernünftig gesichertem Server doch häufig Anwendung findet. 

Kann jemand etwas mehr dazu sagen? Inwiefern tangiert das Gentoo?

----------

## cryptosteve

Auf meinem Gentoo-Server ist das Update auf openssl-1.0.1g ordnungsgemäß durchgelaufen. Die betroffenen Dienste habe ich neu gestartet. In wieweit ich die Zertifikate und Schlüssel noch tauschen muss, muss ich nochmal genauer nachlesen.

----------

## Josef.95

 *Quote:*   

> Inwiefern tangiert das Gentoo?

 

Ein wenig Info dazu gibt es im [ GLSA 201404-07 ] OpenSSL: Information Disclosure

----------

## slick

Das war erst noch nicht raus  :Wink: 

----------

## schmidicom

 *Quote:*   

> As private keys may have been compromised using the Heartbleed attack, it is recommended to regenerate them.

 

Wenn ich diesen Satz richtig verstanden habe wird einem hier empfohlen den privaten Schlüssel der selbst erstellten Zertifikate auszutauschen. Nur wie man das macht steht da nicht und in meinem "app-crypt/xca" lässt sich dazu auch nichts finden.

Was jetzt? OpenSSL ist auf der Konsole alles andere als benutzerfreundlich.

----------

## arfe

Was wohl? Einfach eine neue keyphrase eingeben.

Und wozu brauchst Du bei openssl eine GUI? Vielleicht verwendest Du einfach nur das falsche OS!

----------

## py-ro

Nein, nur eine neue keyphrase hilft _nicht_, den der Key liegt ungeschützt im Speicher des Servers, er muss ihn ja schließlich verwenden.

Es müssen neue Schlüssel, neue Zertifikate erzeugt und die alten Zertifikate Widerrufen werden, ansonsten ist es Sinn frei.

Bye

Py

@Arfe Könntest Du dir bitte die dummen Kommentare verkneifen?

----------

## arfe

 *py-ro wrote:*   

> @Arfe Könntest Du dir bitte die dummen Kommentare verkneifen?

 

Du kennst schmidicom noch nicht.   :Very Happy: 

Er möchte bei Gentoo die Funktionalität eines Windows 7 Desktops.   :Very Happy: 

----------

## py-ro

Ja, und? Ist trotzdem kein Grund. Aber das wird hier jetzt zu OT.

----------

## Finswimmer

@Arfe: Bitte unterlasse solche Kommentare. Auf eine normale Frage sollte auch normal geantwortet haben.

Falls Dir die Art von schmidicom nicht gefällt, dann antworte nicht...

----------

## schmidicom

 *py-ro wrote:*   

> Nein, nur eine neue keyphrase hilft _nicht_, den der Key liegt ungeschützt im Speicher des Servers, er muss ihn ja schließlich verwenden.
> 
> Es müssen neue Schlüssel, neue Zertifikate erzeugt und die alten Zertifikate Widerrufen werden, ansonsten ist es Sinn frei.

 

Sowas habe ich schon befürchtet aber wenigstens hält sich der Aufwand dafür bei mir noch in grenzen, nur wie machen das eigentlich die großen CA's?

----------

## py-ro

Die CAs? Die bekommen nur CSR und zeichnen die ab.

Ansonsten reine fleiß Arbeit.

----------

## schmidicom

 *py-ro wrote:*   

> Die CAs? Die bekommen nur CSR und zeichnen die ab.
> 
> Ansonsten reine fleiß Arbeit.

 

Mit CA's meinte ich solche Zertifizierungsstellen wie Beispielweise VeriSign und was die machen wenn deren Schlüssel zum RootCA (ob nun durch einen Softwarebug oder einfachen Diebstahl) kompromittiert ist.

Inzwischen ist auf Heise noch ein Artikel mit etwas mehr Informationen zu diesem Thema online gegangen. Also nach dem was ich dort lese ist der Schlüssel zum Zertifikat technisch gesehen in Ordnung, nur besteht durch die Lücke einfach die Möglichkeit das er gestohlen worden sein könnte. Aber da meine RootCA nicht auf einem vom Internet aus erreichbaren Server liegt müsste diese ja eigentlich sicher sein, oder?

----------

## py-ro

Die CA Keys sind für gewöhnlich nicht auf erreichbaren Systemen gespeichert und für normale Anwendungen auch nicht nötig. Man könnte theoretisch das Root Zertifikat mit Key nutzen, aber das wäre absolut unüblich und dämlich.

----------

## slick

Aktuell gibt es Anzeichen für ein Ausnutzen bereits seit Nov. '13. (http://www.golem.de/news/openssl-bug-spuren-von-heartbleed-schon-im-november-2013-1404-105782.html ). Logwütige Admins sind hier aufgerufen alte Logs zu durchforsten.

----------

## ChrisJumper

Fefe hat dazu einen Artikel bei der FAZ geschrieben.

Bisher ging ich der Vermutung nach das man bei openssl auch auf der Sicheren Seite war wenn das Useflag tls-heartbeat nicht gesetzt wurde. Aber ja besser ist es neue Schlüssel zu generieren.

----------

## forrestfunk81

 *py-ro wrote:*   

> Die CA Keys sind für gewöhnlich nicht auf erreichbaren Systemen gespeichert und für normale Anwendungen auch nicht nötig. Man könnte theoretisch das Root Zertifikat mit Key nutzen, aber das wäre absolut unüblich und dämlich.

 

Ich benutze keine CA Keys sondern self-signed Zertifikate. Wie ist das damit? Laut einem Artikel aus dem alten Gentoo Wiki (leider nicht mehr online) sollte man die Keys folgendermaßen erstellen:

```
openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout server.key -out server.crt
```

Das ergibt dann den privaten Key server.key und das zugehörige Zertifikat server.crt. Für Apache sind die so angegeben:

```

# grep SSLCertificate /etc/apache2/vhosts.d/00_default_ssl_vhost.conf 

        SSLCertificateFile /etc/ssl/apache2/server.crt

        SSLCertificateKeyFile /etc/ssl/apache2/server.key
```

So wie ich das verstanden habe, besteht die Möglichkeit, dass mein privater Key (server.key) ausgelesen wurde. Deshalb habe ich beides mal ausgetauscht und hoffe, damit auf der sicheren Seite zu sein.

----------

## cryptosteve

 *ChrisJumper wrote:*   

> Bisher ging ich der Vermutung nach das man bei openssl auch auf der Sicheren Seite war wenn das Useflag tls-heartbeat nicht gesetzt wurde. Aber ja besser ist es neue Schlüssel zu generieren.

 

Nach meinem Verständnis ist ein System mit nicht gesetztem tls-heartbeat in dieser Hinsicht nicht anfällig. Demnach besteht hier auch keine Notwendigkeit, die Schlüssel neu zu erstellen. Voraussetzung ist allerdings, dass die Keys und Zertifikate auch wirklich nur auf diesem System genutzt werden bzw. wurden.

----------

