Die Aktualisierungen gibt es als RSS-Feed oder im Changelog

Warnung:

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. 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: Score: "A" - hey, geht doch). Warum der Server für die Listen vergessen wurde, ist unklar. Die Software des Servers ist veraltetet und grob geschätzt seit mindestens drei Jahren nicht aktualisiert worden, was unprofessionell und ein Sicherheitsrisiko ist.

Anonym: THIS FUCKER CHANGED CURRENT COLOR THEME !!! ui.use_standins_for_native_colors = true

ui.systemUsesDarkTheme = 0

Antwort: Ja - und es ist relevant für das Browserfingerprinting.

Gedanken zur Axolotl Verschlüsselung

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.

British signals intelligence agency Government Communications Headquarters (GCHQ) can crack end-to-end encrypted messages sent using WhatsApp and Signal.

Last Wednesday I met with the chief cryptographer at GCHQ ... And he assured me that this was feasible.

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.

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.

Mehrere Leser haben um einen Kommentar zum Beschluss des BVerfG gegen Posteo gebeten.

Antwort: Das BVerfG hat in seinem Beschluss klar gestellt, dass E-Mail Provider nicht zur anlasslosen Vorrats­daten­speicherung verpflichtet sind. Es gelten aber die mehr als 20 Jahre alten Mitwirkungs­pflichten eines Telekommunikations­providers zur Straf­verfolgung. Ein Quick Freeze Verfahren, wie es vom CCC oder der DigiGes und anderen Datenschützern im Rahmen der Diskussion um die VDS als datenschutz­freundliche Alternative vorgeschlagen wurde, sieht das BVerfG als ausreichend an.



Das BVerfG sieht keinen Bedarf zur weiteren Verhandlung. Ein Telekommunikations­provider hat geltende Gesetze zu befolgen, auch wenn das Geschäftsmodell "Daten­schutz" ist. Dazu gehören die Mitwirkungs­pflichten bei der Verfolgung schwerer Straftaten. Punkt. Dem kann sich ein E-Mail Provider wie Posteo nicht entziehen. Eine unzulässige Einschränkung von Freiheitsrechten sieht das BVerfG dabei nicht.



Die Argumentation von Posteo war für mich nicht nachvollziehbar. Sie behaupten, sie brauchen die IP-Adressen der Kunden nicht und hätten sie deshalb auch nicht. Wenn sich mein Thunderbird mit dem Mailserver von Posteo verbindet, dann schickt der Server die via POP3 abgerufenen E-Mails aber nicht irgendwo ins Internet sondern an meine IP-Adresse. Meine IP-Adresse ist also mindestens einem Server von Posteo zum Zeitpunkt der Kommunikation notwendigerweise bekannt und könnte damit auf Anforderung ("Quick Freeze") zur Verfolgung schwerer Straftaten gemäß geltenen Gesetzen protokolliert werden.



Posteo könnte eine Infrastruktur aufbauen, die die Herrausgabe der IP-Adressen unmöglich macht. Zuerst einmal würde ich einen Tor Onion Service für die Mailserver empfehlen, wie es auch andere datenschutzfreundliche E-Mail Provider anbieten (mailbox.org, Riseup, ProtonMail).



Wenn Posteo einen NAT Proxy vor die eigenen Mailserver setzt, um die IP-Adressen der Kunden gegenüber den Mailservern zu veschleiern, dann muss dieser Proxy Service von einem unabhängigen, nicht-deutschen Provider betrieben werden. Diese Internationalisierung von Komponenten war das Konzept von JonDonym, um Über­ wachung zu erschweren und trotzdem kompatibel mit geltenden Gesetzen zu bleiben.



Außerdem müsste Posteo dann seinen Kunden erklären, dass die Kunden nicht die Server Posteo kontaktieren sondern zuerst einen Proxy Betreiber, der irgendwo auf den Cayman Islands o.ä. registriert ist. Das könnte auf einige Kunden abschreckend wirken, bei denen der Schutz vor Strafverfolgung nicht im Vordergrund steht - oder?



Einfach zu sagen: "Nö - mach' ich nicht, geltende Gesetze sind mir egal weil mein Geschäftsmodell Datenschutz ist." funktioniert nicht. Bei JonDonym musste musste ich mich bereits vor mehr als 10 Jahren mit genau diesem Problem befassen und das Geschäftsmodell von JonDonym war: Datenschutz! (Die JonDos GmbH hatte offenbar andere juristische Berater, die mit uns zusammen Lösungen erarbeitet haben und uns nicht in sinnlos teure Prozesse drängen wollten.)



Btw: Messenger wie Signal App, Wire, Jabber oder Threema sind Telemedien­dienste (keine Telekommunikations­provider) und müssen daher im Gegensatz zur E-Mail Providern oder Skype keine IP-Adressen an Strafverfolger herausgeben. Die Kooperationsangebote mit Strafverfolgung wie bei Telegram im Fall von Terrorismus sind ausschließlich freiwillig.

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.

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.

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.

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: 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. 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? 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. 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. 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. 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. Btw: auch die von Prof. Schinzel als Alternative empfohlenen Messenger verwenden häufig HTML Bibliotheken zur Darstellung der Buchstaben auf dem Bildschirm - ja, wirklich.



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.)

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.

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.)

Post von den Anwälten von Posteo.de

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.

§3 Abs. 1 UWG.

nicht

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.:

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

und umsetzt

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). 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. 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!) 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 ...

2004

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.)

ist ein "gaaaanz schlimmer" Angriff auf die E-Mail Verschlüsselung mit OpenPGP und S/MIME. Ein aktiver Angreifer (Typ: ) 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).

Nachtrag:

Aber:

#Efail kompromittiert die Verschlüsselung der aktuell empfangenen E-Mail.

Ein erfolgreicher Angriff auf Autocrypt kompromittiert zukünftig versendete E-Mails.

Beobachtungen zum Kommunkationsverhalten

Kommentar zum Autocrypt Schlüsseltausch für PGP

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.)

(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.

Opportunistic Security

Some Protection Most of the Time

unbrauchbar für hohe Sicherheitsanforderungen

User A schreibt eine E-Mail und klickt auf einen Button "Sicher verschlüsseln" Die Mail wird als (verschlüsselter) Entwurf gespeichert und eine Request zum DH-Schlüsseltausch an den Empfänger gesendet. 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. Bei Bedarf könnten die ausgehandelten Schlüssel anhand des Fingerprint über einen unabhängige Kanal verifiziert werden (für hohe Sicherheitsanforderungen). Dann erfolgt die weitere Kommunikation verschlüsselt ohne weitere Interaktionen.

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: 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." Die E-Mail enhält einen Button: "Klicken Sie hier, um sich anzumelden" Die Zielperson klickt auf den Link und denkt sich: "Eyh - ich hab' doch 2FA, was kann da schon passieren." 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.) Danach könnte das Opfer mit einer Fehlermeldung "Falsches Passwort" auf die richtige Loginseite weitergeleitet werden - das wäre einfach für den Angreifer. 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. 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: Wenn man der Meinung ist, dass das Passwort bei einem Login im Web­interface nicht kompromittiert werden kann, dann braucht man keine 2FA. 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.

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: 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 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: Der Sinn von 2-Faktor-Auth mit OTP-Token besteht darin, das Passwort für den E-Mail Account der Kompromittierung zu schützen und . 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!

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: Deutsch: 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 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.

Andere Provider sind da flexibler. Posteo könnte noch einiges verbessern.

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. 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?

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.

Für wen sollen sollen die BSI Richtlinien zur TLS-Verschlüsselung gelten, wenn sie einem sicheren E-Mail Provider nicht zumutbar sind???

Es müssen AES128-GCM-SHA256 Cipher oder besser mit Forward Secrecy und TLSv1.2 für die Transportverschlüsselung verwendet werden. 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!) 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.) 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.

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)

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.

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. 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. 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.

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.

Posteo verwendet in der Kommunikation zu seinen Nutzern (IMAP, POP3, E-Mail-Einlieferung mit SMTP, HTTPS) die neuesten und sichersten Verschlüsselungsmethoden.

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.

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.

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.

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.

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

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.

Ein Posteo-Nutzer versendet seine E-Mail mit TLS-Versandgarantie. 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.) 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).

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.

erzwingen

steht auf unserer Liste der empfohlenen Provider

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....

Twitter

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. 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) 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. 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:

XMail.net findet man in der Liste der nicht-empfohlenen E-Mail Provider (fast ganz unten) 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.

Anonym: Schade, dass man mit Ihnen nicht anonym kommunizieren kann. Der Name "e;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: Hat es einen Grund TheAmnesticIincognitoLiveSystem nicht in Euer Handbuch aufzunehmen??



Antwort: Nein, TAILS ist im Kapitel Live-DVDs zu finden.

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.

In letzter Zeit haben so gefühlt 20+ Unbekannte mir geschrieben, das AdBlock Plus irgendwie Scheiße wäre, ich könnte bei Heise.de ja selbst suchen um zu lesen, wie Scheiße es ist. AdBlock Edge wäre eine viel bessere Empfehlung und das Add-on uBlock wäre noch viel besser. Ich werde nicht bei Heise.de nach "irgendwas" suchen, was "irgendwie Scheiße" sein soll. Entweder ihr habt ein konkretes Problem oder nicht. Es wäre schön, wenn ihr zumindest den Artikel zu AdBlock im Handbuch lesen würdet. Das Whitelisting von Webseiten bei Adblock Plus wird dort genannt (das ist wahrscheinlich der Punkt, der "irgendwie Scheiße" ist) und auf AdBlock Edge wird auch hingewiesen. Wenn es nichts Neues gibt, dann ist das Thema aus meiner Sicht ausreichend behandelt. uBlock ist genauso "Scheiße" (ihr könnt ja mal die Suchmaschine eurer Wahl nutzen). Wenn man über eine Alternative zu AdBlock reden möchte, dann wäre es uBlock origin. Dieses Add-on von dem früheren Autor von uBlock ist eine echte Alternative zu AdBlock, vielleicht ein bisschen besser, weil perfomanter. Das ist aber kein Grund, gleich alles umschreiben zu müssen nur weil es gerade einen Werbeblocker gibt, der kleines bisschen besser ist. Wenn man AdBlock Plus so nutzt, wie beschrieben, dann ist das aus meiner Sicht ok. uBlock origin kann man auch nutzen oder 10-20 andere listenbasierte Werbeblocker.

Wenn man AdBlock Plus so nutzt, wie beschrieben, dann ist das aus meiner Sicht ok. uBlock origin kann man auch nutzen oder 10-20 andere listenbasierte Werbeblocker.

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".

Anonym: Ich habe irgendwie kein gutes Gefühl dabei, wie Du die Möglichkeiten der polizeilichen Angriffe gegen Festplattenverschlüsselung präsentierst. Bei den genannten Beispielen geht es um Leute, die vermutlich bei den meisten keine Sympathien wecken...



Antwort: Es gibt auch andere, politische Beispiele, z.B. wenn der Staatsschutz kurz vor dem vorletzten G8-Gipfel (G8 und nicht G7!) eine Razzia bei Attack macht und 40 Computer beschlagnahmt (die gesamte Infrastruktur zur Kommunikation mit allen Kontaktdaten von Sympathisanten), und diese Aktion 2 Jahre später von einem Gericht für illegal erklärt wird. Leider zeigen die Berichte darüber nicht so schön deutlich jenes kleine Detail, auf das ich besonders hinweisen wollte.



Anonym: Ich finde es übrigens positiv, wenn die Polizei solche Mittel anwendet. Denn es zeigt, dass die Polizei sehr wohl gegen die angeblich blindmachenden Anonymisierungs- und Verschlüsselungstechniken ankommen kann...



Antwort: Wir sind da einer Meinung. Ich habe die beiden Beispiel auch ausgewählt, um nebenbei zu zeigen, dass die Polizei gegen illegale Hidden Services erfolgreich vorgehen kann. TorProject.org unterstützt übrigens das FBI direkt (Stichwort: MEMEX).

Anonym: Ich bezweifle, dass Ubuntu eine gute Empfehlung ist. Ein paar Gründe, die auch gegen Xubuntu/Lubuntu/Kubuntu sprechen, findest Du bei prism-break



Antwort: Wie man die unerwünschte Suchfunktion mit Datenübertragung an Amazon in Ubuntu entfernt, habe ich beschrieben. Der Rest wie distributionsspezifische NTP-Server, automatisch gestartetes Backup Tool, Protokolle des Systems u.ä triff auf jede andere Linux Distribution und jedes andere OS (Win, MacOS, NetBSD) ebenfalls zu.



Aber es ist ok, wenn jemand einen andere Meinung hat. Ich habe nicht den Stein der Weisen gefunden, es sind nur meine Gedanken zu dem Thema.

Anonym: Sie haben browser.send_pings vergessen sollte man auch auf false stellen oder liege ich falsch?



Antwort: Darum kümmert sich NoScript standardmäßig, habe ich deshalb nicht extra erwähnt.

Anonym: du empfiehlst ein buch, das beim kopp-verlag erscheint. der kopp-verlag ist bisher eher als dubioser rechtslastiger verlag aufgefallen. weiß nicht, ob du mit sowas zu tun haben willst...



Antwort: 1: Das Buch ist wirklich gut. Wenn es im falschen Verlag erschienen ist, dann vielleicht deshalb, weil andere Verlage es nicht drucken wollten?



2: Bei "rechtslastig" und "linkslastig" habe ich die Übersicht verloren.



Früher war es einfach, wie man bei Feuchtwanger nachlesen kann. Die geistig minder­bemittelten gründeten eine Rechts-Partei und die materiell minderbemittelten gründeten eine Links-Partei. Wer nicht wusste, ob er stärker geistig oder stärker materiell minder­bemittelt war, der blieb liberal. Heute ist es so kompliziert. Es gibt Grüne (früher mal Friedens- und Umweltbewegung), die sich als Kriegstreiber sooo weit nach rechts lehnen, dass.... oder .... – ach lassen wir das. Ein gutes Buch bleibt ein gutes Buch.

Anonym: Warnmeldung: "NoScript filtered a potential cross-site scripting (XSS) attempt from https://www.anonym-surfen.de" Das ist etwas besorgniserregend.



Antwort: Ich kann es nicht nachvollziehen. Entweder liegt es an den Einstellungen von NoScript (kann ich nicht reproduzieren, die Seite ist vollständig Javascript frei) oder es wäre wirklich besorgniserregend.



Bitte etwas mehr Informationen senden, wenn ein derartiger Fehler auftritt (Quellcode der Seite, die im Browser geladen wurde? NoScript Einstellungen? Browser Typ und OS? Welcher Tor Exit Node oder anderer Anondienst? DNS Server und IP-Adresse? ...)

Anonym: ich habe gesehen, dass Tails seit kurzem UEFI Support bietet. Die JonDo Live-DVD hat das nicht. Das heißt, Tails läuft mit moderner Win8-Hardware, die JonDo Live-DVD nicht. Meiner Meinung nach ist das ein gravierender Unterschied



Antwort: Das kann ich nicht nachvollziehen. UEFI bietet mit dem "Compatibilty Support Module" (CMS) die Möglichkeit, Betriebssystem ohne UEFI-Support zu starten. Diese System ohne UEFI-Support werden in der Boot-Auswahl (BBS) als "Legacy Boot Systems" aufgelistet. Es gibt eigentlich keine Probleme mit der JonDo Live-DVD auf UEFI-Systemen. Laut Fachpresse soll es nur ganz wenige Laptops mit UEFI ohne CMS geben, z.B das Packard Bell EasyMote ME69 BMP.



Ich sehe es eher etwas umgekehrt. Die JonDo Live-DVD kann man mit AMD 64Bit Prozessoren nutzen, TAILS kann man damit nicht nutzen.

Anonym: heise und andere Medien berichten darüber, dass Firmen immer mehr Canvas-Tracking machen. Da steht bis jetzt aber erst wenig drüber drin im Privcacy Handbuch



Antwort: Canvas-Fingerprinting ist nicht neu, wurde 2012 beschrieben: Pixel Perfect: Fingerprinting Fingerprinting Canvas in HTML5. Es wird ein Text in einem Canvas-Element gerendert und via Javascript als Bild ausgelesen. Die Ergebnisse unterscheiden sich aufgrund der Rendersoftware, installierten Schriftarten usw.



Ich habe diese Technik bisher nicht einzeln erwähnt sondern sie unter javascript-basiertes Fingerprinting zusammengefasst. ich habe die neue Studie hinzugefügt.



Verteidigung: Javascript mit NoScript deaktivieren (vor allem für alle Drittseiten). Außerdem blockiert AdBlock die Trackingscripte, die in dem aktuellen Paper beschrieben werden.

Ich bekomme immer wieder anonym Kommentare. Oft gibt gibt der Absender keine Kontak­adresse für eine Antwort oder Diskussion an. Viele wollen ganz anonym bleiben.Gelegentlich möchte ich doch antworten, ein Dialog würde auch uns helfen.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.Das Projekt scheint tot zu sein und der zugehörige Server wird scheinbar seit längerem nicht mehr gepflegt:Es wird Zeit, über Alternativen nachzudenken, falls jemand diese Mailinglisten verwendet.25.04.202004.10.2019 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: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 Auf Nachfrage betonte er nochmals: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:, 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. Dievon Signal App könnten eine sinnvolle Ergänzung sein.08.05.2019 15.03.201930.01.2019 09.01.2019 08.01.2019 01.01.201930.12.201805.08.201805.08.201802.06.201831.05.2018Vor 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: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ß gegenDie Anwälte haben sichmit 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):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.In dem anwaltlichen Schreiben wird behauptet, dass Posteo e.K. die aktuellen Richtlinien für TLS-Verschlüsselung kennt(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)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. 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.2018Hmmm ... beides gleichwertig - oder? Ein Angreifer vom Typkann 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. #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 Typaber nicht mehr gegen aktive Angreifer vom Types ist eine durchaus legitime Schlussfolgerung, wenn Autocrypt-Fans anerkennen, dass #Efail kein Problem für sie ist, da sie den Schutz gegen Angreifer vom Typselbst 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: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: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.bietet aber nurund das ist nicht kompatibel mit den Intentionen von PGP. Die Einführung dieses Konzeptes für PGP macht die Verschlüsselung kaputt undohne 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: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: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.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: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.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.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: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.Also dann mal, 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.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?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...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. ;-)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: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? 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. 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: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.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(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 vonerwä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: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 alsgeouted 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ösenzitieren? 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. EinigeNutzer 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: