Privacy Handbuch

Einleitung…
Surfen… E-Mail (allgm) E-Mail (crypt) Chatten…
Tor… VPN… DNS…
Daten schützen PC/Laptop OS Smartphones
Kontakt Druckversion

Für Diskussionen zum Thema gibt es den [matrix] Raum #prhdb-diskussion:nitro.chat.

Öfters enthalten die Nachrichten via Webformular keinen Absender und es ist bedauerlich, dass man nicht antworten kann. Die Antworten gibt es dann evtl. hier (oder auch nicht).

09.04.2024  
16.02.2024  
15.02.2024  
18.01.2024  
05.01.2024  
22.12.2023 

27.11.2023  Tipps zum Umgang mit Offensive Security Tools beim Testen von Webservern:

26.11.2023 
12.11.2023 
08.11.2023 
18.05.2023 

Nachtrag (14.11.2023): Jemand hat sich die Mühe gemacht, sich durch den Sourcecode gearbeitet und sich die Krypto von Ginlo mal ein bisschen genauer angeschaut. Das Ergebnis ist: veraltet und buggy. Nix mit toller Sicherheit und weit entfernt von Signal & Co.

28.02.2023 
28.02.2023 
23.10.2022 
10.10.2022 
22.03.2022
01.11.2021

05.08.2021 

Ein hohes Tier bei den US-Amerikanern hat eine häßliche E-Mail mit Todesdrohung bekommen, die von Protonmail versendet wurde. Die US-amerikanischen Ermittlungs­behörden haben sich an die Schweizer Kollegen gewand, die dann bei Protonmail nachgefragt haben und die IP-Adresse des Absenders bekamen. Damit konnen die US-Behörden den Täter ermitteln - NEIN! GANZ SCHLIMM!

Also mal in Ruhe:

  1. Protonmail ist als Schweizer Unternehmen zur Kooperation mit Schweizer Behörden bei der Verfolgung von Straftaten verpflichtet. Wenn die US-Amerikaner sich an die Schweizer Behörden wegen Amtshilfe wenden und dieses Ersuchen akzeptiert wird… - … ok.

  2. Protonmail wirb mit hohen Privacystandards und es hätten auch in diesem Fall die Möglichkeiten für den Kriminellen zur Verfügung gestanden, anonym zu bleiben.

    Protonmail bietet einen Onion Service… hätte man nur nutzen müssen. Ich hätte vielleicht TAILS verwendet, wenn man damit rechnen muss, dass man sich mit dem FBI anlegt.

    (Weitere Hinweise siehe: anonyme E-Mails).

Aus meiner Sicht hat der Täter unzureichende Sicherheits­vorkehrungen getroffen, die sich nicht an seiner konkreten Bedrohung orientierten. Das ist aus meiner Sicht nicht Protonmail anzulasten.

Die besonderen Sicherheitsfeatures von Protonmail wie die einfache Verschlüsselung von E-Mails und verschlüsselte Speicherung spielten in dem Fall keine Rolle und sind nicht kompromittiert.

16.03.2021 
03.01.2021 
03.01.2021 
31.12.2020
08.05.2020: Warnung vor den Mailinglisten bei Posteo 

Vor einigen Jahren hat Posteo.de Mailinglisten im Beta Test eingeführt. Das Projekt ist schein­bar eingeschlafen und wurde nicht zur Produktionsreife weiterentwickelt.

Ich habe gehört, dass es einige Kunden bei Posteo gibt, die diesen Mailinglisten Testbetrieb im Beta Status heute noch aktiv nutzen, da er offiziell nie abgeschaltet wurde.

Warnung: Das Projekt scheint tot zu sein und der zugehörige Server wird scheinbar seit längerem nicht mehr gepflegt:
  1. Das SSL Zertifikat des Mailservers lür die Mailinglisten ist seit 1,5 Jahren abgelaufen. Das führt dazu, das die Kommunikation mit anderen Mailservern nicht besonders sicher TLS-verschlüsselt und TLSA/DANE verifiziert erfolgt (Posteos Werbung) sondern komplett unverschlüsselt, wie eine Testmail zeigt: Received: from mout-102.mailbox.org (mout-102.mailbox.org [80.241.56.152])
       by mx02.posteo.de (Postfix) with ESMTPS for ...@lists.posteo.de>;     Posteo verfügt über ein aktuelles SSL Zertifikat für alle MX Mailserver, dass auch für den Mailinglisten Server gültig wäre. Das es nicht installiert wurde deutet auf Schlampigkeit hin und zeigt, dass der Server nicht im Monitoring überwacht wird.
  2. Die TLS Cipher des Mailserver für die Listen sind auf dem Stand, der hier bereits vor 3,5 Jahren kritisiert wurde (Score "F" beim Cryptcheck). Es werden RC4-Cipher mit MD5 verwendet, die es in aktuellen OpenSSL Versionen nicht mehr gibt:
    Posteo TLS Mailinglisten
    Die regulären Mailserver von Posteo sind inzwischen auf dem aktuellen Level. (Score: "A" - hey, geht doch). Warum der Server für die Listen vergessen wurde, ist unklar.
  3. Die Software des Servers ist veraltetet und grob geschätzt seit mindestens drei Jahren nicht aktualisiert worden, was unprofessionell und ein Sicherheitsrisiko ist.
Es wird Zeit, über Alternativen nachzudenken, falls jemand diese Mailinglisten verwendet.

25.04.2020
08.05.2019
15.03.2019
09.01.2019 
08.01.2019 
30.12.2018
05.08.2018
05.08.2018
02.06.2018 MAT funktioniert nicht mehr. 

31.05.2018 Post von den Anwälten von Posteo.de 

Vor einigen Wochen hat sich Rundfunkmedienanstalt bei mir gemeldet und mich unter Androhung von 10.000 € Strafe aufgefordert, ein Impressum zu veröffentlichen.

Meiner Meinung nach fällt das Privacy-Handbuch weder unter RStV noch unter TMG §5, da es kein journalistisches Projekt ist und keine kommerziellen Interessen verfolgt. Ich wollte mich mit der Rundfunkmedienanstalt aber nicht streiten und war außerdem neugierig, was dahinter steckt. Ich bin mir absolut sicher, dass die Popularität dieser Webseite nicht so groß ist, dass die Rundfunkmedienanstalt von selbst darauf gekommen wäre. Und ich hatte den Verdacht, dass da noch mehr kommt.

Dieser Verdacht hat sich jetzt bestätigt:

Posteo e.K. hat ein Rechtsanwaltsbüro damit beauftragt, die hier geäußerte Kritik an dem Dienst posteo.de via Take-Down Notiz aus dem Netz entfernen zu lassen.

Die beauftragten Rechtsanwälte fahren schwere Geschütze auf. Im Kern wird der Vorwurf der Rechtswidrigkeit damit begründet, dass ich für die Heinlein Support GmbH arbeiten würde und dass ich deshalb Posteo.de als Mitbewerber der Heinlein Support GmbH nicht kritisieren darf, auch nicht als Privatperson in einem privaten Projekt, das in keinerlei Bezug zur Heinlein Support GmbH steht. Das wäre ein Verstoß gegen §3 Abs. 1 UWG.

Die Anwälte haben sich nicht mit mir in Verbindung gesetzt (trotz Impressum!), sondern von dem Hosting Provider die sofortige Entfernung der Inhalte gefordert ("Take-Down-Notiz") und mit Störerhaftung gedroht, wenn der Provider der Aufforderung nicht umgehend nachkommen sollte. Das Impressum diente in dem anwaltlichen Schreiben nur als Beweis für die Behauptung, dass der Autor für die Heinlein Support GmbH arbeiten würde.

Der Hosting Provider hat mich um eine Stellungnahme zum dem Schreiben gebeten, das ich hier veröffentlichen (gekürzt):

Sehr geehrte Damen und Herren,

im Gegensatz zu der von Posteo e.K. aufgestellten Behauptung arbeite ich nicht mehr für Heinlein Support GmbH sondern bin zur Zeit als Berater für Netzwersicherheit bei der secunet Security Networks AG tätig.

Ich kann ihnen versichern, dass die secunet Security Networks AG nicht im Wettbewerb mit Posteo e.K. steht und eine Rechtswidrigkeit nach UWG damit nicht konstruiert werden kann.

Ich werde in den nächsten Tage einige flappsige Formulierungen entfernen und meine Kritik an Posteo.de und anderen Kommunikationsdiensten sachlicher formulieren.

Da das Impressum meiner Webseite die ladungsfähige Anschrift des inhaltlich Verantwortlichen enthält, der für rechtswidrige Inhalte direkt zur Verantwortung gezogen werden könnte, gehe ich davon aus, dass der Vorgang damit für Sie erledigt ist.

Mit freundlichen Grüßen

A: Ein Hinweis an die Anwälte von Posteo e.K.:

Die Störerhaftung für den Provider greift nicht, wenn der Verursacher bekannt ist und juristisch zur Verantwortung gezogen werden kann. Ist Ihnen sicher bekannt - oder?

Zur Klärung der Rechtswidrigkeit der hier veröffentlichter Inhalte können Sie sich an mich wenden. Meine ladungsfähige Anschrift finden Sie Impressum, wie Ihnen bekannt ist.


B: In der fachlichen Argumentation folgt Posteo e.K. dem üblichen Muster:

In dem anwaltlichen Schreiben wird behauptet, dass Posteo e.K. die aktuellen Richtlinien für TLS-Verschlüsselung kennt und umsetzt (genannt werden: BSI TR 03116-4 inklusive Downgrade Optionen in BSI TR 02102-2, BSI TR 03108-1, IETF RFC 7525 und RFC 7435). Im Privacy Handbuch veröffentlichte gegenteilige Behauptungen wären rechtswidrig.

Wie sieht die Realität bezüglich der Umsetzung der Richtlinien aus? (Stand: heute)

  1. 1024 Bit DH-Parameter für den Diffie-Hellman-Schlüsseltausch sind seit Publikation von Logjam 2015 ein absolutes NO-GO.(Screenshot von Posteos POP3 Server 31.05.18).
    Posteo POP3 Cipher
    Die TLS Config des POP3 Servers ist nicht schwach sondern eine echte Sicherheits­lücke und steht im krassen Gegensatz zu ALLEN Empfehlungen von BSI, IETF, NIST... Ein potenter Angreifer wie die NSA kann die TLS Transport­verschlüsselung on-the-fly entschlüsseln und Login Namen sowie Passwörter extrahieren.
  2. Die Verwendung von TLS v1.0 und TLS v1.1 für Client-Server Verbindungen (Browser - Webserver, Mail Client - Mail Server) ist laut BSI TR 03116-4 und zulässiger Downgrade Optionen in BSI TR 02102-2 seit 1,5 Jahren nicht mehr erlaubt. Das gleiche gilt für SHA1 als Signaturalgorithmus für die Authentifizierung von Daten.

  3. Für den ECDHE Schlüsseltausch müssen Sichere E-Mail Provider nach BSI TR 03108-1 die Brainpoolkurven gegenüber den NIST-Kurven bevorzugen.

    Die Server von Posteo.de bieten für ECDHE keine Brainpoolkurven an, obwohl die dafür nötige Serversoftware prinzipiell zur Verfügung steht. (Vielleicht mal ein Upgrade durchführen?)

  4. In der leidigen Diskussion über RC4 Cipher verschweigt Posteo e.K. den RFC 7465 der IETF, der nichts anderes sagt, als das RC4 nicht mehr eingesetzt werden darf.
    TLS servers MUST NOT select an RC4 cipher suite when a TLS client sends such a cipher suite in the ClientHello message.

    If the TLS client only offers RC4 cipher suites, the TLS server MUST terminate the handshake. The TLS server MAY send the insufficient_security fatal alert...
    Das gilt auch für opportunistisches TLS, keine Ausnahmegenehmigung - nirgends. Für die Empfehlung der IETF gibt es Gründe, die J. Appelbaum bereits 2013 nannte:
    RC4 is broken in real time by #NSA - stop using it. (Nov. 2013)
    Inzwischen haben alle aktuellen Krypto-Bibliotheken gemäß Empfehlung der IETF die Unterstützung von RC4 Ciphersuiten entfernt oder zumindest standardmäßig deaktiviert. Wenn die Server von Posteo.de noch immer RC4 unterstützen, dann könnte das heißen, dass dort keine aktuellen Versionen der Krypto-Bibliotheken zum Einsatz kommen. (Was aber nicht bedeutet muss, dass die Software unsicher ist!) OpenSSL muss man beispielsweise mit folgender Option compilieren, um RC4 nutzen zu können: > ./configure ... --enable-weak-ssl-ciphers ...

Es steht Posteo e.K. frei, in Abwägung aller Randbedingungen eigene Ansichten zu entwickeln und umzusetzen. Dann müssen sie sich auch Kritik gefallen lassen und können nicht behaupten, sie würden alle aktuellen Empfehlungen von BSI / IETF umsetzen.


C: Noch eine Bemerkung in eigener Sache:

Das Privacy-Handbuch gibt es seit 2004. Disskussionen über Anonymisierungsdienste und E-Mail Provider waren stets Bestandteil. Aufgrund meiner Kompetenz habe ich zeitweise sowohl bei der JonDos GmbH gearbeitet als auch bei Heinlein Support GmbH.

Die berufliche Tätigkeit hat meiner Meinung nach den privaten Blick für die Realitäten nicht getrübt, wie man an meiner Einschätzung von JonDonym nachlesen kann. Ich sehe keinen Grund dafür, dass ich mich jetzt und in Zukunft nicht mehr über Mängel bei E-Mail Provider äußern darf, nur weil ich früher einmal für die Heinlein Support GmbH gearbeitet habe.

24.05.2018 Vergleich von #Efail und #Autocrypt für PGP  Hmmm ... beides gleichwertig - oder? Ein Angreifer vom Typ Mallory kann die E-Mail Verschlüsselung kompromittieren, indem er die E-Mail unterwegs modifiziert. Aber in dem einen Fall ist es ein gaaanz schlimmer Bug und im anderen Fall ein Komfort-Feature, das man euphemistisch mit Opportunistic Security nach RFC 7435 umschreibt.

Wer Autocrypt für PGP toll findet und aktiviert lässt, der braucht sich um Efail keine Sorgen zu machen, weil das Tor für einen Angreifer vom Typ Mallory bereits weit offen ist. 

Nachtrag: #Efail als Bug und Opportunistic Security nach RFC 7435 als Konzept (Autocrypt) senken die Sicherheit von OpenPGP bei der E-Mail Verschlüsselung in gleicher Weise. Die OpenPGP Verschlüsselung schützt dann nur noch gegen passive Angreifer vom Typ Eve aber nicht mehr gegen aktive Angreifer vom Typ Mallory.

Aber: es ist eine durchaus legitime Schlussfolgerung, wenn Autocrypt-Fans anerkennen, dass #Efail kein Problem für sie ist, da sie den Schutz gegen Angreifer vom Typ Mallory selbst aufgegeben haben. Aber Autocrypt gut finden und #Efail verdammen geht nicht.

Btw: es gibt auch Unterschiede zwischen #Efail und Autocrypt: Aber das sind Spitzfindigkeiten, die die qualitative Bewertung nicht ändern.

Um es abschließend noch einmal klar zu formulieren: Opportunistic Security nach RFC 7435 öffnet ein Tor für aktive Angreifer, das ist der Inhalt dieses Konzeptes! Ein bisschen mehr schwache Verschlüsselung gegen passive Angreifer bei gleichzeitigem Aufgeben des Schutzes gegen aktive Angreifer. Können wir die Diskussion damit abschließen?
01.04.2018: Beobachtungen zum Kommunkationsverhalten 

Seit wir von E-Mail Kontakt Adressen auf ein anonymes Kontaktformular gewechselt sind, haben sich die Nachrichten im Postfach verdoppelt. Außerdem ist der Ton flapsiger geworden.

Ähnliches habe ich schon früher bemerkt, aber jetzt habe ich zum ersten Mal einen direkten Vergleich und vergleichende Zahlen zu diesem Effekt.

Einige Absendern ist nicht klar, das Anonymität und Reputation antagonistische Widerspüche sind und fühlen sich beleidigt und abgewatscht, wenn wir Absender von Nachrichten ohne wiedererkennbare Absenderkennung (Ich vermeide bewusst "Name", Namen interessieren mich nicht!) als "anonyme Unbekannte" einstufen.

Wenn man uns nur kurz mitteilen möchte, dass es auf Seite xx im Handbuch einen Fehler gibt, dann ist das auch ohne wiedererkennbaren Absender ok, wird korrigiert - fertig. Wenn man aber eine Antwort haben möchte, dann sollte man auch eine Kontaktadresse angeben.

Einige Absender schreiben, wir könnten im Changelog antworten oder hier auf der Diskussionseite. Nein! Das Changelog ist für Changes, deshalb heißt es Changelog. Auf der Diskussionseite schreibe ich manchmal Dinge, die von allgemeinen Interessen sein könnten, aber ob ein allgm. Interesse vorliegt oder nicht, ist meine Entscheidung. Das klingt jetzt für einige Leser wahrscheinlich wieder etwas "abwatschend", aber hey - versucht es mal selbst mit einem anonymen Kontaktformular oder nutzt eure Fantasie, um euch die Situation als Empfänger anonymer Botschaften vorzustellen.
20.12.2017: Kommentar zum Autocrypt Schlüsseltausch für PGP 

Das Verfahren Autocrypt will dem Nutzer den manuellen PGP-Schlüsselaustausch abnehmen und ihn dadurch nutzerfreundlich machen. Der PGP-Schlüssel soll im Header jeder E-Mail mitgesendet werden, damit der Empfänger sofort automatisch verschlüsselt antworten kann, ohne sich um den Schlüsseltausch (und Validierung?) kümmern zu müssen.

Kurzer Kommentar (eine ausführlich Begründung vielleicht später, wenn ich mehr Zeit haben): Meine Schlussfolgerung: Man verbessert die Sicherheit von E-Mail nicht, indem man die Sicherheit vorhandener Lösung zugunsten einer (zweifelhaften) Verbesserung der Usability reduziert und eine Krücke anschraubt, die Angriffen ein Scheunentor öffnet. (Einen konkreten Angriff über einen kompromittierten E-Mail Provider beschreibe ich vielleicht später mal.)

Natürlich kann man das euphemistisch mit netten Umschreibungen verbinden, Autocrypt greift für die theoretisch Begründung auf das Konzept Opportunistic Security (RFC 7435) zurück. Opportunistic Security bietet aber nur Some Protection Most of the Time und das ist nicht kompatibel mit den Intentionen von PGP. Die Einführung dieses Konzeptes für PGP macht die Verschlüsselung kaputt und unbrauchbar für hohe Sicherheitsanforderungen ohne wirklich einen wesentlichen Beitrag zur Verbreitung von PGP zu leisten.

Opportunistic Security bedeutet, das die Verschlüsselung gegen passive Angreifer schützt aber nicht gegen aktive Angreifer, die sich als man-in-the-middle in die Kommunikation einschleichen könnten. Wenn jemand "Opportunistic Security" verspricht, dann meint er damit, dass die Verschlüsselung ganz gut funktioniert, solange sich niemand ernsthaft für die Kommunikation interessiert. Gegen einen ernsthaften Angriff bietet dieses Konzept keinen Schutz und man muss im Zweifel davon ausgehen, dass die Verschlüsselung gebrochen wird.

Die meisten E-Mail Nutzer haben aber noch nie etwas von "PiGheePih" gehört. Von denen, die etwas davon gehört haben, sind die meisten zu faul, die nötige Software zu installieren und wollen nicht über die Erstellung eines Schlüssels Nachdenken. Der verschwindend kleine Rest schafft es auch ohne Autocrypt, die Schlüssel zu tauschen. Nach meiner Erfahrung scheitert die Nutzung von PGP in der Regel nicht am Schlüsseltausch sondern weil der Gegenüber kein PGP kennt.

Vielleicht könnte man von den Kryptomessengern lernen (z.B. von OTR oder Axolotl), wie einfach anwendbare aber trotzdem sichere Verschlüsselung funktioniert. Man könnte mal über die Umsetzung des folgenden Konzepte nachdenken:
  1. User A schreibt eine E-Mail und klickt auf einen Button "Sicher verschlüsseln"
  2. Die Mail wird als (verschlüsselter) Entwurf gespeichert und eine Request zum DH-Schlüsseltausch an den Empfänger gesendet.
  3. Der E-Mail Client des Empfänger bearbeitet den Request automatisiert und einigt sich mit dem E-Mail Client des Absenders im Hintergrund auf einen Schlüssel.
  4. Bei Bedarf könnten die ausgehandelten Schlüssel anhand des Fingerprint über einen unabhängige Kanal verifiziert werden (für hohe Sicherheitsanforderungen).
  5. Dann erfolgt die weitere Kommunikation verschlüsselt ohne weitere Interaktionen.
Ein ähnliches Konzept hatte POND erfolgreich umgesetzt (das Projekt ist leider eingestellt). Vielleicht könnte man "Axolotl" für E-Mails adaptieren, das wäre ein interessantes Projekt. PGP ist mehr oder weniger tot für breite Massenanwendung. 
13.11.2017: 2-Faktor-Auth bei Posteo.de ist ein Placebo 

Phishing ist eine der großen Plagen im Internet und 2-Faktor-Auth kann dagegen schützen. Am WE wollte ich einen Artikel zur Verwendung von Nitrokeys für die 2-Faktor-Auth mit OTP (One-Time-Passwords) schreiben. Posteo hat ein hübsches Video, das erklärt, wie man sich dort die Nutzung von OTP vorstellt. Also habe mir das Video angeschaut und nebenbei einen Testaccount erstellt. Am Ende vom Video blieb Kopfschütteln.
04.05.2017: Posteo warnt vor Mailvelope (auch: Heise.de, Golem.de), großes Kino!

Die Dokumentation des Exploit zum Zugriff auf die privaten PGP-Schlüssel von Mailvelope soll geheim bleiben bis Firefox 57 released wird. Dann soll das Problem behoben sein. Aus den dünnen Veröffentlichungen von Posteo.de kann man folgendes entnehmen:
  1. Der Angriff beruht darauf, dass auch andere Add-ons in Firefox auf den Mailvelope Keyspeicher zugreifen können - Ohhh, das ist aber schon länger bekannt, das Add-ons in Firefox nicht gegeneinader abgeschottet sind.
  2. Der Angreifer muss das Opfer dazu bringen, die bösartige Software (in diesem Fall ein Browser Add-on) im Firefox zu installieren - Ohhh, das Opfer installiert sich also selbst die Software mit einer bösartigen Funktion?
Als Schutz gegen den Angriff wird von Posteo.de empfohlen, statt Firefox und Mailvelope einen E-Mail Client wie Thunderbird+Enigmail mit GnuPG zu nutzen.

Nehmen wir mal an, ich würde euch jetzt erzählen, dass ich mir die Mühe gemacht hätte und den DNSSEC/TLSA Validator für Firefox auch für Thunderbird angepasst habe - ganz tolles Sicherheitsfeature. Download hier im Privacy Handbuch. Aber dieses Add-on/Pug-in hat eine kleine versteckte Funktion. Es klaut euch den privaten PGP-Schlüssel aus dem GnuPG Keyring und schickt ihn mir. Außerdem startet es einen kleinen Keylogger für das GnuPG's Passphrase Fenster beim Start von Thunderbird und .... Scheiße - das wäre ja im Prinzip der gleiche Angriff wie... (Das Opfer installiert eine Software, die Zugriff auf den PGP Keyspeicher hat.)

Btw: Eine GnuPG Smartcard würde den privaten PGP-Schlüssel übrigens gegen diese Angriffe schützen, Nitrokey wäre meine Empfehlung, aber das ist nur eine Bemerkung am Rande.

Wenn das Opfer die Software des Angreifers selbst installiert (z.B. als Browser Add-on), dann hat das Opfer verloren - fast immer. Der Angreifer muss dafür nur wissen, welche Software das Opfer nutzt. Posteo.de könnte es den Angreifern schwerer machen und die eigenen Nutzer besser schützen, indem sie die User-Agent Header aus den E-Mais entfernen, wie es bei mailbox.org oder Mail.de z.B. implementiert ist. (Leser des Privacy Handbuches wissen, wie man das bei Thunderbird selbst macht.)

Ich halte nicht viel von Mailvelope, aber die Meldung von Posteo.de ist PR-Bullshit. Ähnliche Angriffe gab es bereits z.B. auf Nutzer des TorBrowserBundels. Eine Gruppe ANONYMOUS hatte eine bösartige Version des Add-ons TorButton verteilt, das bei Besuch von Hidden Services mit KiPo Material die Daten des Surfers an die Entwickler sendete. Die Liste der damit deanonymisierten Surfer wurde im Herbst 2011 im Internet veröffentlicht. Damals hat niemand dem TorBrowser die Schuld gegeben, sondern dem Ding mit zwei Ohren vor dem Computer, das das Add-on aus unsicherer Quelle installierte.

P.S. Das man Software installiert, die im Hintergrund unbemerkt irgendwelche privaten Daten sammelt und verschickt, ist bei Smartphones übrigens normal, das ist dort kein Bug sondern ein Feature. Legendär ist die App, die das Smartphone zu Taschenlampe macht und bei jeder Aktivierung den Standort des Nutzers an den Entwickler sendet. Wir haben uns daran gewöhnt, das als normal zu akzeptieren.
12.01.2017: Nach 4 Wochen warten, mehrmaligem Nachfragen und vielleicht ein bisschen zus. Druck durch Heise.de hat das BSI auf meine Fragen zur Zertifizierung von Posteo.de als sicheren E-Mail Provider geantwortet.

Die Kernaussagen der Diskussion zur TLS-Verschlüsselung in komprimierter Form: Also das wollte ich nicht erreichen - bedauerlich, dass das BSI nachträglich den mittel­mäßigen Stand von Posteo.de in der TLS-Verschlüsselung als "sicheren Standard" definieren will und die Möglichkeit zum Durch­setzen einer besserer TLS-Verschlüsselung gemäß den eigenen BSI-Richtlinien TR-03116-4 und TR-02102-2 ungenutzt lassen wird. Für wen sollen sollen die BSI Richtlinien zur TLS-Verschlüsselung gelten, wenn sie einem sicheren E-Mail Provider nicht zumutbar sind???
11.12.2016: In der letzten Woche wurde gemeldet, das Posteo.de vom BSI gemäß Richtlinie TR-03108-1 als sicherer E-Mail Provider zertifiziert wurde. Eigentlich halte ich das für PR und wollte es ignorieren, da aber auch etwas Crypto zur Zertifizierung dazu gehört und einige Leser nachgefragt haben, habe ich mir die TR 03108-1 genauer angeschaut.

Hinsichtlich Crypto wird für eine Zertifizierung die Einhaltung der BSI Richtlinie TR-03116-4 (Kryptografische Vorgaben für TLS, S/MIME, OpenPGP und SAML) gefordert:
  1. Es müssen AES128-GCM-SHA256 Cipher oder besser mit Forward Secrecy und TLSv1.2 für die Transportverschlüsselung verwendet werden.
  2. Ab 2016 müssen BSI-zertifizierte Server für den ECDHE-Schlüsseltausch die elliptischen Kurven "brainpoolp256r1" und "secp256r1" anbieten. Die Brainpool-Kurven sind zu bevorzugen. (Die Posteo-Server unterstützen keine Brainpool Kurven!)
  3. Wenn der Client das nicht unterstützt, darf ein zertifizierter Server Downgrades auf schwächere Cipher gemäß TR-02102-2 anbieten. Konkret heißt das, man darf in diesem Fall auch AES-CBC-SHA256 ohne Forward Secrecy verwenden. RC4, CAMELIA oder 3DES dürfen nicht verwendet werden. (RC4 auf den MXen wurde hier schon diskutiert.)
  4. Bis Ende 2016 ist gem. TR-02102-2 auch die Verwendung von SHA-1 in TLS-Ciphern übergangsweise noch als Downgrade Option erlaubt. Ab Januar 2017 ist die Übergangsfrist abgelaufen. Damit ist auch die Übergangsfrist für TLSv1 und TLSv1.1 engültig abgelaufen, da es für diese Protokolle nur Cipher mit SHA-1 gibt.
Ich glaube nicht, dass ein Mailprovider ab Januar 2017 die alten Protokolle TLSv1 und TLSv1.1 auf den Mailservern einfach abzuschalten kann. Eine solche Entscheidung müsste man ankündigen und betroffenen Kunden etwas Zeit zur Umstellung geben.

Ich habe beim BSI mal nachgefragt, was ab Jan. 2017 gilt, und außerdem um ein detailliertes Prüfprotokoll zur Zertifizierung von Posteo gebeten. Jetzt bin ich neugierig geworden.
  • Anonym: Anscheinend hat posteo.de etwas an Ihrer Konfiguration geschraubt und schneidet jetzt immerhin mit B- bzw C beim High Tech Bridge Test. Die verwendeten CIPHER sind immer noch ungut aber immerhin ist die Verschlüsselung nicht mehr via padding-oracle flaw attack (CVE-2016-2107) angreifbar. (28.10.2016) 
    • 06.10.2016: Wir bekommen noch immer E-Mails zum den Posteo Mailservern, in denen die TLS-Konfiguration von Posteo verteidigt wird unter Hinweis auf RFC xyz...

    Um es nochmals und abschließend zu diesem Thema zu sagen: Die Verwendung von RC4-Ciphern für die TLS-Verschlüsselung ist NICHT mehr zulässig. PUNKT. Es gibt auch einen eigenen RFC dafür: RFC 7465, der nichts anderes sagt, als das RC4 nicht mehr eingesetzt werden darf, weil unsicher. Gleiches gilt seit mehreren Jahren für MD5 Hashes.
    TLS servers MUST NOT select an RC4 cipher suite when a TLS client sends such a cipher suite in the ClientHello message.

    If the TLS client only offers RC4 cipher suites, the TLS server MUST terminate the handshake. The TLS server MAY send the insufficient_security fatal alert in this case.
    Das gilt auch für opportunistisches TLS, es gibt keine Ausnahmegenehmigung - nirgends.

    Falls man sich dafür interessiert, warum Krypto-Experten die Verwendung schwacher Cipher mit 40 Bit bzw. 56 Bit EXPORT Security oder RC4-MD5 grundsätzlich verbieten, dann kann man näheres in der Fachliteratur zu dem Thema lesen aber nicht in verschrubbelten FAQ.

    Die Empfehlung der IETF zur TLS-Verschlüsselung aus RFC 7525 kurz zusammngefasst:
    1. Es gibt sichere Cipher, die in Abschnitt 4.2 definiert werden. Diese Cipher sind zu verwenden, wenn beide Seiten es unterstützen: TLS 1.2 mit AES-GCM-SHA256 (oder besser) und Forward Secrecy.
    2. Es gibt unsichere Cipher, die nicht genutzt werden dürfen - never! Dazu zählen die Cipher mit EXPORT Security, RC4, MD5 und SSLv3. Diese Cipher werden in Abschnitt 4.1 ("Allgemeine Hinweise") definiert. Aufgrund der Definition als "allgemein gültig", die Großschreibung von "MUST NOT" und flankierene RFCs wird deutlich, dass diese Festlegungen NICHT overruled werden, auch nicht von Punkt 5.2. Verboten - PUNKT.
    3. Es gibt schwache Cipher. Diese Cipher dürfen gemäß Abschnitt 5.2 für einen Downgrad genutzt werden, wenn die unter 4.2 empfohlenen (sicheren) Cipher zu strikt sind sind und eine schwache Verschlüsselung besser ist als gar keine Verschlüsselung (wie bei opportunistischem TLS möglich). Es wird ausdrücklich TLS 1.0 mit RSA-AES128-CBC-SHA genannt, was in den allgemeine Festlegungen Abschnitt 4.1 als "SOULD NOT be used" gekennzeichnet ist.
    Ist das jetzt hinreichend klar formuliert? Weitere Mails zu dem Thema werden wir nicht beantworten, egal welche Ausreden und Begründungen Posteo noch erfindet.
    09.09.2016: Vor einer Woche hatten wir die TLS-Verschlüsselung der Mailserver von Posteo kritisiert. Mehrere Leser hatten die Kritik an Posteo weitergeleitet und vom Support eine Antwort bekommen, die jede Kritik abweist und behauptet, bei Posteo wäre alles sicher. Wir wurden mehrfach gebeten, zu dieser Antwort von Posteo Stellung zu nehmen. Die Zitate sind aus der Antwortmail von Posteo, soweit keine anderen Quellen angegeben sind.

    Posteo verwendet in der Kommunikation zu seinen Nutzern (IMAP, POP3, E-Mail-Einlieferung mit SMTP, HTTPS) die neuesten und sichersten Verschlüsselungsmethoden.
    Also dann mal "Butter bei de Fische", die Fakten:

    Unsere Testergebnisse vom 31.08.2016 für die MX-Mailserver von Posteo haben wir teil­weise protokolliert. Der TLS-Test von HTBridge prüft Server hinsichtlich Kompatibilität mit den aktuellen SSL/TLS Empfehlungen vom NIST und PCI DSS und außerdem auf bekannte Sicherheitslücken in der Verschlüsselung. Download des Testergebnisses für mx04.posteo.de vom 31.08.2016 als PDF (die anderen MX-Server hatten das gleiche Ergebnis).

    Die Ergebnisse von den Posteo MXen waren die schlechtesten von allen getesteten Mailservern. Folgende Mängel wurden am 31.08.2016 um 17:15 protokolliert: Hinweise zum Report: Das untrusted Certificate ist ein Fehler im TLS-Test und kein Fehler von Posteo, weil man bei diesem Test die MX-Server mit der IP-Adressen testen muss. Das die TLS Compression aktiviert ist und damit eine CRIME Attack möglich sein könnte, ist für SMTP-Server nicht so relevant wie für Webserver, da die konkret publizierte CRIME Attack nur mit Javascript auf HTTPS anwendbar ist. (Trotzdem empfehlen aktuelle TLS Standards die Deaktivierung von TLS Compression für alle Protokolle.)

    Posteo hat hat nach den Hinweisen von Lesern unseres RSS-Feed in der vergangenen Woche ein bisschen an der Konfiguration geschraubt, hier die Testergebnisse vom 09.09.2016 als PDF-Download. Schlussfolgerung: Die Verschlüsselung erfüllt NICHT die Mindestanforderungen der aktuellen SSL/TLS-Empfehlungen von NIST und PCI DSS und ist außerdem angreifbar. Mit diesem Fazit könnte man eigentlich die Diskussion beenden.

    Interessierten Leser hatten aber noch ein paar weitere Fragen zu den plausibel klingenden Aussagen von Posteo.
    Beim Empfang und Versand von E-Mails [...] bietet Posteo dennoch ausnahmsweise auch ältere Verschlüsselungstechnologien übergangsweise an [...]. Diese Vorgehensweise wird im RFC 7435 der Internet Engineering Task Force (IETF) empfohlen. Eine ausführliche Erklärung dazu finden Sie in unserem Hilfe-Artikel.
    Ohhh - ein RFC von der IETF als Referenz. Der Laie ist beeindruckt doch der Fachmann wundert sich. RFC 7435 ist veraltet, die aktuelle Empfehlung der IETF zur SSL/TLS Verschlüsselung ist RFC 7525 vom Mai 2015 (auch schon 1,5 Jahre alt).

    Das Problem des Downgrade der SSL-Verschlüsselung auf ältere Verschlüsselungs­technologien, um eine verschlüsselte Verbindung mit legacy Systemen zu ermöglichen, wird im RFC 7525 ausdrücklich angesprochen. Es ist spezifiziert, wie weit ein Server von den sicheren Standards abweichen darf, um eine verschlüsselte Verbindung zu ermöglichen.

    Zum Protokoll SSLv3, zum Cipher RC4 und der Hashfunktion MD5 trifft der aktuelle RFC 7525 eine eindeutige Aussage: "Implementations MUST NOT negotiate RC4 cipher suites." (Großschreibung aus dem RFC 7525 zitiert, auf Deutsch: DARF NICHT verwendet werden).

    Schlussfolgerung: Die Konfiguration auf den MX-Mailservern ist NICHT kompatibel mit den aktuellen SSL/TLS-Empfehlungen der IETF, was daran liegt, dass Posteo die aktuellen Empfehlungen der IETF nicht kennt und veraltete RFCs als Arbeitsgrundlage verwendet.

    Wenn man der plausibel klingenden Argumentation von Posteo konsequent folgen würde, dann würde man sich fragen, warum die noch schwächeren Cipher mit 40 oder 56 Bit EXPORT Level Security nicht auch noch angeboten werden? Wäre doch auch ein bisschen besser als unverschlüsselt - oder gilt die Argumentation dann plötzlich nicht mehr?

    Ein E-Mailserver, der bei dem zitierten SMTP-Test von "besonders gut" abschneidet, wird in der Praxis vermutlich eine geringere Anzahl von verschlüsselten Verbindungen zu anderen E-Mailservern und eine größere Anzahl von gänzlich unverschlüsselten Klartext-Verbindungen erreichen.
    Diese Behauptung ist "vermutlich" Bullshit. Selbst 10 Jahre alte Mailserver Software (falls soetwas irgendwo noch im Einsatz ist) kann TLSv1.0 mit RSA-AES128, wenn der Admin SSL/TLS aktiviert. Aber gut - Posteo könnte die eigene Argumentation leicht beweisen, die notwendigen Daten stehen zu Verfügung. Wenn Sie in ihren eigenen Logs einen Mailserver finden, zu dem ihre MX-Server regelmäßige eine schwache, RC4-verschlüsselte Verbindung aufbauen können und die IETF-konformen Mailserver von Google können das nicht, dann wäre das ein interessantes Argument. Die Logdaten der Google findet man auf der TLS Transparency Webseite von Google und kann sie dort durchsuchen. Wäre interessant...

    Ein Test, der die Besonderheiten der Server-zu-Server-Kommunikation bei E-Mail beachtet, ist z.B.: https://de.ssl-tools.net/mailservers/posteo.de
    Kennen wir, haben wir auch zuerst als Test genommen. Im Ergebnis von letzter Woche wurde SSLv3 deutlich erkennbar als Fehler bemängelt und das hat uns auf die Idee gebracht, mit anderen Tests bei allen Mailservern mal ein bisschen genauer hinzuschauen. ;-)
     
    Deswegen ist die ausgehende E-Mail-Kommunikation mit DANE und der TLS-Versandgarantie auch strenger konfiguriert, damit es immer zu einer besseren Verschlüsselung kommt.
    Ach ja - der aktuelle Hype um die TLS-Versandgarantie bei Posteo. Es ist ein nettes Feature, aber ohne die fehlende TLS-Empfangsgarantie zu 50% sinnlos. Ein Beispiel:
    1. Ein Posteo-Nutzer versendet seine E-Mail mit TLS-Versandgarantie.
    2. Der Empfänger klickt auf den Antworten-Button und schickt ein "full-quote" der empfangenen E-Mail zurück. (Das kommt im realen Leben wirklich vor.)
    3. Ein SSL-interceptierender Lauscher am Draht beschnüffelt die Antwort-Mail und bekommt damit praktische alle Informationen aus 1. und 2. (und die garantiert TLS-verschlüsselten Mailversendung ist ausgehebelt).
    Statt ein kleines Feature als die Lösung der Probleme zu hypen, könnte Posteo.de etwas klarer über die (noch) bestehenden Schwächen informieren. Die aggressive PR-Strategie von Posteo ist eher gefährlich, wenn (noch) bestehenden Schwächen in Sicherheitsfunktionen unzureichend kommuniziert werden und Laien sich deshalb in Sicherheit wiegen.


    Bezüglich der PR-Strategie von Posteo.de haben wir noch einen weiteren Kritikpunkt. Anläßlich der Einführung der neuen DANE-Anzeige im Webinterface schreibt Posteo.de in dem Artikel Warum gibt es bei Posteo eine DANE-Anzeige - und keine TLS-Anzeige?:
    Eine TLS-Anzeige kann nämlich entweder auf Erfahrungen aus der Vergangenheit beruhen, das lässt aber keine Aussage auf zukünftige Verbindungen zu. Oder sie kann kurz vor dem eigentlichen Versand prüfen, ob TLS zustandekommt. Und auch das kann sich kurz darauf durch eine technische Störung oder einen Angriff geändert haben. Deshalb sind TLS-Anzeigen unserer Überzeugung nach unseriös: Sie täuschen Sicherheit nur vor.
    Klingt plausibel und nach besonderer Kompetenz bei Posteo - oder? Ist aber Bullshit. Man kann die in der Vergangenheit gesammelten Erfahrungen in einer sogenannten Datenbank speichern und bei zukünftigen Verbindungen den früher erreichten Sicherheitslevel wieder erzwingen. Aussage für zukünftige Verbindungen sind damit keine Voodoo Magie mehr. Eine Unterschreitung des geforderten Sicherheitslevels kann wie jede andere technische Störung im E-Mail Verkehr behandelt werden -> Zustellung der Mail (temporär) nicht möglich.

    Ich kenne nur einen Mitbewerber, der eine TLS-Anzeige im Webinterface anbietet. Dort werden die angezeigten Sicherheitslevel bei der Versendung auch durchgesetzt. Allen anderen E-Mail Providern ist ebenfalls klar, dass man den Nutzern nur anzeigen sollte, was man wirklich durchsetzen kann. Somit stell sich die Frage: Welche TLS-Anzeigen sind nach Ansicht von Posteo.de unseriös? Was ist mit dieser fett hervorgehobenen, diffuse-orakelnden Andeutung im FAQ Artikel gemeint?

    Um Missverständnisse wie in dieser Diskussion hier zu vermeiden, sollte Posteo es etwas klarer formulieren, z.B. "Wir können bei Verbindungen zu Google, Yahoo und anderen Providern keine TLS-Verschlüsselung erzwingen und verzichten daher auf eine TLS-Anzeige." Das wäre ein Satz, dafür braucht man keinen FAQ Artikel.

    Posteo demonstriert hier an einem Beispiel, wie PR funktioniert. Es wird angedeutet, das es ominöse, nicht konkret genannte E-Mail Provider gäbe, die keine Ahnung haben. Und Posteo erklärt euch jetzt mal, wie E-Mail funktioniert. Beim Leser entsteht der Eindruck, einen besonderers kompetenten Provider gefunden zu haben. Der Faktencheck zeigt, das es diese ahnungslosen E-Mail Provider garnicht gibt und alle Mitbewerber mindestens die gleiche Kompetenz haben oder besser. Besonders störend ist, dass Kolateralschäden bei anderen Mitbewerbern durch unbegründeten Vertrauensverlust von Kunden durch die PR-Abteilung von Posteo billigend in Kauf genommen wird.


    Abschlussbemerkung: Trotz einzelner Mängel ist Posteo.de in der Gesamtbertrachtung ein guter Mailprovider und steht auf unserer Liste der empfohlenen Provider (da stehen nicht sehr viele Provider). Diese Bewertung beruht auf Fakten (nicht auf Mythen, die von PR-Strategen aufgebaut werden) und toleriert auch mal Probleme. Nobody is perfect.
    Das Privacy-Handbuch wurde im Verfassungschutzbericht 2013 auf Seite 57 im Kontext von "Cyberterrorismus" erwähnt. Da die Erwähnung in einem Verfassungsschutzbericht für mich unverständlich ist, habe ich beim Verfassungschutz nachgefragt, warum das Handbuch das Missfallen der Verfassungschützer erregt hat, und folgende Antwort bekommen:
    Das "Privacy-Handbuch" wurde im Verfassungschutzbericht 2013 erwähnt, weil darin auf Autoren verwiesen wird, die sich selbst dem "cyberterrorism" zuordnen... Anknüpfungs­punkt für die Erwähnung sind weder der Inhalt noch Sie als Autor des Buches....
    Hmmm - wir bemühen uns natürlich, das Privacy-Handbuch verfassungs­konform zu gestalten und würden die Erwähnung der bösen Cyberterroristen gern entfernen. Wir haben aber keine Ahnung, wer sich selbst irgendwo als "Cyberterrorist" geouted hat - Peter Schaar, Angela Merkel, Ulf Burmeyer, Phil Zimmermann, Jakob Appelbaum, die PiratenPartei oder Frank Rieger vom CCC?

    Es ist seltsam, dass das Privacy-Handbuch als einzige Publikation in diesem Kontext im Verfassungs­schutz­bericht erwähnt wird. Sind wir wirklich die einzigen, die diese bösen "Cyber­terroristen" zitieren? Wir verweisen ausschließlich auf öffentlich zugängliche Quellen im Internet und erwarten natürlich, dass terroristische, strafrechtlich relevante Inhalte via Take-Down-Notiz entfernt werden. Was bei Kinderpornos funktioniert, sollte auch bei Terrorismus möglich sein. 
    Einige Twitter Nutzer haben in der letzten Woche eine E-Mail von Twitter erhalten, dass ein vermutlich staatlicher Angreifer versuchte, Zugriff auf die Account Details zu erlangen. Qbi und Analist waren beispielsweise betroffen und sind beunruhigt. Ein paar kleine Gedanken:
    1. Es gibt keine Privatsphäre bei Twitter, fast alles ist irgendwie öffentlich, es ist eine moderne Form vom "Geschrei auf dem Marktplatz der Eitelkeiten". Wer Twitter nutzt, sollte sich darüber klar sein.
    2. Twitter hat 2014 die kostenpflichtigen API-Schnittstellen geändert. Eine Abfrage der E-Mail Adressen der Nutzer und weiterer Daten wie mit der API von 2009 ist seit 2014 nicht mehr möglich. Der staatliche Angreifer hat also keine Möglichkeit mehr, diese Daten durch Bezahlung zu erhalten. (Danke für den Hinweis)
    3. Twitter kooperiert nicht im Rahmen des PRISM Programms mit US-amerikanischen Geheimdiensten. Das DHS hatte bisher für 360.000 Dollar pro Jahr die API-Schnittstelle genutzt, wie jeder andere zahlende Kunde. Da über diese API die gewünschten Daten nicht mehr geliefert werden, kann man auch die US-Dienste nicht mehr prinzipiell als Angreifer ausschließen.
    4. Spekulationen über das Ziel des Angriffs anhand der betroffenen Personen sind sinnlos, weil ein Angreifer nicht nur die eigentlichen Targets angreifen wird, sondern ein paar mehr Personen, um die Zielstellung des Angriffs zu verschleiern oder in eine falsche Richtung zu lenken. Jene Opfer des Angriffs, die wirklich Grund zur Beunruhigung haben, werden vermutlich schweigen. Der Rest sind wahrscheinlich Cover-Targets.