Der IT-Sicherheitsblog

Am 25. Novmber 2009 stellte John L. Young von cryptome eine Anfrage nach dem “Fredom of Information Act” der USA an die National Security Agency (NSA) bezüglich „… all documents pertaining to a letter written by Joseph A Meyer to the IEEE in August 1977 concerning possible ITAR violations of cryptographic research exported to countries outside the United States unless by export license.” (“… alle Dokumente, die sich auf den Brief von Joseph A. Meyer an das IEEE im August 1977 beziehen, in dem es um mögliche ITAR-Verletzungen von kryptographischer Forschung geht, die in Länder außerhalb der Vereinigten Staaten exportiert wird, sofern keine Exportlizenz vorliegt.“) Dieser Brief wurde geschrieben, da das IEEE 1977 ein Symposium zum Thema Verschlüsslung plante. Es sollte erreicht werden, dass die wissenschaftlichen Veröffentlichungen vorab durch die NSA zu genehmigen seien. Dies wurde als Bedrohung der Wissenschaftler angesehen und die Journalistin Deborah Shapley veröffentlcihte dazu einen Artikel im „Science“.

Als Antwort erhielt er mit Datum 26. April 2021 ein Dokument „NSA comes out of the closet: The Debate over public Cryptography in the Imman Era” aus dem September 1991, das im Cryptologic Quartely, Spring 1996 erschien. Cryptoligc Quartely ist eine interne “Zeitschrift” der NSA, aus der einige Artikel online verfügbar sind. Der jetzt an J.L. Young herausgegebene Artikel ist als „Top Secret Umbra“, der höchsten Geheimhaltungsstufe der USA, klassifiziert. In dem Dokument sind immer noch etliche Stellen aus Gründen der nationalen Sicherheit geschwärzt.

Im Wesentlichen geht es in dem Dokument um die Tatsache, dass in den späten 70er Jahren des vergangenen Jahrhunderts die freie wissenschaftliche Forschung begann, sich mit Kryptographie zu beschäftigen und damit das Monopol der NSA auf das Krypto-Know-How in den USA in Farge zu stellen. Die NSA versuchte dies zu verhindern und dieser Prozess wird in dem Dokument beschrieben.

So ganz nebenbei erfährt man einige Details zu Verschlüsselungsentwicklung. Dr. Ruth Davis, Leiterin des Instituts for Computers Sciences and Technology am National Büro of Standards (NBS) versucht ab 1968 die IT-Sicherheit voranzubringen und forderte von der NSA ein Verschlüsslungssystem für Regierungsbehörden, um vertrauliche Daten austauschen zu können. Dies führte letztendlich zur Entwicklung des DES-Algorithmus.

Da IBM für die Lloyds Bank of London 1971 den Lucifer Algorithmus entwickelt hatte und noch an der Weiterentwicklung arbeitete, kontaktierte die NSA Walter Tuchman bei IBM, der Lucifer zu DSD-1 verbessert hatte. Das war die Basis für die DES Entwicklung. Die NSA versprach eine „sichere Version von DSD-1“ zu evaluieren und ihn für alle Angriffe bis auf Brute Force abzusichern. Dabei wurde IBM vorgeschlagen die Schlüssellänge von 64 Bit auf 48 Bit zu reduzieren. Letztendlich einige man sich auf 56 Bit Schlüssellänge, 16 Runden und auf „sichere S-Boxen“. Leider sind einige Design-Entscheidungen geschwärzt. Da gibt es also noch unbekannte spannende Informationen.

Die kritische öffentliche Diskussion über die Sicherheit und eventuelle Hintertüren von DES, angeführt von dem Wissenschaftler Martin Hellman und dem Journalisten David Kahn, wird auch dargestellt.

Die NSA wurde dann wohl 1976 völlig überrascht von der Veröffentlichung des Papers „New Directions in Cryptography“ von Witfield Diffie und Martin Hellman. Der Kommentar dazu „This first public work on the topic of public-key cryptography was supported by NSF funds and discovered results that were both known and classified by NSA” („Diese erste öffentliche Arbeit zum Thema Public-Key-Kryptographie wurde mit Mitteln der NSF unterstützt und brachte Ergebnisse, die sowohl bekannt als auch von der NSA als geheim eingestuft waren.”)

Im April 1977 erschien dann das berühmte RSA-Paper von Ronald Rivest, Adi Shamir und Leonard Adleman. Der Kommentar aus dem Dokument: „The research was supported by grants from NSF and the Office of Naval Research (ONR), and it duplicated NSA research results obtained more than five years earlier. NSA did not receive any indications that this research was occurring until May 1976 when it received a copy of the published paper.” („Das Forschungsprojekt wurde durch Mittel der NSF und des Office of Naval Research (ONR) unterstützt und duplizierte Forschungsergebnisse der NSA, die mehr als fünf Jahre zuvor erzielt worden waren. Die NSA hatte bis Mai 1976 keine Hinweise darauf, dass diese Forschung durchgeführt wurde, bis sie eine Kopie der veröffentlichten Arbeit erhielt.“).

Dass eine Regierungsbehörde die National Science Foundation (NSF) kryptographische Forschung förderte, die die NSA gerne geheim gehalten hätte, das wollte die NSA verhindern. Zum Glück gelang das nicht. Die Versuche der NSA die Kontrolle über die Vergabe von Forschungsmitteln zur Krypto-Forschung zu erlangen, Export-Vorschriften für Kriegswaffen und sogar das Patentrecht für die Zwecke freie Krypto-Forschung zu verhindern einzusetzen, sind jetzt gut dokumentiert.

Es ist schon lange bekannt, dass Philip Zimmerman wegen Pretty Good Privacy Probleme mit amerikanischem Kriegswaffenexport hatte.

Insgesamt ist das Dokument ein wichtiger Einblick in die Krypto-Geschichte. Einige kleine Informationen zur DES-Entwicklung und zur Public-Key-Kryptographie sind auch enthalten und zeigen, dass das Krypto-Know-How der NSA der freien Forschung voraus ist.

Ein Hintergrundartikel aus der Perspektive der Wissenschaft erschein 2014 im Stanford Magazin.

Einhörner haben bekannter Weise magische Fähigkeiten und die werden auch gebraucht, um die Forderungen der Europäischen Union aus der Entschließung des Rates zur Verschlüsselung "Sicherheit durch Verschlüsselung und Sicherheit trotz Verschlüsselung" umzusetzen.

Die widersprüchliche Forderung aus dem Titel des Papiers verwenden das Wort Sicherheit in einer nicht synonymen Art. Das erste "Sicherheit" ist als Informations- und IT-Sicherheit gemeint. Wir schützen unsere Daten und Systeme durch Verschlüsselung. Das zweite "Sicherheit" ist im Sinne öffentlicher Sicherheit und Schutz vor Kriminalität gemeint. Dass "Terrorismus, organisierte Kriminalität, sexueller Missbrauch von Kindern" und andere schwere Cyberkriminalität zu bekämpfen ist, findet unser aller Zustimmung.

Nur die Vorstellung der Politiker man könne in die Verschlüsselung eine Art von Magie einbauen, so dass die Bösen durch die Verschlüsslung abgehalten werden, die Guten aber für einen rechtmäßigen, transparenten, notwendigen und verhältnismäßigen Zugang durch die Verschlüsselung nicht aufgehalten werden, das funktioniert nicht. Solche Lösungen können nur Einhörner finden und die gibt es ja bekannter Weise nicht.

Eine bekannte Lösung für eine (halb)staatliche Hintertür sind die TSA-Schlösser an unserem Gepäck. Nur die Berechtigten im Bereich der Sicherheitskontrollen an Flughäfen haben die erforderlichen Schlüssel. Und damit ist kein Missbrauch möglich. Dumm nur, das ein Foto der Schlüssel im November 2014 in der Washington Post in dem Artikel „The secret life of baggage: Where does your luggage go at the airport?” und damit im Internet erschienen ist, Dadurch existieren jetzt 3D-Druckvorlagen, die es jedem erlauben TSA-Schlüssel zu drucken. Details in meinem Kurzvortrag auf der 25. Konferenz "Sicherheit in vernetzten Systemen" des DFN-CERT.

Sicherlich wird die ETSI jetzt ihren kaputten Standard Enterprise Transport Security (ETS), als unsichere Alternative zu TLS 1.3, wieder ins Spiel bringen. Der ursprünglich mal eTLS genannte Standard hat sogar offiziell eine Schwachstellenummer: CVE 2019-9191. Dieser Standard bietet aber keine Lösung für das Problem, sondern entfernt lediglich Perfect Forward Secrecy aus dem TLS 1.3.

Die Frage ist nicht, ob eine Hintertür missbraucht wird, sondern nur wann eine Hintertür missbraucht wird!

Wir haben uns daran gewöhnt, Web-Seiten über verschlüsselte https-Verbindungen aufzurufen, damit niemand mitlesen kann. Bei dieser Verschlüsslung gibt es unterschiedliche Versionen: TLSv1.0, TLS 1.1, TLS 1.2 und TLS 1.3, die auch unterschiedlich sicher sind. Wegen der teilwiese massiven Unsicherheiten in den veralteten Protokollen (TLSv1.0 ist 20 Jahre alt) werden die führenden Browserhersteller die Unterstützung von TLS 1.0 und 1.1 ab etwa März 2020 abschalten. Web-Seiten, die dann kein TLS 1.2 anbieten, können dann nicht mehr mit aktuellen Browsern abgerufen werden.

Microsoft unterstützt im Rahmen des Angebots Office 365 bereits seit dem 31.10.2018 die Protokolle TLS 1.0 und TLS 1.1 nicht mehr. Der Standard der Kreditkarten-Industrie PCI DSS verbietet seit dem 20.6.2018 die Verwendung von TLS 1.0.

Die Zeitpläne der Browserhersteller zur Deaktivierung von TLS 1.0 und TLS 1.! sind wie folgt:

• Google: ab Chrome 81 (ca. März 2020)
• Mozilla: Firefox ab März 2020
• Apple: Safari ab März 2020
• Microsoft: IE 11 und Edge in der ersten Hälfte 2020

Aus Sicherheitsgründen ist der Einsatz veralteter Browser, um weiterhin TLS 1.0 und 1.1 nutzen zu können, daher nicht sinnvoll.

Wenn Sie also ab März 2020 feststellen, dass Web-Seiten nach einem Browser-Update nicht abrufbar sind, verwenden diese doch noch die alten Verschlüsselungsverfahren. Das kann nur der Anbieter der Web-Seite beheben. Bei einem Webservern im Unternehmen (ein aktueller Apache bzw. Microsoft IIS oder vergleichbarer Server) ist eine entsprechende Konfiguration problemlos möglich. Kritisch werden jedoch unter Umständen ältere proprietäre Systeme, wie Workflow-Systeme, Zeiterfassungs-Systeme, sog. embedded Web-Server in Geräten wie Firewalls, Router, Switches, Telefonanlagen, Gebäudeleittechnik etc., da hier Abhängigkeiten von der jeweiligen Firmware existieren. Hier gibt es erfahrungsgemäß noch viele Server, die noch kein TLS 1.2 oder besser unterstützen.

Dies gilt auch im Privatbereich. Wenn Sie z.B. auf die Web-Oberfläche Ihrer Heizungssteuerung oder Ihres älteren DSL, bzw. Kabel-Router ab März nicht mehr zugreifen können, liegt es wahrscheinlich an diesem Problem. Da müssen Sie sich dann mit dem Hersteller der Steuerung in Verbindung setzen, da nur er in der Lage ist das Problem zu beheben.

Soweit die erforderliche Konfiguration bei einem oder mehreren Geräten nicht möglich ist, wird der Zugriff über einen reverse Proxy empfohlen. Dabei ist darauf zu achten, dass das Netzwerksegment zwischen reverse Proxy und Web-Server geschützt ist. Bei einem entsprechenden hohen Schutz des Netzes zwischen reverse Proxy und Web-Server kann u.U. in diesem Segment auf Verschlüsselung verzichtet werden.

Bezüglich der konkreten Konfiguration für die Webserver Apache, lighttpd, nginx, Cherokee und MS IIS wird auf die Anleitung „Applied Crypto Hardening: bettercrypto.org“ oder die Empfehlungen von Mozilla "Security/Server Side TLS" verwiesen. Die Mozilla-Seite verlinkt auch einen Konfigurationsgenerator.

Sobald Anmeldungen mit Benutzername und Passwort über verschlüsselte https-Verbindungen laufen oder auf personenbezogene Daten zugegriffen wird, muss nach Art. 32 DSGVO bei den technischen Maßnahmen der Stand der Technik eingehalten werden, d.h. midestens der Level „Intermediate“ der Mozilla-Empfehlung. Dies gilt auch für Web-Angebote bei denen personenbezogene Daten, z.B. in Kontaktformulare oder Registrierungen, eingeben werden. Bei unkritischen Informationsangeboten kann auch noch übergangsweise nach einer Risikobetrachtung der Level „Old“ genutzt werden, um ältere Geräte nicht auszuschließen.

Spiegel Online und Golem.de berichten heute (16.12.19) über ein als VS-NfD (Verschlusssache – Nur für den Dienstgebrauch; die niedrigste behördliche Geheimhaltungsstufe in Deutschland) eingestuftes Sicherheitsaudit der veralteten Software TrueCrypt. Es wird sich ein bisschen echauffiert, dass niemand von diesem Audit wusste. Dabei war die Existenz des Audits bekannt, es wurde nämlich schon im Juni 2014 in einer Pressemeldung der Fa. Sirrix AG (2015 von Rhode und Schwarz aufgekauft) erwähnt. Leider sind die Web-Seiten der Sirrix AG nicht mehr verfügbar. Der Autor ist sich aber sicher, dass dort auch die Einstufung des Audits-Reports als VS-NfD erwähnt wurde.

Die Sirrix AG hatte gemeinsam mit der escrypt GmbH im Auftrag des Bundesamtes für Sicherheit in der Informationstechnik (BSI) TrueCrypt einem umfassenden Audit unterzogen. Der Hintergrund des Audits war die Entwicklung der Software TrustedDisk Enterprise. Noch heute im Kaufhaus des Bundes für Behördenbeschäftigte verfügbar. TrustedDisk basiert wohl auf dem Code von TrueCrypt und ist eine deutlich aufgebohrte Lösung mit zusätzlichen Funktionen. TrustedDisk ist seit 2013 für Dokumente der untersten Vertraulichkeitsstufe VS-NfD (und entsprechend seit 2015 für RESTREINT UE / EU RESTRICTED sowie NATO RESTRICTED) unter Windows 7/8/10 zugelassen.

In der Pressemeldung wird auch – allerdings sehr abstrakt – auf die gefundenen Schwachstellen eingegangen. „Die im Audit gesammelten Erkenntnisse sind in die neue Verschlüsselungssoftware eingeflossen und haben die bisherige TrueCrypt-Sicherheits-Architektur und -Implementierung deutlich verbessert. Hierzu gehören beispielsweise ein verbesserter Bootloader, die Zufallszahlenerzeugung oder der Schutz des Schlüsselmaterials.“ Mit der neuen Verschlüsselungssoftware ist TrustedDisk gemeint.

Anlass der Pressemeldung von 2014 war die (bis heute nicht erfüllte) Ankündigung eine OpenSource Version von TrustedDisk als TrueCrypt-Nachfolger zu entwickeln und zur Verfügung zu stellen. Die Probleme liegen in der sehr eigenwilligen Lizenz von TrueCrypt, die nicht als freie Lizenz angesehen wird.

Das mittlerweile der Audit-Report bei FragDenStaat veröffentlicht wurde, ist natürlich zu begrüßen. Insbesondere VeraCrypt als legitimer TrueCrypt-Nachfolger hat schon und wird auch weiter davon profitieren, indem vorhandene Sicherheitslücken geschlossen wurden und werden.

Mittlerweile (18.12.) hat Golem.de diesen Blogeintrag aufgegriffen und den Sachverhalt entsprechend dargestellt.

Warum werden E-Mails eigentlich nicht verschlüsselt? Alles was man braucht ist ein E-Mail-Programm, das die Verschlüsselung der E-Mail unterstützt. Die wichtigsten E-Mail-Programme unterstützen dies mittlerweile out-of-the-box. Zumindest wenn es um S/Mime geht. An der fehlenden Software kann das also nicht liegen. Der wahre Grund ist das Schlüsselmanagement. Bei S/Mime (oder genauer bei den X.509 Zertifikaten) ist die Schlüsselverwaltung streng hierarchisch organisiert. Bei OpenPGP gibt es das berühmte Web-of-Trust.

Letzteres ist schwer zu verstehen. Selbst Fachzeitungen schreiben von vertrauenswürdigen Schlüsseln. Ein Schlüssel ist gültig oder ungültig (validity). Nur der Inhaber eines Schlüssels kann vertrauenswürdig sein (Owner trust). Eine Unterschrift unter einem Schlüssel mit dem Schlüssel eines vertrauenswürdigen Inhabers akzeptiere ich (Im Grunde sind die Bestätigungen Zertifikate). Nur dem Inhaber eines gültigen Schlüssels kann ich auch das Vertrauen aussprechen.

Aber auch in der vermeintlich einfachen X.509-Welt gibt es Probleme im Umgang mit den Schlüsseln. So gibt es unter Windows bis mehrere Speicherorte für Zertifikate (Certificate Stores): Microsoft, Mozilla und Oracle/Java. Der Nutzer muss diese – falls erforderlich – synchron halten. Zusätzlich kann (muss?) man die Zertifikate seiner Kommunikationspartner im Outlook-Adressbuch speichern.

Hier verliert man gerne mal die Übersicht welches Zertifikat wo ist. Zusätzlich müssen öffentlicher und privater Schlüssel auch noch auf das Smartphone kopiert werden. Und spätestens wenn das Windows mal nicht mehr so richtig will (Stichwort Software-Verrottung), und man Windows neu installiert, ist der private Schlüssel weg, da man das Backup des Schlüssels vergessen hat.

Moderne E-Mail-Provider versuchen das Schlüsselmanagement vor dem Anwender zu verbergen. Sie speichern auch den privaten Schlüssel des Kunden mehr oder weniger geschützt und stellen so die Verfügbarkeit sicher. Lavabit, der E-Mail-Provider dem Edward Snowden (fälschlicherweise?) vertraute, wusste sich gegen einen National Security Letter nur durch die Einstellung des Geschäftsbetriebs zu retten. 1 und 1 mit den Marken web.de und GMX versucht in einer geschlossen Nutzergruppe (d.h. nur für Kunden) ein OpenPGP-Schlüsselmanagement vor dem Anwender zu verbergen.

Wir sind hier schon ziemlich nah an der Quadratur des Kreises. Entweder der private Schlüssel ist durch eine Passphrase, die nur der Anwender kennt, geschützt. Ist die Passphrase weg, ist der Schlüssel weg. Oder der Provider kann dem Kunden jederzeit „helfen“, auf den privaten Schlüssel zuzugreifen. Dann kann der Provider aber auch jederzeit (!) an den privaten Schlüssel, also auch auf „Wunsch“ staatlicher Stellen.

Eine einfache, benutzerfreundliche und sichere Lösung für das Schlüsselmanagement gibt es noch nicht.

Da E-Mail-Verschlüsselung immer vor dem Hintergrund der zu schützenden Individualkommunikation gesehen wird, fehlen leider auch gute Konzepte für Vertretungsregeln. In Unternehmen und Behörden sind Vertretungsregeln unverzichtbar. OpenPGP wäre in der Lage mit seinen flexiblen Schlüsselformat so etwas abzubilden. X.509 kann das nur über mehrere Schlüssel abbilden. Aber wirklich angegangen ist das noch niemand.

Eine von PGP vor Jahren erfundene Lösung sind Verschlüsselungs-Proxies wie Symantec PGP Universal, Z1 SecureMail Gateway oder Ciphermail, um nur einige zu nennen. Sie verzichten auf Ende-zu-Ende-Verschlüsslung und übernehmen die Schlüsselverwaltung. Auch De-Mail ist im Grunde fast eine solche (allerdings staatliche) Gateway-Lösung.

Letztendlich haben aber alle Probleme bei der E-Mail-Verschlüsselung ihren Ursprung im Schlüsselmanagement. Nicht Verschlüsseln ist kompliziert, sondern der sichere Umgang mit den Schlüsseln.

Die Ankündigung, dass im April De-Mail um eine Ende-zu-Ende Verschlüsselung auf Basis von Mailvelope angereichert werden soll, ist sehr zurückhaltend aufgenommen worden. Bisher war eine wesentliche Kritik an De-Mail die fehlende Ende-Zu-Ende Verschlüsselung.

Was ist eigentlich der Unterschied zwischen einer TLS-Transport-Verschlüsselung und einer Ende-zu-Ende Verschlüsselung wie OpenPGP oder S/Mime?

Bei einer TLS-Transport-Verschlüsselung wird der Mail-Verkehr zwischen zwei Mail-Servern oder zwischen dem Mail-Klienten komplett verschlüsselt. Die einzelnen unverschlüsselten E-Mails werden – wie in einem Tunnel – geschützt übertragen. Ein Lauscher sieht nur noch, dass Mail-Server A mit Mail-Server B Daten austauscht. Er sieht nicht mehr, wer wem eine E-Mail schickt.

Auf den beteiligten Mailservern liegen die E-Mails unverschlüsselt und damit ist der Provider technisch in der Lage die E-Mails zu lesen (auch wenn er es rechtlich nicht darf). Deshalb propagierten Experten immer, dass „nur“ eine TLS-Transport-Verschlüsselung Blödsinn sei.

Die Abbildung zeigt eine unverschlüsselte und eine mit S/Mime verschlüsselte E-Mail (Die Header der E-Mail wurden stark verkürzt). In der verschlüsselten E-Mail sind Absender, Empfänger, Zeitpunkt und Betreff immer noch im Klartext zu lesen: nur der Mail-Body und eventuelle Anhänge werden verschlüsselt. Die berühmte Speicherung und Analyse der Meta-Daten durch die NSA ist auch bei der verschlüsselten E-Mail immer noch möglich ohne eine Verschlüsselung zu knacken.

Dies macht deutlich das wird beides dringend brauchen: die TLS-Transport-Verschlüsselung, damit die Header der Mail beim Transport zwischen den Mail-Servern verschlüsselt sind und die Ende-zu-Ende-Verschlüsslung, damit der Provider die Mail-Inhalte nicht lesen kann.

In diesem Zusammenhang ist es auch wichtig, dass wir in unserem Mail-Klienten (Outlook, Thunderbird oder wie immer er heißt) die Verschlüsslung für SMTP und POP3 oder IMAP aktivieren.

Die Einführung der TLS-Transport-Verschlüsslung durch Projekte wie De-Mail und „E-Mail made in Germany“ ist zu begrüßen. Aber OpenPGP und S/Mime sind auch unverzichtbar. Erst im Zusammenspiel beider Mechanismen wird ein vernünftiges Gesamtpaket daraus.

Die sog. Freak Sicherheitslücke hat die Aufmerksamkeit auf die Verwendung der sog. Cipher Suiten bei verschlüsselten Verbindungen gelegt.

Bei dem Aufbau einer verschlüsselten Verbindung müssen zwichen Klient und Server die verwendeten Verschlüsselungsverfahren ausgehandelt werden. Dabei haben der Server und der Klient jewiels eine Liste der von ihnen unterstützen Verschlüsselungsverfahren. Der Klient macht eine Vorschlag und der Server akzeptiert diesen Vorschlag oder sagt "beherrsche ich nicht, wir müssen was anderes nehmen". Können die beiden sich nicht auf eine Cipher Suite einigen, kommt keine Verbindung zu Stande.

Es müssen das Protokoll (SSL, TLS) und vier Algorithmen vereinbart werden:

• das Schlüsselaustauschverfahren (RSA, DH)
• das Authentifizierungsverfahren (RSA, DSA, ECDSA)
• das Verschlüsselungsalgorthmus inkl. Schlüssellänge (keine, RC4, DES, 3DES, IDEA, AES
• die verwendete Hashfunktion (MD5, SHA1, SHA2)

Aus den fünf Angaben setzt sich dann der Name der Cipher Suite zusammen, z.B. DHE-DSS-AES256-SHA256 (OpenSSL-Name) oder TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (IANA Name). Dies sind die für den Menschen lesbare Form. Intern werden die Cipher Suiten durch Codezahlen (0x00,0x6A) dargestellt.

Die Grundidee der Attacke ist es, in diesen Verbindungsaufbau so einzugreifen, dass sich beide Partner auf eine schwache Cipher Suite einigen, so dass die Entschlüsselung dann "einfacher" geknackt werden kann. Nicht alle Server und Klienten sind angreifbar. Unter Windowssystemen sind alle Anwendungen, die auf die schannel.dll Verschlüsselungsbibliothek zurückgreifen angreifbar. Darüber hinaus sind Chrome, Safari und andere Browser angreifbar.

Eine Liste der angreifbaren Server der Top Million Server des Alexa Rankings ist hier verfügbar. Ingesamt sind 9,5% (am 7.3.) der Top Million Server verwundbar (am 3.3. waren es noch 12,2%).

Aber was muss ein Administrator tun, um seinen Server so zu konfigurieren, damit nur sichere Cipher Suiten verwendet werden? Die derzeit beste verfügabre Anleitung ist ein umfangreiches PDF-Doukment "Applied Crypto Hardening" von bettercrypto.org. Erfahrene Praktiker aus eropäischen Certs und Hochschulen haben für die gängisten Webserver (Apache, lighttpd, nginx und MS IIS) die sichere Konfiguration der Cipher Suiten beschrieben. Alle Besipiele können direkt per Copy & Paste übernommen werden. Darüber hinaus wird die Krypto-Konfiguration von SSH, Mail Serverv, VPNs, PGP, Instant Messaging Systemen Datenbanken und anderen Systemen beschrieben.

Obwohl das Dokument ncoh den Status "draft" hat, gibt es derzeit wohl keine bessere Anleitung.

Wer jetzt seine eigenen SSL/TLS fähigen Server überprüfen möchte, dem sei der Kommandozeilen SSL-Scanner SSLyze ans Herz gelegt. Das in Python geschriebene Programm ist für Windows, OS X und Linux verfügbar.

Nachtrag vom 21.3.2015: Dieser Beitrag wird in der Datenschutz Newsbox 3/2015 verwendet

In den Verfassungen aller demokratischer Staaten ist die Unverletzlichkeit des Kommunikationsgeheimnisses festgeschrieben (in Deutschland z.B. konkret als Brief-, Post und Fernmeldegeheimnis). Es werden dann noch Feinheiten unterschieden, ob das Kommunikationsgeheimnis für alle Menschen (z.B. in Deutschland) oder nur für die eigenen Bürger (z.B. in den USA) gilt.

In der „guten alten Zeit“ waren dies organisatorische Regeln. Der Staat garantierte das Kommunikationsgeheimnis durch Gesetze, konnte es aber selber jederzeit durchbrechen. Als die Post in Deutschland noch als staatliches Unternehmen die komplette Kommunikation abwickelte, war das unproblematisch: der Beamte der Sicherheitsbehörde ging zu dem Beamten des Kommunikationsunternehmens und gut war's. Die Kommunikationsüberwachung fand innerhalb von oder zwischen Behörden statt.

Mit dem Aufkommen von guter Verschlüsselung (z.B. Pretty Good Privacy, Encryption for the Masses) konnte endlich ein Bürger seine Kommunikation mit eigenen technischen Mittel schützen und er war nicht mehr auf die organisatorischen Regeln des Staates angewiesen. Und plötzlich waren sich Regierungen dieser Welt einig, so was das aber nicht gemeint mit dem Kommunikationsgeheimnis. Die Krypto-Debatte war geboren. Unter Innenminister Kanther war die erste große Runde in Deutschland. David Cameron hat im Januar 2014 die derzeit letzte Runde in Europa eröffnet.

Die heute verfügbaren Krypto-Algorithmen sind so gut, dass auch potente Dienste wie die NSA diese nicht ohne weiteres brechen können. Deshalb müssen die Dienste ausweichen. Wenn die Schlüssel bekannt sind, muss man die Algorithmen nicht knacken. Wie kommt man an den Schlüssel? Man „bittet“ jemanden, der ihn hat, ihn herauszugeben. Man sorgt dafür, dass nur Schlüssel generiert werden, die man kennt (d.h. man beeinflusst die Generierung der Zufallszahlen, aus denen die Schlüssel erzeugt werden). Man nimmt sich die Schlüssel einfach bei jemanden, der sie hat.

Gerade auch letzteres wird, wie wir heute wieder lernen mussten, intensiv gemacht. Ob eine Firma wie RSA, die geheimen Schlüssel aller Einmal-Passwort-Token (SecureID) speichert (Warum eigentlich?) oder ob man bei Chip(karten)-Herstellern einbricht, um sich die Schlüssel zu nehmen, wird letztendlich dann glücklicherweise doch bekannt.

Wir brauchen deutlich mehr asymmetrische Verschlüsselung mit dezentraler Erzeugung der Schlüsselpaare, so dass man die geheimen Schlüssel nicht gesammelt an einer Stelle abgreifen kann. Insofern ist der neue Personalausweis (nPA) ein guter Schritt. Er wird ohne Schlüsselpaar ausgeliefert und das Schlüsselpaar wird erst bei mir erstellt. Aber die Zertifizierer zieren sich noch das Verfahren zu unterstützen. Nur die Bundesdruckerei macht einen vorsichtigen Pilot-Test (sign-me).