HTTPS, SSL, TLS

Um es auch technischen Laien verständlich zu machen, das folgende Beispiel: Wenn man ein großes Schloss mit vielen Zimmern besitzt und dieses schützen will, so kann man jede Tür und jedes Fenster sowohl mit einem neuen Sicherheitsschloss als auch mit einer Glasbuch-Alarmanlage sichern.

Aber, wenn der Handwerker auch nur bei einem einzigen Fenster geschlampt hat, oder nachträglich bei Reparaturen daran ein einziger Fehler unterlief, oder man das Fenster offen lässt, so kann jemand in das gesamte Schloss einbrechen. Für Einbrecher im Internet spielt es im Übrigen keine Rolle, ob sich das offene Fenster im Keller oder unter dem Dach befindet. Es existieren für jedermann zugängliche, kostenlose Tools, welche hunderte von Seiten (Fenster) je Sekunde auf Sicherheit überprüfen. - D.h. beim Thema Sicherheit kommt es wirklich auf jedes Detail an.

• Um die Sicherheit der Server muss sich (bei sogenannten managed Servern) der Provider kümmern. Falls Sie als Anbieter einen eigenen Server komplett selbst betreuen, dann ist dies inzwischen eine Vollzeitaufgabe für einen Spezialisten. Ständig werden Sicherheitslücken in irgendeinem Modul entdeckt und müssen schnellstmöglich geschlossen werden.
• Redaktionssysteme (zur Seitengestaltung) wie z.B. Joomla oder WordPress wurden bereits systematisch mit Hintertürchen versehen. Zudem werden von Programmieren aufgrund von Schludrigkeit und mangelnder Endkontrolle ständig weitere Fehler hineinprogrammiert. Ein Redaktionssystem, das einen Internet-Auftritt über das Internet betreut, ist in der Praxis nicht ohne weiteres sicher zu gestalten.
• Eigene Programme in PHP, JavaScript, Pearl, CGI usw. sind oft sehr oberflächlich programmiert. Jedes Modul stellt bereits eine gewisse Sicherheitslücke dar und in der Kombination bilden sie nicht selten ein Scheunentor für jeden Angreifer. Manche Sicherheitsexperten fordern, dass man jedes Script einmal jährlich überprüfen soll, andere verlangen zumindest alle 2 Jahre eine genaue Überprüfung. Aber alle 5 Jahre sollte man wirklich jedes alte Script komplett überprüfen oder besser gleich neu programmieren. - Wenn Sie sich jetzt fragen, wie alt Ihre Programme sind, dann haben Sie bereits ein Problem. So etwas gehört notiert und verwaltet.
• Noch gravierender ist es, wenn ganze Programmierversionen als veraltet / unsicher eingestuft werden. D.h. wenn Ihr PHP etc. auf einer veralteten Version läuft, riskieren Sie Kopf und Kragen.
• Das unsichere SSL wurde inzwischen von vielen Anbietern ersetzt durch TLS (Transport Layer Security). Aber auch TLS 1.0 wurde inzwischen geknackt. Darauf folgten ständig weiter verbesserte TLS-Versionen. Das klingt vertrauenserweckend, zeigt jedoch nur, dass alles Vorhergehende nachweislich unsicher war. Ferner schalten viele Systeme automatisch zurück, wenn ein alter Browser etc. anfragen. Dann wird die Sicherheit auch bei neuesten Standards wieder heruntergefahren.
• Immer wieder wurden Man in the middle (MITM) Angriffe erfolgreich durchgeführt, wobei ein Dritter sich zwischen Sender und Empfänger einschleust und Daten filtert oder mitliest oder verändert.
• Da die meisten Nutzer eher nur die Abkürzungen der Adresse eingeben wie z.B. haumichblau.info - also ohne https bis www. oder maximal www.uvwxyz.de -, werden Angriffe durch Dritte dazwischen (man in the middle) möglich, die dann eine eigene HTTPS-Verbindung zu sich aufbauen.
• Selbst mit dem noch strengeren HTTP Strict Transport Security - einem Zusatz zu HTTPS kann man MITM-Angriffe nicht völlig verhindern. Dafür wird der Datenschutz durch Google außer Kraft gesetzt und missbraucht.
• Sicherheitslücken wie POODLE, FREAK, BEAST, CRIME oder Heartbleed bleiben selbst bei vielen modernen Zertifikaten bestehen.
• Cookies sind auch unter HTTPS nur dann geschützt, wenn sie ausdrücklich als sichere Cookies deklariert werden. D.h. das secure flag muss explizit gesetzt sein.
• HTTPS verschlüsselt nur die direkte Verbindung zwischen Sender und Empfänger. Der dafür vorgesehene Port ist 443. Verwechselt man dies bei der Installation / Konfiguration, kann man dadurch bereits ein Sicherheitsloch erzeugen.
• Meist werden nur Server-Zertifikate verwendet. Signierte Client-Zertifikate werden sehr selten verwendet. - Dies verstieße derzeit auch (noch) gegen den Datenschutz, da sich dadurch der Absender - immer und überall - eineindeutig nachweisen und verfolgen ließe.
• Oft wird nicht die gesamte Sitzung mit S geführt. Teilweise findet sich ein Erstkontakt mit HTTPS und danach werden die Inhalte unverschlüsselt ausgetauscht, um Rechenzeit etc. zu sparen. Das passiert öfter, als die meisten Nutzer im Internet denken. So setzt z.B. ebay beim ersten Kontakt über HTTPS einen Cookie und führt dann alles unverschlüsselt durch.
• Keineswegs immer (d.h. bei jedem Seitenaufruf) werden Zertifikate vom Browser abgefragt oder von Server zum Nutzer ausgetauscht. Nicht selten findet dies nur beim Erstkontakt statt und danach wird pauschal vertraut.
• Da die im Browser erscheinenden Zertifikat-Abfragen die Normalnutzer erheblich irritierten, wurden oft ganze Listen den Browsern bereits untergeschoben, damit diese blind akzeptiert werden. Wer hier - am durchaus angreifbaren Browser - ansetzt und eine weitere Adresse in jene Listen einfügt, kann jeden Nutzer täuschen.
• Waren früher eine eigene IP beim Server für HTTPS erforderlich, so funktioniert dies heute auch mit Unteradressen auf einem gemeinsam genutzten Server. Das ist heute der Standardfall für über 95 % aller Internet-Auftritte. SNI = Server Name Indication bildet jedoch ein weiteres im Zweifel unsicheres Detail.
• Da das wichtige TCP/IP unterhalb der geschützten Schicht liegt, sind IP-Adressen, Port Nummern des Servers und meist sogar die Internet-Adresse (Domain) jedem in Klarschrift lesbar. Ferner kann jeder die transferierte Datenmenge erkennen sowie die Dauer der Verbindung. Da auch das Spidern der Web-Inhalte unter HTTPS weiter möglich ist, kann man aufgrund des reinen Vergleichs der Dateigröße eine offene Inhaltsseite mit Ihrer verschlüsselten direkt vergleichen. D.h. der Abhörer kann die abgerufenen Inhalte sehr wohl erkennen. Ferner erlaubt der freie Besitz beider Dateien ein knacken der verwendeten Verschlüsselung.
• Die Zertifikate müssen regelmäßig erneuert werden. Verfallene Zertifikate gehören zu den häufigsten Fehlern. Unterschätzen Sie auch hier den Zeitaufwand und ggf. die Kosten nicht.
• Es existiert eine erstaunlich große Liste der Fehlermöglichkeiten, die man bei der Implementierung von HTTPS auf seinem Internet-Auftritt alle vermeiden muss, um wirklich Sicherheit zu produzieren. - Rund die Hälfte der von mir 2017 und 2018 untersuchten Internet-Auftritte mit HTTPS zeigten mindestens einen der dort erwähnten Fehler.
• Wenn Sie auch nur das Geringste falsch machen bei der Implementierung von HTTPS, dann können Sie fast alle Nutzer ausschließen. Siehe hierzu Performance test of MD5, SHA1, SHA256 and SHA512 auf dem Firefox Versionsnummer 57. Der seriöse Auftritt verwendet sogar das sicherere Zertifikat SHA-2. Der Nutzer muss dort jedoch so viele Ausnahmen im Browser erlauben, dass er vermutlich darauf verzichtet, Ihren Inhalt zu lesen.
• Der Nachfolger SHA-3 wurde übrigens bereits 2015 als Standard vorgestellt. Bis heute wird er allerdings kaum verwendet.
• Und selbst, wenn Sie alles richtig machen, können Browser Sie sperren, weil Sie laut deren Definition ein falsches Zertifikat verwenden, das die Browser-Hersteller (aus rein firmenpolitischen Motiven) nicht akzeptieren. Pech! - Ketzerisch ausgedrückt, sind Ihre Seiten dann absolut sicher. Niemand wird sie jemals abrufen. - Was Firmenpolitik ist, und wie sie sich auf Sie negativ auswirkt, zeigt sich daran, dass so manche Zertifizierungsstelle für Schlüssel von einigen Browser-Herstellern nicht akzeptiert werden.
• Es müssen alle Inhalte innerhalb des mit Zertifikat geschützten Bereiches liegen.
  • Liegt auch nur eine Datei außerhalb, und wird für den Aufbau der Seite verwendet, so wird das Sicherheitskonzept verletzt.
  • Man spricht dann von Mixed Content - also gemischten Inhalten, die sowohl aus sicheren als auch unsicheren Elementen bestehen.
  • Das ist in meinen Tests das am häufigsten anzutreffende Symptom bei erstaunlich vielen Internet-Auftritten.
  • Es reicht eine einzige Grafik oder eine CSS-Datei. Dies erlaubt dann diverse Angriffe, bis hin zum Abfangen sogar der Session oder Cookies.
  • Bei Internet-Auftritten mit externer Werbung ist dieser sicherheitsrelevante Fehler Mixed Content oft anzutreffen und nur dann halbwegs in den Griff zu bekommen, wenn auch dieser Werbeanbieter über HTTPS verfügt.
  • Das ist u.a. deshalb nachteilig, da Betrüger dies bereits seit Jahren nutzen: Man erwirbt eine kleine, einfache, seriöse (z.B. deutsche) Domain mit ein paar absolut seriösen Inhalten, zertifiziert alles und verlinkt dann in die eigenen Seiten externe Inhalte mit den Betrugsdetails aus dubiosen Auslandsquellen. Das wurde lange Zeit in den Browsern nicht als Warnung angezeigt. Und selbst heute wird in den meisten Browsern noch immer das S für sicher verwendet und nur in einem manuell aufklappbaren Zusatzinfofeld auf die Risiken hingewiesen. D.h.: Der Kunde sieht HTTPS in der Adresse, glaubt sicher zu sein. In Wirklichkeit ist dem allerdings nicht so.
  • Seit kurzem gehen Browser-Hersteller dazu über, unsichere Zertifikate von Nutzern direkt an sie melden zu lassen: Nachdem Sie auf eine unsichere Verbindung gestoßen sind, öffnet sich vielleicht ein Fenster, in dem Sie gefragt werden, ob Sie den Fehler Mozilla melden möchten. Das Weitergeben der Adresse und des Zertifikats der unsicheren Seite wird uns helfen, gefährliche Seiten zu identifizieren und zu blockieren, um Sie besser zu schützen. - Im Klartext: Falsch installierte Zertifikate können sogar dazu führen, dass die Browser Ihren Auftritt sperren.
  • Firefox seit V23, Internet Explorer seit V9 und Chrome blockieren jeden aktiven gemischten Inhalt. Nur passive gemischte Inhalte werden angezeigt. Quelle Betroffen sind Skripte, Links, Iframe, XMLHttpRequests, fetch-Befehle, alle Angaben in der CSS etc., in denen fremde URLs angegeben sind. Letzteres können auch Bilder und Grafiken sein. Auch Object-Daten werden blockiert. (Bilder, Audio, Video-Dateien, Objekt-Dateien).
  • Seit November 2017 blockiert Firefox V 57 alle gemischten Inhalte, weil sie unsicher sind. Quelle . Das hat zur Folge, dass evtl. für den Betreiber wichtige Inhalte nicht angezeigt werden
    • Z.B. betrifft dies Bilder oder Grafiken oder die Seite wird überhaupt nicht angezeigt, falls das CSS (= Cascading Style Sheet zur Formatierung des Layouts), oder wichtige JavaScripts nicht ausgeführt werden.
    • Ferner laufen Sie als Anbieter Gefahr, dass ganze Module wie Interaktion oder Transaktion zwar angezeigt, aber nicht ausgeführt werden. D.h. der Kunde füllt etwas aus und verschwendet so seine Zeit, weil es nicht verarbeitet wird.
    • Selbst Mozilla / Firefox schreibt: Die Seite, die Sie besuchen, ist nur teilweise verschlüsselt, und obwohl sie sicher erscheint, ist sie es nicht.
  • Unterschätzen Sie die Gefahren bei gemischten Inhalten nicht. Welche Risiken bestehen bei gemischten Inhalten? Ein Angreifer kann die HTTP-Inhalte auf der aktuell besuchten Seite austauschen und damit Ihre Anmeldeinformationen stehlen, Ihr Benutzerkonto übernehmen, auf Ihre sensiblen Daten zugreifen, Inhalte der Seite austauschen oder Schadsoftware auf Ihrem Rechner installieren.
  • Allerdings zeigte jeder Browser manche Varianten des Mixed Content entweder überhaupt nicht oder zumindest unterschiedlich an:
    • Mozilla: Vieles an mixed content-Fehlern wird nicht angezeigt.

Festzuhalten bleibt, dass fast alle Browser bis heute viele Fälle von gefährlichem mixed content nicht warnend anzeigen, sondern weiterhin auf HTTPS blind vertrauen sowie dies auch so wissentlich falsch anzeigen.

• • • Anfang 2018 besaßen mindestens 1/4 aller von mir getesteten Internet-Auftritt mit Verschlüsselung dennoch keinen Automatismus zur Umschaltung. D.h. Kunden, welche nichts oder http:// eingaben, bleiben auf den ungesicherten Seiten. U.a. betraf dies große, kompetente Firmen - auch aus dem IT-Bereich wie Adobe - oder den Bayrischen Rundfunk.
    • Zahlreiche Verschlüsselungsverfahren, welche über viele Jahre verwendet wurden, sind derart unsicher, dass moderne Browser sie seit 2016 zunehmend systematisch nicht mehr unterstützen. - Im Klartext: Selbst die Browser-Hersteller räumen inzwischen ein, dass vieles an HTTPS nicht sicher war und ist. Aber diese alten Verfahren werden weiter von Anbietern / Servern verwendet und von einigen Browsern auch unterstützt.
    • Wie HTTPS://www.o.bike.de im Jahr 2017 bewies, waren die gesamten Systeme trotz HTTPS so schlampig programmiert, dass jeder nicht nur die gesamten Kundendaten, sondern auch deren Benutzer- und sogar Bewegungs-Profile aufrufen konnte. Siehe u.a. Tagesschau.de vom 30.11.2017. Dasselbe geschah bei der Firma Uber im Jahr 2017, die sich für die Vernichtung der gestohlenen 57 Millionen Kundensätze Daten sogar erpressen ließen.
    • Nur relativ wenige Server bieten Forward secrecy = FS = perfect forward secrecy (PFS). D.h. die meisten Server bieten keinen nachträglichen Schutz, wenn der private Schlüssel jemals geknackt werden sollte. Da z.B. die NSA jedoch weltweit alles aufzeichnet, kann sie auch in Jahren noch alle bis dahin geschützten Aufzeichnungen nachträglich entschlüsseln, sobald ihr der private Schlüssel bekannt wird. - Hinweis: Das hier verwendete System bietet Forward Secrecy mit modernen Browsern.
    • Server-seitig finden sich u.a.:
      • Internet-Auftritte, die zwar HTTPS besitzen, aber gleichzeitig eigene Cookies ohne Grund / technische Notwendigkeit verwenden, sind ein Widerspruch in sich selbst. Wozu benötigen diese Auftritte diese Cookies, wenn nicht, um Sie auszuspionieren. (Ausgenommen hiervon sind Session-Cookies / Session-IDs, die nur zur Verwaltung der Sitzung benötigt werden.)
      • Internet-Auftritte, die zwar HTTPS besitzen, aber gleichzeitig Fremdprogramme mit Cookies verwenden (z.B. Googles Logfile-Analyseprogramme), sind ein Widerspruch in sich selbst. Wozu benötigen diese Auftritte und vor allem die dritten Fremdanbieter diese Cookies, wenn nicht, um Sie auszuspionieren. P.S.: JavaScript in Seiten, die solche Daten auswerten und dann auch noch an Server in den USA oder dem sonstigen Ausland versenden, sind natürlich das Gegenteil von sicher.
    • Nutzerseitig finden sich u.a.:
      • Betriebssysteme und sämtliche Anwenderprogramme (inklusive Browsern), welche erwiesenermaßen Hintertürchen besitzen und/oder mit Trojanern verseucht sind.
      • Ganz abgesehen von den speziellen Abhörprogrammen / Spionagesoftware wie die der NSA oder unserem Bundestrojaner.
      • Selbst sogenannte Sicherheitsprogramme sind vermutlich alle verseucht resp. mit Hintertürchen versehen. Installieren Sie sich im Zweifel eine Antiviren-Software und überprüfen Sie deren Tätigkeiten mit einer scharf eingestellten Firewall. Sie werden über die häufigen Kontaktaufnahmen nach draußen erstaunt sein.
      • Noch gravierender sind Zugriffe auf die Hardware selbst. So bin ich immer wieder erstaunt, wie oft meine Grafikkarte und deren Software (u.a. Treiber) versuchen, Kontakt zu Internet-Adressen herzustellen. Die Grafikkarte muss definitiv alles lesbar darstellen. Das ist ihre Kernaufgabe.

    SSL / TLS resp. HTTPS schützen nur den Verbindungsweg:

  • Das SSL-Protokoll schützt nur die reine Verbindung vom Sender zum Empfänger und vom Empfänger zum Sender - also nur den Transportweg.
  • Nicht geschützt sind hingegen weiterhin die Senderseite (Internet-Auftritt / Server) sowie die Empfängerseite (Nutzer).
  • An den Endstellen anzusetzen, ist auch viel einfacher, da hier alle Nachrichten / Inhalte zwangsläufig entschlüsselt werden müssen, damit man als Nutzer sie lesen und als Server verarbeiten kann.
  • Eine Ende-zu-Ende-Verschlüsselung bedeutet leider nicht das, was sich die meisten Menschen darunter vorstellen. In einer erheblichen Anzahl von Fällen ist die HTTPS-Verschlüsselung nicht bis zum Server ausgeführt, sondern nur bis zu einem davor gelagerten Load-Balancer. Diese Load-Balancer ver- und entschlüsseln alle Daten. Dahinter wird im Anbieter-/Firmennetz alles unverschlüsselt (= offen lesbar) weitergeleitet. Dieses wird zwar gerne als firmenintern bewertet und vermarktet, ist es jedoch nicht immer. Größere Firmen und Organisationen, welche mehrere Standorte besitzen, oder sogar über mehrere Länder verteilt arbeiten, verwenden nicht nur Kabelnetze, sondern auch Funk. Sie als Endanwender können nur hoffen, dass dort dann wirklich alles perfekt geschützt ist.
  • Passend zum Artikel kam Anfang 2018 einer der größten Skandale der Computer-Geschichte ans Licht:
    • Bereits im Sommer 2017 wurde Intel von schwersten Sicherheitsmängeln in allen Prozessoren informiert.
    • Statt die Produktion zu stoppen und eine andere Architektur zur Lösung des Problems zu erarbeiten, ließ man alles weiterlaufen.
    • Stattdessen verkaufte der Intel-Chef Brian Krzanizh Ende November 2017 alle seine freien Aktien zum höchsten Kurs seit dem Jahr 2001 - als kleines eigenes Weihnachtsgeschenk in Höhe von über 24 Million US$, bevor die Sache publik wurde. So etwas wurde früher als Insider-Handel schwer bestraft. Aber warum sollten die Sicherheitsdienste, welche davon wissen und von den Sicherheitslücken profitieren, diesen ehrenwerten Helfer bestrafen?
    • Erst als manchen anderen Beteiligten die weitgehende Untätigkeit der Firma Intel zu weit ging, wurde Anfang Januar 2018 - ein halbes Jahr später - die Öffentlichkeit informiert.
    • Auch dann flüchtete sich Intel - wie bei früheren Zwischenfällen - zu Falschaussagen, Vertuschung, Beschwichtigung und Abwarten.
    • Laut Aussage Intels sind die Prozessoren nur der letzten paar Jahre betroffen.
    • Laut Aussage der Kritiker sind alle Prozessoren seit mindestens 1995 betroffen.
    • Es wird zwar halbherzig von anderen US-Chip-Herstellern (AMD und ARM) bestritten. Aber es sollen auch die meisten Chips aller anderen Chip-Hersteller betroffen sein.
    • Ferner sind alle Geräte mit Prozessoren betroffen: PCs zu Hause, Server in Firmen und bei Providern, alle Cloud-Systeme, Computer der Universitäten, der Banken, der Behörden..., alle Laptops, Tablets, Smartphones, Fernseher usw.
    • D.h. praktisch alle sich heute überhaupt irgendwo in Betrieb befindlichen Systeme, welche einen Prozessor verwenden.
    • Der Prozessor gehört der untersten Hardware-Schicht an. Alle relevanten Daten gehen durch ihn. Da greift kein Schutzmechanismus der höheren Schichten.
    • Es handelt sich gleich um mehrere Fehler in dem Prozessorsystem, welche die komplette Übernahme des Speichers und somit aller Daten auf dem PC in Klarschrift erlauben: Alle Ihre Passwörter, Zugangsdaten, Schlüssel für die HTTPS-Verschlüsselung - alles.
    • Nun ist also bekannt geworden, was Sicherheitsanalytiker schon seit 2001 befürchteten: Die unterste Hardware-Schicht wurde systematisch übernommen.
    • Angesichts der wieder einmal nur scheibchenweise bekanntgewordenen Zusammenhänge bei diesen US-Firmen, fällt es vielen Sicherheitsanalytikern schwer, an Zufälle glauben. Dazu sind es inzwischen zu viele.
    • Fakt bleibt, dass es keine praktikable Lösung für diese Sicherheitslücken gibt. Die einzige Weg besteht in der kompletten Abschaltung wichtigster Funktionen im Prozessor, welche die Leistung laut Intel um 2% drosselt, laut Kritikern jedoch um bis zu 30%. Das ist völlig inakzeptabel und wird deshalb so auch nicht durchgeführt werden können.
    • Um die Lage noch zu verschlimmern: Mit Software-Updates lässt sich nur ein Teil der Lücken überhaupt schließen. Ferner wird es definitiv keine Updates für alle älteren Geräte (vor 2017) geben, da diese nicht mehr supported werden (z.B. alle älteren Smartphones). D.h. ca. 90% aller Geräte mit Prozessor (weltweit mehrere Milliarden) werden weiterhin komplett abhörbar bleiben, weil man das Problem überhaupt nicht lösen will.
    • Und bezeichnenderweise lässt sich auch im Nachhinein nicht nachweisen, ob oder wann man zum Opfer wurde. Die Sicherheitslücken sind so clever gemacht, dass sie keine Spuren hinterlassen (siehe hierzu: Meltdown und Spectre).
    • Um es klar festzuhalten, nicht die Prozessor-Technologie des Ausnutzens der arbeitsleeren Wartezeiten (das Ausführen von Aufgaben im Voraus) an sich ist falsch oder sicherheitsanfällig, sondern exakt nur das Detail, wie die Chip-Hersteller sie in den Prozessor vorsätzlich eingebaut haben und wie alle Betriebssysteme sie verwenden.
    • Auffällig ist ferner, dass die Sicherheitslücken nur das Mithören / Abhören aber nicht das verändern der Daten erlauben.
    • Überdies hätte zumindest den Prozessoranalytikern bereits vor Jahren auffallen müssen, dass alle US-Chip-Hersteller dieselbe Technologie auf dieselbe Weise in ihre Prozessoren implementierten. Normalerweise vermeiden alle Beteiligten die ständigen und extrem teuren Schadenersatzansprüche bei Patentstreitigkeiten, indem sie dieselbe Technologie auf unterschiedliche Weisen, sprich mit einer anderen Technik, umsetzen. Hier wurde - trotz zahlreicher Alternativen - von allen US-Herstellern jedoch die identische Implementierung gewählt. Und niemand klagte. So etwas hilft selbstverständlich einer zentralen Instanz, welche für alle Abhörmaßnahmen nur ein Verfahren wünscht.
    • Der hier getriebene Aufwand spricht gegen normale Verbrecher und für Genies, welche das System über Jahrzehnte ausnutzen wollten. Dies ist ihnen seit 1995 auch gelungen.
    • In den 1990er Jahren liefen die Sicherheitsdienste auch in Deutschland Sturm und forderten ein Hintertürchen in alle damals neu aufgekommenen Verschlüsselungssysteme. Obwohl die Regierung bereit war, dieses Gesetz durchzubringen, ließen die Sicherheitsdienste das Ansinnen von einem Tag auf den anderen - völlig unerwartet für die Beobachter und Beteiligten - fallen. Schon damals vermuteten zahlreiche Sicherheitsexperten, dass sie einen Weg gefunden hatten, jedes moderne Verschlüsselungssystem zu knacken.
    • Intel und die anderen Chip-Hersteller werden nun natürlich neue Chips entwickeln, produzieren und - angesichts der nun erzeugten gigantischen Nachfrage - für sündhaft viel Geld verkaufen. Aber ich wette keinen Cent darauf, dass diese Prozessoren auch nur im geringsten sicherer sein werden. Die Sicherheitsdienste werden schon darauf bestehen, dass die alten Lücken durch neue ersetzt werden.
    • Wer die Prozessoren über Lücken von außen kontrolliert, beherrscht die Welt.
    • Alle Schutzmaßnahmen in Schichten darüber (wie HTTPS) eignen sich bestenfalls als Beruhigungsplazebos. - Wenn ein Kuchen (die gesamte IT-Infrastruktur) von unten her systematisch vom Schimmelpilz zersetzt ist, dann kann man ihn durch einen oben angebrachten Zuckerguss (HTTPS) auch nicht mehr retten.

  Für die Nutzer kommen weitere Tücken hinzu:

• Es finden sich je nach Browser unterschiedliche Symbole für HTTPS. Noch nicht einmal auf die einheitliche Darstellung konnte man sich in allen Browsern einigen. So ist das Schloss in Microsoft Edge z.B. grau gestaltet. - Aber, bevor nun alle wieder auf Microsoft schimpfen: De facto haben deren Programmierer Recht. Die gesamten Attribute sicher, grün etc. sind nicht gerechtfertigt. Allerdings ist es bezeichnend, dass der Internet-Explorer 11 überhaupt nichts anzeigt.
• Hinzu kommt, dass je nach Zertifikat auch unterschiedliche Darstellungen der Symbole existieren. EV-Zertifikate (= Extended-Validation-Zertifikate) werden so z.B. durch einen grünen Balken mit einem weißen Firmennamen angezeigt oder durch grüne Schrift auf weißem Hintergrund. Das dürfte keineswegs allen Nutzern klar sein.
• Die Ansicht im Webbrowser verrät noch nicht, ob auch die komplette Zertifikatkette des Webservers auf SHA-2 umgestellt wurde. Insbesondere können die dargestellten Intermediate-CAs auch aus dem internen Zertifikatspeicher des Webbrowsers kommen und nicht die tatsächliche Konfiguration des Webservers widerspiegeln. - In anderen Worten: Selbst, wenn ein Server / Internet-Auftritt Ihnen ein aktuelles und korrektes Zertifikat im Browser anzeigt, muss keineswegs alles sicher sein. Der Laie dürfte die Details kaum selbst austesten können.
• Die HTTPS-Verschlüsselung ist in gewissem Sinne abwärtskompatibel. D.h. nur mit dem neuesten Betriebssystem und den neuesten Browsern können Sie überhaupt die höchste Verschlüsselung nutzen. Alte Betriebssysteme oder Browser verwenden hingegen automatisch unsicherere Verfahren bei HTTPS. Wer mehr dazu wissen möchte, sollte sich bei Server-Gated Cryptography (SGC) einlesen.
• Sichere Verbindung: Die oft zu lesende Behauptung, dass HTTPS die gesamte Kommunikation mit der Firma sicher machen würde, ist unzutreffend. Nur im Idealfall kann es evtl. so sein: wenn z.B. alles um das Zertifikat und dem Internet-Auftritt korrekt implementiert wurde, ist die Kommunikation über ein perfekt programmiertes Kontaktformular, das anschließend verschlüsselt an den Mail-Server der Firma übertragen wird, und die Nachricht dann auch verschlüsselt abgerufen wird. Die üblichen anklickbaren Mail-Adressen, bei denen sich Ihr E-Mail-Programm öffnet, sind weiterhin völlig ungeschützt. E-Mail ohne PGP ist noch immer eine offene Postkarte.