HTTPS, SSL, TLS

Systembedingt finden wir zwei Hauptrisiken - die Verschlüsselung und das Zertifikatsystem. Seit spätestens 2013 ist bekannt, dass Sicherheitsdienste an beiden Stellen ansetzen, um jede HTTPS-Verbindung in Echtzeit (während der Nutzer diese verwendet) 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. 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.
• Bei Übergängen von einem SHA-Protokoll zum Nachfolge wird 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.