Aktualisierungen gibt es im Changelog, als RSS-Feed
oder im [matrix] Raum #prhdb-changes:nitro.chat

Privacy-Handbuch

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


23.10.2022 
10.10.2022 
  • Anonym: Woher kennt Similarweb.com die Besucherzahlen vom Privacy-Handbuch?
  • Antwort: Similarweb.com kauft Daten von Trackingdiensten, die jeden Klick auf einen Link registrieren (Google, Facebook usw.) und evtl. auch von Datensammlungen an den Knotenpunkten des Internet (keine Ahnung, reine Spekulation).

    Similarweb.com liegt bei Schätzung der Besucher des Privacy-Handbuch aber ziemlich daneben. Für Sept. 2022 werden bei Similarweb.com 37k Besucher angegeben. Die Auswertung der Logs vom Webserver kommt auf 109k Besucher für diesen Monat.

22.03.2022 
  • Anonym: Wir sind eine ukrainische Hackergruppe und haben ihren Webserver www.privacy-handbuch.de gehackt. Bitte überweisen zur Unterstützung der ukrainischen Armee X.y Bitcoins an folgenden Adresse, oder wir werden…
  • Anonym: Guten Tag, ich habe Ihren E-Mail Account ...@privacy-habdbuch.de gehackt und anschließend ihren Computer. Das war ganz einfach. Jetzt kann ich Sie unbemerkt beim Surfen beobachten und gleichzeitig mit Ihrer Kamera filmen. Ich habe Videos gespeichert, wie Sie sich Pornoseiten anschauen und dabei selbst befriedigen. Bitte überweisen Sie innerhalb von einer Woche X.y Bitcoins an folgende Adresse, oder ich werde…
  • Antwort: Ohhh man - gibt es wirklich Leute, die darauf reinfallen?


01.11.2021 
  • Anonym: Hast Du Dich mal gefragt, warum Signal eine Cryptocurrency launchen konnte und Telegram nicht.
  • Antwort: Ja, und die Anwort ist ganz einfach. Im Gegensatz zu Telegram (und Facebook, denen das auch verboten wurde), hat Signal keine eigene (stabile) Cryptocurrency gelauncht sondern einfach die API zu Moxies Lieblingscoins genutzt, die es schon längst gab.


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 
  • Anonym: Es gibt ihn noch. Hatte schon große Sorge, dass es die gut getarnte BND Connection hier nicht mehr gibt.
  • Antwort: "BND Connection" - das ist neu. Wie habe ich mir das Prädikat verdient und warum ist MAD jetzt nicht mehr passend?


03.01.2021 
  • Anonym: Thunderbird verwendet WebDiscovery und lädt den Schlüssel vom Webserver des E-Mail Providers herunter. Das macht doch wenig Sinn, wenn man dem Provider bei E2E Verschlüsselung nicht vertrauen sollte?
  • Antwort: Das gilt auch, wenn einen Schlüssel per E-Mail Anhang versendet oder wenn man den Schlüssel aus dem Autocrypt Header importiert. Bei OpenPGP gibt es leider keinen brauch­baren Schlüsseltausch (einfach und sicher zugleich).

    Wer mehr als lari-fari Sicherheit möchte, muss die Fingerprints der Schlüssel über einen sichern, unabhängigen Kanal verifizieren oder bei einem persönlichen Treffen (out-of-band).

    (Evtl. könnte man dann die Frage stellen, warum man E-Mail Verschlüsselung braucht, wenn man bereits einen sichern Kanal hat... - hmmm, die Katze beißt sich in den Schwanz.)

  • Nachtrag: Die Messenger haben das unterschiedlich gelöst. So richtig gut macht es Signal App mit dem X3DH Schlüsseltausch. Bei Threema muss man auch verifizieren, weil die öffentlichen Schlüssel der Kommunikationspartner vom Server kommen... kompliziertes Thema. Wenn ich Zeit habe, werde ich das bei dem Messengern mal einfügen.


03.01.2021 
  • Anonym: Es gibt im Moment nur einen Weg, um ein Always-on-VPN unter iOS zu aktivieren: nur für IKEv2 VPNs als "managed device" mit einem VPN Profil (für Firmen).
  • Antwort: Nein - es gibt auch einige VPN Apps, die das können (z. B. ProtonVPN für iOS). Deshalb ist bei ProtonVPN die Verwendung der App empfohlen worden und nicht die IPsec/IKEv2 Konfiguration in iOS.

31.12.2020
  • Anonym: Wie ist eure Einschätzung zu Riseup.net VPN?
  • Antwort: Riseup.net VPN mit nur einem Server in den USA sehe ich eher als Ergänzung zu einem E-Mail Account bei Riseup.net und nicht als eigenständigen VPN-Provider.

    Die Sicherheit ist nach einem oberflächlichen Test "gut" (durchschnittlich, keine gravierenden Mängel aber auch nicht top-of-the-art wie die IPsec/IKEv2 Server von ProtonVPN).


16.11.2020 
  • Anonym: Wenn man in der URL Suchleiste im FF den Cursor reintut, bekommt man amazon, yt etc. vorgeschlagen. das lässt sich nur entfernen, in dem man in der startseite die entsprechenden icons entfernt. Die werden aber aufgrund der user.js ausgeblendet. Mal darüber nachdenken...
  • Antwort: Einfach die aktuelle user.js verwenden. Die Lösung ist hier beschrieben und folgene Einstellung löst das Problem wahrscheinlich schon: browser.urlbar.suggest.topsites = false

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
04.10.2019 Gedanken zur Axolotl Verschlüsselung

Die von Moxie Marlinspike entwickelte Axolotl Verschlüsselung für den Messenger Signal App git als der Gold­standard für die Ende-zu-Ende Verschlüsselung für Messenger. In der zivilen Kryptoanalyse sind keine Schwachstellen bekannt. Andere Messenger wie WhatsApp haben diese E2E-Verschlüsselung übernommen.

Vor wenigen Tagen berichtete Bloomberg, dass Facebook und WhatsApp die E2E-verschlüsselten Nachrichten der Nutzer der britischen Polizei zukünftig zur Verfügung stellen sollen. Im Gegenzug sollen die USA Zugriff auf britische Messenger bekommen:
Social media platforms based in the U.S. including Facebook and WhatsApp will be forced to share users encrypted messages with British police under a new treaty between the two countries.
WhatsApp verwendet mit Axolotl die gleiche Verschlüsselung wie Signal App. Die Verschlüsselung wurde mit Unterstützung der Signal Developer implementiert und M. Marlinspike schreibt in einem Blogartilel, das es keine Backdoor gibt.

Seltsam? Was wollen die Briten mit den verschlüsselten Nachrichten? Der australische Justizminister George Brandis sagte 2017 in einem Interview, das der GCHQ in der Lage wäre, die Verschlüsselung von Signal zu knacken:
British signals intelligence agency Government Communications Headquarters (GCHQ) can crack end-to-end encrypted messages sent using WhatsApp and Signal.
Auf Nachfrage betonte er nochmals:
Last Wednesday I met with the chief cryptographer at GCHQ ... And he assured me that this was feasible.
George Brandis ist keine technische Leuchte auf diesem Gebiet und verwechselt auch mal Metadaten und Inhaltsdaten. Die Aussage ist also mit Vorsicht zu behandeln ohne eine unabhägige Bestätigung durch Dritte (oder durch einen Whistleblower, der Lust auf ein Leben in Russland hat?)

Es ist aber auch so, dass die geheimdienstliche Kryptoanalyse in der Regel mehrere Jahre Vorsprung gegenüber der zivilen Kryptoanalyse hat. Beispielweise erreichte die NSA 2010 einen Durchbruch in der Kryptoanalyse, der es ermöglichte, dass 2/3 des weltweiten VPN-Traffic und 1/3 des HTTPS Traffic on-the-fly entschlüsselt und in XKeyscore eingespeist werden werden konnte. Die zivile Kryptoanalyse konnte das Phänomen erst 2015 plausibel erklären. Als Jakob Appelbaum 2013 sagte, das die NSA den RC4 Cipher on-the-fly knacken kann, haben viele nur gelacht. Heute weiß man, dass er Recht hatte.

Wenn der Chef der GCHQ Kryptoanalytiker sagt: "...this is feasible...", dann muss das nicht bedeuten, dass die Krypto auf Knopfdruck in Millisekunden gebrochen wird, es kann durchaus mit einigem Aufwand verbunden sein, aber trotzdem bei ernsthaftem Interesse möglich.

Im Crypto War 3.0 steht die Ende-zu-Ende Verschlüsselung von Messengern im Mittelpunkt. Aufgrund der Verbreitung steht insbesondere Axolotl im Fokus. Das zeigt sich auch an den Weiterentwicklungen der Forensiktools der Firma ElcomSoft, die neuerdings die Chatverläufe von Signal App aus der verschlüsselten Datenbank auf dem Smartphone extrahieren können, wenn Ermittler physischen Zugriff auf das Smartphone haben.

Man sollte sich vielleicht nicht nur auf die Krypto verlassen, keine Krypto hält ewig. Die "Selbst­löschenden Nachrichten" von Signal App könnten eine sinnvolle Ergänzung sein.
08.05.2019 
  • Anonym: Fefe rantet gegen Firefox ESR, könntest Du das kommentieren?
  • Antwort: Ich gehöre zu den Veteranen, die Firefox ESR einsetzen und früher bei JonDonym als Grundlage für einen "anonymen" Browser verwendeten, die IT meiner Firma gehört zu den Veteranen, die Firefox ESR für die Mitarbeiter ausrollen, alle Kunden, die ich als Berater betreue verwenden Firefox ESR in der internen IT...

    Bei dem TorBrowser gibt es ein wesentliches Argument für die Verwendung von Firefox ESR: die Tor-Devs müssen die Neuerungen des Firefox hinsichtlich Einfluss auf die Anonymität abklopfen und manchmal Patches entwickeln, die diese neuen Funktionen entschärfen. Das braucht Zeit.

15.03.2019
  • Anonym: I2P funktioniert technisch zwar sehr gut, aber I2P schützt leider nicht vor der Haftung für verschlüsselten Datenverkehr von Dritten der wegen dem eigenen I2P Client über den eigenen Internetanschluss geleitet wird. Für das Anonymisierungsnetzwerk Freenet gilt übrigens genau das gleiche.

    Es gab nämlich schon den Fall vor einem deutschen Gericht, dass jemand für den verschlüsselten Datenverkehr von Dritten in die Haftung genommen und verurteilt wurde und das sogar für Traffic, den er gar nicht selbst abgefragt hat. Der Fall geht zwar nicht explizit auf I2P und Freenet ein, ist im übertragenen Sinne aber das gleiche Problem

    Damit kann man praktisch I2P und Freenet in Deutschland nicht mehr verwenden.
  • Antwort: Ich kenne das Urteil, es ist 6 Jahre alt. In dem Verfahren ging es um einen Retroshare Nutzer, der seine kryptografischen Schlüssel im Internet veröffentlicht hatte, um sein Filesharing Netzwerk zu vergrößern.

    Retroshare ist ein Friend-2-Friend Netzwerk. Die Sicherheit von Friend-2-Friend Netzwerken beruht darauf, das man sich nur mit vertrauenswürdigen Partner verbindet und dass man seine kryptografischen Schlüssel nur Freunden zur Verfügung stellt.

    Diese Grundregel hatte der Verurteilte verletzt. Er hat die Schlüssel für seinen Knoten im Internet veröffentlicht und damit hat er der Content Mafia dn Angriff ermöglicht, der zum Sammeln der notwendigen Daten genutzt werden konnte.

    I2P und Freenet sind Peer-2-Peer Netzwerke und schützen aufgrund des stärken Angreifermodells und stärken kryptografischen Protokolls gegen diesen Angriff. Ein vergleichbares juristisches Verfahren wie in dem genannten Fall gegen einen Retroshare Nutzer ist bei I2P und Freenet nicht möglich. (Auf die technischen Details möchte ich nicht weiter eingehen.)

    Daher sehe ich keinen Grund, vor I2P oder Freenet zu warnen und bezüglich Retroshare verweise ich seit Jahren darauf, dass man in ein Friend-2-Friend Netzwerk nur vertrauenswürdige Freunde einladen darf.

09.01.2019 
  • Anonym: Woher weißt Du das Tor verwendet wurde? Also wertest Du doch Logdaten aus?
  • Antwort: Welche Logdaten der Webhoster für die Domain www.privacy-handbuch.de speichert und wer darauf Zugriff hat, ist unter Datenschutz beschrieben.

    Für mich reichen diese Daten aus, um ein TorBrowserBundle zu erkennen (ich habe jahrelang in der Branche gearbeitet). Eine Identifizierung einzelner Surfer anhand der Logdaten ist aber nicht möglich, auch wenn man keinen TorBrowser verwendet.

08.01.2019 
  • Anonym (via TorBrowser): Gehörst du zu den braunen Scheißhaufen dazu die mit diesen Kremlaktionen ein neues Nazideutschland bewirken wollen? Schlachten, allesamt! Ihr Untermenschen!
  • Antwort: Das der Kreml (der Hort für alles Böse) ein neues Nazideutschland etablieren möchte, scheint mir absolut plausibel, da die Geschichte ja schon gezeigt hat, das Russland davon enorm profitiert. Und das massenweise Schlachten von "Unter­menschen" gab es auch schonmal - ähmmm ... war das nicht ...

    Ich war gestern in der Berliner Phiharmonie beim Eröffnungskonzert der "Russian Season 2019". Im Rahmen des interkulturellen Dialogs werden 2019 in 400 Veranstaltungen hochkarätige russische Künstler in Deutschland gastieren. Gestern spielte das St. Petersburger Mariinsky Orchester unter Leitung von W. Gergijew, der u.a. Chefdirigent der Münchner Philharmoniker ist.

    Im Eröffnungskonzert wurde die Oper Jolanthe von Tschaikowski konzertant aufgeführt. Es gibt sicher bedeutendere Werke von Tschaikowski oder anderen russsischen Komponisten, aber das lyrisch verbrämte Libretto (mit König, Prinzessin, Rittern, Hofdamen und einem maurischem Arzt) hat eine tiefere Botschaft:
    Man kann nur "Sehen" lernen und von der eigenen Blindheit geheilt werden,
    wenn man es wirklich selbst will.

01.01.2019
  • Ich habe on letzter Zeit mehrere anonyme Nachrichten bekommen, dass folgende Option in die user.js von Thunderbrird aufgenommen werden sollte: network.trr.mode = 5 Thunderbird 60.x (und Firefox 60.x ESR) kennen für network.trr.mode nur die Optionen [0-4]. Option "5" wurde erst in Firefox 61 eingeführt.

30.12.2018
  • Anonym: Beim 35C3 gab es einen Vortrag zum Thema E-Mail Verschlüsselung, Efail usw. Der Prof. hat Ratschläge gegeben, die uns etwas ratlos zurück lassen und nicht dem entsprechen, was wir im Privacy Handbuch lesen.

    HTML abschalten bringt nichts, weil viele E-Mail Clients irgendwie doch HTML im Hintergrund verwenden. Remote-Content abschalten reicht auch nicht...

  • Antwort: Ich habe den Vortrag von Prof. Schinzel auch zur Kenntnis genommen. Ein paar Gedanken dazu:
    1. Das E-Mail im Vergleich zu modernen Messengern für private Kommunikation die grotten­schlechteste Alternative ist, habe ich hier schon geschrieben. In diesem Punkt sind die Empfehlungen vom Privacy Handbuch und Prof. Schinzel durchaus ähnlich.
    2. E-Mail stammt aus der Steinzeit des Internet, als man noch an das Gute im Internet glaubte. Entsprechend unsicher ist das gesamte Design. Später versuchte man immer wieder, ein bisschen mehr Sicherheit aufzupfropfen, aber das hat stets nur sehr begrenzt funktioniert, weil man abwärtskompatibel sein wollte. (TLS für SMTP, PGP, S/MIME, DKIM...)

      Das ist jetzt wirklich keine neue Erkenntnis -oder?
    3. Das Ergebnis dieses unsicheren Design ist heute: E-Mail Tracking, Phishing Kampagnen, Trojaner die per E-Mail kommen (gern als Bewerbung, anwaltliche Drohung oder Rechnung getarnt). Dazu zählen Verschlüsselungstrojaner, die um Bitcoins betteln, oder der Bundestrojaner des BKA, der ebenfalls bevorzugt per E-Mail zum Target kommt.
    4. Je exponierter eine Person ist und je wertvoller als Target, desto ausgefeilter und technisch besser werden die Angriffe. Deshalb empfiehlt Prof. Schinzel exponierten Personen, die ein interessantes Spionage-Ziel für potenten Angreifern mit staatlichem Hintergrund werden können (das können CEOs sein, Personalchefs, hochrangige Politiker oder "Landes­verräter"), auf die Nutzung von E-Mail zu verzichten.

      Aus meiner Sicht ist diese Empfehlung nachvollziehbar. Das ist auch die Sicht des BSI, wenn es um klassifizierte Kommunikation geht. Selbst NfD Dokumente ("Nur für Dienstgebrauch") dürfen nicht per E-Mail mit PGP oder S/MIME verschlüsselt versendet werden.
    5. Exponierte Personen sollten sich aber generell von qualifizierten IT-Spezialisten beraten lassen und sich nicht anhand des Privacy Handbuch selbst qualifizieren wollen. Auch in der technischen Ausstattung liegen die Kosten in deutlich anderen Bereichen, das ist nicht die Zielgruppe vom Privacy-Handbuch.
    6. Für Normal-User, die praktisch nicht auf E-Mail verzichten können (wie sollte man sonst einen Billig-Flug buchen, online shoppen, bei eBay seinen Ramsch loswerden, Twittern, in Foren diskutieren o.ä.), sind die Hinweise im Privacy ein Vorschlag des Machbaren.
    7. Btw: auch die von Prof. Schinzel als Alternative empfohlenen Messenger verwenden häufig HTML Bibliotheken zur Darstellung der Buchstaben auf dem Bildschirm - ja, wirklich.

05.08.2018
  • Anonym: Fefe warnt vor alternativen DNS-Servern und rät, weiterhin den DNS-Server des eigene ISP zu nutzen. Vielleicht keine gute Idee, DNS-Server von Google, Cloudflare Quad9 SecuredDNS.eu oder andere zu nutzen.
  • Antwort: Fefes Blog, die "Yellow Press" für Nerds, für einige seiner Jünger der Quell absoluter Wahrheit... ohhh man! (Technisch halte ich nicht sehr viel dem Geschnodder und Fefes Empfehlung "network.trr.mode = 5" funktioniert nicht bei FF 60.x ESR sondern erst ab FF 61, andere Themen sind aber manchmal unterhaltsam.)

    Ich denke, ich habe im Kapitel DNS/DNSSEC einige Gründe genannt, warum man einen anderen DNS-Server nutzen könnte: Zensur durch den Provider, keine DNSSEC Validierung, nicht RFC-konforme DNS Manipulationen... Es steht jedem frei, die Gründe abzuwägen und selbst zu entscheiden, welchem Provider man vertraut. Google und Cloudflare habe ich nie empfohlen, habe nur erwähnt dass es diese Dienste gibt. Quad9 hat hinsichtlich Thread Protection Vorteile und dass verschlüsseltes DNS kein Privacy Feature ist, steht auch da.

    Fefe hat seine Meinung und ich habe meine Meinung. Fefe war auch mal der Meinung, dass 8.8.8.8 eine feine Sache ist. Er nutzte die Google DNS-Server nur nicht, weil er einen eigenen DNS-Server hat (nix "DNS-Server des Providers").

    International geht es bei der Einführung von verschlüsseltem DNS vor allem um den Kampf gegen Zensur (ja - Google, Mozilla u.a. engagieren sich gegen Zensur, weil sie im Internet Geld verdienen). Kann sein, dass das für Fefe kein Problem mehr ist, in der Türkei sieht man das bestimmt anders und freut sich auch über Cloudflare Server via DNS-over-HTTPS. (Ich habe das ZugErschwG und Zensursula noch nicht vergessen.)

05.08.2018
  • Anonym: hallo, es fehlt das thema link prefetching. du sagst nicht dazu. im firefox sollte man network.prefetch-next ausschalten.
  • Antwort: Nein, ich sehe keinen Grund, warum man das Link Prefetching extra deaktivieren sollte. Ziel der Konfiguration für "spurenarmes Surfen" ist es, webseiten-übergreifendes Tracking und langfristiges Tracking zu unterbinden. Wenn man die Empfehlungen umsetzt (FirstParty.Isolate aktivieren und alle Caches beim Beenden löschen) dann bring die Deaktivierung von Link Prefetching keinen weiteren Vorteil bezüglich Trackingschutz. Falls es andere Ansichten dazu gibt, dann bitte mit technicher Begründung.
  • Anonym: Wenn irgendwo auf einer Webseite ein Link auf dubiose, unseriöse oder zwielichtige Seiten verweist, dann lädt Firefox den schon mal vor und tauchst mit deiner IP Adresse in den Logs des dubiösen Webservers aud. Willst Du das???
  • Antwort: Ich glaube, Du hast nicht verstanden, wie Link Prefetching funktioniert. Es werden nicht irgendwelche Links auf der Webseite geladen. Ein Webmaster muss im Header der Webseite die Medien (CSS Dateien, Bilder o.ä.) definieren, die im Hintergrund per Prefetch schon mal in den Cache geladen werden, damit sie schneller aufgerufen werden können. <link rel="prefetch" href="/images/big.jpg"> Wenn ein Webmaster Dich bewusst reinlegen will und möchte, dass Deine IP in irgendwelchen dubiosen Webserver Logs auftaucht, dann kann er das ganz ohne Prefetching machen und ein CSS oder ein Bild von diesem dubiosen Webserver direkt einbinden, muss nicht sichtbar sein.

    Es ist also eine bewusste Entscheidung des Webmasters ob er Dateien für das Prefetching definiert und gegen Logeinträge bei dubiosen Webservern schütz das Deaktivieren von Prefetching nicht.

02.06.2018 MAT funktioniert nicht mehr. 
  • Anonym: Für Images und OpenOffice Dokumente funktioniert MAT immernoch ganz gut, könnte man doch dafür weiter benutzen.
  • Antwort: Wenn in der Dokumentation einer Software steht, sie könnte die Metadaten von PDF, JEPG, TIFF, OGG, FLAC, OpenOffice.org .... entfernen, und PDF funktioniert nachweislich nicht, dann probiere ich nicht, ob andere ein bisschen funktionieren.

    Wenn der Autor der Software selbst warnt:
    The current version might have bugs [...] Please avoid using it.
    dann kann ich es hier im Privacy-Handbuch nicht mehr empfehlen. (Ich hätte MAT schon viel früher entfernen sollen, hatte aber wenig Zeit.) 

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 Rund­funk­medien­anstalt 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 Rund­funk­medien­anstalt 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.

Meine Stellungnahme möchte 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.

    Die Konfiguration der Posteo Server kann sich jeder selbst anschauen. Auch wenn manche Tests ein "A+" für Posteos Server vergeben, hat das BSI in seine Richtlinien höhere Ansprüche definiert.
  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. (Upgrade!)
  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 
  • Efail ist ein "gaaaanz schlimmer" Angriff auf die E-Mail Verschlüsselung mit OpenPGP und S/MIME. Ein aktiver Angreifer (Typ: Mallory) modifiziert eine verschlüsselte E-Mail und kann damit Zugriff auf den verschlüsselten Inhalt der Kommunikation erlangen, wenn der Empfänger die unsicheren Default-Einstellungen von Thunderbird nicht geändert hat. (Wer es genauer wissen will, kann die Artikel bei Heise.de lesen.)
  • Autocrypt ist nach Meinung einiger Leser ein "gaaaanz tolles" Feature, dass die Verschlüsselung von E-Mails mit OpenPGP vereinfachen soll. Autocrypt will nur gegen passive Lauscher schützen und öffnet dafür ein Scheunentor für aktiver Angreifer (Typ: Mallory), der die E-Mails auf dem Weg modifizieren kann um die PGP-Verschlüsselung zu kompromittieren (wenn der Anwender es bei den unsicheren Default-Einstellungen von Enigmail belässt, genauere Beschreibung eines Angriffs hier im Handbuch).
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:
  • #Efail kompromittiert die Verschlüsselung der aktuell empfangenen E-Mail.
  • Ein erfolgreicher Angriff auf Autocrypt kompromittiert zukünftig versendete E-Mails.
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):
  • Es ist keine Validierung der Schlüssel vorgesehen. Der E-Mail Client soll automatisiert alles aktzeptieren, wenn die ID des Schlüssels zur Absenderadresse passt.
  • Die E-Mail Header werden von den Mailprovidern ständig routiniert manipuliert. Es werden neue Header eingefügt, einige Header werden gelöscht.... In gleicher Weise könnten die Autocrypt Header bei den versendenden oder empfangenen E-Mail Providern manipuliert werden und ein falscher Schlüssel eingefügt werden.

    (Das funktioniert auch, wenn der Absender Autocrypt garnicht nutzt. Ich bin also möglicherweise in meiner Kommunikation auch betroffen, obwohl ich dieses Feature sofort deaktivieren würden, wenn GnuPG oder Enigmail es implementieren werden.)
  • Es gibt also keinen Grund, den PGP-Schlüsseln in Autocrypt Headern zu vertrauen.
  • Wenn die Verschlüsselung nicht mathematisch gebrochen werden kann, wie es bei PGP mit ausreichend starken Schlüsseln der Fall ist, dann ist der naheliegende nächste Angriff ein Angriff auf die Schlüssel, und Autocrypt öffnet dafür ein Scheunentor.
  • Es kommt nicht darauf an, irgendwelche Schlüssel irgendwie zu tauschen. Man braucht einen VERTRAUENSWÜRDIGEN Schlüsseltausch, der sicherstellt, dass man wirklich die richtigen Schlüssel verwendet. Das bietet Autocrypt nicht.
    In God you may trust, for encryption you have to be sure about the used keys.
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.
  • 2-Faktor-Auth bei Posteo ist ein Placebo. Wenn man die 2FA bei Posteo aktiviert, dann muss man zukünftig auf der Login Seite den Usernamen und das Passwort eingeben und danach auf einer zweiten Seite das One-Time-Passwort (OTP).

    Das Passwort, welches man auf der ersten Login Seite eingibt, ist das GLEICHE PASSWORT, das auch für den Login via IMAP, POP3, SMTP... verwendet wird!

    Üblicherweise nutzt man 2-Faktor-Auth, um sich gegen Angriffe auf die Login Credentials zu schützen (z.B. Phishing, Keylogger auf unbekannten Rechnern usw.)

    Bei Posteo könnte ein Phishing Angriff auch mit 2-Faktor-Auth wie folgt ablaufen:
    1. Die Zielperson bekommt eine eine E-Mail im passenden Design vom Posteo Support mit dem Hinweis: "Ihr E-Mail Account wird in Kürze gelöscht, da Ihr Guthaben aufgebraucht ist. Bitte prüfen Sie die Zahlungsdetails."
    2. Die E-Mail enhält einen Button: "Klicken Sie hier, um sich anzumelden"
    3. Die Zielperson klickt auf den Link und denkt sich: "Eyh - ich hab' doch 2FA, was kann da schon passieren."
    4. Auf der Phishing Seite ignoriert das Opfer die fehlenden Sicherheitsmerkmale wie EV-Zertifikat usw. und gibt den Usernamen und das PASSWORT ein. (Das passiert leider immer wieder, deshalb ist Phishing so erfolgreich.)
    5. Danach könnte das Opfer mit einer Fehlermeldung "Falsches Passwort" auf die richtige Loginseite weitergeleitet werden - das wäre einfach für den Angreifer.
    6. Während der Angreifer mit dem erschnüffelten Usernamen und Passwort die E-Mails via IMAP abruft und sich die Liste der Kontakte via CardDAV holt, kann sich das Opfer beim zweiten Versuch problemlos anmelden und merkt nicht, dass er trotz 2-Faktor-Auth mit einem simplen Phishing Angriff gehackt wurde.
    7. Wenn dann die E-Mails bei Wikileaks veröffentlicht werden oder Kriminelle per E-Mail versendete Rechnungen "korrigieren" oder Geheimdienste die Kontakte von politischen Aktivisten analysieren, dann dämmert es langsam: FAIL!
    Um sich gegen dieses Angriffsszenario schützen, könnte man nach den Empfehlungen von Posteo den Zugriff auf den E-Mail Account via IMAP, SMTP usw. verbieten, so dass nur der 2FA Login via Webinterface möglich ist. (Aber selbst der Leiter des Support von Posteo relativiert diese Empfehlung im Videotutorial.) Das Blockieren von IMAP, POP3 und SMTP ist keine Lösung, wenn man auf sichere Ende-2-Ende Verschlüsselung mit OpenPGP Wert legt. Mailvelope ist keine sichere Lösung, das sagt auch Posteo.

    Wie man eine 2-Faktor-Auth richtig einsetzt, kann man sich bei mailbox.org oder GMail anschauen. Der erste Faktor "WISSEN" darf NICHT identisch mit dem PASSWORT für den IMAP Login sein. Dann kann 2FA auch gegen Phishing u.ä. Angriffe schützen.

    Was Posteo als 2-Faktor-Auth anbietet, ist ein Placebo, weil:
    1. Wenn man der Meinung ist, dass das Passwort bei einem Login im Web­interface nicht kompromittiert werden kann, dann braucht man keine 2FA.
    2. Wenn man der Meinung ist, dass das Passwort bei einem Login im Web­interface kompromittiert werden könnte, dann schütze diese 2FA einfach nicht vollständig.
    Der Sinn von 2-Faktor-Auth mit OTP-Token besteht darin, das Passwort für den E-Mail Account vor der Kompromittierung zu schützen und nicht danach. Wenn das Passwort kompromittiert wurde, dann ist es in der Regel zu spät. Scheinbar hat man bei Posteo das Konzept von 2-Faktor-Auth mit OTP-Token nicht ganz verstanden.
  • Außerdem glänzt Posteo mit Unkenntnis gängiger Empfehlungen von NIST und BSI zur Multi-Faktor-Auth. In dem Videotutorial zur 2-Faktor-Auth empfiehlt der Leiter des Posteo Support, dass man sich die Secrets für die OTP-Generierung bei der Aktivierung der 2FA speichern oder aufschreiben sollte, damit man den OTP-Generator bei Bedarf auf ein anderes Gerät klonen könnte.

    In den aktuellen NIST Special Publication 800-63B Abschnitt 5.1.5.1 "Multi-Factor OTP Authenticators" steht zum Thema Klonen von OTP-Tokengeneratoren:
    OTP authenticators - particularly software-based OTP generators - SHOULD discourage and SHALL NOT facilitate the cloning of the secret key onto multiple devices.
    Deutsch: "Insbesondere bei OTP Software Token sollte man den User davon abraten und sie nicht dabei unterstützt, die OTP-Generatoren zu klonen."

    Das BSI hat eine ähnliche Meinung zum Klonen von Token (z.B. BSI-CS 108).

    Bei dem Sicherheits­konzept von OTP geht man davon aus, dass die Tokengeneratoren einzigartig sein sollen (unique) und nicht von einem Angreifer geklont werden können. Nur dann kann man den zweiten Faktor "Besitz" eindeutig nachweisen.

    Wenn man ein Backup braucht, um sich bei Verlust eines OTP-Tokens nicht auszusperren, dann sollte man mehrere OTP-Token authorisieren. Das entspricht den Empfehlungen von NIST und BSI zur Lösung des Problems. Klonen ist falsch!
  • Noch zwei kleine Bemerkungen, was mich bei Posteos 2FA ein bisschen stört:
    • Posteo beitet nur TOTP (Time-based OTP) an. Man kann keine HOTP-Token nutzen, die robuster und einfacher in Anwendung sind, aber schwieriger zu klonen. Somit kann man leider keinen Yubikey out-of-the-box für die 2FA verwenden sondern nur mit dem TOTP Hilfprogramm von Yubico, das aber unterwegs auf fremden Rechner nie vorhanden ist.
    • Außerdem muss man sich darauf verlassen, dass der Server sichere Secrets für OTP generiert und kann die Secrets nicht selbst auf einem Hardware Token generieren lassen und dann auf den Server hochladen.
    Andere Provider sind da flexibler. Posteo könnte noch einiges verbessern.

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:
  • Meine Frage: Warum wurden die Posteo-Server zertifiziert, obwohl die Anforderungen an die TLS-Verschlüsselung aus BSI TR-03116-4 nicht vollständig erfüllt werden? (Kryptografische Vorgaben des BSI für TLS, PGP, S/MIME usw.)

    Antwort BSI: Für den Bereich E-Mail-Transport wurden Abweichungen von der BSI TR-03116-4 als zulässig definiert, um den heterogenen Aufbau der E-Mail-Infrastruktur zu berücksichtigen. So ist es ein grundlegendes Prinzip, dass vom EMSP hochwertige vom BSI empfohlene Kryptographie gefordert wird, aber der EMSP auch mit anderen EMSPs kommunizieren darf, die vom BSI nicht (mehr) empfohlene Algorithmen oder nur Plaintext anbieten. Es wurde auch festgelegt, dass nicht alle vom BSI in TR-03116-4 definierten Algorithmen unterstützt werden müssen, sondern lediglich mindestens einer.
  • Meine Frage: In der BSI Richtlinie TR-03108-1 (Sichere E-Mail Provider) steht wörtlich:
    EMLREQ_1: TLS (user to EMSP): The communication between the EMSP systems and the user for sending and receiving emails, for identification and all other communictions to the procedure MUST proceed via TLS in accordance with BSI TR-03116-4...

    EMLREQ_2: TLS (incoming): The EMSP MUST permit connection from other EMSPs via TLS in accordance with [BSI TR-03116-4]. For incoming connections, algorithms that provide so-called forward secrecy MUST preferably be used. They MUST correspond to the recommendations from [BSI TR-03116-4]....

    EMLREQ_3: TLS (outgoing): For connections to other EMSPs, the EMSP MUST use STARTTLS.... .... ... and correspond to the recommendations from [BSI TR-03116-4].
    Wo sind in der BSI Richtlinie TR-03108-1 die zulässigen Ausnahmen von TR-03116-4 beschrieben und sehen Sie das wirklich so, dass die Nutzung von RC4-Ciphern noch eine zulässige Ausnahme sein kann?

    Antwort BSI: In Ihrem Zitat des EMLREQ_3 unterschlagen Sie n dem von Ihnen gepunkteten (...) Bereichen das Wort SHOULD, welches gemäß Definition eine Empfehlung ist, von der in begründeten Ausnahmefällen (z.B. wenn ein Großteil der E-Mails nicht mehr ankommen würde) abgewichen werden darf.

    Das EMLREQ_2 ist so zu verstehen, dass für eingehende Verbindungen mindestens einer der Algorithmen aus BSI TR-03116-4 unterstützt werden MUSS.
  • Mein Kommentar: Zu EMLREQ_2 und EMLREQ_3 ist aus meiner Sicht zu sagen, dass die BSI Richtlinien auch die zulässige Downgrade Optionen für die Verbindungen mit veralteten Mailservern anderer Provider in TR-02102-2 definieren. In TR-03116-4 wird für diesen Fall auf TR-02102-2 verwiesen. Das Problem wird also sinnvoll vom den BSI Standards adressiert. Es besteht kein Bedarf an einer weiteren Aufweichung.

    Bezüglich EMLREQ_1 (TLS to user) haben Sie sich nicht geäußert und es nicht erklärbar, warum das BSI in diesem Punkt Abweichungen von BSI TR-03116-4 zulässt.
  • Antwort BSI: Ihren Änderungswunsch, dass die Ausnahmen zur Abweichungen von der BSI TR-03116-4 besser gekennzeichnet werden, nehme ich gerne auf und denke, dass wir in der nächsten Versionen einen entsprechenden Absatz in das Kapitel 3.4.1 Deviations from [BSI TR-03116-4] aufnehmen.
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.
    • Anonym: Hallo, tolle Kritik bei euch. Es war bei Posteo aber bis zum 10. August noch schlimmer! : 1024 bit Diffie Hellman Parameter xD

      Antwort: How the NSA breaks so much crypto: Die NSA konnte den verschlüsselten E-Mail Verkehr von Posteo also bis August 2016 teilweise on-the-fly entschlüsseln (auch wenn starke Cipher verwendet wurden) und den befreundeten Geheimdiensten zur Verfüngung stellen, obwohl der Angriff ist seit über einem Jahr bekannt ist.

    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:
    • Protokoll SSLv3, Cipher RC4, und Hashfunktion MD5 wurden verwendet.
    • Der SSLv3-Verschlüsselung war mit POODLE Attack (CVE-2014-3566) angreifbar.
    • Die TLS-Verschlüsselung war mit der padding-oracle flaw attack (CVE-2016-2107) angreifbar.
    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.
    • SSLv3 wurde abgeschaltet und die Verschlüsselung ist nicht mehr via POODLE Attack angreifbar.
    • Der Cipher RC4 und die Hashfunktion MD5 werden weiterhin als Downgrade Option angeboten.
    • Die Verschlüsselung ist weiterhin mit padding-oracle flaw attack (CVE-2016-2107) angreifbar.
    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.

    • Anonym: ...mich interessiert der xmail.net E-mail Account. Was haltet ihr davon?

    • Anonym: Eine Anregung/Ergänzung für die Kategorie E-Mails (allgm.) --> Thunderbird ist das Addon "Tor-Birdy".
    Antwort: In letzter Zeit häufen sich Fragen bzw. Hinweise zu Dingen, bei denen ich den Eindruck habe, dass die Absender sich nicht die Zeit nehmen, das Privacy-Handbuch zu lesen bevor sie eine Mail schreiben.
    1. XMail.net findet man in der Liste der nicht-empfohlenen E-Mail Provider (fast ganz unten)
    2. TorBirdy findet man im Kapitel Anonymisierungsdienste - E-Mail. TorBirdy erzwingt SSL/TLS-Einstellungen, die nicht mit meinen Ansichten kompatibel sind, außerdem wird der Assistent für neue Accounts deaktiviert. Man kann sich TorBirdy passend zurechtbiegen (habe ich für die JoToSL-DVD gemacht), dann ist es aber keine Vereinfachung in der Konfiguration mehr.
    Vielleicht braucht das Handbuch mal eine Suchfunktion - hmmm?

    • Anonym: Schade, dass man mit Ihnen nicht anonym kommunizieren kann. Der Name "cane" ist nun auch nicht unbedingt aussagekräftig. Finde ich nicht ganz ok von Ihnen.

      Antwort: Sie wollen mit mir "anonym" kommunizieren, Sie selbst haben keinen Namen und auch kein wiedererkennbares Pseudonym angeboten und erwarten aber von mir einen aussagekräftigen Namen??? Meiner Meinung nach ist es völlig belanglos, ob ich "Rudolf Meier" oder "Pitschie Hufnagel" heiße.

    • Anonym: Bezüglich der Entwicklungen bei JonDonym habe ich eine Bitte an Sie. Bitte nehmen Sie mit Heise und Netzpolitik.org Kontakt auf, um diese Lage publik zu machen

      Antwort: Das ist etwas, was Sie ganz einfach selbst machen können. Heise oder Netzpolitik bieten Kontaktadressen, die Sie einfach nutzen können. Für Nachfragen von Heise oder Netzpolitik oder anderen stehe ich gern zur Verfügung (meine Kontaktadressen kennt ihr ja).

      Ich bekomme öfters Aufforderunge, mehr für die PR des Privacy-Handbuches zu tun. Warum soll ich alles selbst machen? Das ist etwas, wo jeder das Projekt ein bisschen unterstützen kann. Ihr könntet interessante Beiträge aus dem Changelog bei Twitter oder Facebook posten (wenn ihr dort einen Account habt). Ihr könntet in Blogs oder in Foren darüber schreiben.... Es gibt viele Möglichkeiten. Es sind keine Absprachen nötig, macht es einfach.

    • Anonym: auf .... steht, das die DNS Server von CCC und Digitalcourage e.V. kein DNSSEC können. Soweit ich das beurteilen kann stimmt das inzwischen nicht mehr.

      Antwort: Mein Test zeigt, dass beide DNS-Server kein DNSSEC können: > dig @213.73.91.35 +dnssec test.dnssec-or-not.net
      ....
      # ;; flags: qr rd ra; ...
      Kein ad Flag, also keine "Authenticated Data".