Mindestenssechszeichen...keine Panik!

Wenn im Browser das bunte Schlösschen bzw. Firmenlogo neben der Adresse auftaucht, ist alles sicher – so zumindest haben es die Browser (allen voran Google Chrome) in den letzten Jahren den Benutzern eingetrichtert. Zunächst eine Erklärung, was es damit überhaupt auf sich hat und warum das gar nicht so "sicher" ist, wie es dargestellt wird.

1. Warum Verschlüsselung?

Die Geschichte beginnt vor einigen Jahren mit dem schlichten Bedürfnis nach Privatsphäre und Sicherheit. Das Problem: Wenn man im Browser eine Adresse eingibt (z.B. www.yhoko.com) wird ein Server aufgerufen und dieser liefert die gewünschte Webseite aus – oder? Für den einfachen Fall, dass der Server per LAN-Kabel direkt mit dem eigenen PC verbunden ist, mag das stimmen, aber im Internet wird so eine Verbindung über dutzende Knotenpunkte aufgebaut. Diese Knotenpunkte können alles mitlesen, analysieren und auch beliebig verändern, was durch ihre Leitungen fliesst. Sowohl die Anfrage des Nutzers als auch die zurückkommenden Daten könnten also manipuliert sein. Jeder mit genügend Macht bei den Providern kann also Fakten umschreiben und Bilder austauschen, sei es ein Geheimdienst, Hacker oder ein angepisster Mitarbeiter!

Gut, man fragt sich jetzt vielleicht, warum die NSA die aktuellsten Sportresultate auf der Newsseite manipulieren sollte... aber halt, es geht ja nicht (nur) um Textinhalte sondern etwa auch um Downloads. Viele Webseiten, die Programme als Downloads anbieten, zeigen daher heute noch MD5-Hashes an, über die man feststellen kann, ob man wirklich genau das erhalten hat, was der Betreiber da anbietet. Und noch etwas: Lange Zeit (und traurigerweise auch heute noch) waren viele Nutzer mit dem Internet Explorer unterwegs, hatten Plugins wie Flash oder Java installiert oder einfach seit Jahren kein Update mehr gemacht. All diese Programme sind höchst anfällig für Viren, die sich heimlich in einer Mediendatei unterbringen lassen – ein bequemes Einfallstor für alles mögliche. Aber es geht sogar noch banaler, indem gewisse Provider die Web-Inhalte bewusst verändern. Im positiven Sinne kann das eine Komprimierung sein, etwa um mobiles Datenvolumen zu schonen, im negativen Sinne aber auch Werbung, die frecherweise in alle Webseiten eingefügt wird. Damit will man an sich nur etwas dazuverdienen, aber unnötig zu sagen, dass auch böse Buben Werbeplätze buchen können, um so wiederum ihren Dreck an ein grosses Publikum auszuliefern (also auch Viren, Crypto-Trojaner, Wahlwerbung und dergleichen). Dann hilft es auch nichts, wenn sich ein Webseiten-Betreiber die Werbung auf seiner Seite sorgfältig aussucht oder er selbst gar keine schaltet.

Und dann muss man noch einmal den Fakt beleuchten, dass alle Betreiber der Infrastruktur (Telekom-Anbieter, Backbones und alle Inhaber von Servern die gerade zufällig in der Route lagen) und damit auch alle Geheimdienste den ganzen unverschlüsselten Datenverkehr einfach mitlesen und aufzeichnen können. Das mag bei Terroristen ja noch sinnvoll sein, bei Whistleblowern hingegen... (und bei dir?)

2. Eine (teure) Lösung: SSL

Wenn also nicht jeder mitlesen darf, muss der Datenverkehr verschlüsselt werden. Die Beobachter sehen dann nur noch Kauderwelsch, können also auch nichts mehr verändern, was Manipulation ausschliesst, und das ganze Problem ist gelöst – oder? Leider hat die Sache einen kleinen Haken, und das ist der Schlüssel. Es kann nicht nur den einen Schlüssel geben; jede Webseite braucht einen eigenen. Es gibt allerdings zig Millionen Webseiten, täglich werden tausende an- oder abgemeldet, Server werden umgezogen und wenn wieder einer gehackt wird, steht ein Schlüsselwechsel an – kurzum: es ist unmöglich, jedem Nutzer ein riesiges Archiv zu geben, in dem die aktuellen Schlüssel für jede Webseite enthalten sind (tatsächlich ist es bereits unmöglich, ein solches Archiv überhaupt herzustellen).

Die Lösung ist also, dass jeder Server seinen eigenen Schlüssel bereitstellt. Erst beim Verbindungsaufbau werden die Informationen ausgetauscht (mitunter auch die Art der Verschlüsselung) und wenn alles passt, aktivieren beide die Kryptografie. Klingt das sicher?
Leider hat auch das noch einen Haken, denn was ist, wenn der Angreifer schon bei der ersten Verbindung in der Leitung sitzt und diesen Schlüssel-Austausch manipulieren kann? Er könnte dann die Verschlüsselung mit Server und Client separat aushandeln und quasi zwischen beiden Seiten vermitteln, mitlesen und wiederum alles manipulieren. Falls das jetzt unrealistisch klang, hier ein kleiner Denkanstoss: Der Angreifer ist womöglich ein Virus oder eine Schadsoftware die der Nutzer sich irgendwo eingefangen hat (ach so, darum gabs das praktische Tool neulich als kostenlosen Download) und die sich in den Netzwerkverkehr geklinkt hat, um wiederum Werbung zu schalten oder weitere Viren in die Downloads zu schmuggeln. Ein direktes Vertrauensverhältnis zum Server scheint also unmöglich zu sein.

Aber auch dafür gibt es eine Lösung und zwar externe Zertifizierungsstellen (genannt CA; Certificate Authority). Wenn ein unabhängiger Dritter das Ganze kontrolliert, kommen wir dem Begriff Sicherheit schon sehr nahe. Mehr noch, bisher ging es immer nur um den technischen Aspekt, aber was ist mit der Verbindung zur realen Welt? Selbst wenn der Schlüsselaustausch sicher abläuft, wer garantiert mir, dass Yhoko.cn tatsächlich die beliebte Community ist und nicht von einem findigen Hacker registriert wurde? Oder vielleicht hat jemand GoogIe.com mit grossem i statt kleinem L registriert? Oder er wäre über einen einfältigen Mitarbeiter und mittels Social-Engineering an die Domain gekommen? Für einen (grosszügigen) Obolus bieten die CAs daher als Extraleistung besonders sichere Zertifikate an, bei denen der Antragssteller tatsächlich überprüft wird (je nach CA sogar per Handelsregisterauszug oder telefonischem Kontakt). Als Rest-Risiko bleibt dann nur noch, dass die CA ihren Job nicht richtig macht und daher kein Vertrauen mehr verdient (und ja, auch dieser Fall ist längst eingetreten, hallo Symantec).

Insgesamt scheint das aber ein sicherer und praktikabler Weg zu sein... wäre da nicht der Kostenfaktor. Da selbst einfache Zertifikate monatliches Geld kosten, kommen sie für die allermeisten Websites schon aus Prinzip nicht in Frage; man denke nur an die ganzen Gratis-Domains und Werbeschleu-, ich meine, werbefinanzierten Informationsangebote.

Randnotiz: Um zumindest den Datenverkehr zu verschlüsseln kann man seine Zertifikate theoretisch auch selbst signieren. Man verzichtet dann zwar auf die externe Autorität (CA), aber zumindest kann dann nicht Hinz und Kunz im selben WLAN alles mitlesen – das wäre schon ein ordentlicher Sicherheitsgewinn gewesen, nur dummerweise haben die Browserhersteller diese Suppe von Anfang an ordentlich versalzen. Besucht man eine solche Webseite, wird man mit einer Vollbild-Warnung aufgehalten und muss dann umständlich das selbst-signierte Zertifikat als Ausnahme hinzufügen – selbst für mich jedes Mal ein Graus. Diese Massnahme hat man wohl so getroffen, weil für den Browser ein selbst-signiertes Zertifikat genau so auftritt wie ein gekapertes CA-Zertifikat, und davor muss man ja durchaus dringend warnen.

3. Das WLAN kommt

Einige Jahre lang lief das Ganze auch ohne Verschlüsselung mehr oder weniger rund, doch es gab auch immer wieder starke Anstubser zu mehr Sicherheit, von denen selbst Yhoko.com nicht verschont blieb. Der Grund hiess: WLAN, und zwar genau die erste Generation in einer Zeit, in der die Technik gerade so richtig populär wurde – Internet ohne Netzwerkkabel, wow!
Wie so oft war das erste WLAN-Protokoll aber nicht allzu sehr auf Sicherheit ausgerichtet, und bei den niedrigen Datenraten war das nur allzu verständlich. Es geht aber eigentlich um ein substanzielleres Problem: Alle Teilnehmer im selben WLAN teilten denselben Schlüssel (man kennt noch heute die Passwort-Zettelchen an der Pinnwand) und in dieser ersten Protokollversion hiess das, dass jeder Teilnehmer auch sämtliche Daten auch aller anderen Teilnehmer empfing und alles mitlesen konnte. Man kann sich das etwa so vorstellen: In einer WG werden alle Briefe eingescannt und jedem (!) Bewohner wird eine Kopie per E-Mail zugestellt. Erhält man fremde Post, muss man sie wegwerfen. Also, ja, es war genau so sicher, wie das jetzt klingt.
Bei einem halbwegs modernen Kabelnetzwerk ist das weniger ein Problem, weil die Datenpakete für einen bestimmten Rechner anhand der IP-Adresse auch nur zu genau diesem durchgereicht werden. Zudem bleiben die Daten "im Kabel", wohingegen beim WLAN ja alles einfach ausgestrahlt wird und jeder mit einem Empfänger einfach mithören kann (genau wie beim Radio).

Fazit: Wer sich damit auskannte, konnte seine Drahtlos-Nachbarn die längste Zeit ausspionieren, insbesondere an öffentlichen Orten wie Schulen und Bahnhöfen, wo die Hardware dem Stand der Technik meist auch immer etwas hinterherhinkt. Auch auf Ycom gab es gelegentlich merkwürdige Fälle von Spielern, die plötzlich unter fremden Accounts eingeloggt waren. Konkret wurde dabei die Session-ID mitgelesen, mit der man bereits unter fremden Accounts agieren kann. Das ist übrigens einer der Gründe, warum man zum Wechseln von Passwörtern und E-Mail Adressen erst einmal das aktuelle Passwort eingeben muss. Wer bloss die Session gekapert hat, kennt das Passwort nämlich nicht.
Die Problematik erreichte ihren Höhepunkt, als jemand ein einfach zu bedienendes Tool im Internet verbreitete, mit dem man ganz bequem per Mausklick jede beliebige Session aller anwesenden WLAN-Nutzer übernehmen konnte.

Was jetzt nach Horror klingt, war tatsächlich sehr aufwühlend – allerdings klappte das, wie schon erwähnt, nur im Funknetzwerk und auch nur beim ersten WPA-Protokoll. Glücklicherweise kam zu der Zeit bereits WPA2 auf (wo trotz des gemeinsamen WLAN-Passworts jede Verbindung anders verschlüsselt wird), so dass nicht jeder betroffen war, und auf Ycom (wo es hauptsächlich um Spirits-Konten ging) konnte ich das Problem anderweitig eindämmen. So erkennt beispielsweise das System, wenn plötzlich ein anderes Gerät eine Session (mit-)verwendet, ausserdem wird seit jeher das Passwort beim Login verschlüsselt.

Randnotiz: Diesen Skandal nahm ich schon damals zum Anlass, mich intensiv mit SSL zu beschäftigen, nur um am Ende festzustellen, dass diese Zertifikate schweineteuer sind, insbesondere da ich damals schon Wildcard-Zertifikat benötigt hätte (also sowas wie *.yhoko.com). Als einziger Weg blieb dann nur ein selbst-signiertes Zertifikat, was an sich praktischer gewesen wäre, zumal ich damit auch *.*.yhoko.com und www.yhoko.* hätte eintragen können (letzteres kriegt man via CA schlichtweg gar nicht). Aber, wie schon erwähnt, wäre da nur nicht die Browser-Warnmeldung und das komplizierte Hinzufügen der Ausnahmeregel... so flog das Zertifikat bald wieder raus und das Thema SSL war für Ycom erstmal erledigt.

4. Let's Encrypt

Zurück zum eigentlichen Kern der Geschichte. Nun ist es heute also so, dass der Schrei nach HTTPS bzw. SSL immer lauter wird, insbesondere auch dank der Bemühungen von Let's Encrypt. Die Jungs und Mädels von Mozilla (bekannt durch Firefox) haben sich nämlich in den Kopf gesetzt, eine kostenlose, automatisierte CA zu betreiben, damit möglichst viele Webseiten verschlüsselt werden können. Nach anfänglichen Verzögerungen lief das Projekt dann auch wirklich rasant an und hat dazu geführt, dass heute laut Messungen schon über die Hälfte aller Webseiten-Aufrufe verschlüsselt abläuft. Freilich hat in letzter Zeit auch Google stark dazu beigetragen, bzw. die ganze Sache fast schon dramatisch forciert.

Ich selbst hatte mich zunächst riesig auf Let's Encrypt (LE) gefreut – endlich kostenfreie Zertifikate, ganz offiziell und für jedermann! Aber schon zu Beginn kam der erste Dämpfer angeflogen, und zwar wollte LE keine Wildcard-Zertifikate anbieten. Es gab einige Anfragen zu dem Thema, doch diese wurden mit "ist nicht geplant" abgeschmettert. Nochmal zur Erklärung: Mit Wildcard ist das Sternchen in *.yhoko.com gemeint. Ohne Sternchen muss man sämtliche (!) Subdomains wie "www.yhoko.com", "spirits.yhoko.com", "lib.yhoko.com", usw. separat aufführen. Tatsächlich hatte ich das Sternchen aber intensiv genutzt und auch überhaupt keine Liste all meiner Subdomains geführt. Es waren hunderte, darunter auch Multi-Sub-Domains (*.*.yhoko.com) und Wildcard-TLDs (www.yhoko.*) um nur einige Spezialfälle zu nennen. Statt nämlich beispielsweise die Sprachauswahl hinten in die URL zu nehmen (starly.yhoko.com/de/home/) fand ich es eleganter, sie bei der Domain unterzubringen, damit der Pfad hinter dem "/" auch bei einem Sprachwechsel unverändert bleibt (de.starly.yhoko.com/home/).

Fazit: Meine Erwartungen in Let's Encrypt waren gestorben, zumal auch nichts den Anschein machte, dass sie in absehbarer Zukunft doch noch Wildcard-Zertifikate anbieten wollten. Mir blieb nur die Hoffnung auf einen anderen kostenlosen Dienst, der eines Tages entstehen und solche anbieten würde.

5. Let's Encrypt Wildcards

Schliesslich ein Lichtblick am Horizont. Vor einigen Monaten erfuhr ich in den News, dass LE demnächst nun doch Wildcard-Domains anbieten wollte, jubelte und schöpfte neue Hoffnung auf ein Ycom mit HTTPS. Als es soweit war, installierte ich voller Freude... erst einmal gar nichts, weil der Launch noch einmal verschoben wurde, aber dann..! Ich installierte also den CertBot, der geradezu magisch die gesamte Webserver-Konfiguration auslesen und vollautomatisch absichern sollte, wow!

Aber denkste. Bereits die Installation scheiterte und der Bot musste von Hand kompiliert werden. Dann weigerte er sich, meine Apache-Konfiguration zu verarbeiten, weil mehr als ein VirtualHost pro Datei eingetragen wurde (bei mir: teils hunderte). Seufzend biss ich in den sauren Apfel und kopierte testweise einige Konfigurationen in eigene Dateien, um zu sehen, ob das wenigstens klappt. Jawoll! ... nein, doch nicht. Die gewöhnlichen Domains wurden zwar erkannt (das war ja auch nichts neues), aber Wildcard-Domains würden nur mittels DNS-Plugin oder manuell unterstützt, hiess es da. Also zurück zur Mozilla-Webseite, das passende DNS-Plugin für meinen Server gesucht und... ah ja, aus Sicherheitsgründen wurde es wieder zurückgerufen, auf unbestimmte Zeit.

Jahrelang hatte mich das Thema nun schon belastet und der Geduldsfaden war wirklich arg strapaziert – insbesondere auch, weil das Thema immer dringender wurde. Einige Kunden hatten mich in der Zwischenzeit bereits auf SSL hin angesprochen und gefragt, ob sie nicht auch ein "grünes Schlösschen" auf ihren Webseiten haben könnten. Tja, leider noch immer nicht, aber ich versprach, mich darum zu kümmern. Einige Zeit später rollte ich die ganze Sache dann noch einmal komplett auf und griff nach dem letzten verbleibenden Strohhalm: manuelle Validierung statt DNS-Plugin.

Das heisst, man startet den CertBot, in der Konsole erscheint ein Code, diesen Code kopiert man in den DNS-Server, startet ihn neu, wartet ca. 2 Stunden, startet erneut den Certbot woraufhin sich LE mit dem DNS verbindet, den Code prüft und (wenn alles passt) endlich das Zertifikat ausstellt. Macht man das zu früh, ist die Änderung im DNS womöglich noch nicht durch, die Anfrage schlägt fehl, wird damit auch gleich ungültig (!) so dass man wieder am Anfang landet. Fehlersuche mit stundenlanger Verzögerung und jeweils nur einem Versuch, es war wirklich schön. Nach einigen Versuchen klappte es dann aber tatsächlich. Endlich! Natürlich liess sich der ganze Vorgang automatisieren, irgendwie, auf Umwegen, aber dennoch. Ich investierte abermals viel Zeit und Mühe, um alles für diese manuelle Validierung anzupassen und sie einzurichten.

Und es klappte. Zumindest anfangs. Mein Skript führte den CertBot gleich für alle Server am Stück aus, sammelte die Codes (einen pro Wildcard-Domain) und schrieb sie alle in den DNS, andernfalls hätten sich die DNS-Wartezeiten ja multipliziert. Doch plötzlich ging gar nichts mehr, die Code-Validierung seitens LE schlug fehl, die Fehlermeldung war nichtssagend ("DNS problem: server failure").
Nach stundenlangem Debuggen (hier wieder die 2-stündige Wartezeit bei jedem Versuch) fand ich heraus, dass LE beim Abrufen des Codes nur die ersten 512 Bytes ausliest. Sehr ärgerlich, denn jeder Code umfasst an sich bereits 32 Zeichen und dazu kommen am Anfang der DNS-Antwort noch weitere notwendige Informationen.
Letztendlich kam ich nicht umhin, die Abfrage doch wieder auf einzelne Domains zu beschränken. Das heisst, Anfrage stellen, warten, validieren, und das ganze dann für alle hundert Domains. Ganz grosser Spass. Hatte ich schon erwähnt, dass jedes Zertifikat auch noch spätestens alle 90 Tage erneuert werden muss? Inklusive erneuter Validierung via DNS?

Nach diesem Höllenritt überwog das Leid noch immer stark den Erfolg, aber zumindest hatte ich einen Fuss in der SSL-Tür. Bis dann abermals Validierungen fehlschlugen und zwar aus folgenden Gründen, die wiederum einzeln und mühsam gefunden werden wollten:

Erstens darf man in einem einzelnen Zertifikat keine Wildcard-Domain und gleichzeitig eine gewöhnliche Subdomain beantragen, also *.yhoko.net und dazu www.yhoko.com funktionieren nicht in einem. Genau solche Fälle habe ich aber konfiguriert, in diesem konkreten Beispiel weil yhoko.net für alle Subdomains zuständig ist, plus eben noch die www-Subdomain von yhoko.com. Dies aufzuteilen bedeutet mitunter, dass die Apache-Konfiguration jeweils kopiert und einzeln eingetragen werden muss, also eine Vervielfachung der Konfigurationen und noch mehr Verwaltungsaufwand.

Zweitens erlaubt LE keine Multi-Wildcard-Domains wie etwa *.*.yhoko.com, aber – man ahnt es schon – auch solche sind bei mir rege in Gebrauch, etwa für die oben erwähnte Sprachauswahl im Sternchenspiel.

Drittens erlaubt LE auch keinerlei Wildcard-Domainnamen oder TLDs, also weder www.yhoko.* noch www.*.com noch www.*.* – und auch hier findet sich beides in meiner Konfiguration wieder. Es war für mich einfach naheliegend, alle Ycom TLDs (yhoko.com, yhoko.ch, yhoko.org, yhoko.de, usw.) in einer einzigen Konfiguration abzudecken, mit einem schönen Sternchen. Für LE werden daraus nun wieder ein dutzend Konfigurationen. Und weil alle meine Domains über (denselben) Webmail-Dienst verfügen, war es naheliegend, in Apache webmail.*.* zu konfigurieren. Egal, welche meiner Domains der Nutzer aufruft, und egal, ob ich neue Domains hinzufüge, Webmail funktionierte weiterhin ohne jegliche Anpassungen meinerseits... bis jetzt.

Randnotiz: Warum kann ich so etwas wie www.*.com auf meinem Webserver eintragen? Das liegt einfach in der Natur der Sache; nur Anfragen die z.B. yhoko.com betreffen werden vom DNS-System überhaupt an meinen Server weitergeleitet. Anders ausgedrückt, dieser ganze Beitrag und all der Stress wäre hinfällig, wenn es ein Zertifikat für * (also einfach alles) gäbe. Nur leider lässt sich seitens LE natürlich nicht validieren, dass mir * gehört, und deshalb funktionieren auch Wildcard-TLDs nicht.

Zähneknirschend und weil Google mit Chrome immer mehr Druck auf non-SSL-Webseiten ausübt, habe ich schliesslich all diesen Probleme überwunden und ein System geschaffen, welches die ganze Domain-Verwaltung automatisiert übernimmt und dabei so viel von der bisherigen Flexibilität wie möglich erlaubt. Nicht alles hat funktioniert, vieles war lästig und insgesamt war alles enorm anstrengend. Die ganze Sache schränkt mich als Web-Entwickler deutlich ein, macht von einem Drittanbieter abhängig, wirkt noch immer irgendwie instabil und schafft viel unnötige Reibung zwischen Systemen, die so einfach nicht füreinander gedacht waren. Zudem hängt nun alles an Let's Encrypt, denen man einerseits als Anbieter, andererseits aber auch vom technischen Standpunkt aus vertrauen muss – was, wenn dort mal ein Hacker eindringen kann, oder erwähnen wir noch einmal den zornigen Ex-Mitarbeiter?

6. Fazit

HTTPS ist und bleibt für mich ein Krampf und dabei rede ich noch nicht einmal von der Webseite selbst, wo nun überall das hartkodierte "//" durch "//" ersetzt werden muss, damit der Browser nicht "gemischte Inhalte" anzeigt und mit einem gelben Schlösschen warnt (das heisst, nicht ganz überall, denn bei Links nach draussen weiss man ja nicht, ob diese schon HTTPS unterstützen).
Aber auch die geschilderten Ereignisse sind zum Teil noch beschönigt, viele Frustmomente wurden gut verdrängt (zugegeben, gelegentlich klemmts auch vor dem Monitor), einige Fakten und Ereignisse wurden in dem Bericht hemmungslos (zugunsten der Schreiblaune) unterschlagen und was in Zukunft noch alles kommen (und schiefgehen) mag, darüber will ich gar nicht spekulieren. Im Vergleich dazu war es fast schon ein Spaziergang, die interaktiven Dienste (Chat, Endyr, Ynet) umzugestalten, obwohl diese nie dafür konzipiert wurden, Verbindungen auf 2 verschiedenen Ports anzunehmen.

Um aber zum Schluss noch einmal auf die Browser-Hinweise zurückzukommen – was nutzt es denn nun, wenn in der Adresszeile ein grünes, blaues, gelbes oder graues Feld angezeigt wird? Darf man sich als Nutzer damit sicher fühlen? Nein, denn natürlich kann auch der findige Hacker von weiter oben, der vielleicht G00GLE.com registriert hat (diesmal mit zwei Nullen statt Os) für diese Domain ein Zertifikat bei Let's Encrypt beantragen und schon sieht der Nutzer ein grünes Schlösschen, wenn er via Phishing-E-Mail auf G00GLE.com landet.
Aus diesem Grund wurde in Chrome dieses Verhalten bereits wieder umgeschaltet; das trügerische Grün abgeschafft und die Beweislast quasi umgekehrt – HTTPS ist der Standard ohne besondere Merkmal, aber vor HTTP-Verbindungen wird gewarnt. Firefox und die anderen müssen wohl oder übel nachziehen, um die Nutzer nicht noch vollends zu verwirren (hey, wieso ist die Seite im Firefox grün und damit "sicher" aber in Chrome nicht?).
Nicht zuletzt geschieht es auch jetzt schon allzu schnell, dass aus dem grünen Schlösschen eine orange Warnung wird, etwa wenn gemischte (Fremd-)Inhalte nachgeladen werden – so gesehen immer wieder in der Google Bildersuche. Ist Google deswegen jetzt unsicher? Nein? Wieso muss man dann überhaupt auf solche Warnungen achten? Es stellt sich hier wirklich die Frage, inwieweit die ganzen Hinweise den Nutzern helfen oder gar schaden. Sicherheit gibt es letztendlich immer nur dann, wenn man sich mit einer Thematik auseinandersetzt und die Risiken begreift.

Damit wir uns jetzt aber richtig verstehen, Verschlüsselung im Netz ist absolut notwendig und auch sinnvoll, nur mit der Umsetzung kann ich mich nicht anfreunden. Ich bewundere die Arbeit, die hier reingesteckt wurde, aber selbst wenn dies jetzt die bestmögliche Lösung war; für mich hat das alles einfach nicht so recht funktioniert und der Aufwand steht nach wie vor in äusserst fragwürdigem Verhältnis zum Nutzen. Vielleicht hatte ich einfach Pech mit meiner effizienten, übersichtlichen und wartungsfreundlichen Konfiguration – ich werde sie vermissen. Vielleicht hat man sich auch einfach zu sehr darum bemüht, alte Protokolle weiter auszubauen, statt etwas Neues zu etablieren – abgehängt werden alte Geräte ja so oder so (etwa indem man TLS 1.0 abschaltet, was bereits der Fall ist).
Allen anderen drücke ich jedenfalls die Daumen, hoffe der Beitrag hat irgendwie geholfen (oder war zumindest unterhaltsam) und freue mich jetzt schon auf das nächste Dist-Upgrade.

Yhoko