Aktualisierungen als RSS-Feed oder
auf unserem Twitter Account @PrHdb

Privacy-Handbuch

Ich bekomme immer wieder anonym Kommentare. Nur ganz selten gibt jemand eine Kontakt-Adresse für eine Antwort oder ein Gespräch an. Alle wollen ganz ganz doll anonym bleiben.

Gelegentlich möchte ich doch antworten, ein Dialog würde auch uns helfen.
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 geklickt. Am Ende vom Video blieb nur Kopfschütteln.
06.10.2017: Wire.com operational Security

Wire.com wird als neuer Star unter den Krypto-Messengern bezeichnet. Ich habe mir die (experimentelle) Linux Version von Wire.com kurz angesehen und teilweise erhebliche Sicherheitsmängel gefunden: Schlussfolgerung: Die operational Security von Wire.com ist nach einem kleinen, oberflächlichen Test (noch) nicht für sicherheitskrkitische Anwendung geeignet. Insbesondere Whistleblower sollten aus dem Beispiel von Mannings lernen und es nicht verwenden.

Disclaimer: das ist KEIN Audit sondern ein kurzer Test der Linux Version.
04.05.2017: Posteo warnt vor Mailvelope (auch: Heise.de, Golem.de), großes Kino!

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

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

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

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

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

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

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

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

Hat Posteo schnell noch eine Zertifizierung durchgepeitscht, weil sei wissen, dass sie die BSI-Anforderungen für "Sichere Mailprovider" ab Januar 2017 nicht mehr erfüllen werden? Das wäre dann wirklich eine bösartige PR-Täuschung. Oder wird Posteo.de im Jan. 2017 die nötigen Anpassungen vornehmen, um die Vorgaben des BSI zu erfüllen?

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

  • 06.10.2016: Wir bekommen noch immer E-Mails zum den Posteo Mailservern, in denen die TLS-Konfiguration von Posteo verteidigt wird unter Hinweis auf RFC xyz...

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

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

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

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

    09.09.2016: Vor einer Woche hatten wir die TLS-Verschlüsselung der Mailserver von Posteo kritisiert. Mehrere Leser hatten die Kritik an Posteo weitergeleitet und vom Support eine Antwort bekommen, die jede Kritik abweist und behauptet, bei Posteo wäre alles sicher. Wir wurden mehrfach gebeten, zu dieser Antwort von Posteo Stellung zu nehmen. Die Zitate sind aus der Antwortmail von Posteo, soweit keine anderen Quellen angegeben sind.

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

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

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

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

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

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

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

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

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

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

    Ein Test, der die Besonderheiten der Server-zu-Server-Kommunikation bei E-Mail beachtet, ist z.B.: https://de.ssl-tools.net/mailservers/posteo.de
    Kennen wir, haben wir auch zuerst als Test genommen. Im Ergebnis von letzter Woche wurde SSLv3 deutlich erkennbar als Fehler bemängelt und das hat uns auf die Idee gebracht, mit anderen Tests bei allen Mailservern mal ein bisschen genauer hinzuschauen. ;-)

    Deswegen ist die ausgehende E-Mail-Kommunikation mit DANE und der TLS-Versandgarantie auch strenger konfiguriert, damit es immer zu einer besseren Verschlüsselung kommt.
    Ach ja - der aktuelle Hype um die TLS-Versandgarantie bei Posteo. Es ist ein nettes Feature, aber ohne die fehlende TLS-Empfangsgarantie zu 50% sinnlos. Ein Beispiel:
    1. Ein Posteo-Nutzer versendet seine E-Mail mit TLS-Versandgarantie.
    2. Der Empfänger klickt auf den Antworten-Button und schickt ein "full-quote" der empfangenen E-Mail zurück. (Das kommt im realen Leben wirklich vor.)
    3. Ein SSL-interceptierender Lauscher am Draht beschnüffelt die Antwort-Mail und bekommt damit praktische alle Informationen aus 1. und 2. (und die garantiert TLS-verschlüsselten Mailversendung ist ausgehebelt).
    Statt ein kleines Feature als die Lösung der Probleme zu hypen, könnte Posteo.de etwas klarer über die (noch) bestehenden Schwächen informieren. Die aggressive PR-Strategie von Posteo ist eher gefährlich, wenn (noch) bestehenden Schwächen in Sicherheitsfunktionen unzureichend kommuniziert werden und Laien sich deshalb in Sicherheit wiegen.


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

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

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

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


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

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

    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: Die TLS-Verbindung zu privacy-handbuch.de läuft im CBC-Mode. GCM-Mode als Standard wäre besser.

      Antwort: Ich weiss, darauf habe ich aber kein Einfluss.

      Die TLS-Verbindung ist aber noch halbwegs erträglich. Wenn man sich anschaut, was bei diesem Webhoster bei SSH (für den Upload) an Ciphern angeboten wird, dass ist eine Katastrophe (OpenSSH 3.7!!!). Aber hey - den Webspace hat mir jemand kostenfrei zur Verfügung gestellt, also ist ein bisschen Nachsicht angebracht.

    • 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: grützi, die swiss privacy foundation verlinkt immer noch auf dein privacy handbuch bei awxcnx. du kannst denen ja mal stecken, dass du umgezogen bist. schöne grüsse

      Antwort: grützi zurück, aber warum schreibst Du mir das und nicht der swiss privacy foundation? Bin ich für die toten Links auf der Webseite der swiss privacy foundation verantwortlich? Email an den webmaster@... funktioniert bestimmt, wenn keine andere Kontaktadresse angegeben ist. Webmaster sind auch dankbar dafür, wenn sie solche Hinweise erhalten.

    • Anonym: Wenn man eine Nachricht absendet, wird man von https://www.anonym-surfen.de/cane auf https://anonymous-proxy-servers.net/bin/cane umgeleitet.

      Antwort: Es gibt zwei Konatktformular: www.anonym-surfen.de/cane (deutsch) und anonymous-proxy-servers.net/cane (Englisch). Beide Konatktformulare senden den Input and das gleiche Script, welches die Verschlüsselung und Weiterleitung durchführt: <form action="https://anonymous-proxy-servers.net/bin/cane" method="post"... Ich bin zu faul, eine "Ok" Meldung in Deutsch und in Englisch zu pflegen.

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

      Mich beunruhigt eigentlich die Cookie Migration in dem aktuellen Paper mehr. Es werden First-Party Cookies zu Third-Party Cookies migriert und für das Tracking verwendet. Das verschiedene Trackingdienste sich First-Party Status erschleichen, habe ich in einem Blogartikel mal beschrieben. Das Cookie-Zeug im Handbuch muss ich dringend mal überarbeiten.




    Lizenz: Public Domain