Hypertext Transfer Protocol Secure

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von HTTPS)
Wechseln zu: Navigation, Suche
HTTPS (Hypertext Transfer Protocol Secure)
Familie: Internetprotokollfamilie
Einsatzgebiet: Verschlüsselte Datenübertragung
Port: 443/TCP
HTTPS im TCP/IP‑Protokollstapel:
Anwendung HTTP
Transport SSL/TLS
TCP
Internet IP (IPv4, IPv6)
Netzzugang Ethernet Token
Bus
Token
Ring
FDDI
Standards: RFC 2818 (HTTP Over TLS, 2000)

HyperText Transfer Protocol Secure (HTTPS, englisch für sicheres Hypertext-Übertragungsprotokoll) ist ein Kommunikationsprotokoll im World Wide Web, um Daten abhörsicher zu übertragen.

Technisch definiert es als URI-Schema eine zusätzliche Schicht zwischen HTTP und TCP. HTTPS wurde von Netscape entwickelt und zusammen mit SSL 1.0 erstmals 1994 mit deren Browser veröffentlicht.

Nutzen[Bearbeiten]

Das HTTPS-Protokoll wird zur Verschlüsselung und zur Authentifizierung der Kommunikation zwischen Webserver und Browser (Client) im World Wide Web verwendet.

Ohne Verschlüsselung sind Web-Daten für jeden, der Zugang zum entsprechenden Netz hat, als Klartext lesbar. Mit der zunehmenden Verbreitung von Funkverbindungen, die etwa an WLAN-Hotspots häufig unverschlüsselt ablaufen, nimmt die Bedeutung von HTTPS zu, da damit die Inhalte unabhängig vom Netz verschlüsselt werden. Es stellt dabei das einzige Verschlüsselungsverfahren dar, das ohne gesonderte Softwareinstallation auf allen Internetfähigen Computern unterstützt wird.

Die Authentifizierung dient dazu, dass sich jede Seite der Verbindung vor dem Aufbau der Kommunikation der Identität des Verbindungspartners vergewissern kann – ein Bedarf, der durch die steigende Zahl von Phishing-Angriffen ebenfalls wächst.

Technik[Bearbeiten]

Syntaktisch ist HTTPS identisch mit dem Schema für HTTP, die zusätzliche Verschlüsselung der Daten geschieht mittels SSL/TLS: Unter Verwendung des SSL-Handshake-Protokolls findet zunächst eine geschützte Identifikation und Authentifizierung der Kommunikationspartner statt. Anschließend wird mit Hilfe asymmetrischer Verschlüsselung oder des Diffie-Hellman-Schlüsselaustauschs ein gemeinsamer symmetrischer Sitzungsschlüssel ausgetauscht. Dieser wird schließlich zur Verschlüsselung der Nutzdaten verwendet.

Der Standard-Port für HTTPS-Verbindungen ist 443.

Neben den Server-Zertifikaten können auch signierte Client-Zertifikate nach X.509.3 erstellt werden. Das ermöglicht eine Authentifizierung der Clients gegenüber dem Server, wird jedoch selten eingesetzt.

Eine ältere Protokollvariante von HTTPS war S-HTTP.

Client-Verarbeitung[Bearbeiten]

Mit der Entwicklung von HTTPS durch Netscape wurde das Protokoll und die anwenderseitige Client-Software schon früh in den Browser integriert. Damit ist, anders als etwa bei E-Mail (S/MIME oder GnuPG), SSH oder SFTP, die Installation gesonderter Software durch den Anwender nicht notwendig.

SSL Symbol.png

Eine HTTPS-Verbindung wird durch eine https-URL angewählt und durch das SSL-Logo angezeigt – beim Internet Explorer 6 ein Schloss-Icon in der Statusleiste, bei Mozilla zusätzlich in der Adresszeile, die bei Firefox, aktuellen Opera- und Internet-Explorer-7-Browsern zusätzlich gelb hinterlegt wird, bei Apple Safari 3.0 durch ein kleines Schloss-Symbol in der obersten rechten Ecke des Browserfensters.

Varianten der HTTPS-Anwahl[Bearbeiten]

Die Entscheidung, ob eine sichere HTTPS- statt einer HTTP-Verbindung genutzt wird, kann unterschiedlich erfolgen:

  • Serverseitig wird ausschließlich HTTPS zugelassen, wie meist bei Online-Banking; teils wird dabei eine angewählte http-Adresse automatisch in https umgewandelt.
  • Der Login wird über HTTPS erzwungen, dann wird ein HTTP-Cookie im Browser gesetzt und, um Rechenzeit zu sparen, der weitere Dienst unverschlüsselt abgewickelt; z. B. bei SourceForge oder eBay.
  • Login per http-Adresse, die aber vom Anwender manuell in „https…“ geändert werden kann, um eine Verschlüsselung zu bewirken; z. B. bei GMX; teils auch über einen Link „Sicheres Login“ o. ä.
  • Clientseitiges Browser-Add-on (z. B. für Firefox „HTTPS Everywhere“) welches http-Anfragen durch https-Anfragen ersetzt, falls der Server das Protokoll unterstützt. Z. B. würde der Zugriff auf „http://de.wikipedia.org/wiki/Wikipedia:Hauptseite“ automatisch umgeleitet auf „https://de.wikipedia.org/wiki/Wikipedia:Hauptseite“.

Nach Anwahl der HTTPS-Adresse soll der Client-Browser dem Anwender zuerst das Zertifikat anzeigen, sofern es nicht automatisch über bereits akzeptierte Zertifikate überprüft werden kann. Dieser entscheidet nun, gegebenenfalls nach Prüfung über die angegebenen Links, ob er dem Zertifikat für diese Sitzung vertraut, ggf. es auch permanent speichert. Andernfalls wird die HTTPS-Verbindung nicht hergestellt („Diese Seite verlassen“ bei Firefox bzw. „Klicken Sie hier um diese Seite zu verlassen.“ beim Internet Explorer).

Vorinstallierte Zertifikate[Bearbeiten]

Um diese für Unkundige eventuell irritierende Abfrage zu vermeiden, wurde mit der Zeit eine Reihe von Root-Zertifikaten von den Browserherstellern akzeptiert, die schon bei der Installation eingetragen werden. Webseiten, die entsprechende Zertifikate haben, werden dann, ebenso wie davon abgeleitete Unter-Zertifikate, bei Aufruf ohne Nachfrage akzeptiert. Ob ein Root-Zertifikat dem Browser bekannt ist, hängt von der Browser-Version ab; zudem wird die Liste der Zertifikate teils auch online im Rahmen der Systemaktualisierung auf den neuesten Stand gebracht, so bei Microsoft Windows.

Mit dem Internet Explorer 7 hat Microsoft, kurz danach auch Mozilla mit dem Firefox 3, die Warnung bei nicht eingetragenen Zertifikaten verschärft: Erschien vorher nur ein Pop-up „Sicherheitshinweis“, das nach Name, Quelle und Laufzeit des Zertifikats differenzierte, so wird nun der Inhalt der Webseite ausgeblendet und eine Warnung angezeigt, mit der Empfehlung, die Seite nicht zu benutzen. Um diese sehen zu können, muss der Anwender dann explizit eine „Ausnahme hinzufügen“. Ein nicht im Browser eingetragenes Zertifikat wird damit für Massenanwendungen zunehmend untauglich.

Die Frage, welche Zertifikate in die Browser aufgenommen werden, hat in der Open-Source-Community fallweise zu längeren Diskussionen geführt, so zwischen CAcert, einem Anbieter kostenloser Zertifikate, und der Mozilla Foundation, siehe CAcert (Vertrauenswürdigkeit).

Server-Voraussetzungen[Bearbeiten]

Als Software zum Betrieb eines HTTPS-fähigen Webservers wird eine SSL-Bibliothek wie OpenSSL benötigt. Diese wird häufig bereits mitgeliefert oder kann als Modul installiert werden. Der HTTPS-Service wird üblicherweise auf Port 443 bereitgestellt.

Zertifikat[Bearbeiten]

Weiterhin ist ein digitales Zertifikat für SSL notwendig: Ein Binärdokument, das im Allgemeinen von einer – selbst wiederum zertifizierten – Zertifizierungsstelle (CA von englisch certificate authority) ausgestellt wird, das den Server und die Domain eindeutig identifiziert. Bei der Beantragung werden dazu etwa die Adressdaten und die Firmierung des Antragstellers geprüft.

In den registrierten Root-Chains eingetragene Zertifikate werden typischerweise zu Preisen zwischen 39 und 1200 US-$ pro Jahr angeboten, wobei fallweise weitere Dienste, Siegel oder Versicherungen enthalten sind. Eine Reihe von Zertifizierungsstellen gibt kostenlos Zertifikate aus. Die etwa von StartCom[1] ausgestellten Zertifikate werden dabei von fast allen modernen Browsern ohne Fehlermeldung akzeptiert. Ebenfalls kostenlose Zertifikate erstellt CAcert, wo es bisher jedoch nicht gelang, in die Liste der vom Browser automatisch akzeptierten Zertifikate aufgenommen zu werden; siehe oben. Ein solches Zertifikat muss daher bei der Client-Verarbeitung vom Anwender manuell importiert werden; dieses Verhalten kann aber auch erwünscht sein.

Auch ist es möglich, selbst-signierte Zertifikate (engl. self-signed certificate) zu verwenden, die ohne Beteiligung einer gesonderten Instanz erstellt wurden und ebenfalls manuell bestätigt werden müssen. Ein so erstelltes Zertifikat ist aber nur dann sicher, wenn es vor der Erstverwendung dem Anwender auf einem sicheren Weg zugestellt und von ihm in seine Client-Anwendung importiert wurde. Wurde der beschriebene sichere Erstzustellungsprozess nicht durchgeführt, sind Verbindungen mit dem betroffenen Zertifikat verwundbar durch einen Man-in-the-middle-Angriff.

Um veraltete oder unsicher gewordene Zertifikate für ungültig zu erklären, sind Zertifikatsperrlisten (engl. certificate revocation list, CRL) vorgesehen. Die Konzeption sieht vor, dass diese Listen regelmäßig etwa von Browsern geprüft und darin gesperrte Zertifikate ab sofort abgewiesen werden. Das Verfahren ist jedoch nicht durchgängig organisiert und wird praktisch nur wenig genutzt.

Zu Angriffen auf das Zertifikatsystem, siehe unten.

Extended-Validation-Zertifikat[Bearbeiten]

Vor dem Hintergrund zunehmender Phishing-Angriffe auf HTTPS-gesicherte Webanwendungen hat sich 2007 in den USA das CA/Browser Forum[2] gebildet, das aus Vertretern von Zertifizierungsorganisationen und den Browser-Herstellern Google, KDE, Microsoft, Mozilla und Opera besteht. Im Juni 2007 wurde daraufhin eine erste gemeinsame Richtlinie verabschiedet, das Extended-Validation-Zertifikat, kurz EV-SSL in Version 1.0, im April 2008 dann Version 1.1.

Ein Domain-Betreiber muss für dieses Zertifikat weitere Prüfungen akzeptieren: Während bisher nur die Erreichbarkeit des Admins (per Telefon und E-Mail) zu prüfen war, wird nun die Postadresse des Antragstellers überprüft und bei Firmen die Prüfung auf zeichnungsberechtigte Personen vorgenommen. Damit sind auch deutlich höhere Kosten verbunden, exemplarisch 650 € p. a.

Für den Anwender macht sich das EV-Zertifikat durch eine zusätzliche weiß auf grün unterlegte Firma in der Adresszeile des neueren Browsers (ab 2007, also etwa Firefox 3 und IE7), rechts vom Site-Logo, bemerkbar. Durch das Ausbleiben der (für diese Site) gewohnten grünen Farbe soll der Anwender dann gefälschte HTTPS-Sites schnell und ggf. auch intuitiv – also ohne spezielle Schulung – erkennen können.

IP-Adresse[Bearbeiten]

Zum Betrieb eines HTTPS-Webservers war lange Zeit eine eigene IP-Adresse pro Hostname notwendig.

Bei unverschlüsseltem HTTP ist das nicht notwendig: Seitdem Browser den Hostnamen im HTTP-Header mitsenden, können mehrere virtuelle Webserver mit je eigenem Hostnamen auf einer IP-Adresse bedient werden, zum Beispiel bei Apache über den NameVirtualHost-Mechanismus. Dieses Verfahren wird inzwischen bei der weit überwiegenden Zahl der Domains benutzt, da hier der Domain-Eigner selbst keinen Server betreibt.

Da bei HTTPS jedoch der Webserver für jeden Hostnamen ein eigenes Zertifikat ausliefern muss, der Hostname aber erst nach erfolgtem SSL-Handshake in der höheren HTTP-Schicht übertragen wird, ist das Deklarieren des Hostnamen im HTTP-Header hier nicht anwendbar. Die Information muss daher bereits beim SSL-Handshake übermittelt werden, was seit TLS 1.2 mithilfe von Server Name Indication (SNI) realisiert wird. Zuvor war eine Unterscheidung nur anhand der IP/Port-Kombination möglich; ein anderer Port als 443 wird wiederum von vielen Proxys nicht akzeptiert.

Server Name Indication[Bearbeiten]

Mit der neueren Spezifikation Transport Layer Security 1.2 ist der Betrieb mehrerer Domains unter der gleichen IP via SNI möglich. Zusätzlich können mehrere Domain-Namen in ein Zertifikat mittels des Parameters SubjAlt-Name eingesetzt werden. Aktuelle Browser, wie beispielsweise Mozilla Firefox ab Version 2.0 oder der Internet Explorer ab Version 7 (jedoch nur ab Windows Vista), unterstützen SNI bereits.[3]

Shared SSL[Bearbeiten]

Um ihren Kunden auch HTTPS ohne eigene IP-Adresse zu ermöglichen, benutzen einige Provider spezielle „shared SSL“ oder auch „wildcard certificates“. Das Zertifikat bezieht sich normalerweise auf die komplette Domain, also Third-, Second- und Top-Level-Segmente, wie https://www.kunde1.com. Bei shared SSL kann nun die Third-Level-Domain kundenspezifisch vergeben werden – also etwa https://kunde1.provider.com, während sich das Zertifikat auf *.provider.com bezieht. Der Provider kann so mit einem Zertifikat mehreren Kunden https ermöglichen.

Eine weitere Variante besteht darin, eine Weiterleitung auf einen von mehreren Domains genutzten HTTPS-Server vorzunehmen, etwa https://provider.com/ssl/kunde1/.

Einbindung[Bearbeiten]

Die Einbindung von HTTPS in eine Website oder -anwendung erfolgt analog zu den oben genannten Varianten der HTTPS-Anwahl:

  • Wenn ausschließlich HTTPS zulässig ist, kann das umgesetzt werden durch:
    • Weiterleitung (HTML-refresh) oder auch ein rewrite der URL
    • Konfiguration von HTML-Seiten oder Skripten als Muss-SSL, bei Apache etwa durch die Anweisung SSLRequireSSL in der .htaccess. Wird eine solche Seite per http aufgerufen, erzeugt der Server einen '403 - Forbidden' HTTP-Fehlercode.
  • Der Anwender wird auf die Möglichkeit der SSL-Nutzung durch einen entsprechenden Link hingewiesen. Auf diese Weise wird die Serverlast gering gehalten, während sicherheitsbewusste Nutzer nicht abgewiesen werden.
    • Teils wird auch der Link weggelassen, und der Anwender kann https nutzen, indem er in der URL selbstständig ein „s“ hinter „http“ eintippt.
  • Skriptgesteuerte Erzeugung von HTTPS-Links, um den Anwender bei bestimmten Arbeitsschritten oder Ausgaben auf eine HTTPS-Seite zu lenken. Anschließend kann im Skript geprüft werden, ob dieses per HTTPS aufgerufen wurde, bei PHP etwa durch die Bedingung: $_SERVER['HTTPS']=='on'

Leistung[Bearbeiten]

Die Verschlüsselung auf Serverseite ist rechenaufwändig und belastet die Server-CPUs häufig stärker als etwa das Generieren des HTML-Codes aus einer Skriptsprache. Auch aus diesem Grunde hat sich HTTPS bisher nur bei einem kleinen Teil der Websites durchgesetzt, bei denen es aus Sicht des Datenschutzes sinnvoll ist.

Die Liste der vom Server unterstützten Verschlüsselungsalgorithmen wird serverseitig konfiguriert. Der Client wählt dann den ersten von ihm unterstützten Algorithmus aus dieser Liste aus. Um Rechenzeit zu sparen, werden auf Servern mit hohem Datenverkehr bevorzugt Strom-Chiffren wie RC4 (bis 128 Bit) verwendet, da diese weniger rechenintensiv sind als Block-Chiffren wie AES oder Camellia (bis 256 Bit). Anfangs teils noch genutzte 40-Bit-Schlüssel-Algorithmen, die wiederum weniger Rechenlast verursachen, gelten nicht mehr als sicher und werden daher heute nicht mehr verwendet.

Zur Entlastung der Server-CPU werden auch Hardware-SSL-Beschleuniger (SSL accelerators) angeboten: PCI-Steckkarten mit speziellen, optimierten Prozessoren, die aus der SSL-Bibliothek angesprochen werden. Daneben gibt es auch eigenständige Geräte, meist in Rack-Bauweise, die Teile des HTTP-Datenstroms automatisch verschlüsseln. Weiterhin werden Server mit programmierbaren Recheneinheiten angeboten, die mit entsprechenden SSL-Bibliotheken höhere Leistung als vergleichbar aufwendige Universal-CPUs erreichen, so die MAU (Modular Arithmetic Unit) von Sun.

Spezielle Hardware steht aber im engen Wettbewerb mit der stetigen Entwicklung der Multiprozessor- und Multi-Core-Systeme der großen CPU-Hersteller Intel und AMD.[4]

Angriffe und Schwachstellen[Bearbeiten]

Mit den allgemein zunehmenden Kenntnissen über die HTTPS-Technik haben sich auch die Angriffe auf SSL-gesicherte Verbindungen gehäuft. Daneben sind durch Recherche und Forschungen Lücken in der Umsetzung bekannt geworden. Dabei ist grundsätzlich zu unterscheiden zwischen Schwachstellen bei der Verschlüsselung selbst und im Zertifikatsystem.

Am 5. September 2013 wurde im Zusammenhang mit der globalen Überwachungs- und Spionageaffäre bekannt, dass die NSA sich über beide Angriffskanäle Zugang durch ein Programmsystem namens Bullrun verschafft hat.

Verschlüsselung[Bearbeiten]

Die bei SSL eingesetzten Verschlüsselungsverfahren werden unabhängig von ihrem Einsatzzweck regelmäßig überprüft und gelten als mathematisch sicher, d. h. sie lassen sich theoretisch mit den heute bekannten Techniken nicht brechen. Die Zuverlässigkeit der Algorithmen wird regelmäßig etwa durch Wettbewerbe unter Kryptologen überprüft.

Im Mai 2008 wurde jedoch ein Fehler in der OpenSSL-Bibliothek der Debian-Linux-Distribution und davon abgeleiteten Derivaten wie Ubuntu bekannt, der bereits seit September 2006 bestand.[5][6] Der Fehler bewirkte, dass mit einem solchen OpenSSL erzeugte Schlüssel in einem sehr viel kleineren Bereich liegen, mit überschaubarem Aufwand gebrochen und damit die Daten ggf. auch nachträglich entschlüsselt werden können. Serverbetreiber mussten daraufhin nicht nur ihre SSL-Software prüfen, sondern ggf. auch die im Laufe der zwei Jahre damit erstellten Schlüssel nachverfolgen und erneuern.

Für die Anwenderseite wurden daraufhin Möglichkeiten entwickelt, über Browser-Plug-ins einerseits „schwache“ Zertifikate angezeigt zu bekommen, andererseits erweiterte Prüfungen auf Browser-Seite vorzunehmen; so befragt das „Perspectives“-Plugin mehrere „Notare“, welches Zertifikat sie bei der gleichen Site sahen.[7]

Der Vorgang führte auch zu Kritik an den Prozessen bei Debian und am Open-Source-Entwicklungsmodell im Ganzen, etwa bei heise.de: „Das offensichtliche Fehlen von wirksamen Qualitätssicherungsmechanismen bei der Pflege von sicherheitskritischen Programmpaketen (…) wird es Verfechtern von Open-Source-Software nicht unbedingt leichter machen, diese im professionellen Umfeld einzusetzen.“[8]

Zertifikatsystem[Bearbeiten]

SSL-Verbindungen sind grundsätzlich gefährdet durch Man-in-the-middle-Angriffe, bei denen der Angreifer den Datenverkehr zwischen Client und Server abfängt, indem dieser sich beispielsweise als Zwischenstelle ausgibt. Eine Reihe von Angriffsverfahren setzen voraus, dass der Angreifer sich im Netzwerk des Opfers befindet. Beim DNS-Spoofing wiederum bestehen diese Voraussetzungen nicht.

Um sich als (anderer) Server auszugeben, muss der Angreifer auch ein Zertifikat vorweisen. Das ist ihm beispielsweise dann möglich, wenn es ihm gelingt in das System einer Zertifizierungsstelle einzudringen oder anderweitig in den Besitz eines Zertifikats kommt, mit dem sich beliebige andere Zertifikate ausstellen lassen. Insbesondere bei einflussreichen Angreifern, wie etwa Regierungsbehörden, können solche Möglichkeiten bestehen, da mitunter auch staatliche Zertifizierungsstellen existieren.[9]

Phishing und HTTPS[Bearbeiten]

Ein Nachteil der automatischen Bestätigung der Zertifikate besteht darin, dass der Anwender eine HTTPS-Verbindung nicht mehr bewusst wahrnimmt. Das wurde in jüngerer Zeit bei Phishing-Angriffen ausgenutzt, die etwa Online-Banking-Anwendungen simulieren und dem Anwender eine sichere Verbindung vortäuschen, um eingegebene PIN/TAN-Codes „abzufischen“. Als Reaktion wiesen betroffene Unternehmen ihre Kunden darauf hin, keine Links aus E-Mails anzuklicken und https-URLs nur manuell oder per Lesezeichen einzugeben.

Wegen der teils oberflächlichen Prüfungen bei der Vergabe von Zertifikaten wurde von den Browserherstellern das extended-validation-Cert eingeführt, siehe oben.

Warnungen bei Gemischtbetrieb[Bearbeiten]

Im Rahmen der immer ausgeklügelteren Phishing-Angriffe wurde ein weiteres Problem erkannt: Der Wechsel einer https-verschlüsselten Seite zu einer unverschlüsselten sowie das Nachladen von unverschlüsselten Inhalten aus einer per HTTPS übertragenen Seite. Während es – aus Performancegründen – seitens des Anbieters durchaus sinnvoll sein kann, nur einzelne Elemente einer Seite HTTPS-gesichert auszugeben, stellt es auch eine mögliche Sicherheitslücke dar. Daher blenden die gängigen Browser in solchen Fällen Warnhinweise ein. Damit diese auf Dauer nicht stören, können sie im Allgemeinen durch eine Checkbox direkt bleibend abgeschaltet werden – womit aber auch der Warneffekt bei tatsächlichen Angriffen entfällt.

HSTS[Bearbeiten]

Als eine Maßnahme gegen sogenannte Man-in-the-middle-Angriffe wurde im September 2009 erstmals das HTTP Strict Transport Security- oder kurz HSTS-Verfahren vorgeschlagen.[10] Im November 2012 wurde HSTS als RFC 6797 herausgegeben. Der vom Betreiber entsprechend eingerichtete Dienst sendet hier den besonderen HTTP response header namens „Strict-Transport-Security“ und unter anderem einen Zeitraum, für den nach Ende einer Sitzung bei der erneuten Kommunikation die Gegenseite wiedererkannt wird und zwangsweise die Verschlüsselung erzwingt.

Ein dafür ausgelegter Browser – Stand August 2010 sind der Firefox (ab Ausgabe 4, Beta), dessen NoScript-Erweiterung sowie Chrome (ab Ausgabe 4.0.211) – wird daraufhin diese Sitzung (englisch session) für die angegebene Zeit ausschließlich verschlüsselt abwickeln. Dazu gehört auch die eigenständige Umwandlung von HTTP-Adressen in HTTPS sowie die Ausgabe einer Fehlermeldung und der Abbruch der Verbindung, falls die verschlüsselte Übertragung irgendeine Fehlermeldung bewirkt.

Voraussetzung ist natürlich, dass die ursprüngliche Anfrage (initial request) erfolgreich vom (originalen) HTTPS-Server aufgebaut wurde.

Angriffe auf das Zertifikatsystem[Bearbeiten]

Grundsätzlich stellen auch HTTPS-Verbindungen mit vorinstallierten Zertifikaten keine absolute Sicherheit her.[11]

Im Rahmen des 25. Chaos Communication Congress in Berlin wurde im Dezember 2008 ein erfolgreicher Angriff auf das SSL-Zertifikatsystem veröffentlicht. In internationaler Zusammenarbeit von Kryptologen und mit Einsatz speziell programmierter Hardware – einem Cluster aus 200 Playstation-3-Spielkonsolen – war es gelungen, im MD5-Algorithmus eine Kollision zu erzeugen, auf deren Basis ein Angreifer sich selbst beliebige Zertifikate ausstellen könnte.[12] Von der Verwendung des MD5-Algorithmus wurde in Fachkreisen vorher schon abgeraten, bei EV-Zertifikaten kann er ohnehin nicht verwendet werden.

Anlässlich dieser Veröffentlichung wurde unter Experten auch die neuerdings scharfe Trennung der Browser zwischen eingetragenen und unbekannten Zertifikaten (siehe oben) kritisch hinterfragt.[13]

Spezifikationen[Bearbeiten]

Weblinks[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. Vorlage:Internetquelle/Wartung/Zugriffsdatum nicht im ISO-FormatVorlage:Internetquelle/Wartung/Datum nicht im ISO-FormatHeise-Online: Mozilla vertraut kostenlosen StartCom Zertifikaten. 3. Juni 2006, abgerufen am 4. März 2010.
    Vgl. dazu auch Comparison of SSL certificates for web servers in der englischsprachigen Wikipedia.
  2. cabforum.org.
  3. CaCert.org: CAcert Wiki VhostTaskForce, 3. Way: Certificate with 1 Common Name + 2 Subject Alt Names, 4. Oktober 2007.
  4. Quad Core Intel Xeon SSL Performance auf anandtech.com, 27. Dezember 2006.
  5. debian.org:DSA-openssl -- predictable random number generator, 13. Mai 2008.
  6. Konsequenzen der erfolgreichen Angriffe auf MD5. Auf heise.de, 6. Januar 2009, abgerufen am 3. Januar 2013.
  7. Der Perspective Firefox Plugin.
  8. Gute Zahlen, schlechte Zahlen – Die Bedeutung der Zufallszahlen beim OpenSSL-Debakel. Auf heise.de, 27. Mai 2008, abgerufen am 3. Januar 2013.
  9. EFF zweifelt an Abhörsicherheit von SSL auf heise security, abgerufen am 28. Juni 2013
  10. w3.org: Strict Transport Security
  11. SSL-GAU zwingt Browser-Hersteller zu Updates. Auf heise.de, 19. Oktober 2012.
  12. 25C3: Erfolgreicher Angriff auf das SSL-Zertifikatsystem. Auf heise.de, 30. Dezember 2008, abgerufen am 3. Januar 2013.
  13. Vertrauenswürdigkeit von Zertifikaten auf heise security news-Foren, 30. Dezember 2008.