Controlling 21

Dr. J. Schuhmacher

Sicherheit im Internet mit HTTPS, Secure Socket Layer, SSL, TLS

In allgemeinen Fachkreisen bereits seit vielen Jahren im Gespräch wurde HTTPS 2017 zum Trend in Deutschland. Da in den weitgehend unkritischen deutschen Medien fast ausschließlich die Befürworter Redefreiheit erhalten, wird hier diese ganze Sache auch kritisch betrachtet, und die konkreten Bedenken anderer Sicherheitsexperten aus der ganzen Welt kommen zu Wort. Dabei werden unverhofft zahlreiche Haken und Ösen sichtbar.

Im Anschluss finden Sie einen Beschreibung, wie Sie Ihre Website perfekt auf https umstellen können.

Ein Inhaltsverzeichnis mit direkten Sprungmarken und Überblick über alle bei Sicherheit im Internet mit HTTPS, Secure Socket Layer, SSL, TLS behandelten Themenbereiche finden Sie als Pop-Up.

Schwarz-Weiß-Malerei

Von den Befürwortern (u.a. den Browser-Herstellern) wird pauschal nur in zwei Kategorien eingeteilt: sicher und unsicher.

Bereits in der Wortwahl liegt ein typischer Übersetzungsfehler aus dem Englischen vor. Dort verwendet man korrekt im Zusammenhang mit HTTPS das Wort secure oder secured. Dies ist jedoch mit gesichert oder abgesichert zu übersetzen. - Folglich stehen mit HTTPS (ab-) gesicherte Internet-Verbindungen solchen gegenüber, die nicht mit HTTPS abgesichert sind.

Sicherheitsberater und -Techniker sprechen auch korrekt nie von (absoluter) Sicherheit, sondern immer von Zonen, Stufen, Bereichen, Ebenen der Sicherheit. Korrekt spricht man im Englischen deshalb auch von a more secure Internet - einem Internet mit höherer Sicherheit. Das Wort safe, welches eher dem pauschalen deutschen sicher entspricht, wird dafür im Englischen von offizieller Seite nicht verwendet.

Dieser Artikel über Sicherheit mit HTTPS, SSL, TLS erklärt Ihnen (auch als Laien verständlich) die Graustufen der damit verbundenen Sicherheitsebenen, damit Sie selbst entscheiden können, wie Sie dies zu bewerten haben, und was Sie als Nutzer (eines Browsers) oder Betreiber (eines Internet-Auftrittes) tun können.

Unsichere Geschichte

Um die Vor- und Nachteile von HTTPS bewerten zu können, muss man zuerst einen kurzen Blick auf die Geschichte des Internets werfen.

Anfänge

Als US-Militärs das Internet 1959 konzipierten, bestand die Forderung darin, Datenpakete = Nachrichten von A nach B zu transportieren, selbst wenn ein Großteil der weltweiten Kommunikationsmittel durch einen atomaren Erstschlag des Gegners zerstört wären. Dazu benötigte man dezentral arbeitende Netzwerke, die sich gegenseitig ersetzen konnten.

Datensicherheit meinte damals nur, dass eine Nachricht irgendwie komplett am Ziel ankommen soll - betraf somit den reinen Datentransport. Unter Sicherheit verstanden die Erdenker des ursprünglichen internationalen Netzwerkes somit nur Ausfallsicherheit. Dies wurde mit dem sogenannten ARPANET 1969 erreicht - Advanced Research Projects Agency Network. Dazu hatte man das noch heute verwendete Netzwerkprotokoll TCP/IP entwickelt.

Da es sich um ein US-Netzwerk handelte, das zuerst auch nur der NATO und den anderen Militärpartnern zur Verfügung stand, machte man sich keine großen Sorgen um Datensicherheit im modernen Sinne, insbesondere stand der Datenschutz nicht im Blickfeld.

Die Teilnetze arbeiteten autark. Nachrichten wurden (zerteilt in kleine Datenpakete) folglich von Knoten zu Knoten weitergereicht, wobei niemand im Voraus wusste, welche Netzwerkknoten (= Computer) verwendet wurden, oder von dort als nächstes angesteuert wurden. Exakt dies machte die Unzerstörbarkeit aus. Selbst wenn viele Knoten zerstört worden wären, hätten die Datenpakete eine oder mehrere andere Route(n) eingeschlagen. Beim Empfänger wären die Einzelteile wieder zur Gesamtnachricht zusammengesetzt worden.

Da die Beteiligten aus quasi nur zugelassenen Clubmitgliedern (Insidern) bestanden, spielte es keine Rolle, wie die Nachrichten sich im Netz fortbewegten. De facto war sogar das unkontrollierbare = unzerstörbare Fortbewegen der Nachrichten das Ziel.

Um diese Kommunikation über alle Medien (Netze) durchgängig führen zu können, wurden in den 1970er Jahren Abstraktions-Ebenen (abstraction layers) eingeführt: Im Prinzip handelt es sich um 4 bis 7 Schichten, denen jeweils Funktionen zugeordnet wurden. Das war ein in jeder Beziehung wichtiger Schritt. Denn nun wurden Aufgaben delegiert. D.h. bestimmte Schichten führten bestimmte Aufgaben durch und hatten dazu allerdings auch bestimmte Rechte.
Spätestens hier steigen normalerweise die meisten Betrachter aus. Denn hier wird es wirklich kompliziert und auch fehleranfällig. Eigentlich wurden diese Ebenen erdacht, um Fehler zu vermeiden. Da sich jeder jedoch darauf verlässt, dass der andere Programmierer auf der darunter liegenden Ebene alles korrekt durchführt, und die erforderlichen Schnittstellen passen, können dadurch auch gigantische Sicherheitslöcher entstehen.
Bitte behalten Sie das Schichtmodell im Kopf. Wir werden es bei HTTPS wieder benötigen.

Als weiterer Gefahrenpunkt war bereits früh die Autonomie, der Autarkismus aller Systeme, erkannt. De Facto kontrollieren die Router (spezielle Hard- und Software, welche die Daten auf bestimmte Wege schicken) die Netzwerke. Aus damaliger Sicht war dies sinnvoll.

Hinzu kommen sowohl politische wie ökonomische Gefahrenpunkte: So technisch dezentral das Internet auch ist, die USA haben bis heute sämtliche hierarchisch und organisatorisch wichtigen Stellen in ihrer eigenen Hand behalten. Letztendlich bestimmen sie die Spielregeln.

Fazit

Die unteren Layer / Ebenen und eigentlich das gesamte Denkgebäude = IT-System hatten einen völlig anderen Zweck und keinen Bezug zum modernen Datenschutz.

Im Grund waren Privatnutzer und kommerzielle Firmen, die dann auch noch Geschäfte miteinander über dieses Netzwerk tätigten, in der Frühphase nicht vorgesehen.

Das darauf-gesattelte HTTP

Ab 1972 wurden systematisch US-Universitäten und dann auch weitere Forschungseinrichtungen weltweit an das zunehmend als Internet bezeichnete Netz angeschlossen.

Systematisch wurden auf das Protokoll TCP/IP weitere Ebenen / Layer und Protokolle (= Dienste) aufgeschaltet, wie z.B. E-Mail, FTP etc. Zusätzlich wurden die Details dazu im Zuge der allgemeinen Modularisierung und Objektorientierung als eigenständige Module geschaffen, wodurch alles noch undurchschaubarer wurde.

Bereits dies machte die Infrastruktur schon damals ziemlich unsicher. Aber es störte noch kaum jemanden.

Relevant wurde das Ganze erst, als man oben drauf die HTTP-Ebene setzte und sich das damit verbundene WWW ab 1989 explosionsartig für private sowie kommerzielle Nutzer öffnete und verbreitete.

Hinzu kommt ein vergessener resp. gerne verschwiegener Umstand: Die unsichere Architektur des Internets mit den vielen Schichten sowie komplexen Modulen wurde in den letzten Jahrzehnten für fast alle Geräte übernommen, die an das Internet angeschlossen werden sollten: Alle Hardware, Betriebssysteme etc. D.h. inzwischen ist Ihr PC, Smartphone, Tablett, Auto, Fernseher etc. auch so konzipiert.

Grundlegende Probleme des Internets

Lassen Sie uns zuerst einen Blick auf die allgemeinen Sicherheitsprobleme des Internets werfen, damit Sie die Details bei HTTPS besser verstehen.

Schichten, Module, Protokolle

Aus Sicherheits-Sicht liegt eines der größten Probleme darin, dass eine Anwendung / Layer / Schicht etwas macht, aber nicht mitteilt, was und wie sie das macht. Man spricht hierbei völlig euphemistisch von transparent. Es ist jedoch nicht durchschaubar, sondern unsichtbar. De facto ist alles eine Blackbox, der man meist blind vertraut.

Diese Schichten und deren einzelne Module (Bausteine) kommunizieren über Protokolle und werden durch schriftlich fixierte Standards definiert. Man schätzt inzwischen die Anzahl der nur zum Kernbereich des Internets gehörenden Protokolle auf etwa 500. So genau weiß das niemand mehr. Hinzu kommt, dass diese dann jeweils selbst wieder aus zahlreichen Modulen / Bausteinen bestehen. Aber die Protokolle / Regeln sind keineswegs so klar formuliert, dass man sie nicht missverstehen oder zweckentfremden kann.

Da das gesamte Internet aus einer kaum mehr überschaubaren Anzahl derartiger Schwarzer Kisten besteht, existieren auch nur noch wenige IT-Spezialisten, die wirklich einen Überblick und vor allem Durchblick besitzen. In der Tat ist es bereits sehr schwer, auch nur die notwendigen Schnittstellen zur Datenübergabe eines einzigen Moduls / Layers perfekt zu verstehen.

Exakt hier setzen viele Sicherheitsdienste sowie Kriminelle an. Wer eine Schicht, oder auch nur wichtige autarke Bausteine in einer Schicht durch Hintertürchen kontrolliert, kontrolliert de facto alles darüber im Schichtaufbau.

Nun wird auch verständlich, warum Sicherheitsdienste Zugangsdaten / Hintertürchen in fast alle Elemente - vor allem auf den tiefen Schichten - einbauen oder knallhart von den nationalen Herstellern diese Einbauten für sie selbst fordern.

Hinzu kommt, dass neue (vermeintlich sicherere) Protokolle sowie Hard- und Software neben weiterhin laufenden alten (unsicheren) arbeiten. Das Netz ist historisch gewachsen, und man kann alte Teilnehmer nicht so einfach ausschließen. Der Haken liegt nun jedoch darin, dass man neue mit alten Protokollen gezielt mischen und somit sicherheitstechnisch austricksen kann. Plötzlich kann sogar weniger Sicherheit als jemals zuvor das Ergebnis sein.

Die Komplexität ist in den letzten Jahrzehnten sogar stets weiter gewachsen.

Spielverderber

Stellen Sie sich das Internet wie ein Schachspiel vor. Die Regeln wurden halbwegs fair aufgestellt und haben sich deshalb lange gehalten. Alle ehrlichen Spieler halten sich daran. Die Feldgröße und die Figuren sowie deren Bewegungen sind fest-gelegt.

Hacken oder cracken besteht nun darin, diese Spielregeln als Spielverderber bewusst zu missachten. So kann man das Spielfeld der erlaubten 8*8 Zellen erweitern, indem man (rein zweidimensional) rund herum 8 weitere Spielfelder aufbaut, um Spielregeln im wahrsten Sinne des Wortes zu umgehen. Begabtere Leser dürfen sich dies auch gerne räumlich mit 3 Dimensionen von Spielfeldern vorstellen, und Mathematiker gerne auch in weiteren beliebig vielen Dimensionen als Matrix. Auf den neuen Spielfeldern kann man auch neue Figuren einführen - mit ganz anderen Möglichkeiten, die erlaubten Figuren im Zentralfeld zu schädigen, zu manipulieren etc.

Faktor Mensch

In vielen Firmen und Institutionen werden Millionen an Euro/Dollar in Sicherheits-Hardware und -Software investiert. Da spielt Geld oft keine Rolle.

Bei den Menschen, welche damit arbeiten (z.B. die Systemadministratoren), wird hingegen teilweise mit der Lupe nach Einsparmöglichkeiten gesucht. Die Menschen sind jedoch die leichtesten Opfer im klassischen wie modernen Spionagesystem aller Akteure. Wer einen Maulwurf einschleusen kann, oder angesichts des knappen Gehaltes und hoher Lebenshaltungskosten in Großstädten einen für Geld empfänglichen Menschen innerhalb des Sicherheitssystems umdrehen kann, hat leichten und direkten Zugang zu allem.
Oft reicht es aus, wenn dieser Menschen einmal ein einziges Programm in das System einspielt. Der Rest erfolgt dann von außen.

Die klassischen Sicherheitskontrollen reichen hierbei nicht aus. Denn seit langem wird hier nicht mehr ein offensichtliches Schadprogramm eingeschleust, sondern oft ein bekanntes und überall verwendetes und zwingend erforderliches Nutzprogramm (z.B. eine sogenannte Bibliothek für HTTPS), welche seine Arbeit perfekt und zu aller Zufriedenheit erledigt. Nur hin und wieder macht die Software auch etwas anderes. De facto reicht es aus, wenn sie dies einmal durchführt.

Jeder entgegnet mir, dass so etwas unmöglich sei, da heute alle Programme durch andere überwacht würden. Das klingt in der Theorie immer beeindruckend. In der Computerpraxis ist dies reines Wunschdenken. Mir sind namhafte Firmen bekannt, welche jeden Detaileinblick in die aktuell laufenden Programme verloren haben - ein Zustand, der schon seit Jahrzehnten anhält. Mir sagte einmal ein Rechenzentrumsleiter: Wir schätzen, dass von den zehntausenden ständig laufenden Programmen, vermutlich bis zu 25% überflüssig sind. Aber wir wissen nicht welche. - Und wehe dem, der ein wichtiges Programm aus Versehen abschaltet.

Im seit Jahrzehnten gewachsenen Internet, in dem die Gründer und z.T. bereits die zweite Generation an Programmierern schon im Ruhestand sind, ist dies nicht besser. Man weiß schlichtweg in vielen Details nicht mehr, wer wann was wo wie wozu gemacht hat.

Spielregeln verstehen, ausnutzen und ändern

Am höchsten bezahlt sind jedoch die Logikgenies, welche die Spielregeln durch sich selbst aushebeln. Denn, wer logischer denkt, gewinnt.

Wer weiter vorausdenkt gewinnt. D.h. wer alle Komponenten der Spielregeln (im Internet: Protokolle) über dutzende oder gar hunderte Züge im Voraus berechnen kann, gewinnt.

Da sowohl bei Schach als auch bei Go inzwischen lernende Systeme (= Künstliche Intelligenz) - Software auf Computern - die besten Menschen geschlagen haben, handelt es sich somit beim besseren Ausnutzen der Spielregeln um reine Fragen der Rechenleistung und der Intelligenz beim Programmieren von KI-Programmen (KI - künstliche Intelligenz = AI - artificial intelligence). Sie dürfen davon ausgehen, dass weltweit die Sicherheitsdienste an derartigen AI-/KI-Systemen und ML (= machine learning) zum Übertrumpfen der Spielregeln des Internets arbeiten.

Da ich immer wieder E-Mail-Anfragen zu den Auswirkungen erhalte, hier im Klartext: Zukünftig werden Computer mit Spezialsoftware alle Regeln des Internets selbständig erlernen und ausnutzen - schneller als jeder Hacker oder geniale Programmierer es jemals könnte und bald sogar schneller, als alle Programmierer der Welt zusammen es jemals in ihrer ganzen Lebenszeit könnten. Das Einzige, worüber man sich derzeit noch streitet, sind die Fragen, ob es sich um komplett autarke Systeme handeln soll, oder ob der Mensch die letzte Kontrolle über Entscheidungen behält. - Alle Analytiker sind sich einig, dass diese AI sogar die nationale Sicherheitstechnologie völlig verändert - und damit Ihre private sowieso.

In meinen Sicherheits-Vorträgen erfolgt dann meist der Einwand: Dann ändern wir die Spielregeln!
Das ist in der Tat ein guter Vorschlag, der jedoch schnell an Grenzen stößt. - Nehmen wir das in Diskussionen mir oft genannte viel einfachere Beispiel Fußball zum Vergleich. Dort würden angeblich auch ständig die Regeln verändert. Das ist korrekt. Aber das Spiel ist anders geartet: Von den 7 Milliarden Menschen spielt nicht einmal 1% aktiv das Spiel. Die anderen 99% sind passive Zuschauer. Die 1% Spieler kann man mit massivem internationalen Druck durchaus zum Erlernen der neuen Spielregeln zwingen. Aber beim Internet sind die Verhältnisse deutlich anders. Es wäre schon eine Erleichterung, wenn nur alle 7 Milliarden Menschen daran aktiv teilnehmen würden. De facto liegt die Zahl weit über 100%, wenn man alle Geräte des Internets der Dinge hinzuzählt (Häuser, Kühlschränke, Armbanduhren, Autos, Fernseher...). Viele davon haben eine lange Lebensdauer und sind nicht einfach auf die neuen Spielregeln umprogrammierbar. Vor allem beim weitgehend schutzlosen Internet der Dinge setzen deshalb inzwischen die meisten Hacker an. Es handelt sich um eine Art Neben-Schachbrett, über das man dann wieder die Figuren auf dem zentralen Schachbrett angreifen kann. Beim vermeintlich leichter verständlichen Fußballspiel werden jedoch ebenfalls schnell die Grenzen der Änderungsmöglichkeiten der Spielregeln sichtbar. Wer genau hinsieht, erkennt, dass nur minimale Details veränderbar sind. Bereits die von der Werbebranche geforderte Änderung der Spielzeiten (2 Hälften) in sagen wir 4 mit 3 Werbepausen dazwischen, dürfte vermutlich scheitern, weil die Zuschauer das nicht akzeptieren. Oder die Vergrößerung der Spielfläche - sagen wir um 10 Meter in jede Richtung, dürfte an den immensen Investitionen in die bisherigen Stadien scheitern. Oder die Änderung der Form des Spielfeldes - sagen wir von dem klassischen Rechteck zu einem Sechseck mit drei Toren und drei gleichzeitig spielenden Mannschaften. Vermutlich dürfte bereits die kleine Regeländerung scheitern, dass zukünftig alle Fußballer auch ihre Hände verwenden dürfen. Dann wäre es nämlich ein anderes Spiel (Handball). Sie erkennen es selbst: Einmal etablierte Spielregeln sind in zentralen Punkten sehr schwer zu verändern. - Exakt so ist es im seit Jahrzehnten gewachsenen Internet. Deshalb baut man lieber etwas Halbgares oben drauf (z.B. HTTPS), als die Grundlagen zu erschüttern.

Man kann heute identische Lebewesen Klonen. Aber nach ein paar Jahren Entwicklung sind sie kaum mehr umerziehbar. Jeder, der eigene Kinder hat, weiß, was ich meine. Mit IT-Systemen ist es ähnlich: Gewachsene Systeme sind langlebig.

Es bleibt somit dabei: Wer die Spielregeln am besten versteht, beherrscht das Internet - und zwar von unten.

HTTPS im Detail

Nachdem deutlich wurde, wie unsicher das gesamte Internet systembedingt ist, lassen Sie uns nun einen Blick auf HTTPS im Einzelnen werfen.

Sicherheitsdeckel oben drauf oder Tunnel darunter

Im Internet waren und sind alle Daten in Klarschrift für jeden einsehbar = Prinzip der Postkarte.

Bereits sehr früh erkannte man, dass mit der weltweiten Nutzung des WWW es einer anderen Art der Sicherheit bedurfte, damit das de facto völlig unsichere Datennetz überhaupt eine kommerzielle Zukunft hatte. Deshalb führte Netscape 1994 für seinen damaligen Browser erstmals das SSL Protokoll V1 ein. SSL steht für secure socket layer = eine weitere separate Schicht. Diese wurde später von TLS (Transport Layer Security) abgelöst.

Es finden sich zwei Aussagen, welche beide korrekt sind: Zum Schutz legte man eine weitere Schicht unter HTTP (oft als VPN - Virtual Private Network bezeichnet). Das extra für das WWW eingeführte HTTP ist jedoch bereits die oberste Schicht, unter der viele andere viel wichtigere Internet-Schichten liegen. - Und zweitens liegt dieser Layer (Schutzschicht) somit oben auf allen anderen bereits bestehenden Internet-Protokollen - als Schutzdeckel oben drauf.
In der Folge sprach man auch oft von HTTP über SSL sowie später HTTP über TLS.

Die drei Ziele waren und sind bis heute interessant. Man wollte Folgendes gewährleisten: Erstens war die Identität wichtig - also der Server (Anbieter-Internet-Auftritt) ist wirklich derjenige ist, der er zu sein vorgibt. Dann folgte die Integrität, womit gemeint ist, dass die Nachrichten auf dem Übertragungsweg nicht verfälscht werden dürfen. Schließlich ist die Verschlüsselung elementar - also die Nachrichten dürfen auf dem Übertragungsweg nicht abgehört und entziffert werden.

HTTPS (= Hyper Text Transport Protocol Secure) stellt somit eine Transportverschlüsselung mit Authentifizierung dar. Dazu wurde eine weitere Schicht (layer) direkt unterhalb von HTTP definiert, also unterhalb der eigentlichen Seiteninhalte (Texte, Bilder etc.). Dabei bedeutet Authentifizierung, dass sich die beiden Partner (Sender und Empfänger) beim Verbindungsaufbau gegenseitig identifizieren können (aber nicht müssen). Verschlüsselung bedeutet, dass die Daten nicht mehr in Klarschrift für jeden sofort lesbar sind (= Prinzip des verschlossenen Briefumschlages).

Verschlüsselung

Bei einer Verschlüsselung handelt es sich heute um einen mathematischen Vorgang zur Kodierung und Dekodierung von Informationen.

Allgemein finden sich zur Verschlüsselung der symmetrische Schlüssel, wobei beide Partner denselben Schlüssel verwenden zum Ver- und Entschlüsseln. Das ist eine schnell und einfach zu handhabende Bedienung, mit jedoch einer komplizierten Schlüsselübergabe. Dann gibt es den asymmetrische Schlüssel, wobei der Versender einen geheimen privaten Schlüssel zum Verschlüsseln verwendet, und der Empfänger einen davon abgeleiteten und überall einsehbaren öffentlichen Schlüssel zum Entschlüsseln verwendet. Das ist eine komplexe und langsame Anwendung, bietet aber eine einfache Schlüsselübergabe.

Bei HTTPS werden aus Lastgründen beide Verfahren kombiniert. - Zwei Verfahren sind allerdings immer unsicherer als eines.

Jedes SSL-Zertifikat beinhaltet ein Schlüsselpaar aus einem öffentlichen und einem privaten Schlüssel: Der private Schlüssel mit dem Code und der öffentliche Schlüssel für die Dekodierung. Der private Schlüssel ist auf dem Server des Anbieters (= Internet-Auftritt) installiert und darf nicht weitergegeben werden. Der öffentliche Schlüssel ist hingegen in das SSL-Zertifikat integriert und wird an alle anfragenden Browser gesendet. Ferner liegt der öffentliche Schlüssel auch bei einer sogenannten Zertifizierungsstelle. Dort werden auch alle Daten zum ausgestellten HTTPS-Zertifikat aufbewahrt und für die Öffentlichkeit vorrätig gehalten.

Die Verschlüsselung kann über zwei Wege / Verfahren durchgeführt werden: Erstens die asymmetrische Verschlüsselung oder das Diffie-Hellman-Schlüsselaustausch-Verfahren.
Zwei Verfahren kann man immer gegeneinander ausspielen. Bereits die Unfähigkeit resp. der mangelnde Wille, sich auf eine Varianten zu einigen, zeigt die massiven Probleme jenes angeblichen Sicherheitsstandards.

Beide Verfahren tauschen einen gemeinsamen symmetrischen Sitzungs-Schlüssel zwischen Empfänger und Sender aus. Dieser wird vom Browser des Endnutzers erzeugt und ist nur für diese eine Sitzung gültig.

Von den zahlreichen Schlüssel-Austauschverfahren gelten derzeit nur noch zwei als relativ sicher (Elliptic-curve Diffie–Hellman und Diffie–Hellman key exchange - DH).
Mit diesem symmetrischen Schlüssel werden die Inhalte selbst (Seitentexte, Fotos etc.) verschlüsselt.

Die Schlüssellänge ist jedoch für die Sicherheit entscheidend: SHA-1 verlangt nur 128 Bit-Verschlüsselung. Diese wird zusätzlich noch durch ressourcensparende Mechanismen (z.B. Stromverschlüsselung) weiter aufgeweicht und unsicherer gemacht. Ferner wird der Empfänger / Nutzer meist nicht mit Zertifikat geprüft. Aktuell sind Schlüssellängen von 2048 Bit im Angebot, wobei die meisten eher nur 1024 Bit als Standard verwenden, da dies Rechenzeit spart. Warum verwendet jedoch PGP (Pretty Good Privacy für E-Mails) seit 2007 bereits eine wesentlich aufwändigere Verschlüsselung, die man 2012 nochmals drastisch verschärfte? Und selbst an der Technologie von PGP gibt es ernstzunehmende Kritik in Sicherheitsfragen.
Schwache Schlüssel mit kurzer Schlüssellänge haben schwache Zertifikate zur Folge. So dürfen SSL-verschlüsselte Internet-Auftritte mit schwachen Zertifikaten eine abhörbare Datenübertragung aufbauen, obwohl Ihr Browser in grüner Farbe eine vermeintlich nicht abhörbare HTTPS-Verbindung anzeigt. Um abwärtskompatibel zu sein (d.h. nicht fast alle Nutzer auszusperren), müssen die Server sogar zahlreiche Schlüssel-Verfahren resp. Sicherheitsstufen anbieten. So bieten mein Zertifikat hier und mein Server 22 Verfahren an, die selbstredend nicht alle gleichwertig sicher sind. Ähnlich sieht es bei TLS aus: So unterstützt fast jeder Server heute TLS 1.0, 1.1 und 1.2 sowie 1.3. Das letzte ist von allen am sichersten. Aber man benötigt die anderen für ältere Browser - vor allem alle mobilen Android-Systeme bis einschließlich 4 oder Internet-Explorer bis V 10.

Zertifizierung

Eine vertrauenswürdige Zertifizierungsinstanz = Certificate Authority = CA bestätigt den öffentlichen Schlüssel, der vom Anbieter aus seinem privaten Schlüssel hergestellt wurde. Hierzu kombiniert die CA den öffentlichen Schlüssel des antragstellenden Servers mit weiteren den Server identifizierenden Angaben und erzeugt daraus eine digitale Signatur. Diese Signatur wird von der CA an den antragstellenden Server geschickt. Das ist das digitale Zertifikat. Im Prinzip handelt es sich beim Zertifikat nur um eine relativ kleine Datei mit für den Laien unverständlichen Zeichen.

Der Antragsteller (= Internet-Auftritt) schickt dann diese CA-Signatur mit seinem öffentlichen Schlüssel beim Aufbau einer gesicherten Verbindung an den Nutzer (Client, Browser). Ein digitales Zertifikat soll dadurch einen öffentlichen Schlüssel eindeutig einem Server (= Anbieter) zuordnen. Dafür betreibt die Zertifizierungsstelle auch Datenbanken mit Nummern und Laufzeit etc. der vergebenen Schlüssel.

Zertifizierungsstellen können allerdings nicht nur Zertifikate für Internet-Auftritte (Server) und Nutzer ausstellen, sondern auch andere Zertifizierungsstellen autorisieren. Dadurch entsteht eine Kette von Zertifizierungsstellen = Zertifizierungskette = Certificate Chain. Vertraut ein Client (Browser, Nutzer) der obersten Zertifizierungsstelle, vertraut er auch allen Zertifikaten, die von den einzelnen Zertifizierungsstellen der Kette ausgestellt worden sind. Die oberste Zertifizierungsstelle einer Kette wird auch Wurzelzertifizierungsstelle = Root CA genannt. Root-Zertifikate vieler Anbieter sind bereits in Betriebssystemen und den Browsern integriert.

Es wäre jedoch unmöglich, alle anderen (untergeordneten) Zertifizierungsstellen oder sogar deren Zertifikate beim Nutzer zu speichern. Deshalb werden von den Zertifizierungsstellen sogenannte OCSP-Responder betrieben. Dort kann der Browser des Nutzers nachfragen, ob das Zertifikat des Servers (Internet-Auftrittes) korrekt ist.

Wenn Sie kurz innehalten und diese Punkte durchdenken, dann fällt Ihnen sicher selbst auf, wo man überall betrügerisch ansetzen kann.

Systembedingte Risiken innerhalb von HTTPS

Systembedingt finden sich zwei Hauptrisiken: Erstens die Verschlüsselung und zweitens das Zertifikatsystem.

Seit spätestens 2013 ist bekannt, dass Sicherheitsdienste an beiden Stellen ansetzen, um jede HTTPS-Verbindung in Echtzeit (während Sie als Nutzer diese verwenden) zu entschlüsseln.

Angeblich sollen die mathematischen Verfahren zur Verschlüsselung unknackbar sein. Manche Mathematiker hegen jedoch grundsätzliche logische Bedenken, dass man aus dem öffentlichen Schlüssel den privaten nicht doch errechnen kann. Denn der öffentliche und der private Schlüssel sind mathematisch verknüpft. Damit wäre das gesamte Sicherheitskonzept sinnlos, da der öffentliche Schlüssel qua Definition jedem frei zugänglich sein muss. - Der Haken bei der Analyse dieser Frage liegt jedoch darin, dass die schlausten Mathematiker direkt oder indirekt für die Sicherheitsdienste arbeiten. D.h. sie werden definitiv keine Warnmeldungen an die Presse herausgeben.

Und selbst wenn die Verfahren zur Verschlüsselung (mathematisch theoretisch) sicher wären, so ließ sich in der Vergangenheit mehrfach nachweisen, dass die Implementierung der Kryptologie in Software / Hardware fehlerhaft war. Auch hier liegt der Haken in dem Umstand, dass die klügsten Programmierer, welche so etwas überhaupt verstehen, direkt oder indirekt für die Sicherheitsdienste arbeiten.
Dass es sich bei den Stellen, welche die Software für die Internet-Module herstellen, auch um freie, öffentliche (Open Source) - also angeblich sich selbst kontrollierende - Organisationen / Projekte handelt, darf nicht verwundern. Das Thema Verschlüsselung gehört zum komplexesten überhaupt. Da laufen nicht hunderttausende arbeitsloser Fachleute herum. Und die Wenigsten sind dann auch in der Lage, (als angebliche Studenten) dafür jedes Jahr kostenlos monatelang zu programmieren. Was denken Sie, wer wohl dafür das Fach-Personal, das Geld und die Zeit hat, um solche systemrelevanten kostenlosen Open-Source-Programme / Bibliotheken zu programmieren? Dabei handelt es sich nicht um eine verschwörungstheoretische Fiktion. Das war jahrelang bei systemrelevanten Modulen für HTTPS der Fall, bis es z.B. 2011 publiziert wurde. Mit anderen Worten: Über vermutlich weit über 10 Jahre war das Software-System rund um HTTPS unterwandert und jede Verbindung absolut unsicher und in Echtzeit in Klarschrift abhörbar. Manche derartige Lücken in Software-Modulen, die man für HTTPS verwendet, waren jahrelang in Benutzung. Und die Folgen waren noch länger zu spüren, da manche Betreiber (wie das deutsche Finanzamt mit Elster-Software) den eigenen privaten Schlüssel trotz Kompromittierung noch länger verwendeten, weil er eben noch nicht offiziell abgelaufen war.

Wer Zugriff auf Zertifikate, oder Zertifikatsstellen besitzt (was schätzen Sie, wer das wohl sein könnte?), kann sowieso alles Vortäuschen, indem er seinem Server ein identisches Zertifikat einbaut. P.S.: Es existieren auch staatliche Zertifizierungsstellen, die sowieso per Gesetz gezwungen sind, mit den Sicherheitsbehörden zusammenzuarbeiten.

Die Zertifikatsstellen, Zertifizierungsstelle, Zertifizierungsdiensteanbieter (ZDA) ist eine dritte Partei, die als Referenz bürgt. Sie werden selbst im Kaskadenverfahren autorisiert. Jeder Teilnehmer (Ausgabestelle) bestätigt somit seine Qualität in einer Kette (das ist mit der immer wieder genannten Chain gemeint). D.h. es handelt sich um eine Vertrauenskette, der auch Sie als Server-Betreiber und als Browser-Nutzer blind vertrauen (müssen).

In den letzten Jahren wurden allerdings sogar Angriffe auf die Ausgeber von Sicherheitszertifikaten bekannt, unter anderem waren Skype, Mozilla und Google betroffen (alles angesehene IT-Firmen mit tausenden von hochqualifizierten Mitarbeitern). Für viele Diebstähle von Zertifikaten finden sich zwar Sperrlisten. Aber es gibt keine Garantie, dass sie umfassend sind oder auch wirklich von allen Browsern verwendet und dann auch noch korrekt gesperrt werden. Im Übrigen muss man dies teilweise in sehr tief versteckten Menüs im Browser selbst konfigurieren (manchmal ist dann sogar ein Neustart erforderlich). Auch daran dürften die meisten Nutzer scheitern.

Die bisher bekannt gewordene Schlamperei bei CAs - den Vergabestellen der Zertifikate - wird von Sicherheitsexperten nur noch mit Kopfschütteln quittiert. Da man davon ausgehen muss, dass die bekannt gewordenen Fälle nur die Spitze des Eisberges darstellen, bleibt man fassungslos.

Dank Fehler bei der Implementierung der Software gelang es Forschern sogar, ein Root-Zertifikat herzustellen, mit dem man dann beliebige weitere Zertifikate hätte erstellen können.

Als Beruhigung wird jedoch immer wieder sofort bei all den erwiesenen gravierenden Problemen hinzugefügt, dass andere Menschen so etwas angeblich nie nachmachen könnten (weil die Anderen angeblich alle dümmer, ärmer, fauler und desinteressierter seien als die publizierenden Autoren selbst). - Erstaunlich wie selbstgefällig, überheblich und arrogant manche Menschen sind. Fakt bleibt, dass derartige Angriffe nie nachweisbar sein werden, da alle Ergebnisse (Zertifikate) absolut korrekt sind und es auch sonst keinerlei Spuren gibt. Kurzum: Genuss ohne Reue.

Die oft verwendeten 128-Bit-Schlüssel für HTTPS sind leider schon lange nicht mehr sicher. Schauen Sie hierzu einfach einmal die Zertifikate der HTTPS-Seiten genauer an. Das können Sie in jedem Browser auf einer derartigen HTTPS-Seite.

Viele Zertifikate verwenden noch immer das veraltete und unsichere SHA-1. SHA steht für Secure Hash Algorithm.

Am Rande bemerkt ist es die US-Behörde NIST (National Institute of Standards and Technology), die sich um die Hash-Algorithmen kümmert. Wer vertraut seit dem NSA-Skandal um die weltweiten Abhörung des Internets noch den US-Behörden?

Alle Algorithmen im Sicherheits-Bereich basieren auf mathematischen Problemen, die nur schwer gelöst werden können. Aber d.h. eben auch, dass sie nicht unlösbar sind. Und exakt das wird immer wieder bewiesen. D.h. die Standards müssen alle paar Jahre erhöht werden, da sie de facto nicht absolut sicher sind.

Eigentlich sollte SHA-2 seit vielen Jahren der Standard sein, ist es jedoch nicht weltweit. Und selbst SHA-2 besitzt so viele Weichmacher und Schlupflöcher (von SHA-224, -256, -384 bis -512), dass sich jeder Anwender wieder das Unsicherste und Bequemste aussuchen kann. Zudem wird bei Übergängen von einem SHA-Protokoll zum Nachfolge der Aufwand für die Betreiber hoch, da man dann evtl. beide Zertifikate während einer längeren Überganszeit anbieten muss, bis alle weltweit verfügbare Software darauf umgestellt sind. Sonst wird evtl. ein erheblicher Anteil an Nutzern ausgesperrt.

Ein weiteres systemimmanentes Risiko tritt bei Root-CAs auf, die gleichzeitig wichtige DNS betreiben (DNS sind quasi die Telefonbücher, welche jedem Internet-Namen eine Internet-Nummer zuweisen). So kann so eine Root Certificate Authority jederzeit beliebige Kopien von Zertifikaten oder neue erstellen und dann als Domain Name Server-Einheit die weltweiten Internet-Adressen einfach umleiten. D.h. ein Nutzer gibt somit die Adresse www.meine-private-bank.de ein und wird so auf falsche / nachgebaute Seite von www.meine-private-bank.de umgeleitet, die dann auch noch ein korrektes Zertifikat besitzt.
P.S. Google unterliegt wie alle anderen US-Firmen u.a. dem Patriot-Act zum Schutz vor Terrorismus etc. und ist gezwungen, mit den dortigen staatlichen Behörden zusammenzuarbeiten. Und selbst Verbrecher benötigen nur jeweils eine korrupte Person an den beiden Stellen, um so etwas durchzuführen. Wobei viele CAs (zertifizierende Stellen) und sehr viele Domain-Name-Server existieren. - Um es nochmals klar zu sagen: So lassen sich selbst die als besonders sicher geltenden EV-Zertifikate (Extended Validation = erweiterte Überprüfung) fälschen.

Ein generell unsicheres System, wie das Internet, wird nicht dadurch plötzlich sicher, nur weil man oben drauf ein vermeintlich sicheres Protokoll = eine Sicherheitsschicht wie SSL / HTTPS stellt. Genauso wenig wird aus einem Trabi durch den Einbau eines Lenkradairbags ein sicheres Auto.

Vorteile des HTTPS

Falls alle Beteiligten alles korrekt abgewickelt haben und in allen Komponenten alles optimal installiert und konfiguriert wurde, dann bietet HTTPS folgende Vorteile: HTTPS verschlüsselt bereits die Anfrage des Nutzers an den Anbieter. D.h. Dritte können von außen zwar noch immer den Server (= die IP-Adresse) erkennen und wie oft er kontaktiert wurde, jedoch nicht mehr, welche genauen Seiten aufgerufen wurden. Der HTTPS-Schutz erstreckt sich auch auf vom Anbieter verschickte Cookies. Zudem werden die Inhalte auf dem Weg vom Sender zum Empfänger vor Veränderungen geschützt.

Seit 2017 durchgeführte Tests belegen zudem, dass die meisten Suchmaschinen inzwischen HTTPS positiv bewerten. Google hatte dies bereits 2014 angekündigt. D.h. optimal programmierte und sicher konfigurierte Internet-Auftritte werden etwas höher bewertet als optimal programmierte Auftritte ohne das S im Übertragungsprotokoll.

Aber Fehler werden ebenfalls bewertet. Unsicher programmierte Auftritte, welche HTTPS nur vortäuschen und etwa über miserable Programmierung (Mixed Content oder andere Sicherheitslücken) das Sicherheitsprotokoll HTTPS gefährden, werden bestraft und tiefer gewertet als reine HTTP-Auftritte.

Auch wenn diese Ergebnisse immer etwas schwanken und sich in kleinem Rahmen halten, so schält sich - unter optimalen Bedingungen - ein leichter Suchmaschinen-Vorteil für HTTPS heraus.

Da die meisten Menschen jetzt natürlich wieder einmal die anderen obigen Details ausblenden, wird der Trend hin zu HTTPS alleine aus diesem Grunde anhalten und durch die Suchmaschinen sogar verstärkt. Aber die Qualität der Inhalte ist noch immer viel wichtiger für die Platzierung einer Seite in allen Suchmaschinen als die Verschlüsselung.

Der Verbindungsaufbau mit HTTPS über SSL

So funktioniert (stark vereinfacht) der HTTPS-Datenaustausch zwischen Browser und Server:

Ein Nutzer versucht, mit seinem Browser eine Verbindung zu einem mit HTTPS gesicherten Internet-Auftritt herzustellen. Für jede HTTP-Verbindung benötigt man bei HTTP/1.1 jedoch noch eine separate TCP-Verbindung, die erst ausgehandelt werden muss. Dazu sind in der Startphase bereits mindesten zwei Kontakte erforderlich. Diese Roundtrip-Time (RTT) kann man mit Ping messen.

Dann fordert der Browser für SSL / TLS die Identität des Servers an. Der Server sendet daraufhin eine Kopie seines Zertifikats an den Browser.

Der Browser überprüft, ob das Zertifikat laut seinen eigenen (intern gespeicherten) Regeln korrekt ist. Um die Gültigkeit des Zertifikats zu überprüfen, nimmt der Browser jedoch meist Kontakt mit dem Verzeichnisdienst der angegebenen Zertifizierungsstelle auf, die eine Liste der ausgegebenen, gültigen digitalen Zertifikate sowie eine Sperrliste der verfallenen, ungültigen Zertifikate vorhält.

Bei kleinsten Fehlern muss alles neu erfolgen. D.h. nicht selten kommt es zu mehreren Zyklen der Kontaktaufnahme.

Falls alles korrekt ist, sendet die Zertifizierungsstelle eine Nachricht an den Browser zurück. Dann erzeugt der Browser (Client) einen eigenen symmetrischen Schlüssel, verschlüsselt ihn mit dem öffentlichen Schlüssel des Servers (Anbieters, besuchten Internet-Auftritts) und schickt diesen an den Server. Daraufhin entschlüsselt der Server mit seinem privaten Schlüssel den ihm zugesandten neuen symmetrischen Schlüssel des Browsers (Client, Nutzers) und verwendet ihn für seine Verschlüsselung aller weiteren Kommunikation.

Erst danach beginnen Browser und Server damit, symmetrisch verschlüsselte Daten auszutauschen. Denn nur mit der symmetrischen Verschlüsselung lassen sich halbwegs erträgliche Lasten und Zeitverzögerungen erzielen.

Zeitverzögerung und Lastprobleme = Generelle Nachteile für den Betreiber und Anwender

Das alles kostet Zeit, in welcher der Nutzer wartet. Je schlechter seine Internet-Anbindung ist (z.B. Smartphone oder sonstige langsamen Funknetze) desto länger dauert es. Dies alles geht jedoch von optimal konfigurierten Servern beim Anbieter und optimal eingestellten modernsten Betriebssystemen und Browsern beim Nutzer aus. Ansonsten erhöht sich der Zeitaufwand nochmals spürbar. Ferner befinden sich viele der versprochenen Last-/Zeitverkürzungstechniken noch immer in der Einführungsphase oder sind noch nicht in allen Server-Produkten verfügbar.

Es wird u.a. ein zusätzliches eigenes Programm auf dem Server benötigt, das eine höhere Server-Last erzeugt. Dies produziert zwangsläufig eine längere Wartezeit, bis die Antwort vom Server an den Anfrager gegeben wird, da jede Anfrage entschlüsselt und die Antwort erst wieder verschlüsselt werden muss. Früher fielen die beiden Punkte Entschlüsselung der Anfrage und Verschlüsselung der Antwort extrem ins Gewicht und fielen jedem Nutzer sofort auf. Dank leistungsfähigerer Server relativiert sich das Problem langsam.

Hinzu kam oft ein längerer Download der verschlüsselten Inhalte, da die meisten Server keine SSL/TLS-Kompression durchführen. Dank schnellerer Netzwerkanschlüsse relativiert sich dieses Problem langsam.

Ergänzt wurde dies durch eine längere Dauer bis zur Anzeige der kompletten Datei auf dem Kunden-Endgerät, da erst alles entschlüsselt werden muss. Dank schnellerer PCs bei den Anwendern relativiert sich dieses Problem langsam.

Die Nachteile relativieren sich langsam. Aber sie entfallen nicht - nie! Ganz im Gegenteil nimmt der Aufwand mit jeder noch besseren Verschlüsselungsmethode deutlich zu.
Die immer wieder angegebenen Zitate von Google von nur 1% höherer Last bei E-Mail-Testprogrammen sind für die meisten Firmen unzutreffend. Da seit Jahren für HTTPS zusätzliche sündhaft teure Hardware angeboten wird, welche nur die Verschlüsselung beschleunigt, und diese Geräte sich einer bis heute regen Nachfrage erfreuen, sollte man es auf jeden Fall selbst nachrechnen und in der Praxis nachprüfen.
Die überall auffindbaren und technisch gesehen korrekten Behauptungen, dass man alle Lastprobleme lösen kann, kommen erstaunlicher Weise sehr oft von solchen Persönlichkeiten, welche für vierstellige Tagessätze Ihnen gerne diese Arbeiten erledigen. Selbstverständlich sind alle Probleme lösbar. Aber unterschätzen Sie hierzu nicht den finanziellen und zeitlichen Aufwand. Im Zweifel benötigen Sie einen neuen Provider, einen neuen Server und einen neuen Internet-Anschluss und neben neuer Software sowieso neue Hardware. Dass Sie dann auch die gesamte Software neu aufsetzen müssen, dürfte klar sein.
Grundsätzlich gilt, dass HTTPS noch relativ geringe zusätzliche Last bei kleinen Datenmengen erzeugt (typische E-Mails, Kurznachrichten, kurze Seitentexte etc.), dass das Verfahren jedoch wenig geeignet ist für die Verschlüsselung großer Datenmengen. So kann die Zeit zum Ver- und Entschlüsseln großer Bilddateien deutlich ansteigen. Dies ist relevant, da seit einigen Jahren Internet-Aufritte zunehmend mit teilweise riesigen Fotos (nicht selten mit mehreren tausend Pixeln in der Länge und der Breite sowie 24 oder mehr Bit Farbtiefe) ausgestattet werden.
Exakt aus diesen Gründen gab es früher auch die Möglichkeit, nur die datenschutzrelevanten Dinge wie Bestelldaten im Shop und Kontaktformulare zu schützen, jedoch nicht die reinen Inhaltsseiten. Heute machen es sich jedoch die meisten Programmierer einfach und verschlüsseln alles. Das Lastproblem bleibt beim Anbieter und die Zeitverzögerung hat der Kunde / Nutzer zu tragen.

Technische Detailprobleme bei HTTPS

Um es auch technischen Laien verständlich zu machen, das folgende Beispiel: Wenn Sie ein großes Schloss mit vielen Zimmern besitzen und dieses schützen wollen, so können Sie 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 Sie das Fenster offen lassen, 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) wurde 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 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 dafür aus. 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.
Deshalb gingen 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 Sie als 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: Je nach Browser-Hersteller und Versionsnummer werden durchgestrichene Schlösser, offene Schlösser, gelbe Warndreiecke, graue Symbole, das Symbol 'i' (teilweise in einem Kreis) für weitere Information vor der Adresse etc. angezeigt. Bis heute herrscht hier keine Einheitlichkeit der Kennzeichnung vor.

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, was ein Widerspruch in sich selbst darstellt. 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.)
Ferner finden sich Internet-Auftritte, die zwar HTTPS besitzen, aber gleichzeitig Fremdprogramme mit Cookies verwenden (z.B. Googles Logfile-Analyseprogramme), was ebenfalls ein Widerspruch in sich selbst bildet. 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 zusätzliche 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. Spätestens dort endet jede Verschlüsselung.

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. 2018 wurde also bekannt, 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. Auch 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 Beruhigungsplacebos. - 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 allerdings noch weitere Tücken hinzu: So 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.

Selbsttäuschung - Übersehene Risiken

Betreiber und Kunden wiegen sich in völlig unbegründeter Sicherheit bezüglich HTTPS: So kann HTTPS keine der oft übersehenen Risiken beheben. Sicherheitsexperten sind auch immer wieder erstaunt darüber, dass Menschen - vor allem die leichtgläubigen Deutschen - etwas für sicher halten, nur weil es kompliziert ist und sie es nicht verstehen. Ganz im Gegenteil ist Komplexität ein Risiko, das fast zwangsläufig zu Fehlern führt.

Das Verhalten mancher Browser-Hersteller, alles, das irgendwie mit HTTPS in Verbindung steht, pauschal als sicher zu deklarieren, ist nicht nur ungerechtfertigt, sondern geradezu skandalös irreführend. Man darf gespannt sein, bis es hierzu die ersten Prozesse mit Schadenersatzforderungen gibt.

Die grob fahrlässig im Browser verwendete Farbe Grün für HTTPS sagt somit nicht in Analogie zur Ampel aus, dass man gefahrlos über die Straße gehen kann und blind allem vertrauen darf.

Kontaktformulare mit HTTPS klingen so vertrauenerweckend. Leider wird jedoch dahinter mit einem - zudem oft schlampig programmierten (= für Hacks anfälligen) - PHP-Script sowieso nur eine unverschlüsselte E-Mail daraus an den Betreiber / Händler generiert. Das ist reine Augenwischerei.

Kaum hochwertiger ist es, wenn alles in einer Datenbank abgespeichert wird, die dann jedoch eher mäßig geschützt ist. Das betrifft selbst Großkonzerne wie Sony, die regelmäßig Opfer von Angriffen mit Verlust von Millionen Kundendaten werden.

Und selbst der berechtigte Zugriff der Mitarbeiter auf die sicheren Datenbanken erfolgt oft ungeschützt über das offene Internet. D.h. die Daten werden wieder in Klarschrift vom Server an den Sachbearbeiter geliefert.

Unter Sicherheitsaspekten ganz unglücklich ist es, wenn die verschlüsselte Bestellung dann anschließend per ungeschützter E-Mail vom Händler bestätigt wird. Schauen Sie einmal bei Bestellungen auf Amazon (auch Marketplace), ebay oder anderen Shops nach. Da trifft Sie der Schlag.

Selbst die meisten Passwörter werden unverschlüsselt (also per offener E-Mail) übertragen. Hinzu kommt, dass man bei den meisten Systemen dies sogar als Fremder von außen ganz einfach steuern kann, indem man die E-Mail-Adresse in ein Formular beim Anbieter eintippt und sich das Passwort zusenden lässt. Es wird zwar an den korrekten Adressaten versandt, aber eben offen und damit leicht lesbar.

Betrachten Sie nur einmal die Telefonrechnung / Internet-Rechnung Ihres Netzanbieters. Diese wird in der Regel als ungeschütztes PDF in Klarschrift verschickt. Da steht so ziemlich alles drin, was Sie jemals in ein Kontaktformular tippen würden. - Jahre nach meiner Kritik hier, stellten tatsächlich einige Anbieter dieses offene Versenden ein und erlaubten nur noch den geschützten Download der Rechnung aus dem firmeneigenen gesicherten Kunden-Bereich heraus.

Auch wenn alles perfekt ist: Der Internet-Auftritt ist mit HTTPS geschützt, das Kontaktformular sendet nur mittels neuestem TLS an das Ziel, der E-Mail-Abruf aus dem Postfach erfolgt nur mit HTTPS / TLS, so wird dennoch alles zerstört, wenn die Firma anschließend alle Inhalte der Anfrage (Ihren Name, Adresse etc. inklusive der Details der Anfrage) in der Antwort-E-Mail an den Kunden wieder unten hinschreibt, wie es bei den meisten E-Mail-Programmen üblich ist. Denn diese Antwort-E-Mail wird öffentlich an Sie verschickt. So geschieht es mir regelmäßig bei Anfragen an fast alle Firmen und Krankenkassen, Behörden und Organisationen. D.h. alles ist dennoch für Dritte einsehbar. - Auch diese Unsitte wurde nach meiner diesbezüglichen Kritik in den 2020er Jahren langsam zumindest reduziert.

Daraus folgt, dass ein System nur so sicher ist, wie das schwächstes Glied in der gesamten Kette. Da die normale E-Mail über das Internet jedoch ungeschützt ist und bleibt, muss man hier größte Sorgfalt anwenden. Ansonsten sind alle Sicherheitsmaßnahmen davor sinnlos.

HTTPS verhindert weder einen Virenbefall des Anbieter-Servers noch eine Virenübertragung an den Nutzer. Immer wieder sind auch mit HTTPS geschützte Internet-Auftritte komplett virenverseucht. Es finden sich glaubhafte Berichte, dass manche Viren, welche über manche HTTPS-Versionen verschlüsselt übertragen werden, von manchen Antivirenprogrammen kaum resp. zu spät erkannt werden.

Im Klartext: HTTPS ist nur sinnvoll, wenn alle anderen (wirklich sämtliche) Kommunikationswege ebenfalls komplett verschlüsselt sind. Das sind sie jedoch selten. Vor allem E-Mail ist fast nie mit PGP sicher verschlüsselt. Das ist den meisten Menschen nämlich zu aufwändig.

Jeder Nutzer muss inzwischen sogar noch vorsichtiger sein und wirklich alles kontrollieren. Entweder ist die TLD (also die gemeinhin als Ländercode bekannte Endung) anders oder irgendetwas im Domainnamen. Da reicht es bereits aus, wenn auch nur 1 einziger Buchstabe anders ist oder ein Bindestrich eingefügt wurde oder fehlt. Hinzu kommt, dass seit der Erlaubnis der vielen Fremdsprachen im Internet Zeichen existieren, die unseren lateinischen Buchstaben täuschend ähnlich sehen, aber eine andere Adresse darstellen.

Festzuhalten bleibt, dass man das völlig unsichere Gesamtsystem Internet nicht einfach dadurch sicher machen kann, indem man oben drauf oder irgendwie daran ein sicheres Modul (SSL / TLS / HTTPS) befestigt.

Fazit

Es finden sich unterschiedliche Standards bei HTTPS, die heute noch alle nebeneinander her existieren, die jedoch alle einen anderen Sicherheitsstandard bieten.

Es finden sich zahlreiche zulässige Möglichkeiten, HTTPS anwenderseitig korrekt zu installieren, die jedoch alle einen anderen Sicherheitsstandard bieten.

Es finden sich fast unendlich viele Möglichkeiten, HTTPS anwenderseitig falsch zu installieren, die alle irgendwie dennoch funktionieren, aber einen sehr geringen bis keinen Sicherheitsstandard bieten und im Extremfall sogar gefährlicher sind als reines HTTP ohne S.

Als Nutzer (Browser-Bediener) und weitgehender technischer Laie stehen Ihnen kaum Möglichkeiten zur Verfügung, die meisten der obigen Abweichungen auch nur zu erkennen, geschweige denn deren Gefahren zu umgehen oder gar zu beseitigen.

Die Befürworter bezeichnen alles im Zusammenhang mit HTTPS als sicher, das bisher noch nicht veröffentlicht und von mehreren nachgeprüft als geknackt erwiesen ist. Das ist eine sehr kühne Sichtweise. Vor allem, wenn man weiß, dass die Sicherheitsdienste seit Jahrzehnten alles daran setzen, jede vorhandene Verschlüsselung zu dekodieren, und wenn man in Betracht zieht, dass alle bisherigen Verschlüsselungsverfahren binnen weniger Jahre nachweislich entschlüsselt wurden.

Letztendlich stellt das Verschlüsseln und Entschlüsseln ein Hase- und Igel-Spiel dar. Angesichts der völlig unausgewogenen Kräfteverhältnisse fragt sich allerdings, wer hier der Hase und wer der Igel ist?

Keine höhere Seriosität

Erstaunlicher Weise verwechseln viele Menschen vor allem in Deutschland das S in HTTPS mit seriös.

Selbst wenn alles an und rund um HTTPS funktioniert, ist das folgende immer wieder Aufzufindende zu beachten:

Weder bei Amazon noch auf anderen Marktplätzen und Shops sichert das S in HTTPS eine Seriosität des Händlers oder die Funktionstüchtigkeit der Ware zu.

Auch bei Gebrauchtwarenbörsen wie ebay sichert das S in HTTPS keine Seriosität des Verkäufers zu. Es kann sich weiterhin ein Hehler oder Dieb mit gestohlener Ware dahinter verbergen.

Auch wird durch das S in HTTPS keine Anonymität gewährt. Der Händler erhält weiterhin Ihre kompletten Kundendaten (zumindest Name und Anschrift) für den erforderlichen Postversand.

Auch bei Lastschriften werden selbstredend alle Kundendaten (hier insbesondere Kontonummer und IBAN) an den Händler geliefert. Zusammen mit dem Namen und der Adresse kann er bereits viel Schindluder treiben. Vom Verkauf der Daten wollen wir hier ausnahmsweise einmal absehen. Ihre Kontodaten können Sie nur bei einer eigenen Überweisung von Ihrem Konto aus schützen, da dann diese nicht an den Händler gelieferter werden. - Leider trifft auch dies nicht immer und nicht bei jedem Konto und bei jeder Bank zu.

Auch auf Facebook und Twitter sowie bei Wikipedia sichert das S keinerlei Seriosität persönlicher Meinungen der Verfasser. Das S sichert folglich auch keine Wahrheit oder auch nur Wissenschaftlichkeit zu. Dass inzwischen sogar Diskussionsforen mit HTTPS ausgerüstet sind, in denen allen Ernstes über die Erde als Scheibe ausführlich von den Teilnehmern geschrieben wird, belegt die Diskrepanz.

Selbst von organisierten Verbrechern betriebene betrügerische Online-Spiel-Casinos sind mit HTTPS-Verschlüsselung ausgestattet. Alle ernsthaften Betrüger verwenden heute im Internet bereits HTTPS. Das ist somit kein Gütesiegel mehr und schon gar kein Schutz vor Betrug.

Genauso wenig eignet sich HTTPS als Kindersicherung, da sich Anbieter der Pornoindustrie schon lange mit diesem Zertifikat schmücken.

Die oft in Browsern angegebene Behauptung, dass ein Internet-Auftritt mit HTTPS sicher sei, ist unzutreffend. Heute sind HTTPS-Auftritte überall für wenige Geld zu erhalten - auch von Verbrechern. Das S oder das im Browser vor der Adresse abgebildete Schloss-Symbol sagen somit nicht das Geringste über die Seriosität des Betreibers oder die Inhalte aus. Seit Ende 2015 kann sogar jede Privatperson kostenlos solche Zertifikate erhalten.

Nachweislich verwenden Betrüger inzwischen HTTPS. Manche Browser-Hersteller schreiben deshalb weiter unten, wo es kaum jemand liest: Selbst wenn dieses Symbol angezeigt wird, sollten Sie beim Teilen von privaten Informationen immer vorsichtig sein. Sehen Sie sich die Adressleiste an, um sicherzugehen, dass Sie sich auf der gewünschten Website befinden. (Google Quelle)

Den größten Trugschluss, den ich in Befragungen herausfand, ist, dass viele Nutzer Zertifikate mit einem staatlichen Führerschein verwechseln, der etwas über die nachgeprüfte Qualifikation des Besitzers aussagt. Zertifikate sind jedoch eher mit einer Kino-Karte zu vergleichen. Der Besitzer hat sie vermutlich gekauft und erhält somit das Recht, sie zu einer bestimmten Zeit für etwas Banales zu benutzen. Wie der Kartenkontrolleur auch nur die Korrektheit der Kinokarte bestätigt, so bestätigt ein Browser bei einem irgendwie erworbenen Zertifikat in der einfachsten Form nur die Richtigkeit des Zertifikats für einen bestimmten Zeitraum. Nicht mehr.

Die immer wieder zu lesende Behauptung, dass ein Zertifikat die Person identifiziert, welche den Internet-Auftritt betreibt, ist falsch. Es wird nur das Zertifikat bestätigt. Welche Firma oder gar welche Personen sich dahinter verbergen, bleibt unklar, da jede Firma, Institution etc. selbstredend als juristische Person auftreten darf. Und eine CXFWT Ltd., die in Delaware oder irgendwo in einer anderen Rechts- resp. Steueroase beheimatet ist, muss keineswegs Personenangaben machen. Das machen noch nicht einmal seriöse deutsche Großfirmen. So etwas unterliegt u.a. auch dem Datenschutz. Und selbst wenn dort, wie bei den Providern, Personennamen hinterlegt sind, sind sie nicht selten veraltet, Strohmänner, Rechtsanwaltskanzleien oder schlichtweg falsch. - Prüfen Sie einfach einmal verschiedene Zertifikate in Ihrem Browser nach. In den meisten steht unter Antragsteller / CN nur die Domain z.B. www.haumichblau.info und kein Betreibername. Das ist normal. Denn bei den meisten Zertifikaten handelt es sich nur um Domain Validated (DV) certificates. - Nach erheblichem Klicken und Suchen im Zertifikat wissen Sie also, dass die von Ihnen angeklickte / aufgerufene Domain www.haumichblau.info ein Zertifikat für www.haumichblau.info besitzt. Und exakt nur das Wenige bestätigt ein Zertifikat über eine Domain.

Meine Untersuchungen an einer Universität belegten mir, dass selbst junge Menschen kaum wissen, dass es sich bei Zertifikaten um eine mehrstufige Klassifizierung handelt. Allerdings nutzen die meisten Anbieter dies nicht aus. D.h. in der Regel wird nur der Auftritt (die Internet-Adresse = Domain) also die Technik an sich, nicht jedoch der Anbieter / Inhalt zertifiziert. Dies ist ein extremer Unterschied: Meist wird nur die Sicherheit der Verbindung oder nur das Sicherheits-Zertifikat selbst bestätigt. Ob dahinter auch tatsächlich die angegebene Person steckt, bleibt meist ungeprüft. Und selbst Letzteres ist keine Garantie: Genauso wie es im Ausland durch Strohmänner geführte Firmen gibt, so lassen sich von solchen anonymen Firmen HTTPS-Zertifikate erwerben.

Sogar die höchste Zertifikatsstufe Extended Validation, bei der sich die Browser-Zeile vorne grün färbt, gibt keine wirkliche Garantie in Hinblick auf die Vertrauenswürdigkeit des Internet-Auftrittes. Selbst bei einem EV-Zertifikat (= Extended-Validation-Certificate) wird nur überprüft, ob es die Firma / Person gibt, nicht was sie macht oder wie vertrauenswürdig sie ist. Sogar die hohen Kosten dafür schrecken Verbrecher nicht vor diesen hoch bewerteten EVs ab.

Im Rahmen meiner Arbeiten für Firmen, um diesen HTTPS einzurichten und aufzubauen, fiel mir auf, dass vor allem jene dubiosen deutschsprachigen Firmen, bei denen u.a. auch ich bei Einkäufen Geld verloren hatte, inzwischen - und oft sogar sehr früh - HTTPS verwendeten.

Fazit: HTTPS ist definitiv kein Gütesiegel. - Letztendlich nützt den Nutzern das S in HTTPS wenig. Die Seriosität aller Inhalte muss man weiterhin selbst überprüfen. Mit anderen Worten das S darf nicht dazu führen, dass man irgendjemandem vertraut. Schalten Sie weiterhin Ihren Verstand ein.

Somit bleibt auch alles rund um HTTPS eine Vertrauenssache / Glaubensfrage - so wie der Rest des Internets auch.

Folgen für die Nutzer - Praxis-Tipps für Browser-Benutzer / Endanwender

Hier erfahren Sie, wie Sie mit HTTPS die höchste Sicherheitsstufe erhalten:

Löschen Sie alle Ihre alten Lesezeichen / Bookmarks und setzen Sie sie mit https neu, oder ändern Sie die alten Adressen selbst manuell auf HTTPS ab. So wird bereits die erste Verbindung verschlüsselt hergestellt, und einfache Man-in-the-middle-Angriffe von Personen dazwischen werden erschwert.

Misstrauen Sie allen Sonderkennzeichnungen: Entweder der Internet-Auftritt zeigt ein grünes (bei Microsoft: graues) Schloss oder einen grünen Namenszug der Firma vor der Internet-Adresse, oder der Auftritt ist nicht sicher. Es findet sich auch mit HTTPS in der Adresszeile kein teilweise sicher.

Wenn Sie bereits als Nutzer (= Laie) erkennen, dass ein Zertifikat nicht wirklich korrekt installiert ist, z.B. indem gelbe oder rote Dreiecke oder rote Warnhinwiese stehen (z.B. Mixed Content), oder das Zertifikat abgelaufen ist, dann seien Sie auf der Hut: Entweder sind die Betreiber technisch nicht in der Lage oder aus Bequemlichkeit nicht willig, die Sicherheit zu gewährleisten, oder es handelt sich um ziemlich dreiste Betrüger, oder der angeblich geschützte Internet-Auftritt wurde Opfer einer Attacke und befindet sich evtl. unter Kontrolle der Angreifer.

Bei ehrlichen Profis sowie bei professionellen Betrügern funktioniert HTTPS perfekt. Seriöse Anbieter kümmern sich aus Imagegründen mit eigenen Fachkräften um die korrekte Umsetzung, und organisierte Betrüger bezahlen ebenso Spezialisten, weil sie nicht an derart läppischen Fehlern scheitern wollen.

Der Unterschied eines HTTPS-Auftrittes zu einem http ohne s ist für den Nutzer gleich Null. Denn in Wirklichkeit muss er selbst jedes Zertifikat im Detail überprüfen. Die meisten Nutzer wissen noch nicht einmal, wie dies geht. (Erklärende Links dazu finden Sie unten.)

Und selbst ein korrekt installiertes und dazu noch funktionierendes SSL-Zertifikat ist auch noch keine Garantie dafür, dass Sie gegen alle bereits heute bekannten Bedrohungen geschützt sind.

Letztendlich ist die Überprüfung aller Details so zeitaufwändig, dass sie meines Erachtens von niemandem ständig durchgeführt wird. Um alle Details im Browser-Zertifikat zu überprüfen, sind über ein Dutzend Klicks und mindestens 1 Minute zum korrekten Lesen erforderlich. Wobei die meisten Nutzer die meisten Inhalte der angezeigten Zertifikate vermutlich kaum verstehen und somit nicht überprüfen können. Das gesamte System HTTPS widerspricht den Grundsatz der schnellen Verfügbarkeit der Daten im Internet und ist deshalb schlichtweg nicht alltagstauglich.

Die Nutzung des Internets bleibt eine Frage des Vertrauens.

D.h. auch ganz klar, dass Internet-Auftritte ohne HTTPS keineswegs unsicherer oder unseriöser sind, als solche mit dem S.

Relative Sicherheit

Absolute Sicherheit existiert nicht - vor allem nicht im Internet.

Man kann folglich bei allen Bemühungen nur von einer relativen Sicherheit sprechen. Das Verschlüsselungssystem A ist relativ gesehen sicherer als das Verschlüsselungssystem B. Oder: Heute ist das Verschlüsselungssystem C relativ sicher. Aber morgen kann es bereits unsicher sein. Ferner gelten alle veröffentlichten Betrachtungen zur Sicherheit nur für Normalsterbliche mit kaum vorhandenen Analyseprogrammen und beschränkter Hardware für Privatpersonen.

Fakt ist und bleibt jedoch auch für die Zukunft, dass jedes Verschlüsselungssystem entschlüsselbar ist. Entweder geschieht das Entschlüsseln durch schiere Rechenleistung (= brute force) oder durch intelligente Software - bis hin zu AI / KI. Sie dürfen davon ausgehen, dass die Sicherheitsdienste und die organisierte Kriminalität sowohl auf die schnellsten Rechnersysteme als auch die intelligenteste Software zugreifen können oder sie sogar selbst besitzen.

Sicherheit bedeutet letztendlich bei Verschlüsselungsverfahren nur, dass man den Aufwand für die Entschlüsselung hochtreibt - in der Hoffnung, dass der Aufwand sich für die Angreifer nicht lohnt.

Umstellen oder abwarten

Was soll ich als Internet-Anbieter nun tun?

Ziele der Akteure

Es hat seine Gründe, warum seit Jahren weltweit Milliarden von Euro investiert werden, um alle Anbieter und Anwender zu HTTPS zu zwingen:

Wer an die Philanthropie der Akteure glaubt, und daran, dass Sie alles nur aus selbstloser Nächstenliebe zum ach so schützenswerten armen Kunden tun, darf dies gern weiterhin tun. Aber alle besitzen knallharte irdische Motive und versprechen sich davon massive Vorteile für sich selbst.

Der derzeit größte Akteur Google sprang erst ca. 2014 auf den seit weit über einem Jahrzehnt lahmenden Gaul Verschlüsselung. Google macht dies wie immer ganz geschickt. Im Geheimen werden alle eigenen Systeme auf einen völlig frei definierten hauseigenen Standard umgerüstet, danach dies publiziert und sofort allen Nutzern mitgeteilt, dass ab nun dieser eigene Standard zu erfüllen ist, damit man bei Google in den Suchergebnissen noch erfolgreich oben gelistet wird. So schädigt man alle Mitbewerber, da diese (wie der Hase) immer hinterherrennen müssen, und Google immer voraus ist. - Früher wurde so etwas als Monopolmissbrauch scharf geahndet.

Die Finanzwirtschaft (Banken, Versicherungen, Kreditkartenfirmen etc.) setzen auf diesen Standard, da sie damit eine Beweislastumkehr durchsetzen können. Sobald das Internet sicher ist, wird der betrogene Kunde beweisen müssen, dass nicht er selbst seine Daten kompromittiert hat. Das wird ihm als technischer Laie kaum gelingen. Und die technisch oft wenig bewanderten Richter werden sich definitiv die Sache einfach machen und für den vermeintlich sicheren Standard votieren.

Die Zeitungen und Zeitschriften, Nachrichtensender, Newsportale etc. befürworten HTTPS, damit sie endlich wieder Ihre alte Meinungs- und Deutungshoheit über alle Ereignisse zurückgewinnen, gegen die wesentlich schnelleren und kritischeren Privatauftritte. Denn in ihren Augen steht s für seriös. Dies wird im Übrigen von den Suchmaschinenbetreibern begünstigt, da sie inzwischen deren Nachrichten höher bewerten als die der Privatanbieter ohne HTTPS. - Die sonst oft verfeindeten Akteure arbeiten somit in diesem Punkt Hand in Hand.

Die Regierungen, Sicherheitsdienste und supranationalen Organisationen sind dafür, da sie so die Bürger leichter kontrollieren können. Ein seit langer Zeit geknackter Code, den die meisten für sicher halten, verleitet die unbedarften Nutzer dazu, im falschen Glauben unverhohlen ihre Sicht der Dinge zu schreiben. Vor allem mit den bald folgenden privaten Zertifikaten für alle Nutzer steht dann der Totalkontrolle Tür und Tor offen.

Bei den privaten Zertifikaten im Browser jedes Nutzers kommt auch die gesamte Wirtschaft mit ins Boot, da sie nun endlich die ständige und völlige Kontrolle über den Kunden erhält. Während man Cookies löschen, Browser-Kennungen verändern, Betriebssysteme vortäuschen und die IP wechseln oder verschleiern kann, sogar die Maschinenkennung des Computers kann man meist noch verändern, kann man ein mit seinem Personalausweis verifiziertes persönliches Zertifikat im Browser, das als zwingende Eintrittskarte in das zukünftige Internet erforderlich wird, nicht ändern. So freuen sich alle am endlich gläsernen Kunden, der immer und überall und das über viele Jahre hinweg (die Laufzeit des privaten Zertifikates) mit jedem Detail, jedem Mausklick und jedem eingegebenen Buchstaben ausgewertet werden kann.

Vorsätzliche Falschaussagen

Viele Akteure schrecken auch vor gezielten Falschinformationen nicht zurück.

Der von HTTPS-Befürwortern gerne angeführte Schutz vor Zensur ist nachweislich falsch.
In der Theorie kann HTTPS die Sicherung der Integrität gewährleisten. D.h., dass die vom Nutzer empfangenen Daten mit den vom Server ausgesendeten übereinstimmen.
HTTPS schützt jedoch - auch im optimalsten Fall - nicht vor Zensur. Staatliche Stellen und auch die Suchmaschinenbetreiber besitzen ganz andere (rechtlich erlaubte sowie weniger erlaubte) Mittel, um unerwünschte Inhalte unzugänglich zu machen.
Im Übrigen verwechseln die meisten Menschen Zensur mit Ihrem angeblichen Recht auf Meinungsfreiheit. Selbst in demokratischen Rechtsstaaten existiert ein Zensurverbot nur gegenüber offiziell zugelassenen Presseorganen. Aber selbst bei denen reicht oft ein Anruf, damit sie Selbstzensur üben.
Im Übrigen ist die Kollisionsfreiheit der Hash-Funktionen, welche für die Identitätsprüfung innerhalb von HTTPS notwendig ist, bereits so oft widerlegt worden, dass man festhalten muss, dass sie nicht funktioniert.
Sogenannte Intrusion-Prevention-Systeme, die zahlreiche Firmen verwenden, können z.B. den Inhalt auch bei HTTPS-Verbindungen filtern. D.h. sie können die angeblich so sicheren Inhalte lesen und bei Bedarf ggf. säubern - trotz HTTPS. Jeder Nutzer darf beruhigt davon ausgehen, dass die jeweiligen nationalen Sicherheitsdienste sowie alle daran interessierten Provider und sonstige Firmen dafür gesorgt haben, dass deren Proxys für solche legalen Man-in-the-middle-Eingriffe zertifiziert sind und in den Browser-Listen als vertrauenswürdig geführt werden.
In Klartext bedeutet dies für den Empfänger, dass er leider nicht sicher sein kann, wirklich das Originaldokument vor sich zu haben.

HTTPS soll die mobile Nutzung des Internets mit Smartphones sicherer machen, weil Funknetze angeblich noch leichter abgehört werden können als Kabel. Abgesehen davon, dass Funknetze per se keineswegs unsicherer sind als Kabelnetze, stellen beide für Hacker kein Hindernis dar, da es um das sowieso generell unsichere Protokoll Internet geht. Aber das Problem liegt hier eher am Front-End = dem Nutzer. Wer in der U-, S-Bahn oder im Bus (Bank-) Geschäfte erledigt und dabei personenbezogene Daten eingibt, darf sich nicht wundern, wenn andere das rein optisch mitlesen oder mit deren Smartphone filmen.

Vor allem kommerzielle Provider, welche daran viel Geld verdienen oder sogar als Zertifizierungsstelle arbeiten, behaupten rechtlich völlig unhaltbare Dinge:
Ein SSL-Zertifikat ist zum Beispiel notwendig, wenn Sie einen Onlineshop betreiben und beim Checkout-Prozess Daten wie die Lieferadresse oder Zahlungsmittel vom Kunden abfragen. Oder wenn Sie auf Ihrer Website ein Kontaktformular für Interessenten anbieten, in das diese Namen und E-Mail-Adresse eintragen können. (Quelle: 1und1)
Wenn sich Benutzer auf Ihrer Website anmelden, persönliche Daten, wie Kreditkartennummern, online eingeben oder vertrauliche Daten, wie Krankenkassenleistungen oder Kontodaten eingeben müssen, müssen Sie die Geheimhaltung dieser Daten gewährleisten. Zudem müssen Sie dafür sorgen, dass sich Ihre Kunden die Authentizität Ihrer Website bestätigen lassen können. (Quelle 1und1) Auch diese beiden Behauptungen sind im Zusammenhang mit SSL, TLS oder HTTPS falsch.
Es finden sich keinerlei Gesetze oder Vorschriften, die SSL oder TLS oder HTTPS verlangen.

Da Letzteres dennoch immer wieder von interessierten Kreisen behauptet wird, hier einmal die angeblichen Fundstellen, auf die sich diese Mindermeinung bezieht:
Angeblich ist das Bayerische Landesamt für Datenschutzaufsicht (LDA Bayern) der Ansicht, dass Webseitenbetreiber die Übertragung sensibler Kundendaten mittels Kontaktformularen verschlüsseln müssen.
Die einen Rechtsanwälte berufen sich dabei auf ein im September 2014 vom Bayerischen Landesamt für Datenschutzaufsicht (BayLDA) anlasslos durchgeführten Test von E-Mail-Servern von Unternehmen im Freistaat auf Verschlüsselung. Rechtliche Folgen hatte er nicht. Und es ging um E-Mail-Server, nicht um Webauftritte oder Kontaktformulare etc.
Ende 2015 verschickte dasselbe Landesamt erneut Briefe an Shop-Betreiber. Danach wurde es ruhig.
Die anderen Rechtsanwälte, welche so etwas behaupten, beziehen sich dabei direkt auf das Bundesdatenschutzgesetz (BDSG 1990) § 9 Technische und organisatorische Maßnahmen: Öffentliche und nicht-öffentliche Stellen, die selbst oder im Auftrag personenbezogene Daten erheben, verarbeiten oder nutzen, haben die technischen und organisatorischen Maßnahmen zu treffen, die erforderlich sind, um die Ausführung der Vorschriften dieses Gesetzes, insbesondere die in der Anlage zu diesem Gesetz genannten Anforderungen, zu gewährleisten. Erforderlich sind Maßnahmen nur, wenn ihr Aufwand in einem angemessenen Verhältnis zu dem angestrebten Schutzzweck steht.
Vor allem wird der letzte Satz gerne weggelassen: Erforderlich sind Maßnahmen nur, wenn ihr Aufwand in einem angemessenen Verhältnis zu dem angestrebten Schutzzweck steht.
Bundesdatenschutzgesetz (BDSG - alt) Anlage (zu § 9 Satz 1). Dort fand sich bis 24.05.2018 in Absatz 4. zu gewährleisten, dass personenbezogene Daten bei der elektronischen Übertragung oder während ihres Transports oder ihrer Speicherung auf Datenträger nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können, und dass überprüft und festgestellt werden kann, an welche Stellen eine Übermittlung personenbezogener Daten durch Einrichtungen zur Datenübertragung vorgesehen ist (Weitergabekontrolle),
Kein Wort von SSL, kein Wort von Verschlüsselung des gesamten Auftrittes etc. Ganz im Gegenteil bezieht sich dieser Satz auf ganz andere Dinge der Datensicherheit.
Und selbst die geldgierigen Abmahnbranche hat sich bisher bezüglich SSL nur an bestimmte kleine Shop-Betreiber herangewagt, die man sowieso gnadenlos wegen jeder Bagatelle glaubt, abmahnen zu können. Amazon und andere waren zu groß und zu mächtig. Die hätten diese Abmahner auch in Grund und Boden geklagt.
Folglich gibt es auch keine Urteile zu SSL, nur Mindermeinungen.

Manche fanatischen Vertreter von HTTPS verbreiten gerne, dass man keine Seite im Internet mehr anklicken darf / soll, die nicht über HTTPS verfügt. Das ist völlig übertriebene Panikmache. Fast alle privaten Internet-Seiten besaßen 2018 kein HTTPS und benötigen es auch nicht.
Die meisten Firmen benötigen für ihre Informations- und Werbeseiten kein HTTPS. Es kann jedoch aus Image-Gründen hilfreich sein - sofern es wirklich sicher ist. Ansonsten erzeugt es leicht das gegenteilige Image.

Zu der ebenso klaren Gesetzeslage gemäß der europäischen DSGVO siehe DSGVO.

Folgen / die Zukunft

Dennoch handelt es sich bei HTTPS um einen weltweiten Trend, dem man sich nicht beliebig lange entziehen kann.

HTTPS ist unaufhaltsam. Spätestens mit dem bereits beschlossenen HTTP/2 wird es zwangsweise weltweit eingeführt.

Alle jetzigen Beteuerungen der Befürworter und der Kritiker werden cum grano salis eintreffen: Das Internet wird etwas sicher als heute, indem Kinder und Gelegenheits-/ Laien-Hacker es schwerer haben werden, im Internet die aktuell laufende Online-Verbindung abzuhören. Personen mit Geld, welche sich Spezialisten kaufen können, Sicherheitsdienste sowie Verbrecher werden jedoch weiterhin direkten Zugriff auf Ihre Daten besitzen. Somit werden weder die Anzahl der Internet-Verbrechen (Cyber-Crime) noch deren finanzielles Ausmaß abnehmen.

Viele privaten Anbieter von Informationen werden sich die zeit- und geldaufwändige Umstellung Ihrer alten Internet-Auftritte auf HTTPS nicht leisten können und zwangsweise schließen. Diese Marktbereinigung ist durchaus von vielen derzeitigen HTTPS-Befürworten und Akteuren gewünscht. Folglich wird die Meinungsvielfalt im Internet drastisch abnehmen.

Das Internet wird für Anbieter und Nutzer noch teurer. Denn nicht nur die Umstellung, sondern auch der Betrieb einer etwas sichereren Architektur kostet weltweit betrachtet unglaubliche Summen.

In Deutschland wird aufgrund der Hysterie der daran interessierten Medien und der daran verdienenden Meinungsmacher kombiniert mit der Leichtgläubigkeit der Nutzer sowie der typisch deutschen panischen Angst vor angeblichen Gefahren alles viel früher umgesetzt werden als in anderen Ländern.

Es wird zum Bio-Label des Internets kommen: So wie viele Deutsche Bio kaufen, weil Bio draufsteht, so werden sie auch dem S in HTTPS blind vertrauen. Gleichgültig, dass inzwischen viele Institute nachgewiesen haben, dass die Unterschiede bei Vitaminen, Nährstoffen und Belastungen in Bio-Produkten im Vergleich zu klassischen oft innerhalb der üblichen Messtoleranzen liegen, und andere Kritiker darauf hinweisen, dass in Deutschland mehr Bio-Produkte angeboten werden als in Deutschland und manchmal sogar in ganz Europa angebaut werden. Dieser Etikettenschwindel funktioniert auch im Internet: Grüne Browser-Zeile = sicher. - Deshalb wage ich sogar die Prognose, dass die Leichtgläubigen zukünftig noch leichter auf das HTTPS-Etikett Sicher blind hereinfallen werden, und die Zahl der Betrugsfälle sogar zunehmen wird.

Bis zur zwangsweisen Einführung von Verschlüsslungen im Internet wird es jedoch bereits mittelfristig zur Zweiklassengesellschaft kommen, in der die reichen und mächtigen Meinungsmacher bei den Suchmaschinen dank HTTPS bevorzugt und alle ärmeren Kritiker ohne das S benachteiligt bis hin zu faktisch mundtot gemacht werden, indem man sie ganz unten oder überhaupt nicht mehr auflistet.

Wer als Privatanbieter HTTPS einsetzt, wird dies entweder teuer bezahlen müssen oder schlichtweg technisch kaum perfekt einrichten können und dann sein blaues (Entschuldigung: natürlich grünes) Wunder erleben. Die langen Antwort- und Ladezeiten werden die Nutzerzahlen absenken. Fehlalarme (mit gelber oder roter Farbe sichtbar in der Browser-Zeile) und ständige Anzeigen der Zertifikate sowie das manuelle Bestätigen derselben durch den Nutzer vergraulen jeden. Auch so werden unliebsame Privatanbieter vertrieben.

Was jedoch bisher kaum besprochen und von Nutzern gesehen wird, sind die privaten Zertifikate der Nutzer - Clientauthentifizierung. Diese sind bereits seit Jahren in allen mir bekannten Browsern aktiv vorgesehen. Heute ist dieser Punkt nicht einmal mehr manuell im Browser einstellbar. Warum wohl? Das regeln die Firmen für Sie vertrauensvoll, wie so oft. - Für die Browser-Hersteller ist dieses schon lange vorgesehene vollständig integrierte Modul mit einem minimalen Aufwand auf verpflichtend zu setzen. Und dann benötigen alle Nutzer ein privates Zertifikat, um überhaupt noch das Internet nutzen zu dürfen. Bisher bereits laufende Anwendungen verlangen von privaten Nutzern dann eine im Zertifikat eingebrannte E-Mail-Adresse und den Klarnamen des Nutzers.

Bereits heute existierende Nachteile

Moderne JavaScript-APIs, welche u.a. den Zugriff auf Ihre Webcam und Ihr Mikrofon erlauben, lassen sich z.B. im Browser Chrome und manchen anderen seit geraumer Zeit nur noch per HTTPS ausführen. Das klingt zwar als Vorteil, ist jedoch ein Nachteil. Denn nun können Seiten, die HTTPS verwenden, automatisch auf Ihre Geräte zugreifen. Vermeintlich unsichere HTTP-Seiten jedoch nicht, da sie zurecht ausgesperrt werden. Wer allerdings generell weder gefilmt noch abgehört werden will, muss nun dies im Browser selbst aktiv und manuell unterbinden.

Auch die Geolocation-API von Google kann man seit einiger Zeit nur noch mit HTTPS ausführen. Auch hier gilt, dass man dies nun selbst manuell im Browser verbieten muss, wenn man nicht automatisch lokalisiert und verfolgt werden will.

Während viele Browser-Warnungen bezüglich der Sicherheit bei Bankseiten meist zutreffen, so ist die Anzahl der grundlosen Falschmeldungen bei privaten Hobby-Seiten noch immer ein Ärgernis für alle.

Zahlreiche öffentliche (=kostenlose) Einwahlknoten für WiFis kann man mit HTTPS nicht benutzen. Das ist für mobile Geräte wie Smartphones und Tablet oder Laptops hinderlich. Man muss umständlich zuerst eine reine HTTP-Seite ungeschützt aufrufen und kann sich dann erst in den WiFi-Knoten einwählen.

Absenken des Angst- und Panik-Niveaus

Aus jahrzehntelanger eigener Praxiserfahrung im Internet:

Wer als Nutzer oder Internet-Anbieter nicht ständig die neueste Betriebssystemsoftware und zusätzlich die dazu gehörenden neuesten Sicherheitsupdates verwendet, nicht ständig die neueste Server-/Browser-Software und zusätzlich die dazu gehörenden neuesten Server-/Browser-Plug-ins verwendet, nicht ständig die neueste Anti-Viren-Software und zusätzlich die mindestens täglich dazu gehörenden neuesten Signatur-Updates verwendet, keine Firewall verwendet, die er sowohl aktiv manuell einstellt und dann auch regelmäßig überprüft, (z.B. die kostenlose Windows 10 Firewall Control - für alle Windows Versionen.) keine Passwörter mit mindestens 10 Stellen gemäß sinnvoller Regeln (z.B. erster oder letzter Buchstabe der Wörter eines langen Satzes) verwendet, nicht mindestens einmal jährlich sämtliche Passwörter erneuert,
dafür jedoch kostenlose Software herunterlädt, oder kostenpflichtige Software illegal herunterlädt, oder Filme / Videos oder Musik illegal herunterlädt, jegliche (auch offizielle) Software ohne eindeutige Herstellerzertifikate installiert, Online-Spiel-Casinos nutzt, Online-Spiele spielt, ein Heim- oder Firmennetzwerk mit unterschiedlich konfigurierter Hard- oder Software betreibt, wichtige Seiten (Bank etc.) über (z.B. in E-Mails etc.) vorgegebene Links aufruft, statt die Adressen selbst manuell eintippt (und zwar mit der kompletten sowie korrekten Adresse = HTTPS://www.usw., sollte sich sicherheitstechnisch zuerst um jene Probleme kümmern. HTTPS ist im Vergleich zu jenen Gefahren nachrangig.

Stellen Sie sich wirklich einmal anhand Ihres täglichen Arbeitsablaufes die konkrete Frage, was HTTPS für Ihre Sicherheit erbringt?
Z.B. hätte ich als IT-Experte, der sich seit Jahrzehnten berufsbedingt wirklich wesentlich größeren Gefahren im Internet aussetzt als jeder Normalbürger, keinen einzigen der mir entstandenen Betrugsschäden (weder als Anbieter noch als Kunde), noch auch nur einen der Virenschäden durch HTTPS verhindern können. Auch alle anderen Schäden, wie Einbruch, Festplattenausfall, Überhitzen der Grafikkarte, Datenverlust, Soft- und Hardware-Probleme, hatten und haben nichts mit HTTPS zu tun. Punkt.

Handlungszwang?

Selbst Firefox schreibt: Die meisten Websites werden über HTTP aufgerufen, da meist keine sensiblen Daten ausgetauscht werden. Deshalb sind verifizierte Identitäten oder verschlüsselte Verbindungen nicht unbedingt erforderlich. - Quelle Mozilla.

Allen 2017/18 publizierten Zahlen über angeblich bereits mehr als 50% Anteil von HTTPS sollten Sie sehr kritisch gegenüberstehen. Erstens ist die Analyse aller mir bisher bekannt gewordenen Zahlen unwissenschaftlich. Zweitens stehen die herausgebenden Firmen derartiger alternativer Fakten eindeutig parteiisch auf Seiten der HTTPS-Profiteure. Drittens handelt es sich meist um eine sehr eklektizistische Auswahl. Meist handelt es sich sowieso um Transaktionen oder Transfervolumina. So ist es einfach mit HTTPS-geschützten Portalen wie Google-Suchmaschine, Amazon, Facebook und Twitter bereits auf gigantische Nutzungen täglich zu kommen. Dass es sich bei diesen großen Firmen der Welt heute jedoch eher um ein paar tausend handelt, wird verschwiegen. Genauso wird gerne übersehen, dass mehrere Milliarden Inhalte noch immer ohne das S - nur mit http - ausgestrahlt werden.

Auch die von den Zertifizierungsstellen herausgegebenen Zahlen sind nur mit größter Vorsicht zu interpretieren. Let's Encrypt ließ im Frühjahr 2017 verlauten, sie hätten bereits 100 Millionen Zertifikate ausgestellt. Das sind jedoch nicht 100 Millionen Anbieter. Mein Auftritt besitzt z.B. 10 Domains. Manche meiner Kunden besitzen dutzende oder sogar über 100 solcher Internet-Adressen. Will man alle schützen, so muss man für jede ein Zertifikat erwerben, obwohl sich dahinter nur 1 einziger Auftritt befindet. Hinzu kommen die Subdomains - Direktsprung-Adressen zu den Unterteilen des Hauptauftrittes. Deren Anzahl läuft bei vielen Anbietern schnell in die dutzende oder sogar hunderte. Teilen Sie folglich derartig verlautbarte Zahlen deutlich.

Angesichts der Anfang 2018 bekannt gewordenen großen Sicherheitslücken in praktisch allen Prozessoren seit Jahrzehnten handelt es sich bei HTTPS um eine Frage resp. eine Anforderung, welche die meisten Menschen getrost in die Kategorie schöner Wohnen eingruppieren dürfen.

Abwarten: Sie können getrost abwarten, bis die Medien und Suchmaschinen das Thema derart hochspielen, dass alle Provider gezwungen werden, HTTPS sowieso als kostenlosen Standard in jedem Internet-Paket anzubieten. Dann hat nämlich der Provider den schwarzen Peter und muss sich darum in weiten technischen Feldern kümmern. Dies würde den Aufwand für die Endkunden deutlich reduzieren. - Das kommt sowieso mit HTTP/2, weil dann eine Verschlüsselung erfolgen muss, weil die Browser-Hersteller es fordern. - Im Herbst 2024 war dies auch weitgehend so eingetreten.

Für wen und wofür lohnt sich HTTPS?

Auch auf die Gefahr hin, heftige Kritik zu von Seiten der fanatischen HTTPS-Anhänger zu erhalten, so klassifiziere ich die Wichtigkeit von oben nach unten in abnehmender Bedeutung.

Ganz oben stehen die Transaktionssysteme der Banken (Onlinebanking).Dann folgen die Warenkorb- und Transaktionssysteme der Online-Shops. Selbst 2018 waren jedoch bei weitem noch nicht alle Shops auf HTTPS umgestellt, weder weltweit noch in Deutschland. Danach folgen die Interaktionssysteme der Firmen und staatlichen Verwaltungen, sofern hierbei datenschutzrelevante Inhalte übermittelt oder im Modul selbst verwendet werden. Daran schließen sich die Kommunikationssysteme der staatlichen Verwaltungen, der Firmen und zum Schluss erst die der Privatpersonen.
Für reine Inhaltsseiten wie Texte, Bilder - sowohl bei Firmen und vor allem bei Privatpersonen - ist HTTPS nicht zwingend erforderlich.

Letztendlich bleibt mir schleierhaft, warum Privatanbieter ohne kommerzielle Angebote oder Absichten ihre Inhalte mit HTTPS verschlüsseln. Vor allem bei umfangreichen Text-Inhalten sowie Bildern ist der Verschlüsselungsaufwand (= erforderliche Rechenleistung und Zeit) hoch und der Nutzen bleibt gering. Der einzige Vorteil besteht darin, dass es Personen dazwischen schwerer gemacht wird, diese Inhalte vom Sender zum Empfänger zu verändern. Aber wer sollte das aus welchen Gründen bei privaten Seiten tun - Texte abändern und Bilder verfälschen? Die Inhalte selbst sind sowie frei verfügbar und werden durch HTTPS nicht geschützt. - Nochmals zur Klarstellung in diesem Zusammenhang: HTTPS ist auch weder ein Kopierschutz noch ersetzt es Urheberrechts-Vorkehrungen.

Was soll ich tun?

Wenn Sie sich nicht sicher sind, ob Sie auf HTTPS umsteigen sollen, dann prüfen / beherzigen Sie die folgenden Fragen und Ratschläge: Wer nutzt Ihren Internet-Auftritt? Firmen, Behörden, Kunden oder Privatpersonen? - Wozu nutzen diese Personen Ihren Auftritt? Inhalte lesen, Interaktionsmodule verwenden, kommunizieren, Waren bestellen...? - Wie oft werden diese Seiten, Inhalte, Interaktionsmodule, Kommunikationsformulare etc. verwendet? - Was wird überhaupt an Datenschutzrelevanten / sensiblen Daten aufgenommen und weiterbe- / -verarbeitet? - Kontaktformulare, über die nur ein Hallo, tolle Seite. Gruß M. ausgetauscht werden, rechtfertigen den immensen Aufwand derzeit keinesfalls.
Verwenden Sie hingegen Datenbanken, Redaktionssysteme etc.? Dann werden Sie um eine zeitaufwändige und kostspielige Aktualisierung aller dieser Komponenten für HTTPS nicht umhinkommen.

Je anspruchsvoller Ihre bezahlenden (= echten) Kunden sind und je schützenswerter / sensibler die verwendeten Daten wirklich sind und je größer / häufiger solch ein Datenverkehr ist, umso eher lohnt sich der Aufwand.

Wenn HTTPS, dann richtig

Damit man mich und meine Kritik an SSL und HTTPS korrekt versteht: Ich bin für Sicherheit. Aber hierbei handelt es ich um eine ganzheitliche Aufgabe, die auch als strategische Entscheidung von der Firmenleitung getroffen und dann von allen und in jedem Detail konsequent umzusetzen ist.

Wenn Sie sich dazu entscheiden, HTTPS für Ihren Internet-Auftritt einzuführen, dann richtig. Grundsätzlich ist es nicht sinnvoll, nur an einem Eck sicherheitstechnisch herumzuflicken. Sicherheit erhalten Sie nur als ganzheitliches Paket.

Wenn Ihr Internet-Auftritt alt ist, sollten Sie ihn nicht irgendwie umarbeiten, sondern komplett neu gestalten und auf HTML 5.# ausrichten. Dabei verwenden Sie bitte nur die neuesten Programme und Sprachversionen.

Wenn Ihr Internet-Auftritt neu ist und bereits auf HTML 5.# beruht, sollten Sie ihn dennoch komplett bis in alle Details und Programme hin untersuchen, um Sicherheitslücken auszuschließen resp. sie nun zu schließen. Rüsten Sie dabei alle Programme auf die modernste Version auf / um.

Schließen Sie jegliche Kommunikation über unsichere Kanäle aus. Das klingt leichter, als es ist. Ggf. verlieren Sie dadurch sogar Kunden, welche das nicht können. Auf jeden Fall erhöhen sich Ihre direkten wie indirekten Betriebskosten.

Rechtlicher Hinweis: Bei einem Datenleck handelt es sich um einen Verstoß gegen das Datenschutzgesetz, der geahndet werden kann. Wer eine Sicherheit vortäuscht, die nicht existiert, verschärft das Strafmaß.

Das dreistete Vorgehen fand ich bisher bei einem angeblich privaten deutschen Anbieter, der einen Foto-Auftritt betreibt und dort u.a. E-Books vertreibt. Laut eigenen Aussagen des Betreibers stammt sein Auftritt aus dem Jahr 1998/99 und ist somit bereits auf den ersten Blick völlig veraltet und unsicher. Der damals gewählte Programmierstandard für alle Seiten (-Inhalte) -//W3C//DTD HTML 4.01 Transitional//EN war bereits 1999 veraltet und stellte damals nur den minimalistischen Übergang von HTML 3 dar. Der Betreiber verwendet ihn bis heute. Obwohl er einen derart veralteten und inhaltlich nachsichtigen Programmierstandard wählte, strotzen die Seiten dennoch vor bereits seit 2 Jahrzehnten bekannten und monierten Programmierfehlern in HTML. Meine Tools fanden bis zu über 100 HTML-Programmier-Fehler je Seite. Hinzu kamen Fehler in JavaScript. Dass die Inhalte dann auch noch unergonomisch aufbereiten sind, verwundert kaum mehr jemanden. Darauf hat der Anbieter 2018 einfach SSL setzen lassen. Das Ergebnis sind (mit den unten aufgelisteten Testwerkzeugen) z.T. über 100 sicherheitsrelevante Fehler bezüglich SSL je Seite. Als der Betreiber von anderen und auch von mir darauf aufmerksam gemacht wurde, reagierte er leider typisch mit aggressiver Sprache und verwies darauf, dass andere dies nichts angehe, was er mache. D.h. hier liegt eine dem Betreiber seit langem bekannte und somit vorsätzliche Irreführung sowie Täuschung zum Nachteil aller Nutzer vor. Obwohl vom Browser Firefox mit grünem Schloss markiert, ist der Auftritt somit unsicher.

Umrüsten auf HTTPS

Sie wollen auf HTTPS umrüsten? - Gut!

Umstellung der eigenen Auftritte

Als ich noch keine HTTPS-Verschlüsselung auf meinen eigenen Auftritten anbot, warf man mir von interessierten Kreisen, welche die obige Punkte nicht widerlegen konnten (wie auch, es handelt sich um anhand der unten angebrachten Links nachprüfbare Fakten), immer wieder dfg vor, der Betreiber sei zu dumm, zu faul oder zu geizig, um HTTPS einzuführen.

Meine bisherige Entgegnung auf solche vorsätzlich beleidigenden E-Mails war immer intelligent, erfahren, kundenorientiert: intelligent genug, um alle damit verbundenen Nachteile zu kennen, erfahren genug, um die Probleme der Umschaltung zu sehen, und kundenorientiert genug, um den meisten ahnungslosen Nutzern die Nachteile zu ersparen.

Dennoch habe ich mich nach reiflicher Prüfung zur Umrüstung entschlossen: Hier wurden 10 Domains zu HTTPS überführt.

Aus der eigenen Praxis kann ich somit alle oben aufgeführten Argumente für und wider HTTPS auch mit Praxisbeispielen am eigenen Leib bestätigen. Früher waren es nur meine Kunden, welche die Vorteile nutzen, aber auch die Nachteile erleiden mussten.

Nochmals: Erst nach mehrfachen über die Jahre durchgeführten Logfile-Analysen und reiflichen Überlegungen, sowie vorher im Jahr 2017 durchgeführten Aktualisierungen aller Auftritte auf HTML 5.2, PHP 7.# und MySQL 5.# sowie Neuprogrammierung aller eigenen Werkzeuge, habe ich dann Anfang 2018 diese Umstellung auf HTTPS durchgeführt und dabei auch bewusst auf einen gewissen Prozentsatz an Nutzern, Interessenten, Kunden, Umsatz und Gewinn verzichtet.

Empfehlungen für die Umrüstung auf HTTPS

Kümmern Sie sich ganzheitlich um Sicherheit. Beginnen Sie bei Ihrem eigenen PC als Nutzer, indem Sie alles aktualisieren und modernisieren sowie obige Hinweise beachten.

Als Anbieter im Internet erhöhen Sie dann die Sicherheit dort, indem Sie alles auf dem Server / dem eigenen Auftritt aktualisieren und modernisieren. So müssen Kontaktformulare mit TLS verarbeitet werden und dürfen auf keinen Fall nur mit offenem Sendmail oder sogar mit völlig ungeschütztem mailto verschickt werden.

Danach können Sie über HTTPS als Anbieter im Internet in aller Ruhe nachdenken.

Es handelt sich nicht um eine sofort zu erledigende Aufgabe. Aber wenn Sie die obigen Schritte bereits durchgeführt haben, fällt es Ihnen deutlich leichter, geht schneller von statten und wird preiswerter. Ferner schont der Stufenplan Ihre Nerven und den Ihrer Nutzer / Kunden.

Je nach Zielgruppe Ihrer Nutzer / Kunden, Ihren auf dem Auftritt angebotenen eigenen Produkten / Dienstleistungen sowie den Sicherheitsansprüchen Ihrer Nutzer wird irgendwann ein Umstieg auf HTTPS erfolgen. Im Zweifel weltweit erzwungen durch HTTP/2.

Nochmal: Es besteht klein gesetzlicher Zwang. Lassen Sie sich von niemanden unter Druck setzen.

Falls Sie mehrere (Teil-) Auftritte besitzen, so können Sie mit einem (möglichst kleinen und nicht lebenswichtigen) die Umstellung auf HTTPS beginnen und dort wichtige Erfahrungen z.B. mit einem kostenlosen Zertifikat sammeln.

Gleichgültig, was Sie machen: Bestehen Sie ab sofort darauf, dass jede Neuerung am bestehenden Auftritt HTTPS-fähig und HTTP/2-konform gestaltet werden muss, und lassen Sie sich dies schriftlich bestätigen.

Kosten der Zertifikate

Es werden inzwischen eine sehr große Zahl unterschiedlichster Zertifikate angeboten. Früher verlangten die Zertifizierungsstellen abschreckend hohe Beträge für das Ausstellen eines Zertifikates. In den letzten Jahren sind die Preise deutlich unter Druck geraten und sanken spürbar.

Vor allem validierte SSL-Zertifikate (EV) kosten allerdings noch immer meist dreistellige Eurobeträge je Jahr. SSL-Wildcard-Zertifikate können auch schnell über 300 Euro im Jahr kosten. Selbst bis zu 2.000 Euro je Jahr werden vereinzelt verlangt. Hinzu kommen dreistellige Stundensätze des Providers für die Installation. - Wohl gemerkt gilt das alles für je ein Zertifikat für eine Domain (= Internet-Adresse).

SSL-Zertifikat mit eigener IP sind z.B. für alte Browser notwendig, die SNI nicht unterstützen. So kommen über Umwege noch weiter Kosten hinzu.

Die Gültigkeitsdauer des SSL-Zertifikats beträgt zwischen 3 Monaten und 5 Jahren, je nach Zertifikatstyp. D.h. Sie oder Ihr Provider müssen alles regelmäßig wiederholen.

Um ein (neues) Zertifikat zu installieren, müssen Sie als Anbieter jedoch einen direkten Zugriff auf den eigenen Server besitzen. Ansonsten muss der Provider dies für Sie kostenpflichtig durchführen. Und einfach oder fehlerfrei ist das auch nicht. Hier das Beispiel für den weit verbreiteten Apache-Server.

Informieren Sie sich deshalb vorher über die exakten Kosten.

Ferner finden sich inzwischen Instanzen, die ein Zertifikat auch kostenlos und automatisch anbieten, wie z.B. die Internet Security Research Group (ISRG), welche mit Let's Encrypt als Zertifizierungsstelle für kostenlose - aber nur domainvalidierte und nur 3 Monate gültigen - SSL-/TLS-Zertifikate fungiert. 2024 boten fast alle Provider dies an.

Aber selbst, wenn es kostenlos ist, so bedeutet dies nicht umsonst. Sie müssen auf jeden Fall erhebliche Arbeiten dafür an Ihrem Auftritt durchführen, damit er HTTPS-kompatibel wird. Siehe Praxistipps unten.

Bitte bedenken Sie ferner, dass niemand Ihnen irgendeine rechtliche Garantie über die kostenlosen Zertifikate geben will. Alle Beteiligten weisen im Gegenteil ausdrücklich darauf hin, dass der Dienst ohne jede vorherige Ankündigung eingestellt oder kostenpflichtig werden kann. Allerdings besitzen Sie auch bei den kostenpflichtigen Anbietern keine Gewähr, ob es diesen im kommenden Monat noch gibt, oder ob er seine Preise drastisch anhebt. - Wie bereits mehrfach gesagt: Auch in diesem Punkt bleibt das Internet eine Vertrauensfrage.

Allerdings sollte man generell keine Panik schüren: Im Zweifel ist ein Auftritt schnell wieder auf kostenloses HTTP (ohne S) zurück- / umgestellt oder ein anderes Zertifikat bei einer anderen Stelle beantragt.

Bei den begehrten und teuren EV-Zertifikaten kommen je nach Zulassungsstelle allerdings weitere, hohe Anforderungen hinzu: Außerdem benötigen wir folgenden Nachweis: bei einer Firma mit Handelsregistereintrag (z.B. GmbH, UG, OHG) nennen Sie uns bitte das Registergericht sowie die Registernummer, bei einer Firma ohne Handelsregistereintrag benötigen wir einen Gewerbenachweis, bei Privatpersonen eine Kopie des Personalausweises, bei einem eingetragenen Verein nennen Sie uns bitte das Registergericht sowie die Registernummer. Bei einer Behörde / Körperschaft des öffentlichen Rechts benötigen wir keinen Nachweis.

HTTP/2

Wenn Sie auf HTTPS umrüsten, dann rüsten Sie den Server unbedingt auch auf HTTP/2 auf. So lassen sich wenigsten einige Zyklen und somit wertvolle Wartezeit wieder einsparen.

HTTP/2 zeigt jedoch auch Nachteile: Alte Betriebssystem und vor allem alte Browser kommen damit nicht klar.

Daraus folgt, dass Sie eine genaue Analyse benötigen, welcher Anteil Ihrer derzeitigen Nutzer, Interessenten, Kunden noch derartige alte Konfigurationen verwendet. Vergessen Sie dabei alle unsinnigen Analysen von Google und Co. Sie benötigen zur Auswertung sinnvoll aggregierte, sorgfältig gruppierte und korrekt bewertete Daten Ihres eigenen Auftrittes. - Nach solch einer Nutzeranalyse werden Sie sich wundern, wie viele Personen noch mit alter Hard- und Software im Internet unterwegs sind.

Vor allem betraf diese HTTP/2-Unverträglichkeit 2017 auch die meisten Smartphones. Erst die neusten Mobiltelefone der letzten Jahre sind mit ihren Betriebssystemen und Browsern dazu voll kompatibel. Das alles darf auch nicht verwundern, da der HTTP/2-Standard in der Endfassung erst 2015 wirklich veröffentlicht / verabschiedet wurde. Vorher konnte man nur über die Endergebnisse spekulieren.

Ansonsten kann es Ihnen passieren, dass Sie von einer Minute zur anderen 5-15% (oder auch mehr) Ihrer Kunden und Einnahmen verlieren. - Können Sie sich so etwas leisten? Häufig handelt es sich um wohlhabende ältere Nutzer und Kunden, welche selbst nicht in der Lage sind, ihren eigenen PC zu modernisieren. Ferner handelt es sich auch oft um Firmen und staatliche Behörden oder Organisatoren, deren Administratoren sich weigern, ihre alten Systeme zu aktualisieren.

Zu guter Letzt, handelt es sich auch um Personen wie mich, die grundsätzlich ihren neuesten PC als Stand-alone (sicher und ohne Internet-Anschluss) betreiben und für das Internet die vorausgehende Hard- und Software-Version nutzen (sprich: den Vorgänger). Für die geringen Leistungsanforderungen des Internets reichen derartige Systeme definitiv aus. Denn zwei getrennte Systeme sind sicherer für den reibungslosen Ablauf und auch schneller.

Bei manchen Providern, wie meinem (all-inkl.com) wird inzwischen automatisch bei der Verwendung von HTTPS-Zertifikaten HTTP/2 zugeschaltet. Man muss als Kunde nichts weiter tun (kein Umzug, keine Kosten etc.)
Bei wiederum manchen davon ist dies abwärtskompatibel gestaltet, sodass alte Systeme ggf. heruntergeschaltet werden auf HTTP/1.1 und nicht ausgeschlossen werden. Aber diese alten Systeme werden über HTTP/1.1 deutlich langsamer bedient. Dennoch ist dies ein großer Vorteil bei einer 'weichen' Migration.

Im Idealfall, wenn alles bei Ihrem Provider und alles auf Ihrem Auftritt perfekt und fehlerfrei konfiguriert und programmiert ist, und der Nutzer ebenfalls über die modernste Hard- und Software verfügt, dann kann es sogar sein, dass Sie mit vielen kleinen Dateien einen schnelleren Abruf erzielen als vorher. D.h. HTTPS kann unter günstigsten Umständen - aber nur zusammen mit HTTP/2 - sogar schneller sein als HTTP ohne S und nur HTTP/1.1.

Praxis-Probleme der Umstellung

Hier erfahren Sie, welche Fehler Sie wie vermeiden können.

Auf dem eigenen Server muss man u.a.:
SSL aktivieren - Meist ist damit heute jedoch TLS gemeint. Aber da fast niemand TLS kennt, wird bis heute meist der alte Name verwendet. Nur so funktioniert HTTPS überhaupt. Vorsicht: Die Beantragung eines Zertifikates allein schaltet Ihren Server nicht auf HTTPS um.
SSL erzwingen - Nur so werden alle Anfragen korrekt zu HTTPS umgeleitet, gleichgültig wie sie beginnen. D.h. auch die alten Links werden so von http auf https umgeleitet.
HSTS aktivieren - Dies schützt etwas besser vor Man-in-the-middle-Angriffen.

Subdomains können sich zum Ärgernis bei der Umstellung auf HTTPS entwickeln.
Entweder muss man jede einzelne, verwendete Subdomain mit einem eigenen Zertifikat ausrüsten.
Oder man trennt sich von den früher für die Suchmaschinenbeeinflussung so beliebten, aber heute kaum mehr sinnvollen Subdomains und gestaltet den Teil-Auftritt neu, indem man ihn korrekt in den Hauptauftritt integriert. Dazu muss man alle (bisher absoluten) Links nun relativ setzen. D.h. die http://www.Domainname.tld/ muss durch irgendetwas wie ../ ersetzt werden.
Auch wenn es hart klingt: Die sauberste Lösung ist tatsächlich, sich von den alten Subdomains zu trennen. Selbst bei kostenlosen Zertifikaten wird der Verwaltungsaufwand bei dutzenden oder hunderten von Subdomains kaum mehr handhabbar.

Unter SSL sind Links meist in der Form HTTPS://beispiel.de/ - ohne www. Möchte man wieder die www. davor, dann muss man sich das meist in der .htaccess selbst einrichten.

Testen Sie jede einzelne Seite und vermeiden resp. korrigieren Sie jeden einzelnen Fehler. - Zahlreiche Testwerkzeuge finden Sie unten.

Die Anforderungen an HTTPS sind viel höher als an alle bisherigen Programmiersprachen etc., die Sie evtl. kennen. Es reicht aus, wenn ein einziges Element (von eventuell zehntausenden) auf Ihrem gesamten Auftritt nicht kompatibel ist oder einen irgendwie gearteten Fehler produziert, um bereits alles unsicher zu machen. Dieses kleine Teilchen / die Schwachstelle aufzustöbern stellt keine Schwierigkeit dar. Das kann jedes Kind durch banales Ausprobieren durchführen. Also müssen Sie es auch tun - vor den Anderen.

Unterschätzen Sie den Zeitbedarf für das Testen der Seiten, insbesondere der Interaktionsmodule, nicht.

Man sollte vor allem jede Fehlermeldung zu gemischten Inhalten umgehend reparieren: Reparaturanleitung. Weitere Testtools siehe unten.

Früher spielte es keine Rolle, ob man eigene Inhalte hart mit http oder relativ verknüpfte. Man muss nun alle hart verknüpften eigenen Seiten von http auf https umstellen, oder diese internen Links nun relativ setzen.

Bei der Umrüstung auf HTTPS zeigt sich, wie inkompetent und unwillig Google ist, die größte Firma der Welt, die angeblich alles dafür tut, dass alle einfach zu HTTPS umsteigen können. Sie müssen alles neu einrichten, Ihre sitemap.xml jede Zeile auf s umschreiben, ein neues Property / Konto für die exakt identische Seite nun mit https bei Webmasters Search Console einrichten und so weiter.

In der robots.txt sollten Sie ebenfalls die Zeile Sitemap: https://www.Ihr-domainname.de/sitemap.xml eintragen, damit alle Suchmaschinen sie finden und berücksichtigen.

Bei der Umrüstung auf HTTPS zeigt sich auch, wie gut Ihr Provider ist. Die meisten Provider sind in diesem Punkt leider noch immer eher mittelmäßig. - In diesem Zusammenhang möchte ich meinem Provider all-inkl.com herzlich danken: Die gesamte Umstellung auf HTTPS war kostenlos und verlief reibungslos sowie schnell. Die geringe erforderliche Kommunikation verlief schnell, kompetent und freundlich.

Hilfe beim perfekten Einrichten von HTTPS

Ich helfe Ihnen gerne dabei, Ihren Internet-Auftritt perfekt auf HTTPS umzurüsten. Nehmen Sie Kontakt auf.

Quellen - Literatur

Alle oben niedergeschriebenen Fakten können Sie in den folgenden Quellen nachprüfen. Deshalb werden sie als Belege angeführt, nicht nur für diejenigen, welche sich vertieft weiterbilden wollen.

Netzinfrastruktur

HTTPS - Englisch

Hypertext Transfer Protocol Secure - Deutsch

Internet Deutsch

Internet Englisch

rfc2818- HTTP Over TLS - Der Standard für HTTPS

Arpanet - Deutsch

ARPANET - Englisch

Transmission Control Protocol/Internet Protocol TCP/IP - Deutsch

Internetprotokollfamilie - mit grafischer Darstellung des Schichtenmodells - rund 500 Netzwerk-Protokolle

Internet protocol suite - Englisch

Protokollstapel - Schichten des Internets

Autonomes System AS - Router

Server Name Indication Erweiterung zu TLS für mehrere Internet-Auftritte auf einem Server.

Request for Comments RFC = Standards des Internets - Deutsch

Paketfilter offiziell vorgesehene Säuberungsinstanzen im Internet

Verschlüsselung

Cipher - Englisch

Verschlüsselung - Deutsch

Asymmetrisches Kryptosystem

Symmetrisches Kryptosystem - Deutsch

Diffie-Hellman-Schlüsselaustausch - Deutsch

Diffie–Hellman key exchange (DHE) - gilt derzeit als relativ sicher

Elliptic curve Diffie–Hellman key exchange - gilt derzeit als relativ sicher

Forward secrecy = FS = perfect forward secrecy (PFS) - Englisch

Stromverschlüsselung - schnell aber unsicher

Transport Layer Security - Verschlüsselung - Deutsch

Transport Layer Security TLS Englisch

ImperialViolet - Englisch - u.a. Kontaktaufbau unter TLS

HTTP Strict Transport Security - Deutsch

SHA-1 wird verabschiedet, SHA-2 startet 6. August 2015

SHA-2 2005 - Deutsch

SHA-3 2015 - Deutsch

Virtual Private Network - Deutsch

Virtual private network - Englisch

HTTPS-Verschlüsselung im Web erreicht erstmals 50 Prozent heise 16.10.2016

TLS has exactly one performance problem: it is not used widely enough. Everything else can be optimized.

Wie lässt sich feststellen, ob auf einem Server ein SHA-1-Zertifikat installiert ist? - September 2014 - Anleitung für Browser-Nutzer / Endnutzer

HTTPS Everywhere - Software, Browser-Plug-in, welches angeblich die Fehler vieler HTTPS-Auftritte automatisch behebt, indem es vor allem viele http-Aufrufe in https-Aufrufe wandelt. Warnung: Erwarten Sie als Anbieter nicht, dass Kunden diese Software freiwillig installieren, um die Fehler auf Ihrem Internet-Auftritt auszubügeln.

Sie sind Inhaber einer Website und sehen Folgendes? Google Analyse-Hinweise zu gehackten Internet-Auftritten.

Verschlüsselung bei heise online - Ein Beispiel

HTTPS as a ranking signal - Google bewertet HTTPS höher

Pretty Good Privacy - Sichere Verschlüsselung der E-Mail. Deutsch

OpenPGP - Deutsch

OpenPGP - Email encryption. For all operating systems. Standing the test of time. - Englisch

E-Mails mit PGP verschlüsseln

Verschlüsselte Datenübertragung ist nicht sicher Zeit 2011

Über die (Un-)Sicherheit von SSL und HTTPS

Ab Juli 2018: Google Chrome warnt offensiv vor unverschlüsselten Webseiten, 23.02.2018

Viele schwache Web-Server-Zertifikate gefährden Online-Shopping

HTTPS via Proxy unsicher? MITM = Man in the middle erklärt

Man-in-the-middle attack MITM - Englisch

Man-in-the-Middle-Angriff - Deutsch

Mass surveillance Englisch - Überwachung des Internets durch Sicherheitsdienste

Zertifikate und Zertifikatsherausgeber

Digitales Zertifikat Deutsch

Zertifizierungsstelle Deutsch

Certificate authority Englisch

Public key certificate Englisch

Root certificate - Englisch

Sicherheitszertifikate von Webseiten - Hinweise von Mozilla

Online Certificate Status Protocol OCSP - Englisch

SSL-trust SSL-Zertifikat überprüfen

SSL.de - SSL-Zertifikat überprüfen

Internet Security Research Group (ISRG) Englisch

Let's Encrypt - A free, automated, and open certificate authority.

Let’s Encrypt - kostenlose Zertifikate für Jedermann

Symantec Deutsch

Comodo Group Englisch

GoDaddy Deutsch

GlobalSign Deutsch

Mozilla Englisch

Google Englisch

Microsoft Englisch

CAcert - Dieses kostenlose Zertifikat wird seit vielen Jahren nicht von Firefox akzeptiert.

HTTP/2

HTTP/2 - Englisch

Wie HTTP 2.0 das Surfen beschleunigt

Zeitplan für HTTP 2.0

SPDY Englisch - Ein Vorläufer des HTTP/2 - heute veraltet, aber noch verwendet

HTTP Strict Transport Security Englisch

Testwerkzeuge

JitBit - SSL Check - scan your website for non-secure content Web-Seiten-Test auf Vorkommen von Mixed Content für 200 Seiten am Stück.

HTTPS Checker Software zum Herunterladen, Privat kostenlos aber auf 250 Seiten eingeschränkt. Bei mir untersuchte es auch viel mehr Seiten.

DigiCert SSL Installation Diagnostics Tool

SSL test

SSL Checker

Test an SSL Web Server

why no padlock ? - Das Online-Werkzeug erkennt Sicherheitslücken in https-Auftritten. Verlangt eine manuelle Sicherheitsabfrage mit Bildern zum Anklicken und ist deshalb sehr langsam. Ferner reagiert das Testwerkzeug über bei Protokollen, welche einen Fall-back auf alte System erlauben. Obwohl das neue sichere Protokoll verwendet wird, zeigt es oft das alte unsichere an und moniert das.

Überprüfung von SSL/TLS

TLS dump Software Prüfung der gesamten TLS-Kette

CSR-Decoder - Certificate Signing Request (CSR)

10 Online Tool to Test SSL, TLS and Latest Vulnerability Englisch

Überprüfung eines Zertifikats im Browser erklärt

Mixed-Content-Warnung auf SSL-Website beheben - Beispiele von green.ch

SSLyze - für Administratoren

Netzwerk-Tools - bei heise

badssl - Lister der möglichen Fehler bei HTTPS

Zum Seitenanfang

• Startseite
  • Controlling im Internet
  • Nutzeranalyse
  • Ergonomie
  • Gutachten
  • Suchmaschinen-
      Optimierung
  • Beratung
  • Firma
    • Dienstleistungen
    • Presse
    • Artikel
      • Wasserkühlung am PC
      • Suchmaschinen-
        gerechte Programmierung
      • PC-GAU
      • Neuer PC
      • Passwort-Generator
      • DSGVO
      • VVT
      • Auskunftspflicht
      • Interne Suchmaschinen
      • Sicherheit
      • Schnelle SSD
      • Schutz
      • Mobiltauglich ?
      • Korrektes Impressum
      • Ergänzungen zum Impressum
      • Logfile-Nutzeranalysen
      • Kosten senken
      • Internet-Projekte
      • Gestaltung
      • Eintragen
      • Protokolle
      • Spionage
      • VPN
      • Rasterfahndung
    • Lebenslauf
    • Referenzen
    • Beruf & Karriere
    • Broschüren
    • Anfahrt
    • Impressum
    • Kontakt
    • Erklärung
    • Kurse
  • Impressum
  • Datenschutz
  • Artikelliste
  • Inhalt
  • Interne Suche
  • Kontakt

Controlling21.de - Dr. J. Schuhmacher
Internet und Multimedia in Perfektion