OpenSSL Sicherheitslücke Heartbleed: Schlüssel eines TLS-Servers auslesen
Eine neue gefährliche OpenSSL-Sicherheitslücke wurde bekannt. Die mit dem Namen "Heartbleed" entdeckte Sicherheitslücke ermöglicht das Auslesen des privaten Schlüssel eines TLS-Servers. Jeder Server, auf dem OpenSSL installiert ist, sollte von einem Administrator dringend überprüft werden!
Korrigierte Pakete für Ubuntu, Debian und Fedora sind bereits verfügbar. Die CVE dazu lautet: CVE-2014-0160
Hier findet ihr einen Online-Check für HTTPS Seiten: http://possible.lv/tools/hb/
Hier findet ihr weitere Informationen zu "Heartbleed" : http://heartbleed.com/
Gruß
Frank
http://www.golem.de/news/sicherheitsluecke-keys-auslesen-mit-openssl-14 ...
Korrigierte Pakete für Ubuntu, Debian und Fedora sind bereits verfügbar. Die CVE dazu lautet: CVE-2014-0160
Hier findet ihr einen Online-Check für HTTPS Seiten: http://possible.lv/tools/hb/
Hier findet ihr weitere Informationen zu "Heartbleed" : http://heartbleed.com/
Gruß
Frank
http://www.golem.de/news/sicherheitsluecke-keys-auslesen-mit-openssl-14 ...
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 234858
Url: https://administrator.de/forum/openssl-sicherheitsluecke-heartbleed-schluessel-eines-tls-servers-auslesen-234858.html
Ausgedruckt am: 20.04.2025 um 02:04 Uhr
5 Kommentare
Neuester Kommentar
Noch ein Punkt der beachtet werden sollte:
Die auf betroffenen Systemen eingesetzten Zertifikate sollten nicht nur entfernt sondern bei der zuständigen CA widerrufen werden. Ansonsten ist es auch später noch möglich das ein MitM Angriff mit dem geleakten Key und dem öffentlich verfügbaren Zertifikat durchgeführt wird, ohne das der Client eine Möglichkeit hat den Betrug zu bemerken. Falls der Client keine OCSP oder CRL Prüfung durchführt hilft das dann allerdings auch nicht mehr...
Es wird wohl endlich Zeit für DANE (http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities ..)
Gruß
Andi
Die auf betroffenen Systemen eingesetzten Zertifikate sollten nicht nur entfernt sondern bei der zuständigen CA widerrufen werden. Ansonsten ist es auch später noch möglich das ein MitM Angriff mit dem geleakten Key und dem öffentlich verfügbaren Zertifikat durchgeführt wird, ohne das der Client eine Möglichkeit hat den Betrug zu bemerken. Falls der Client keine OCSP oder CRL Prüfung durchführt hilft das dann allerdings auch nicht mehr...
Es wird wohl endlich Zeit für DANE (http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities ..)
Gruß
Andi
Wer lieber offline testet: https://gist.github.com/takeshixx/10107280
Hier ein etwas umfangreicherer Check:
https://www.ssllabs.com/ssltest/
Ergebis für meine owncloud Installation A-
https://www.ssllabs.com/ssltest/
Ergebis für meine owncloud Installation A-
Wie im anderen Post schon geschrieben sind wir hier sauber...
root@raspi:/home/pi# python hb-test.py www.administrator.de
Connecting...
Sending Client Hello...
Waiting for Server Hello...
... received message: type = 22, ver = 0302, length = 58
... received message: type = 22, ver = 0302, length = 3242
... received message: type = 22, ver = 0302, length = 4
Sending heartbeat request...
Unexpected EOF receiving record header - server closed connection
No heartbeat response received, server likely not vulnerable
und
root@raspi:/home/pi# ./check-ssl.pl www.administrator.de:https
...ssl received type=22 ver=0x302 ht=0x2 size=54
...ssl received type=22 ver=0x302 ht=0xb size=3238
...ssl received type=22 ver=0x302 ht=0xe size=0
...send heartbeat#1
no reply - probably not vulnerable
Die entsprechenden Python und Perl Scripte zum Test gibt es frei zum Download.
root@raspi:/home/pi# python hb-test.py www.administrator.de
Connecting...
Sending Client Hello...
Waiting for Server Hello...
... received message: type = 22, ver = 0302, length = 58
... received message: type = 22, ver = 0302, length = 3242
... received message: type = 22, ver = 0302, length = 4
Sending heartbeat request...
Unexpected EOF receiving record header - server closed connection
No heartbeat response received, server likely not vulnerable
und
root@raspi:/home/pi# ./check-ssl.pl www.administrator.de:https
...ssl received type=22 ver=0x302 ht=0x2 size=54
...ssl received type=22 ver=0x302 ht=0xb size=3238
...ssl received type=22 ver=0x302 ht=0xe size=0
...send heartbeat#1
no reply - probably not vulnerable
Die entsprechenden Python und Perl Scripte zum Test gibt es frei zum Download.