In letzter Zeit erregt WireGuard große Aufmerksamkeit, es ist tatsächlich der neue "Star" unter VPN. Aber ist es wirklich so gut, wie es scheint? Ich möchte einige Beobachtungen teilen und die Implementierung von WireGuard betrachten, um zu erklären, warum es kein Ersatz für IPsec oder OpenVPN ist.
In diesem Artikel möchte ich einige Mythen [um WireGuard] entlarven. Ja, es wird eine Weile dauern, also sollten Sie sich jetzt eine Tasse Tee oder Kaffee machen, wenn Sie das noch nicht getan haben. Außerdem möchte ich Peter für das Korrekturlesen meiner chaotischen Gedanken danken.
Es ist nicht mein Ziel, die Entwickler von WireGuard zu diskreditieren oder ihre Bemühungen oder Ideen abzuwerten. Ihr Produkt ist funktional, aber ich persönlich glaube, dass es völlig falsch dargestellt wird – es wird als Ersatz für IPsec und OpenVPN präsentiert, die es in Wirklichkeit einfach nicht gibt.
Als Hinweis möchte ich hinzufügen, dass die Verantwortung für diese Positionierung von WireGuard bei den Medien liegt, die darüber berichtet haben, und nicht beim Projekt selbst oder seinen Schöpfern.
In letzter Zeit gab es nicht gerade viele positive Nachrichten über den Linux-Kernel. Wir hörten von gewaltigen Sicherheitsanfälligkeiten bei Prozessoren, die durch Softwarelösungen behoben wurden, während Linus Torvalds darüber in einer trockenen und langweiligen, utilitaristischen Sprache sprach. Scheduler und Netzwerk-Stacks auf Null-Ebene sind auch keine Themen für Magazine. Und dann kommt WireGuard ins Spiel.
Auf dem Papier klingt alles fantastisch: eine faszinierende neue Technologie.
Doch werfen wir einen genaueren Blick darauf.
Technische Dokumentation zu WireGuard
Dieser Artikel basiert auf der offiziellen Dokumentation von WireGuard, die von Jason Donenfeld verfasst wurde. Darin erklärt er das Konzept, die Zielsetzung und die technische Umsetzung [WireGuard] im Linux-Kernel.
Die erste Aussage lautet:
WireGuard […] soll IPsec in den meisten Anwendungsszenarien ersetzen sowie andere populäre Lösungen aus dem benutzerdefinierten Raum und/oder TLS, wie OpenVPN, wobei es sicherer, leistungsstärker und einfacher zu benutzen [ist].
Natürlich ist das größte Plus aller neuen Technologien ihre Einfachheit [im Vergleich zu seinen Vorgängern]. Aber ein VPN muss auch effektiv und sicher sein.
Und was nun?
Wenn Sie sagen, dass Sie nicht das [von einem VPN] benötigen, dann können Sie an dieser Stelle aufhören zu lesen. Dennoch möchte ich darauf hinweisen, dass ähnliche Anforderungen auch an jede andere Tunneltechnologie gestellt werden.
Das Interessanteste an dem oben zitierten Satz steckt in den Worten „in den meisten Fällen“, die die Presse natürlich ignoriert hat. Und hier sind wir, wo wir aufgrund dieses Nachlässigkeit Chaos gelandet sind — in diesem Artikel.
Wird WireGuard mein [IPsec] VPN zwischen Standorten ersetzen?
Nein. Es gibt einfach keine Möglichkeit, dass große Anbieter wie Cisco, Juniper und andere WireGuard für ihre Produkte übernehmen werden. Sie springen nicht einfach auf vorbeifahrende Züge, es sei denn, es gibt einen zwingenden Grund dafür. Später werde ich einige Gründe darlegen, warum sie wahrscheinlich WireGuard nicht in ihre Produkte integrieren können, auch wenn sie es wollten.
Wird WireGuard meinen RoadWarrior vom Laptop ins Rechenzentrum bringen?
Nein. Momentan fehlen im WireGuard eine Vielzahl wichtiger Funktionen, um solche Nutzungsszenarien zu ermöglichen. Zum Beispiel kann es keine dynamischen IP-Adressen auf der Serverseite des Tunnels verwenden, was bereits das gesamte Nutzungsszenario zunichte macht.
IPFire wird oft für kostengünstige Internetverbindungen eingesetzt, beispielsweise für DSL oder Kabelanschlüsse. Dies macht Sinn für kleine oder mittelständische Unternehmen, die kein schnelles Glasfaser benötigen. [Hinweis des Übersetzers: Es sollte nicht vergessen werden, dass Russland und einige GUS-Länder in Bezug auf die Kommunikationsinfrastruktur weit vor Europa und den USA liegen, da wir unsere Netzwerke viel später aufgebaut haben. Mit der Einführung von Ethernet und Glasfasernetzen als Standard war es einfacher für uns, uns anzupassen. In den EU-Ländern oder den USA ist ein xDSL Breitbandzugang mit Geschwindigkeiten von 3-5 Mbit/s immer noch die Norm, während der Glasfaseranschluss für uns unvorstellbare Kosten verursacht. Daher spricht der Autor des Artikels über DSL- oder Kabelanschlüsse als Norm und nicht als veraltete Technologie.] Allerdings verfügen DSL-, Kabel-, LTE- (und andere drahtlose Zugangsarten) über dynamische IP-Adressen. Natürlich ändern sie sich manchmal nicht oft, aber sie ändern sich dennoch.
Es gibt ein Unterprojekt mit dem Namen „wg-dynamic“, das einen Benutzerraum-Daemon hinzufügt, um dieses Manko zu beheben. Ein großes Problem des oben beschriebenen Benutzerszenarios ist die Verschärfung durch dynamische IPv6-Adressierung.
Aus der Sicht des Anbieters sieht das alles auch nicht gut aus. Eines der Ziele der Entwicklung war es, die Einfachheit und Klarheit des Protokolls zu bewahren.
Leider ist das alles tatsächlich zu einfach und primitiv geworden, sodass wir zusätzliche Software verwenden müssen, damit diese gesamte Konstruktion im echten Betrieb funktionsfähig bleibt.
Ist WireGuard so einfach zu benutzen?
Noch nicht. Ich sage nicht, dass WireGuard niemals eine gute Alternative für das Tunnel-Passing zwischen zwei Punkten sein wird, aber bisher ist es nur eine Alpha-Version des Produkts, das es werden sollte.
Was macht es dann tatsächlich? Ist IPsec wirklich so viel komplizierter in der Anwendung?
Offensichtlich nicht. Der IPsec-Anbieter hat dies bedacht und liefert sein Produkt mit einer Benutzeroberfläche, beispielsweise mit IPFire.
Um einen VPN-Tunnel über IPsec einzurichten, benötigen Sie fünf Datensätze, die in die Konfiguration eingegeben werden müssen: Ihre eigene öffentliche IP-Adresse, die öffentliche IP-Adresse der Gegenstelle, die Teilnetze, die Sie über diese VPN-Verbindung öffentlich machen möchten, und den Pre-Shared Key. Auf diese Weise wird der VPN innerhalb weniger Minuten eingerichtet und ist mit jedem Anbieter kompatibel.
Leider gibt es in dieser Geschichte einige Ausnahmen. Jeder, der versucht hat, einen VPN-Tunnel über IPsec zu einer Maschine mit OpenBSD zu leiten, weiß, wovon ich spreche. Es gibt noch ein paar schmerzhafte Beispiele, aber tatsächlich gibt es viel mehr positive Praxiserfahrungen mit IPsec.
Zur Komplexität des Protokolls
Der Endverbraucher sollte sich nicht um die Komplexität des Protokolls kümmern.
Wären wir in einer Welt, in der dies eine echte Sorge des Nutzers wäre, hätten wir uns längst von SIP, H.323, FTP und anderen Protokollen, die vor über zehn Jahren entwickelt wurden und schlecht mit NAT funktionieren, verabschiedet.
Es gibt Gründe, warum IPsec komplizierter ist als WireGuard: es erfüllt zahlreiche Funktionen. Zum Beispiel die Benutzerauthentifizierung mittels Login/Passwort oder SIM-Karte mit EAP. Es ermöglicht zudem eine erweiterte Integration neuer kryptografischer Primitiven..
WireGuard hingegen bietet diese Möglichkeit nicht.
Das bedeutet, dass WireGuard irgendwann scheitern könnte, weil eines der kryptografischen Primitiven geschwächt oder vollständig kompromittiert wird. Der Autor der technischen Dokumentation äußert sich dazu folgendermaßen:
Es ist anzumerken, dass WireGuard kryptografisch selbstbewusst ist. Es fehlt ihm absichtlich an Flexibilität hinsichtlich der Algorithmen und Protokolle. Sollten in den zugrunde liegenden Primitiven schwerwiegende Schwachstellen gefunden werden, müssen alle Endpunkte aktualisiert werden. Wie der anhaltende Strom von Schwachstellen in SSL/TLS zeigt, hat die Flexibilität beim Verschlüsseln derzeit enorm zugenommen.
Der letzte Satz ist absolut korrekt.
Die Erzielung eines Konsenses darüber, welche Verschlüsselung verwendet werden soll, macht Protokolle wie IKE und TLS mehr als komplex. Zu komplex? Ja, in TLS/SSL treten Schwachstellen häufig auf, und es gibt keine alternativen Lösungen.
Über das Ignorieren realer Probleme.
Stellen Sie sich vor, Sie haben einen VPN-Server mit 200 aktiven Clients weltweit. Das ist ein ganz typisches Nutzungsszenario. Wenn Sie die Verschlüsselung ändern müssen, müssen Sie das Update auf alle Kopien von WireGuard auf diesen Laptops, Smartphones usw. verteilen. Gleichzeitig Das ist buchstäblich unmöglich. Administratoren, die versuchen, dies zu tun, werden Monate benötigen, um die erforderlichen Konfigurationen zu implementieren, während durchschnittliche Unternehmen dafür tatsächlich Jahre brauchen.
IPsec und OpenVPN bieten eine Funktion zur Aushandlung von Verschlüsselungen. Daher wird eine gewisse Zeit, in der Sie die neue Verschlüsselung aktivieren, auch die alte aktiv bleiben. So können bestehende Clients auf die neue Version umschalten. Nachdem das Update ausgeführt wurde, schalten Sie einfach die verwundbare Verschlüsselung ab. Und das war's! Fertig! Sie sind großartig! Und die Clients werden es nicht einmal bemerken.
Tatsächlich ist dies ein sehr häufiges Szenario bei großen Deployments, und sogar OpenVPN hat damit einige Schwierigkeiten. Die Abwärtskompatibilität ist wichtig, und obwohl Sie eine schwächere Verschlüsselung verwenden, führt das bei vielen nicht zur Schließung des Unternehmens. Denn das würde die Arbeit von Hunderten von Kunden lahmlegen, da sie ihre Aufgaben nicht erledigen können.
Das WireGuard-Team hat sein Protokoll vereinfacht, aber es ist völlig ungeeignet für Menschen, die keine ständige Kontrolle über beide Endpunkte ihres Tunnels haben. Meiner Erfahrung nach ist genau dieses Szenario das häufigste.
Kryptographie!
Aber was ist das für eine interessante neue Verschlüsselung, die WireGuard verwendet?
WireGuard verwendet Curve25519 für den Schlüsselaustausch, ChaCha20 zur Verschlüsselung und Poly1305 zur Datenautorisierung. Es nutzt auch SipHash für die Schlüssel-Hashes und BLAKE2 für das Hashing.
ChaCha20-Poly1305 ist für IPsec und OpenVPN (über TLS) standardisiert.
Es ist offensichtlich, dass die Entwicklungen von Daniel Bernstein sehr häufig verwendet werden. BLAKE2 ist der Nachfolger von BLAKE, der Finalist von SHA-3, der aufgrund seiner Ähnlichkeit mit SHA-2 nicht gewonnen hat. Wäre SHA-2 kompromittiert worden, hätte auch BLAKE wahrscheinlich unter Umständen verwundbar gemacht werden können.
IPsec und OpenVPN benötigen wegen ihrer Architektur kein SipHash. Somit kann derzeit nur BLAKE2 nicht verwendet werden, und auch das nur, bis es standardisiert ist. Das ist kein großer Nachteil, da VPNs HMAC verwenden, um Integrität zu gewährleisten, was als starke Lösung gilt, selbst in Kombination mit MD5.
Somit bin ich zu dem Schluss gekommen, dass in allen VPN nahezu dasselbe Set an kryptografischen Werkzeugen verwendet wird. Daher ist WireGuard nicht sicherer oder weniger sicher als andere aktuelle Produkte, wenn es um die Verschlüsselung oder Integrität der übertragenen Daten geht.
Doch das ist nicht der wichtigste Punkt, der laut der offiziellen Projekt-Dokumentation beachtet werden sollte. Schließlich ist die Geschwindigkeit entscheidend.
Ist WireGuard schneller als andere VPN-Lösungen?
Kurz gesagt: Nein, es ist nicht schneller.
ChaCha20 ist ein Stromchiffrierverfahren, das leichter in Software implementiert werden kann. Es verschlüsselt jeweils ein Bit. Blockprotokolle wie AES hingegen verschlüsseln Blöcke mit 128 Bit gleichzeitig. Für die Implementierung von Hardwareunterstützung sind wesentlich mehr Transistoren erforderlich, weshalb größere Prozessoren mit AES-NI ausgestattet sind — einer Erweiterung des Befehlssatzes, die einige Aufgaben des Verschlüsselungsprozesses zur Beschleunigung übernimmt.
Es wurde erwartet, dass AES-NI niemals in Smartphones integriert werden würde [und doch ist es so gekommen, Anm. d. Übs.]. Deshalb wurde ChaCha20 als leichte und kosteneffiziente Alternative entwickelt, die den Akku schont. Daher könnte es für Sie überraschend sein, dass jedes Smartphone, das Sie heute kaufen können, eine Art Beschleunigung für AES hat und mit dieser Verschlüsselung schneller und energieeffizienter arbeitet als mit ChaCha20.
Offensichtlich hat praktisch jeder Desktop-PC- oder Serverprozessor, der in den letzten Jahren gekauft wurde, AES-NI.
Daher erwarte ich, dass AES in jedem einzelnen Szenario besser abschneidet als ChaCha20. In der offiziellen Dokumentation von WireGuard wird erwähnt, dass ChaCha20-Poly1305 dank AVX512 AES-NI übertreffen wird, aber diese Befehlserweiterung wird nur auf größeren Prozessoren verfügbar sein, was wiederum nicht bei kleinerer und mobiler Hardware hilft, die immer schneller mit AES-NI arbeitet.
Ich bin mir nicht sicher, ob dies bei der Entwicklung von WireGuard vorhergesehen werden konnte, aber heute ist die Tatsache, dass es auf eine Verschlüsselung festgelegt ist, bereits ein Nachteil, der sich negativ auf seine Leistung auswirken könnte.
IPsec ermöglicht die freie Wahl der am besten geeigneten Verschlüsselung für Ihren Anwendungsfall. Und natürlich ist dies notwendig, wenn Sie beispielsweise mehr als 10 Gigabyte Daten über eine VPN-Verbindung übertragen möchten.
Integrationsprobleme in Linux
Obwohl WireGuard ein modernes Verschlüsselungsprotokoll gewählt hat, verursacht dies bereits zahlreiche Probleme. Statt das zu nutzen, was im Kernel von Haus aus unterstützt wird, wurde die Integration von WireGuard jahrelang wegen des Fehlens dieser primitiven Funktionen in Linux aufgeschoben.
Ich bin mir nicht ganz sicher, wie die Situation in anderen Betriebssystemen aussieht, aber wahrscheinlich unterscheidet sie sich nicht stark von der Situation bei Linux.
Wie sieht die Realität aus?
Leider stoße ich jedes Mal, wenn ein Kunde mich bittet, eine VPN-Verbindung einzurichten, auf das Problem, dass sie veraltete Anmeldedaten und Verschlüsselungen verwenden. 3DES in Kombination mit MD5 ist immer noch gängige Praxis, ebenso wie AES-256 und SHA1. Und obwohl letzterer etwas besser ist, ist das nichts, womit man sich im Jahr 2020 beschäftigen sollte.
Für den Schlüsselaustausch immer wird RSA verwendet – ein langsames, aber ausreichend sicheres Werkzeug.
Meine Kunden arbeiten mit Zollbehörden und anderen staatlichen Einrichtungen sowie mit großen Unternehmen, deren Namen weltweit bekannt sind. Alle verwenden eine Anfragemethode, die vor Jahrzehnten entwickelt wurde, und die Möglichkeit zur Nutzung von SHA-512 wurde einfach nie hinzugefügt. Ich kann nicht sagen, dass dies offensichtlich den technologischen Fortschritt beeinflusst, aber es verlangsamt offensichtlich die Unternehmensprozesse.
Es tut mir leid, das zu sehen, denn IPsec unterstützt elliptische Kurven seit 2005. Curve25519 ist ebenfalls neuer und verfügbar. Es gibt auch Alternativen zu AES wie Camellia und ChaCha20, aber nicht alle davon werden von großen Anbietern wie Cisco und anderen unterstützt.
Und die Leute nutzen diese. Es gibt viele Cisco-Kits und zahlreiche Kits, die für die Zusammenarbeit mit Cisco entwickelt wurden. Sie sind Marktführer in diesem Segment und nicht besonders an Innovationen interessiert.
Ja, die Situation [im Unternehmenssegment] ist katastrophal, aber wir werden durch WireGuard keine Veränderungen sehen. Die Hersteller werden wahrscheinlich nie Leistungsprobleme mit den bereits verwendeten Werkzeugen und Verschlüsselungen aufdecken und keine Schwierigkeiten bei der Nutzung von IKEv2 feststellen – deshalb suchen sie nicht nach Alternativen.
Haben Sie jemals darüber nachgedacht, Cisco abzulehnen?
Benchmarks
Jetzt wenden wir uns den Benchmarks aus der WireGuard-Dokumentation zu. Obwohl diese [Dokumentation] kein wissenschaftlicher Artikel ist, hatte ich von den Entwicklern dennoch eine fortschrittlichere Herangehensweise oder die Verwendung wissenschaftlicher Ansätze als Maßstab erwartet. Benchmarks sind wertlos, wenn sie nicht reproduzierbar sind, und noch wertloser, wenn sie unter Laborbedingungen gewonnen werden.
In der Linux-Version von WireGuard nutzt es die Vorteile von GSO – Generic Segmentation Offloading. Damit erstellt der Client ein riesiges Paket mit einer Größe von 64 Kilobyte und verschlüsselt/dechiffriert es in einem Durchgang. Dadurch werden die Kosten für den Aufruf und die Durchführung kryptografischer Operationen gesenkt. Wenn Sie die Bandbreite Ihrer VPN-Verbindung maximieren möchten, ist dies eine gute Idee.
Wie gewohnt ist jedoch in der Realität nicht alles so einfach. Das Senden eines so großen Pakets an den Netzwerkadapter erfordert, dass es in viele kleinere Pakete aufgeteilt wird. Die übliche Größe eines Pakets beträgt 1500 Byte. Das bedeutet, dass unser Gigant von 64 Kilobyte in 45 Pakete (1240 Byte Nutzdaten und 20 Byte IP-Header) aufgeteilt wird. Dann blockieren sie vorübergehend den Netzwerkadapter vollständig, da sie gemeinsam und sofort gesendet werden müssen. Letztendlich führt das zu einer Prioritätsausweichung, und Pakete wie VoIP werden in die Warteschlange gesetzt.
So wird die hohe Bandbreite, die WireGuard so selbstbewusst verkündet, durch die Verlangsamung der Netzwerkleistung anderer Anwendungen erreicht. Und das WireGuard-Team hat bereits meine Erkenntnis bestätigt.
Doch lassen Sie uns weitermachen.
Laut den Benchmarks in der technischen Dokumentation zeigt die Verbindung eine Bandbreite von 1011 Mbit/s.
Beeindruckend.
Besonders beeindruckend ist, dass die maximale theoretische Bandbreite einer Gigabit-Ethernet-Verbindung 966 Mbit/s beträgt, wenn die Paketgröße 1500 Byte beträgt, abzüglich 20 Byte für den IP-Header, 8 Byte für den UDP-Header und 16 Byte für den Header von WireGuard selbst. Es gibt noch einen weiteren IP-Header im gekapselten Paket und einen weiteren TCP-Header mit 20 Byte. Woher kommt also diese zusätzliche Bandbreite?
Mit großen Frames und den oben genannten Vorteilen von GSO beträgt das theoretische Maximum bei einer Frame-Größe von 9000 Byte 1014 Mbit/s. In der Praxis ist eine solche Bandbreite normalerweise nicht erreichbar, da sie mit großen Schwierigkeiten verbunden ist. Daher kann ich nur vermuten, dass der Test mit noch größeren Frames von über 64 Kilobyte durchgeführt wurde, mit einem theoretischen Maximum von 1023 Mbit/s, das nur von bestimmten Netzwerkadaptern unterstützt wird. Aber das ist absolut in realen Bedingungen nicht anwendbar oder kann nur zwischen zwei direkt verbundenen Stationen verwendet werden, ausschließlich im Rahmen eines Teststandes.
Da ein VPN-Tunnel zwischen zwei Hosts über eine Internetverbindung hergestellt wird, die große Frames überhaupt nicht unterstützt, kann das erreichte Ergebnis im Teststand nicht als Referenz akzeptiert werden. Es handelt sich hier um eine unrealistische Laborleistung, die in echten Anwendungsszenarien nicht umsetzbar ist.
Selbst im Rechenzentrum wäre es mir nicht möglich, Frames größer als 9000 Bytes zu übertragen.
Das Kriterium der Anwendbarkeit in der realen Welt ist völlig verletzt, und ich denke, der Autor dieser "Messung" hat sich aus offensichtlichen Gründen erheblich diskreditiert.
Der letzte Hoffnungsschimmer
Auf der WireGuard-Website wird viel über Container gesprochen, und es wird klar, wofür er tatsächlich gedacht ist.
Ein einfacher und schneller VPN, der keine Konfiguration erfordert und mit massiven Orchestrierungstools wie denen von Amazon in deren Cloud bereitgestellt und eingerichtet werden kann. Amazon nutzt speziell die neuesten Hardwarefunktionen, die ich zuvor erwähnt habe, wie AVX512. Dies geschieht, um die Leistung zu optimieren und nicht an x86 oder eine andere Architektur gebunden zu sein.
Sie optimieren die Bandbreite und Pakete, die größer als 9000 Byte sind – das ergibt riesige gekapselte Frames für die Kommunikation zwischen Containern, oder für Backup-Operationen, Snapshots oder das Bereitstellen dieser Container. Selbst dynamische IP-Adressen haben keinen Einfluss auf die Funktion von WireGuard in dem von mir beschriebenen Szenario.
Gut gespielt. Eine brillante Umsetzung und ein sehr schlanker, nahezu vorbildlicher Protokoll.
Aber es ist einfach nicht für die Welt außerhalb eines vollständig von Ihnen kontrollierten Rechenzentrums geeignet. Wenn Sie jedoch das Risiko eingehen und beginnen, WireGuard zu verwenden, müssen Sie ständig Kompromisse bei der Entwicklung und Implementierung des Verschlüsselungsprotokolls eingehen.
Fazit
Ich komme zu dem Schluss, dass WireGuard bisher noch nicht bereit ist.
Es wurde als leichtgewichtiges und schnelles Lösungsangebot für einige bestehende Probleme konzipiert. Leider hat es viele Funktionen geopfert, die für die meisten Benutzer relevant sein würden. Aus diesem Grund kann es IPsec oder OpenVPN nicht ersetzen.
Damit WireGuard wettbewerbsfähig bleibt, muss es zumindest eine IP-Adresseneinstellung sowie eine Konfiguration für Routing und DNS hinzufügen. Offensichtlich sind dafür verschlüsselte Kanäle erforderlich.
Sicherheit hat für mich oberste Priorität, und ich habe derzeit keine Anzeichen dafür, dass IKE oder TLS irgendwie kompromittiert oder beschädigt sind. Beide unterstützen moderne Verschlüsselung und wurden über Jahrzehnte hinweg getestet. Nur weil etwas neuer ist, bedeutet das nicht, dass es automatisch besser ist.
Die funktionale Kompatibilität ist von entscheidender Bedeutung, wenn Sie sich mit Dritten verbinden, deren Stationen Sie nicht kontrollieren. IPsec ist de facto der Standard und wird praktisch überall unterstützt. Und es funktioniert. Auch wenn es theoretisch aussieht, könnte WireGuard in Zukunft sogar mit verschiedenen Versionen seiner selbst inkompatibel sein.
Jeder kryptografische Schutz wird irgendwann geknackt und muss entsprechend ersetzt oder aktualisiert werden.
Das Leugnen all dieser Fakten und der blinde Wunsch, WireGuard zu verwenden, um Ihr iPhone mit Ihrer Heimbürostation zu verbinden, ist einfach ein Meisterkurs im Kopf-in-den-Sand-stecken.
Quelle: habr.com
