SSL

aus SecuPedia, der Plattform für Sicherheits-Informationen

(Weitergeleitet von The Hacker's Choice (THC))
Anzeige
Wechseln zu: Navigation, Suche
Beispiel: https-Seite

SSL ist die Abkürzung für Secure Socket Layer, ein von Netscape entwickeltes Protokoll für Standard-Browser zum sicheren Übertragen von vertraulichen Informationen über das Internet. SSL wurde unter dem neuen Namen TLS (Transport Layer Security) weiterentwickelt, wobei Version 1.0 von TLS der Version 3.1 von SSL entspricht.

Besonders im Online-Shopping und E-Banking ist dieses Verschlüsselungsverfahren weit verbreitet, zum Beispiel für die Übermittlung von Nutzer-und Finanzdaten oder Kontonummern. Eine sichere Verbindung per SSL wird durch das Kürzel https (http over SSL) in der URL angezeigt und kann durch Dritte nicht mitgelesen werden. Bei Initialisierung einer SSL-Verbindung (dem sogenannten SSL-Handshake) authentifiziert sich der Server über ein Public-Key-Verfahren gegenüber dem Nutzer. Dazu ist eine kostenpflichtige Zertifizierung durch Drittparteien notwendig, die die Integrität des Servers garantiert. Bei Finanztransaktionen über das Internet ist sogar eine beidseitige Authentifizierung notwendig.

Außerdem verständigen sich Client und Server während des Handshakes über den im Folgenden zu verwendenden Codeschlüssel. SSL unterstützt für die eigentliche Datenübertragung (den im Anschluss an den Handshake stattfindenden sogenannten Bulk Data Transfer) verschiedene symmetrische Verschlüsselungen, wie unter anderem 3DES (Triple Digital Encryption Standard). Die eigentliche Datenübertragung im weiteren Verlauf der SSL-Verbindung verwendet also eine symmetrische Verschlüsselung, lediglich die Initialisierung läuft über ein Public-Key-Verfahren.

Insbesondere beim Online-Banking werden die verwendeten Zertifikate oft besonders geprüft (Extended-Validation-SSL-Zertifikat oder kurz EV-Zertifikat). Im Browser wird bei solchen SSL-Verbindungen zusätzlich zum bekannten Schlosssymbol die Adresszeile grün eingefärbt. Die Vergabekriterien für solche EV-Zertifikate beinhalten allerdings mehr wirtschaftliche Faktoren und geben keinen Ausblick auf die realisierte IT-Sicherheit.

Aktuelle Sicherheitsdiskussion

Obwohl SSL lange als sicher angesehen wurde, kommen in letzter Zeit einige Diskussion zur Zukunft dieser Verschlüsselung auf. Insbesondere Google hat zwischenzeitlich, wohl auch aus Eigeninteressen als Internet-Firma, die daraus resultierenden wirtschaftlichen Gefahren erkannt und müht sich, die aufgetretenen Sicherheitsprobleme zu lösen. Dabei belasten vier Problemkreise die Sicherheit von SSL.

Sicherheitslücken im SSL-Protokoll

Die Implementierung im Protokoll SSL 3.0/TLS 1.0 ermöglichte es, bei mehreren der verwendeten Stromchiffrieralgorithmen die zufällig erzeugten Initialisierungsvektoren (zur Vermeidung, dass gleiche Blöcke das gleiche Chiffrat erzeugen) zu ermitteln. Dazu wurde für eine Man-In-the-Middle-Attacke ein entsprechendes Tool entwickelt (BEAST). Als Lösung dieses Problems wurden von den Browser-Herstellern unterschiedliche Ansätze verfolgt. Microsoft hatte als Lösung das Umschalten von TLS 1.0 auf TLS 1.1 empfohlen, was jedoch erst sehr wenige Web-Server unterstützen[1]. Die Firefox-Entwickler schlugen zunächst vor, das Java-Plug-in im Browser zu deaktivieren. Und Google hatte wieder eine andere Lösung in seinen Chrome-Browser eingearbeitet. Hier werden die Datenpakete aufgeteilt und jedem Paket ein leeres vorangestellt[2]. Auf Web-Serverseite wurde dagegen vermehrt auf den von diesem Problem nicht betroffenen älteren RC4-Algorithmus umgestellt[3]. Allerdings ist auch der RC4-Algorithmus zumindest theoretisch angreifbar[4]; Krypto-Experten spekulieren nun, ob die NSA im Rahmen ihres Ausspähprogramms schon ein effizientes Verfahren entwickelt haben könnte, um RC4-Verschlüsselungen in Echtzeit zu brechen[5]. Da mittlerweile alle Browser-Hersteller den BEAST-Angriff durch browserspezielle Vorkehrungen unmöglich gemacht haben, ist der Grund für den RC4-Einsatz entfallen, die Webserverbetreiber können also wieder zurückstellen[6]. Für Anfang 2016 haben die großen Webbrowser-Hersteller Google, Microsoft und Mozilla angekündigt, das zwischenzeitlich als unsicher geltende Verschlüsselungsverfahren RC4 nicht mehr unterstützen[7].

Analog zu RC4 ist zwischenzeitlich auch 3DES (Triple Digital Encryption Standard) veraltet. Mit dem Sweet32 genannter Angriff, der auf dem Geburtstagsparadoxon beruht, kann man über sogenannte Kollisionen kleinere Datenblöcke ggf. dechiffrieren (z.B. Authentifizierungs-Cookies). Allerdings muss man dafür eine große Datenmenge mitlesen (ca. 256 GByte Daten) [8].

Zwei Mitte 2012 bzw. Mitte 2013 entwickelte neue Protokollangriffe auf die neusten TLS-Versionen (CRIME bzw. der Nachfolger BREACH), inklusive der modernsten Version 1.2, haben jedoch fast keine Auswirkungen, da die angegriffene Kompressionsversion nur vom Chrome- und Firefox-Browser unterstützt wird, aber noch kaum von Webservern[9][10][11]. BREACH ist bisher nur ein theoretisches Angriffsszenario; jedenfalls sind keine realen BREACH-Angriffe bekannt geworden. Auch für den im August 2016 konzipierten Nachfolger HEIST (HTTP Encrypted Information can be Stolen through TCP-Windows) stellt sich die Frage, ob es tatsächlich ein realistisches Angriffsszenario ist. Ein Angreifer, der als Voraussetzung für diesen Angriff bösartigen JavaScript-Code im Browser des Opfers ausführen kann, könnte ja einfacher versuchen, gleich den gesamten Rechner infiltrieren[12]. Der im Oktober 2014 von Google-Forschern entdeckte Poodle-Angriff [13]zwingt zwischenzeitlich zur Abschaltung der veralteten Protokollversion SSL 3.0.

Endgültig kann diese Gesamtproblematik erst beim durchgängigen Einsatz der TLS-Version 1.2 gelöst werden, das BSI empfiehlt sogar schon jetzt den Einsatz für Bundesbehörden im Zusammenwirken mit PFS (s.u.)[14]. Bisher unterstützt aber lediglich der Internet-Explorer diese Version (ab Version 10 voreingestellt), Firefox und Chrome ziehen gerade nach[15][16], allerdings muss derzeit hier noch der Nutzer diese Funktionalität manuell aktivieren.

Anfang 2015 wurde von einer Gruppe von Sicherheitsforschern ein neues Angriffsszenario namens FREAK (Factoring attack on RSA-EXPORT Keys) entdeckt, das es erlaubt, mit SSL/TLS geschützten Datenverkehr zu entschlüsseln. Die Ursache ist ein Relikt aus den 90er Jahren, als die US-Regierung die Nutzung von starker Kryptographie einschränkte. Ein Angreifer kann durch Manipulation des Verbindungsaufbaus einen Rückfall auf die schwache Verschlüsselung erzwingen, sofern diese noch in die Software implementiert wurde. Dabei muss neben dem Server aber auch aber auch der Client diese schwache Verschlüsselung unterstützen. Von den gängigen Browsern sind Firefox und überwiegend Chrome nicht betroffen, verwundbar sind jedoch Android-Browser, Chrome ebenfalls auf Android und der Internet Explorer. Allerdings ist der Angriff ist zwar theoretisch einfach auszuführen, in der Realität sind aber so viele Variablen involviert, dass sich ein Angriff auf beliebige Nutzer als schwierig darstellt[17]. Später war, neben RSA, auch der Diffie-Hellman-Algorithmus betroffen (Logjam-Lücke)[18]. Ein Umschwenken auf elliptische Kurvenverfahren (ECC) schafft hier Abhilfe. Dies muss allerdings erst noch in die Browser implementiert werden (Ausnahme Internet Explorer). Anfang 2016 wurde erneut ein Angriffsszenario namens DROWN (Decrypting RSA with Obsolete and Weakend eNcryption) entdeckt, das es erlaubt, mit SSL/TLS geschützten Datenverkehr zu entschlüsseln und ebenfalls auf veralteten SSL-Versionen beruht. Dazu zeichnet der Angreifer die sichere TLS-geschützte Kommunikation auf und holt sich das geheime Schlüsselmaterial (Pre-Master Secret) über einen Serverangriff auf das veraltete SSL der Version 2.0[19].

Daneben ist im Internet ein Tool der deutschen Hacker-Gruppe "The Hacker's Choice" verfügbar, mit dem bereits ein einziger Rechner einen Web-Server mit SSL-Verschlüsselung zum Absturz bringen kann. Das dahinterstehende Konzept beruht auf der ständigen Neuaushandlungen des verwendeten asymmetrischen Schlüssels im Public-Key-Teil des SSL-Verfahrens. Hierbei muss der Web-Server eine ungleich größere Last bewältigen. Abhilfe schafft hier derzeit nur die Möglichkeit, die ständigen Schlüssel-Neuaushandlung (RENEGOTIATING) per Web-Server-Option zu verhindern. Ein anderes spezielles Angriffstool, welches DDoS-Attacken über das SSL-Protokoll ermöglicht, ist Dirt Jumper.

Im April 2014 wurde ein gravierender Fehler in dem oft verwendeten Produkt OpenSSL gefunden. Dabei erlaubt ein Programmierfehler jedem Kommunikationspartner, bis zu 64 KByte des Speichers der Gegenstelle auszulesen. Ein Angreifer kann über diesen sogenannten Heartbleed Bug dann Schlüssel, Passwörter und andere geheime Daten entwenden (z.B. hat ein Verschlüsselungsschlüssel als Datei wenige KByte). So könnte ein Angreifer den verschlüsselten Datenverkehr der letzten Jahre des Servers aufgezeichnet und mit dem geheimen Schlüssel des Servers im Nachhinein all diese Daten dechiffireren. Nur durch Einsatz von PFS (s.u.) wäre dies zu verhindern. Betroffen sind insbesondere alle LINUX/UNIX-Derivate (u.a. auch im Smartphone-Bereich ältere Android-Modelle), MacOS X soll dagegen nicht betroffen sein. Da viele Web- und auch Mailserver ebenfalls OpenSSL verwenden, ist der Betroffenheitsgrad im Internet hoch; einige Betreiber (Yahoo und Web.de) raten sogar zum Passwort-Wechsel.

Wenig später wurde eine erneute Lücke festgestellt, durch die ein Angreifer durch einen Man-In-the-Middle-Angriff die Verbindung so manipulieren kann, dass die Software auf knackbares Schlüsselmaterial zurückfällt (CVE-2014-0224) [20]. Damit kann der Datenverkehr entschlüsselt und gegebenenfalls manipuliert werden. Diese Lücke greift allerdings nur, wenn Server- und Client-Version von OpenSSL angreifbar sind. Damit sind in erster Linie die Webserverbetreiber gefordert.

Auf Grund der Verwundbarkeiten im OpenSSL wurden 4 neue SSL-Implementierung mit LibreSSL (OpenBSD Foundation), BoringSSL (Google), s2n (Amazon) sowie ReSSL angekündigt[21][22][23].

Einbrüche bei Zertifikatsdienstleistern

SSL war in den letzten Monaten vor allem aber durch gefälsche Zertifikate durch Einbrüche bei Zertifizierungsstellen ins Gespräch gekommen. Damit wird das hierarchisch aufgebaute Vertrauensmodell untergraben, das insbesondere in Browsern über die vorinstallierten Zertifikaten eine große Rolle spielt. Voreingestelle Zertifikate (auch Root-Zertifikate genannt) werden von den Browser-Herstellern schon bei der Installation eingetragen. Webseiten mit diesen entsprechende Zertifikaten wie auch davon abgeleitete Unter-Zertifikate werden so bei Aufruf ohne Nachfrage akzeptiert. Die Eintragung von Root-Zertifikat ist vom verwendeten Browser abhängig, ggf. wird die Zertifikatsliste durch Updates aktualisiert. Die Überprüfung der Zertifikat auf aktuelle Gültigkeit (sofern diese in der Zwischenzeit gesperrt wurden) erfolgt entweder über lokale Certificate Revocation Lists (CRLs) oder durch Online-Abfrage bei OCSP-Servern (Online Certificate Status Protocol) im Internet.

Der publizistische Ausgangspunkt war das vermutete Erschleichen eines gültigen Zertifikats für die Google-Domain durch die die iranische Regierung, um vermutlich Nutzer von Google Mail zu überwachen. Durch eine im Browser Chrome neu eingeführte Sicherheitsfunktion (Public Key Pinning s.u.) wurde auf das merkwürdige Zertifikat aufmerksam gemacht. Die Zertifizierungsstellen DigiNotar (DigiNotar-Hack) und Comodo (Comodogate) mussten in der Folge Einbrüche zugeben. Der Comodo-Einbrecher behauptete sogar, das zugrunde liegende RSA-Verfahren zu brechen. Vermutlich ist das aber nur eine Fehlinterpretation; es besteht wohl nur ein Zusammenhang mit dem Einbruch bei der Firma RSA, bei dem zahlreiche Token entwendet und zu einem Folgeeinbruch beim US-Rüstungskonzern Lockeed Martin verwendet wurden. DigiNotar dagegen, die auch die von der niederländischen Regierung genutzten CAs (wie PKIoverheid) verwaltete, wurde sogar liquidiert. Bei der malaysischen Zertifizierungsstelle DigiCert und der CA-Tochter der niederländischen KPN sowie und auch bei GlobalSign wurde auf Einbrüche hin untersucht. Insgesamt sind also mindestens fünf Zertifizierungsstellen innerhalb von nur 4 Monaten von Einbrüchen betroffen, um in der Folge missbräuchlich falsche Zertifikate auszustellen. Dazu ist die "Dunkelziffer" sehr hoch, da viele Herausgeber von Zertitikats-Sperrlisten das entsprechende Begründungsfeld einfach leer lassen. Auch wurden viele Zertifikate mit dem nicht nachprüfbaren Hostnamen "localhost" ausgestellt.

Zwischenzeitlich werden immer weitere Fälle von Einbrüchen in Zertifizierungsstellen bekannt[24][25][26][27][28][29]. Zudem wurden von Zertifizierungsstellen für bereits wieder aufgelöste oder Scheinfirmen Zertifikate erstellt[30] oder Entwicklerzertifikate eingesetzt[31]. Die französische Sicherheitsbehörde ANSSI und das indische National Informatics Centre stellten über diesen Weg sogenannte "Schnüffelzertifikate" aus[32][33]. Die Spionage-Software Duqu 2.0 war mit einer gültigen digitalen Signatur des Auftragsfertigers Foxconn versehen[34]. Andererseits vertraut das Smartphone iPhone generell den Zertifikaten des US-Verteidigungsministeriums und der japanische Regierung. Man kann diese Einstellung auch selbst nicht ändern[35]. Auch das neue iOS 8 vertraut von Haus aus 222 Zertifikatsherausgebern, darunter unter anderem staatlichen CAs aus China, Hong Kong, Japan, den Niederlanden, Taiwan, der Türkei und den USA[36].

Einige kleinere Zertifizierungsstellen erzeugen auf Wunsch sogar auch den eigentlich geheimen privaten Schlüssel und senden diesen dem Nutzer zu. Dieses Verfahren erzeugt naturgemäß weitere erhebliche Sicherheitslücken und unterminiert die Glaubwürdigkeit von SSL bei Online-Verfahren.

Aber auch große Zertifizierungsstellen haben relativ laxe Richtlinien. So gelang es Betrügern, sich massenhaft Zertifikate für Phishing-Seiten ausstellen zu lassen. In vielen Fällen wird dabei nur geprüft, ob die Antragsteller die Kontrolle über die Domain haben und erhalten postwendend innerhalb weniger Minuten das Zertifikat[37]. Auch die chinesische Kostenlos-CA WoSign steht in der in der Kritik, regelwidrig Zertifikate auszustellen und sich mit den Mitbewerber StartCom zusammengelegt zu haben, ohne es zu kommunizieren[38]. Mozilla und Apple und später auch Google und Microsoft entzogen daraufhin den Zertifikaten das Vertrauen[39][40].

Google verwendet bei seinem Browser Chrome als Ersatz für die Abschaltung des OCSP-Checks (um Geschwindigkeitsvorteile gegenüber den anderen Browsern zu erzielen) eine eigene, zentrale Zertifikats-Widerrufsliste namens CRLSets und hat mit "HTTP Public Key Pinning" (HPKP) eine weitere neue Sicherheitsfunktion eingeführt. HPKP stellt über eine Liste (Whitelist) sicher, dass eine feste Zuordung von Webserver und Zertifikat existiert und damit stets entsprechende öffentlicher Schlüssel in der Zertifikatskette enthalten ist. So kann festgelegt (pinnen) werden, dass ein Zertifikat von einer bestimmten Zertifizierungsstelle (CA) unterschrieben sein muss. Günstig ist das "Pinning" der Root-CA eines Zertifikats, weil diese nicht so schnell wechseln. Diese neuen Funktionalitäten kann allerdings nicht alle SSL-Zertifikatsangriffe abwehren. Für Firefox existiert dazu ein Add-on und ab Version 32 eine Vollintegration in den Browser[41], beim Internet Explorer muss dazu das Sicherheitszusatztool EMET installiert werden.

Mozilla will mit Firefox nun ebenfalls den Weg vom bisherigen Client-orientierten OCSP-Check bei den Zertifizierungsstellen hin zu zentralen Widerrufslisten der Browser-Hersteller gehen[42].

Als Abhilfe des OCSP-Problems empfehlen Google und Mozilla ein anderes Konzept namens OCSP-Stapling. Dabei holt sich der Server regelmäßig (einmal am Tag) eine digital signierte OCSP-Auskunft beim Herausgeber, die ihm bestätigt, dass sein Zertifikat tatsächlich noch immer gültig ist. Allerdings hat dieses Konzept bisher keine große Verbreitung gefunden und die Implementierungen auf den Webservern sind noch im Probestatus[43].

Einen neuen Ansatz zum Zertifikatsdienstleisterproblem verfolgt das Projekt "Convergence". Auch ohne CAs sollen hier Zertifikate überprüfbar sein. Notwendig ist dabei ein Netz von sogenannten Notary-Servern. Wenn die Prüfsumme des Zertifikats einer https-Seite nicht mit den bei den "digitalen Notaren" hinterlegten Werten übereinstimmt, wird der Nutzer gewarnt. Allerdings fehlten in der Praxis noch die im Konzept auf freiwilliger Basis zu betreibenden Notary-Server. Auch ist nicht klar, ob die Browser-Hersteller mehrheitlich auch dieses Konzept unterstützen werden. Bisher gibt es nur eine entsprechende Firefox-Erweiterung.

Ein weiteren neuen Ansatz verfolgt Google mit dem Projekt Certificate Transparency. Per Logging der Einträge von Zertifikatsanbietern sollen öffentlich nachprüfbare Zertifikatslisten erzeugt und über Hash-Bäume nachvollzierbar werden, so dass ein Zertifikatsmissbrauch einfacher aufzuspüren ist. Dazu werden die Zertifizierungsstellen verpflichtet, automatisiert alle durchgeführten Zertifizierungen in einem Log zu protokollieren. Dieser ist so angelegt, dass sie immer nur Informationen anhängen, getätigte Einträge jedoch nicht löschen oder ändern können. Google übt dabei hohen Druck auf die CAs aus, sekundiert wird es dabei u.a. von Facebook und dem bekannten CA-Anbieter Commodo, die entsprechende Überprüfungstools kostenlos zur Verfügung stellen. Als Beispiel will Google die Firma Symantec zur Unterstützung ihres Projektes zwingen, da die Symantec-CA (u.a. auch Austeller für Verisign) zu Testzwecken Zertifikate auf fremde Domains ausgestellt hatte[44][45]. Ab Oktober 2017 soll nun der Browser Chrome Zertifikate, für die keine Certificate-Transparency-Logs vorliegen, generell als nicht mehr vertrauenswürdig einstufen[46]. Allerdings unterstützen derzeit nur Chrome und OpenSSL diesen Ansatz. Ab 08.09.2017 müssen in diesem Zusammenhang alle Zertifizierungsstellen vor dem Ausstellen eines Zertifikats via DNS nachsehen, ob eine Certification Authority Authorization (CAA) vorliegt. Die DNS-Admins können nämlich mit einem CCA-Datensatz im DNS festlegen, wer Zertifikate für ihre Domain unterschreiben darf. Damit würde per Certificate Transparency ein missbräuchlich ausgestelltes Zertifikat sofort erkannt werden, allerdings nur dort. Alle anderen Browser würden ein entgegen der CAA-Vorgabe ausgestelltes Zertifikat auch weiterhin klaglos akzeptieren. Generelle Abhilfe schafft nur der Einsatz von DANE/DNSSEC. Erweitert werden soll dieses Konzept durch "Co-thority" (statt Authority), indem unabhängige Organisationen die Richtigkeit der Logs bezeugen[47].

Unterschieben eines CA-Zertifikats

Hierbei wird dem Nutzer ein (ggf. selbsterstelltes) CA-Zertifikat untergeschoben. Darauf aufbauende Serverzertifikate werden dann klaglos akzeptiert.

Technisch gesehen wird in die Kommunikation ein Web-Proxy (an zentraler Stelle oder lokal am PC) zwischengeschaltet. Die Kommunikation zwischen Webserver im Internet und Web-Proxy verläuft normal, die Kommunikation zwischen Web-Proxy und Browser wird dann mit einem (in Echtzeit) selbst generierten Zertifikat versehen. Damit dies dem Nutzer nicht aufällt, muss dieses zweite Zertifikat mit einem auf dem lokalen PC voreingestellen Zertifikat (auch Root-Zertifikate genannt, s.o.) beglaubigt sein. Nur bei intensivem Nachkontrollieren der Zertifikatseigenschaften (Aussteller des Zertifikats bei einer https-Verbindung zu Google ist dann nicht Google) kann ein Nutzer die Manipulation erkennen, was aber im täglichen Gebrauch nicht zu händeln ist. Diese Möglichkeit wird beispielsweise verwendet, um in Firmennetzen zentral SSL-Gateways auf Internet-Firewalls einzusetzen. Analoges Beispiel für lokale PCs ist die kommerzielle Technologiekomponente "SSL Digestor" der Firma Komodia, die im Fall der Adware "Superfish"[48][49] ursächlich für die Sicherheitsprobleme vielen Notebooks der Firma Lenovo war. Ein weiteres Beispiel ist die Firma MCS Holding, die als eigentlich vom China Internet Network Information Center (CNNIC) beglaubigten Zwischenzertifizierungsstellen zusätzlich eigene gefälschte Domain-Zertifikate (z.B. für Google) in Umlauf gebraucht hat[50]. Auch auf Dell-Rechnern wurde ein eigenes Root-CA-Zertifikat installiert[51]. Entdeckt wurde diese Manipulation über das "Public Key Pinning". Ende Mai 2016 wurde bekannt, dass Symantec der umstrittenen Sicherheitsfirma BlueCoat ein Intermediate-CA-Zertifikat ausstellen lassen hat[52]. Mit einem Intermediate-CA-Zertifikat kann ebenfalls der verschlüsselten Traffic zu https-Webseiten aufgebrochen werden. Auch Hackertools zur Untersuchung der SSL-Kommunikation wie Burp Proxy arbeiten nach dem o.a. Prinzip.

Zwischenzeitlich nutzen auch Virenscanner bei der SSL-Filter-Funktion diese Technik. So werden die Virenschutzhersteller unabhängiger von der Entwicklung Browser-spezifischer Plugins, erhöhen aber das Sicherheitsrisiko für den Nutzer durch Verbreiterung der Angriffsfläche (so u.a. durch Außerkraftsetzung der Public Key Pinning -Sicherheitsfunktion mittels HKPK-Protokoll) sowie fehlerhafte Implementationen[53][54][55].

Im Zuge der Master-Key-Debatte im Rahmen der NSA-Ausspähaffäre wird die Frage gestellt, ob es auch im Internet gelingt, beispielsweise den dynamischen Update-Mechanismus für die Zertifikatsdatenbank (wie bei Windows-Rechnern) zu nutzen, um Nutzern CA-Zertifikate unterzuschieben. Alle auf einem Windows-Recher installierte Browser wären davon betroffen, nur Firefox und Chrome sind durch Verwendung eigener Krypto-Infrastruktur hier unabhängiger.

http/https-Angriff

Dieser Angriff zielt nicht direkt auf das Knacken einer SSL-Verbindung. Es wird sich zunutze gemacht, dass Anwender in der Regel nie eine Seite mit einem vorangestellten https:// aufrufen. Im Normalfall wird zunächst die unverschlüsselte http-Seite aufgerufen und dann auf die https-Version umgeleitet. Durch einen MitM-Angriff kann dies ausgenutzt werden, um sich zwischen Browser und Web-Server zu schieben.

Google und Mozilla haben bei ihren Browsern Chrome und Firefox eine weitere neue Sicherheitsfunktion eingeführt. Mit der Funktion HSTS (HTTP Strict Transport Security) teilt ein Webserver dem Browser mit, dass dieser seine Inhalte ausschliesslich über eine verschlüsselte https-Verbindung abrufen soll. Diese Einstellung merkt sich der Browser (über eine im Browser integrierte Liste, in der eine entsprechende Serverinformation - gültig meist ein Jahr - bei einem ersten Seitenaufruf hinterlegt wurde) und wandelt alle Links mit http in https-Links um. Die Internet Engineering Task Force (IETF) hat das Protokoll HSTS zwischenzeitlich als Internet-Standard bestätigt und im RFC 6797 veröffentlicht. Daneben gab es schon seit längerer Zeit das Plugin "HTTPS Everywhere" der Electronic Frontier Foundation (EFF) ebenfalls für beide der oben genannten Browser, dass auf einem ähnlichen Prinzip beruht.

Bei anderen SSL-gesicherten Diensten (z.B. Mailtransport) gibt es per MitM-Angriff noch die Möglichkeit, dem Zielserver durch Ausfiltern des Verschlüsselungsbefehls eine nur mögliche unverschlüsselte Kommunikationsmöglichkeit vorzugaukeln (analog wie bei der GSM-Verschlüsselung). Abhilfe schafft hier der Einsatz von DANE.

Besonders sicher gestalten kann man die SSL-Kommunikation mittels Perfect Forward Secrecy (PFS). Durch die Anwendung des Diffie-Hellman-Verfahrens kann nur aktuell und nicht nachträglich (im Rahmen einer Verbingungsaufzeichnung) versucht werden, die Kommunikation zu entschlüsseln. Dies wird dadurch möglich, da der geheime Schlüssel (analog wie bei einem Einmal-Passwort) nicht übertragen wird. Immer mehr Web- (u.a. auch Google) und auch Mailserver setzen PFS ein, wohl auch unter dem Hintergrund der NSA-Spionage-Affäre. Allerdings ist dann mit einem zusätzlichen üblichen Verschlüsselungsoverhead von 15 - 30% zu rechnen. Prüfen kann man einen Webserver über die SSL Labs-Webseite https://www.ssllabs.com/ssltest/ . Wird in dem Ergebnisbericht unter "Cipher Suites" der Algorithmus DHE_* oder ECDHE_* angezeigt, nutzt der Webserver PFS (das abschließende E im Algorithmusnamen bedeutet "ephemeral" bzw. flüchtig). Ob ein Mailserver zunächst überhaupt TLS-verschlüsselt, kann man über die CheckTLS.com-Webseite http://www.checktls.com/perl/TestReceiver.pl testen. Dabei zeigt beim Testergebnis ein "ok" in der Spalte "TLS Adv" das Anbieten von TLS bei eingehenden E-Mails bzw. "TLS Neg" beim Mailversand an. Ein nachfolgenden Test auf PFS-Nutzung kann über die SSL-Tools-Seite https://de.ssl-tools.net/mailservers erfolgen.

Bei solchen anderen SSL-gesicherten Diensten (z.B. der Mailtransport) gibt es per MitM-Angriff noch die Möglichkeit, dem Zielserver durch Ausfiltern des Verschlüsselungsbefehls eine nur mögliche unverschlüsselte Kommunikationsmöglichkeit vorzugaukeln (analog wie bei der GSM-Verschlüsselung). Abhilfe schafft hier der Einsatz von DANE.


Zusammenfassung

Das Trustworthy Internet Movement hat den aktuellen Sicherheitsstand bei SSL-Websites untersucht und grafisch dargestellt (SSL Pulse[56]). Als problematisch werden in erster Linie die SSL-Protokoll- und Zertifikatsschwierigkeiten angesehen.

Durch den Einsatz der TLS-Version 1.2 können alle derzeit bekannten protokollseitigen Sicherheitslücken geschlossen werden. Lediglich das FREAK und ggf. das Logjam-Problem (Erzwingen der Verwendung unsicherer Austauschverfahren, obwohl sichere Verfahren zur Auswahl stehen; s.o.) muss zusätzlich per Update beseitigt werden. Zudem ist TLS 1.2, wie auch alle anderen früheren Versionen, unter speziellen Umständen anfällig für einen Bleichenbacher-Angriff[57]. Hierbei lassen die Antworten der Fehlerbehandlung des Servers ggf. Rückschlüsse auf das verwendete Schlüsselmaterial zu, die kommende TLS-Version 1.3 behebt (geplant war Frühjahr 2017, jetzt wohl erst Ende 2018) all diese Probleme. Zudem wird dann auch gleich das grundsätzliche Padding-Orakel-Problem gelöst, um Teile des verschlüsselten Codes zu erraten. Durch die bisherige fehlerhafte Design-Entscheidung wurde zur Integritätssicherung zunächst ein Prüfwert des Klartextes gebildet, an die Daten angehangen und dann verschlüsselt. Angriffe, wie Poodle und Sweet32, nutzten dies in der Vergangenheit aus, um den Klartext zu erraten und diese Vermutung per Prüfwert zu testen. TLS 1.3 erzwingt nun ausschließlich die Integritätssicherung und Verschlüsselung in einem Schritt.

Das BSI hat bereits TLS 1.2 mit PFS als Mindeststandard für die Bundesverwaltung festgelegt[58] (BSI TR-03116-4, wobei allerdings ein solcher BSI-Standard zunächst nur eine "unverbindliche Empfehlung" darstellt und zur Durchsetzung erst noch von der Bundesregierung bzw. -für die ganze Verwaltung- vom IT-Planungsrat beschlossen werden müsste).

Im Zertifikatsbereich ist derzeit der aussichtsreichste Lösungsansatz, mittels DNSSEC bzw. dem darauf aufbauenden DANE-Protokoll zu arbeiten und ggf. dies mit digitalen Webseiten-Zertifikaten bzw. HSTS-Informationen zu verknüpfen. Besonders weit fortgeschritten ist der DANE-Einsatz im Bereich der verschlüsselten Mailserver-Kommunikation, da dieses System zusätzlich auch für Ende-zu-Ende-Verschlüsselungen (DANE/SMIMEA für S/MIME, DANE/OPENPGPKEY für PGP) anwendbar wäre. Das BSI hat zwischenzeitlich dazu den Entwurf einer Technischen Richtlinie "Sicherer E-Mail-Transport" veröffentlicht, in der neben vertrauenswürdigen TLS-Zertifikaten für den Mail-Transport (nach BSI TR-03145) sowie "sicherer Kryptografie" (d.h. TLS 1.2 mit PFS nach o.a. BSI TR-03116-4) auch DNSSEC und DANE/TLSA vorgeschrieben werden[59]. Es ist davon auszugehen, das bei einer zukünftig möglichen Zertifizierung dies dann auch gefordert wird.

Durch die NSA-Ausspähaffäre wird die per TLS verschlüsselte Mail- und Webkommunikation zunehmen. Viele Anbieter und Betreiber (z.B. WordPress[60], aber auch der Verwaltungsbereich, wie beispielsweise die US-Regierungsstellen[61]) denken darüber nach, ihre Webserver komplett auf https-Traffic umzustellen. Mitte 2016 erreichte der Anteil der https-Verschlüsselung im Web erstmals 50 Prozent der Gesamtübertragung[62], Mitte 2017 wurden bereits 58% erreicht[63]. Dabei können auch schon Teillösungen die Internetsicherheit signifikant erhöhen:

  • Der Internetdienst Cloudflare hat im Herbst 2014 die Webseiten all seiner Kunden mit TLS ausgestattet und verdoppelte so die gut zwei Millionen TLS-Websites weltweit. Allerdings wird nur die Strecke zwischen Besucher-PC zur Cloudflare-Infrastruktur per TLS verschlüsselt. Von dort gehen die Daten weiter unverschlüsselt zum Ziel-Server, es sei denn, der Seitenbetreiber hat bereits ein eigenes Zertifikat installiert. Um auch diese Strecke abzusichern, stellt Cloudflare als Zusatzangebot auch gratis TLS-Zertifikate bereit.
  • Auch Amazon Web Services bringt automatisierte SSL/TLS-Zertifikatsverwaltung mit. Dabei wird das Zertifikat und den zugehörigen privaten Schlüssel allerdings im Cloud-Load-Balancer abgelegt, da hier das automatisierbare SSL-Offloading unterstützt werden kann[64].
  • Auch Symantec wollte im Rahmen der neu gestarteten Encryption-Everywhere-Kampagne mit globalen Webhostern kooperieren und kostenlose SSL/TLS-Zertifikate zur Verfügung stellen[65]. Zwischenzeitlich hat die Firma aber - wohl auf Grund der o.a. Quälereien mit Google und auch möglicherweise wegen der aufziehenden DANE-Konkurrenz - die Zertifikatssparte an DigiCert verkauft[66].
  • Über die neue HTTP-Protokollversion HTTP/2 (Kurzform für HTTP/2.0) bzw. dem Vorläufer SPDY kann eine sogenannte "opportunistische Verschlüsselung" (Opportunistic Encryption-OE) auch für "normale" Webkommunikation eingerichtet werden. Die verpflichtenden Vorabauthentifizierungen des Gegenübers entfallen, ein Zertifikat eines Trust Centers ist dann nicht erforderlich. Damit besteht zwar eine Anfälligkeit gegen MitM-Angriffe, aber die Kommunikation erfolgt nicht mehr unverschlüsselt. Die OE für HTTP/2 ist zwar nach RFC 7540 nicht verpflichtend, Google und Mozilla haben aber angekündigt, HTTP/2 aber nur mit Verschlüsselung zu unterstützen. Alle modernen Browser können schon mit HTTP/2 arbeiten, auf der Serverseite wird jetzt auch nachgerüstet (z.B. experimentell mod_spdy für Apache-Webserver, standardmäßig ab Apache Traffic Server 6 und Webserver Nginx Plus Release 7[67]). Da derzeit aber noch Probleme beim Einsatz von HTTP/2 und OE bestehen, wurde (als Zwischenlösung) aktuell ein experimenteller Standard (RFC7838) verabschiedet, der OE auch über das "alte" HTTP-Protokoll ermöglicht (per spezieller Service-Meldung des Webservers sowie Portumleitung von Port 80 auf Port 443)[68].
  • Die Mozilla-Entwicklergemeinde (Browser Firefox) will das unverschlüsselte http-Protokoll in Zukunft nicht mehr unterstützen. Längerfristig sollen neuere Features nur noch sicheren https-Webseiten zur Verfügung stehen. Den bekannten Problemen mit den Zertifizierungsstellen/Zertifikatsdienstleistern sei man sich zwar durchaus bewusst, das System als solches funktioniere jedoch in den meisten Bereichen[69]. Mozilla unterstützt, neben anderen Unternehmen und Institutionen wie Akamai, CISCO, Duda, Fastly, Gemalto, HP Enterprise und die EFF, deshalb die alternative SSL-Zertifizierungstelle Let's Encrypt, die kostenlose SSL-Serverzertifikate verteilt[70]. Der Starttermin wurde auf den 03.Dezember 2015 verschoben. In den ersten 3 Monaten sollen bereits 1 Million Zertifikate ausgestellt worden sein[71], ca. ein Jahr später schon 100 Millionen Zertifikate (wovon allerdings nur 39 Millionen aktiv eingesetzt sind)[72]. Die Zertifikatsaustellung erfolgt dabei vollautomatisch per Tool über das ACME-Protokoll[73], allerdings nur für Apache- und nginx-Webserver unter Ubuntu-Linux. Für andere Konfigurationen, wie beispielsweise Windows-Server, ist noch manueller Aufwand nötig. Das ACME-Protokoll hat den Umgang mit SSL-Zertifikaten für die Zertifizierungstelle und Admins enorm erleichtert, so dass es sogar zu einen Internetstandard (IETF-Standard) erhoben werden soll[74].
Logo Let's Encrypt, Bildquelle: Let's Encrypt ©CC BY-NC 4.0
  • Apple (Browser Safari) drängt App-Entwickler dazu, bei ihren App-Kommunikation ab iOS9 ausschließlich auf eine verschlüsselte Übertragung per https zu setzen. Hierfür stellt Apple eine auf Basis von HSTS (s.o.) entwickelte Technik "Application Transport Security" (ATS) den Entwicklern zur Verfügung[75]. Apps müssen dann nur noch angeben, mit welchen Domains sie verschlüsselt kommunizieren wollen. Ab Ende 2016 wollte Apple https erzwingen[76], verlängerte aber nun die Frist.
  • Nachdem die Browser Chrome, Firefox, Safari und Opera das HSTS-Protokoll unterstützen, will Microsoft wohl auch nicht mehr zurückstehen. Die Browser Internet Explorer 11 und der neue Webbrowser Edge (Windows 10) sind nun auch mit dem Standard kompatibel[77]. Ob auch die WWW-Serverseite das Protokoll unterstützt, kann über die Webseite securityheaders.io geprüft werden (Anzeige: Strict-Transport-Security). Google stattet nach und nach seine 45 Top-Level-Domains standardmäßig mit diesem Sicherheitsmechanismus aus[78].
  • Auch das HKPK-Protokoll wurde im April 2015 durch die Internet-Standardisierungsorganisation IETF standardisiert, um dem Problem korrupter Zertifikate zu begegnen (s.o.). Das Protokoll wird unter anderem von den Webbrowsern Chrome und Firefox unterstützt. Ob auch die WWW-Serverseite das Protokoll unterstützt, kann ebenfalls über die Webseite securityheaders.io geprüft werden (Anzeige: Public-Key-Pins).
Euro-Logo, Bildquelle: BSI
  • Anfang 2016 wurden durch die Internet-Standardisierungs-Arbeitsgruppe der IETF die beiden elliptischen Kurven Curve25519 von Dan J. Bernstein und Curve448 (Goldilocks-Kurve) als RFC 7748 verabschiedet. Damit können die Kurven und ihr Einsatz beim Diffie-Hellman-Schlüsselaustausch (ECDHE) für den Einsatz im Internet auch bei TLS/SSL standardisiert werden. Die Chrome-Entwickler und Microsoft arbeiten bereits an einer Umsetzung in ihren Browsern. So sollen Befürchtung der Unterwanderung von Kryptoverfahren durch die NSA begegnet und die Zeit, bis Quantencomputer gänzlich neue Verfahren erforderlich machen, überbrückt werden[79].
  • Bei Google wird das Webseiten-Ranking in der Suchmaschine verbessert, wenn man ein von einer offiziellen CA unterschriebenes Zertifikat einsetzt. Ergänzend will Google bald alle Webseiten ohne SSL-Verschlüsselung mit einem roten X markieren[80]. Auch Googles Browser Chrome soll ab Anfang 2017 vor nicht verschlüsselnden Webseiten mit einem rotem Dreieck warnen[81].
  • Google will selbst Root-CA werden. Dazu wurden bereits die etablierten Root-CAs GlobalSign R2 und R4 aufgekauft[82].
  • Die neue eIDAS-Verordnung der EU erlaubt die Kennzeichnung einer sicheren Webseiten-Authentifizierung per Euro-Logo[83]. In Deutschland vergibt das BSI das Logo.


Weblinks

Tools


Einzelnachweis

  1. "Updates von Microsoft und Adobe" in heise.de/Security vom 11.Januar.2012
  2. "Google mit besserer Langzeit-Verschlüsselung" in heise.de/Security vom 24.November.2011
  3. "Sechs-Sicherheitsmaengel-in-OpenSSL-gefixt" in heise.de/Security vom 05.Januar.2012
  4. "Erneuter Krypto-Angriff auf SSL/TLS-Verschlüsselung" in heise.de/Security vom 14.März.2013
  5. "NSA entschlüsselt Webserver-Daten angeblich in Echtzeit" in heise.de/Security vom 07.November.2013
  6. "Web-Seiten von Bund und BSI mit gefährlicher Verschlüsselung" in heise.de/Security vom 12.November.2013
  7. "Webbrowser: Endgültig Schluss mit RC4" in heise.de/Security vom 09.September.2015
  8. "3DES wird zum Problem für TLS-Verschlüsselung" in heise.de/Security vom 25.August.2016
  9. "Entwickler des BEAST-Angriffs auf SSL legen nach" in heise.de/Security vom 06.September.2012
  10. "Lücke in SSL-Verschlüsselung kaum ausnutzbar" in heise.de/Security vom 14.September.2012
  11. "lost+found: Was von der Woche übrig blieb" in heise.de/Security vom 09.August.2013
  12. "HEIST: Wiederbelebter Angriff auf HTTPS vorgestellt" in heise.de/Security vom 04.August.2016
  13. "Poodle: Experten warnen vor Angriff auf Internet-Verschlüsselung" in heise.de/Security vom 15.Oktober.2014
  14. "BSI will TLS 1.2 als Mindeststandard für den Bund " in heise.de/Security vom 08.Oktober.2013
  15. "Die Krypto-Vorlieben der Browser" in heise.de/Security vom 28.März.2013
  16. "Krypto-Bibliothek NSS unterstützt TLS 1.2" in heise.de/Security vom 15.Juli.2013
  17. "Schutz vor Freak Attack: Diese Browser sind betroffen " in heise.de/Security vom 05.März.2015
  18. "Logjam-Attacke: Verschlüsselung von zehntausenden Servern gefährdet" in heise.de/Security vom 19.Mai.2015
  19. "DROWN-Angriff: SSL-Protokoll aus der Steinzeit wird Servern zum Verhängnis" in heise.de/Security vom 01.März.2016
  20. "Sieben auf einen Streich: OpenSSL schließt Sicherheitslücken" in heise.de/Security vom 05.Juni.2014
  21. "Google entwickelt eigene SSL-Bibliothek" in heise.de/Security vom 21.Juni.2014
  22. "ReSSL: Der nächste Schritt weg von OpenSSL" in heise.de/Security vom 30.September.2014
  23. "Amazon stellt mit s2n eigene SSL-Bibliothek vor" in heise.de/Security vom 30.Juni.2015
  24. "Webserver von niederländischer CA kompromittiert" in heise.de/Security vom 08.Dezember.2011
  25. "Einbrüche beim Domain-Registrar VeriSign im Jahr 2010" in heise.de/Security vom 02.Februar 2012
  26. "Mozilla erwägt Rauswurf der Trustwave-CA" in heise.de/Security vom 08.Februar 2012
  27. "Fatale Panne bei Zertifikatsherausgeber Türktrust" in heise.de/Security vom 04.Januar 2013
  28. "Sicherheitsfirma Bit9 gehackt" in heise.de/Security vom 12.Februar 2013
  29. "Gefälschtes Microsoft-Zertifikat im Umlauf" in heise.de/Security vom 17.März.2015
  30. "Zertifizierter Online-Banking-Trojaner" in heise.de/Security vom 22.Februar.2013
  31. "Microsoft warnt vor signierter Malware" in heise.de/Security vom 20.Dezember.2013
  32. "Microsoft sperrt französisches Schnüffel-Zertifikat aus" in heise.de/Security vom 10.Dezember.2013
  33. "Indien stellte falsche Google-Zertifikate aus" in heise.de/Security vom 09.Juli.2014
  34. "Trojaner im Kaspersky-Netz hat Signatur von Foxconn" in Heise Online vom 16.06.2015
  35. "Twitter-Tweet: My phone carries a root certificate for a military..." vom 24.April.2013
  36. "lost+found: Was von der Woche übrig blieb" in heise.de/Security vom 26.September.2014
  37. "SSL-Zertifizierungsstellen stellen hunderte Zertifikate für Phishing-Seiten aus" in heise.de/Security vom 15.Oktober.2015
  38. "Kostenlos-CA WoSign in der Kritik, Mozilla erwägt Schritte" in heise.de/Security vom 02.September.2016
  39. "Zertifikats-Schmu bei WoSign und StartCom: Mozilla macht Ernst" in heise.de/Security vom 26.Oktober.2016
  40. "Microsoft verbannt Zertifikate von StartCom und WoSign aus Windows 10" in heise.de/Security vom 11.August.2017
  41. "Firefox soll falsche SSL-Zertifikate enttarnen" in heise.de/Security vom 28.August.2014
  42. "Mozilla zukünftig mit zentralen Sperrlisten" in heise.de/Security vom 06.August.2014
  43. "Zertifikate: Mozilla testet Ausstieg aus dem SSL-Widerrufs-Konzept OCSP" in heise.de/Security vom 02.Juni.2017
  44. "Certificate Transparency: Google setzt Symantec die Pistole auf die Brust" in heise.de/Security vom 29.Oktober.2015
  45. "TLS-Zertifikate: Google zieht Daumenschrauben der CAs weiter an" in heise.de/Security vom 27.Mai.2016
  46. "Google: Certificate Transparency wird Pflicht" in heise.de/Security vom 31.Oktober.2016
  47. "Co-thority statt Authority: Viele-Augen-Prinzip für Zertifikate" in heise.de/Security vom 05.November.2015
  48. "Superfish: Lenovo-Fall ist nur die Spitze des Eisbergs" in Aktuelle Sicherheits-Meldungen – SecuPedia vom 25.Februar.2015
  49. "Nach Superfish-Debakel: Lenovo einigt sich mit US-Behörde auf Konsequenzen" in heise.de/Security vom 06.August.2017
  50. "Google deckt erneut Missbrauch im SSL-Zertifizierungssystem auf" in heise.de/Security vom 24.März.2015
  51. "Dell-Rechner mit Hintertür zur Verschlüsselung von Windows-Systemen" in heise.de/Security vom 23.November.2015
  52. "Überwachungs-Verdacht: Empörung um Intermediate CA von BlueCoat" in heise.de/Security vom 30.Mai.2016
  53. "Eset NOD32 Antivirus 9 gefährdet https-Verschlüsselung" in heise.de/Security vom 05.Februar.2016
  54. "Sicherheitsforscher an AV-Hersteller: "Finger weg von HTTPS"" in heise.de/Security vom 08.Februar.2017
  55. "US-CERT warnt vor HTTPS-Inspektion" in heise.de/Security vom 22.März.2017
  56. "SSL Pulse-Webseite"
  57. "Uni Bochum meldet TLS-Schwachstellen" in Aktuelle Sicherheits-Meldungen – SecuPedia vom 20.Juni.2016
  58. "BSI will TLS 1.2 als Mindeststandard für den Bund" in heise.de/Security vom 08.Oktober.2013
  59. "BSI: Richtlinie für sicheren Mail-Transport zeigt bereits Wirkung" in heise.de/Security vom 22.August.2015
  60. "WordPress will 2017 HTTPS-Ausbau vorantreiben" in heise.de/Security vom 02.Dezember.2016
  61. "USA: Regierungs-Webseiten müssen auf HTTPS umstellen" in heise.de/Security vom 09.Juni.2015
  62. "HTTPS-Verschlüsselung im Web erreicht erstmals 50 Prozent" in heise.de/Security vom 16.Oktober.2016
  63. "100 Millionen Zertifikate von Let's Encrypt im Umlauf" in heise.de/Security vom 29.Juni.2017
  64. "Amazon Web Services bringt automatisierte SSL/TLS-Zertifikatsverwaltung" in heise.de/Security vom 22.Januar.2016
  65. "Verschlüsselung im Web: Symantec verspricht kostenlose SSL/TLS-Zertifikate" in heise.de/Security vom 17.März.2016
  66. "Nachspiel einer fatalen Panne: Symantec verkauft Zertifikatssparte an DigiCert" in heise.de/Security vom 04.August
  67. "Apache Traffic Server 6 bringt HTTP/2-Support" in heise.de/Security vom 22.September.2015
  68. "Neuer IETF-Standard: Alten Webverkehr wenigstens verschlüsseln" in heise.de/Security vom 23.März.2017
  69. "Mozilla will HTTP ausrangieren" in heise.de/Security vom 02.April.2015
  70. "Let's Encrypt: Meilenstein zu kostenlosen SSL-Zertifikaten für alle" in heise.de/Security vom 05.Juni.2015
  71. "Let's Encrypt: 1 Million Zertifikate ausgestellt" in heise.de/Security vom 09.März.2016
  72. "100 Millionen Zertifikate von Let's Encrypt im Umlauf" in heise.de/Security vom 29.Juni.2017
  73. "Let's Encrypt: Ab dem 3. Dezember Gratis-SSL-Zertifikate für alle" in heise.de/Security vom 13.November.2015
  74. "Let's Encrypt: ACME auf dem Weg zum IETF-Standard" in heise.de/Security vom 19.Juni.2017
  75. "Apple will HTTP-Verbindungen aufs Abstellgleis schicken" in heise.de/Security vom 09.Juni.2015
  76. "Apple erzwingt HTTPS in Apps" in heise.de/Security vom 15.Juni.2016
  77. "Microsoft pusht HTTPS beim Internet Explorer und Edge-Webbrowser" in heise.de/Security vom 10.Juni.2015
  78. "Google schützt seine Top-Level-Domains mit HSTS " in heise.de/Security vom 29.August.2017
  79. "Verschlüsselung: IETF standardisiert zwei weitere elliptische Kurven" in heise.de/Security vom 27.Januar.2016
  80. "Google will unverschlüsselte Websites markieren" in Aktuelle Sicherheits-Meldungen – SecuPedia vom 13.April.2016
  81. . "Chrome soll vor nicht verschlüsselnden Webseiten warnen" in heise.de/Security vom 09.September.2016
  82. "Google auf dem Weg zur unabhängigen Root-CA" in heise.de/Security vom 30.Januar.2017
  83. "Elektronische Signaturverordnung eIDAS ist gestartet – wie geht es weiter?" in heise.de/Security vom 02.Juli.2016


Siehe übergeordnete Stichworte


Siehe auch



Diese Seite wurde zuletzt am 29. September 2017 um 20:39 Uhr von Oliver Wege geändert. Basierend auf der Arbeit von Peter Hohl, Markus Albert, Admin und Ian Kilpatrick.

Anzeigen