Freitag, 17. Juli 2015
[*]

Certificate Pinning funktioniert nicht

, 14:13

Wenn Webseiten verschlüsselte Verbindungen benutzen (https), dann wird zu Beginn des Kontakts dem Browser vom Server ein Zertifikat gezeigt, mit dem der Server versichert, dass er auch der richtige Server ist (und nicht irgendein Angreifer, der auf der Leitung steht). Die Ausstellung und Überprüfung dieser Zertifikate folgt einem hierarchischen Ansatz („X.509“), und die Liste der als vertrauenswürdig betrachteten Herausgeber sieht gar nicht so vertrauenswürdig aus, wie man sich das wünschen würde (siehe hier). Es gab immer wieder Fälle, in denen sehr neugierige Menschen sich von einer der zwielichtigeren Zertifizierungsstellen der Liste ein Zertifikat für eine bekannte Webseite organisiert haben. Sie konnten dann alles mithören ohne dass den Benutzern aufgefallen wäre, dass sie nicht direkt mit z.B. Google reden.

Eine Gegenmaßnahme für dieses Problem ist das Certificate Pinning: der Browser merkt sich für alle Webseiten, mit denen er sich schon einmal verbunden hat, das Zertifikat und schlägt Alarm, wenn ihm später ein anderes vorgezeigt wird (funktioniert natürlich nur unter der Annahme, dass die Verbindung nicht schon von Anfang an infiltriert ist, aber das nehmen wir einfach mal an).

Genau zu diesem Zweck habe ich jetzt ein paar Monate lang das Firefox-Plugin Certificate Patrol benutzt. Das Plugin funktioniert auch super, aber es bringt trotzdem keinen Sicherheitsgewinn.

Das liegt daran, dass viele größere Webseiten ihre Daten über Content Delivery Networks ausliefern, und dass die es mit den Zertifikaten nicht so genau nehmen: die über die ganze Welt verteilten Server, die Dateien für dieselbe Webseite ausliefern, scheinen oft jeder ein anderes Zertifikat zu benutzen.

Certificate Patrol bietet sogar noch die Möglichkeit, nicht schon bei einem bloßen Zertifikatswechsel zu warnen sondern erst dann, wenn das geänderte Zertifikat auch von einem anderen Herausgeber stammt, aber selbst diese geringe Integritätsbedingung halten viele CDNs nicht ein.

Wenn ich also mit Certificate Pinning im Web unterwegs bin, muss ich ununterbrochen Warnmeldungen lesen und wegklicken, lesen und wegklicken, lesen und wegklicken, und irgendwann nur noch wegklicken…

Ich werde deshalb Certificate Patrol wieder deinstallieren, denn wenn es mich irgendwann mal vor einem tatsächlichen Lauschangriff warnen würde, würde ich es wahrscheinlich nicht einmal lesen. 🙁

Mittwoch, 21. Januar 2015
[*]
Donnerstag, 20. Februar 2014
[*]

YUCZYU52

, 07:55

Aus aktuellem Anlass:

Threema-ID YUCZYU52

(Ja, ich kann das einfach so hier veröffentlichen; ist ja ein öffentlicher Schlüssel. Ob Ihr der Integrität des Kanals „Dentakus Blog“ zur unverfälschten Übermittlung dieser Information vertraut, müsst Ihr selbst entscheiden.)

Threema gibt es hier.

Dienstag, 3. Dezember 2013
[*]

Mail über Tor routen, ein Experiment

, 22:51

Ungestörte Mailkommunikation ist in den letzten Monaten schwierig geworden (d.h. eigentlich war sie das schon vorher aber wir wussten es nicht). Die Inhalte können wir verschlüsseln, aber inzwischen wissen wir, dass die Metadaten für die Überwacher fast genau so interessant sind. Wenn wenigstens beide an einer Kommunikation beteiligte Mailserver TLS nutzen, dann fällt es dem Lauscher schon schwerer, Adressen und Subject:-Zeile mitzulesen, er kann aber immernoch die IP-Verbindung zwischen den beiden Mailservern sehen. Gerade zwischen uns „Power-Usern“ mit eigenen Mailservern lassen sich dadurch praktisch alle persönlichen Verbindungen rekonstruieren.

Was aber, wenn wir diese Verbindung durch Tor schicken? Probieren wir mal aus, ob das überhaupt geht.

Als Ausgangssituation habe ich wie üblich an beiden Enden Debian GNU/Linux-Server mit Postfix als MTA und Tor — alles von Standard-Paketen installiert.

Empfang

Den empfangenden Mailserver als Tor Hidden-Service einzurichten ist einfach. Dazu muss nur ein Verzeichnis angelegt werden:

mkdir hiddenmailserver

… und in der Konfiguration der SMTP-Port freigeschaltet werden:

HiddenServiceDir /var/lib/tor/hiddenmailserver/
HiddenServicePort 25 127.0.0.1:25

Beim nächsten Start des Tor-Dienstes entsteht dann der neue Hidden-Hostname in der Datei hostname im vorher angegebenen Verzeichnis. Nachdem wir den wissen, können wir die Verbindung gleich testen (mit netcat und torsocks, einem Wrapper, der Bibliotheken zur Umleitung der Netzwerkverbindungen über Tor vorlädt):

ponos:~# torsocks nc -t u2bhrnyodeqtmlt2.onion 25
220 nyx.wazong.de ESMTP Postfix (Debian/GNU)
EHLO ich
250-nyx.wazong.de
250-PIPELINING
250-SIZE 102400000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
QUIT
221 2.0.0 Bye
ponos:~#

Funktioniert.

Versand

Wie auch die meisten anderen Mail Transport Agents ist Postfix in der Lage, abhängig von der Zieladresse den Transportkanal zu wechseln. Der Mechanismus stammt von „früher“, als es aus Kostengründen noch üblich war, bestimmte Domains über einen anderen Weg als SMTP mit Mail zu beliefern (z.B. UUCP). Die einzelnen Transportkanäle sind Programme, die in einem Verzeichnis liegen. Wir erzeugen also ein Skript, das den smtp-Transportkanal mit torsocks aufruft:

#!/bin/bash
torsocks /usr/lib/postfix/smtp $@

… und Tragen es als tor-Transportkanal in der /etc/postfix/master.cf ein:

[...]
smtp      unix  -       -       -       -       -       smtp
tor       unix  -       -       -       -       -       tor
[...]

Dann schalten wir in der /etc/postfix/main.cf den Transport-Auswahlmechanismus ein:

[...]
transport_maps = hash:/etc/postfix/transport
[...]

…, schreiben unsere Tor-Konfiguration in die /etc/postfix/transport:

wazong.de tor:[u2bhrnyodeqtmlt2.onion]

…, und laden sie in den Mailserver:

cd /etc/postfix
postmap transport

Zum Test schicken wir eine Mail. Im Logfile des versendenden Mailservers sieht das so aus:

Nov 25 23:29:02 ponos postfix/smtp[20884]: 002A82A43B6: to=<dentaku@wazong.de>, 
                relay=u2bhrnyodeqtmlt2.onion[127.0.69.0]:25, delay=14,
                delays=0.06/0.09/12/1.5, dsn=2.0.0,
                status=sent (250 2.0.0 Ok: queued as 877A97240DF)

… und in den Headern der empfangenen Mail:

Received: from ponos.wazong.lan (localhost [127.0.0.1])                                   
        by nyx.wazong.de (Postfix) with ESMTP id 877A97240DF                              
        for <dentaku@wazong.de>; Mon, 25 Nov 2013 23:29:01 +0100 (CET)

Funktioniert.

Ausblick

All das ist natürlich im Moment nur im Proof-Of-Concept-Stadium. Es skaliert in dieser Form nämlich überhaupt nicht, weil auf jedem teilnehmenden Server alle anderen über Tor erreichbaren Domains in der Transport-Map stehen müssten. Postfix kann aber den Table-Lookup an ein externes Programm auslagern (Stichwort: tcp_table) — und das könnte wieder in einem verteilten System nachsehen, also z.B. nach einem bestimmten TXT-Record im DNS. Diese Abfrage müsste dann natürlich auch durch Tor gehen, weil wir sonst DNS-Leaks riskieren.

Außerdem eignet sich die Methode nicht für komplett anonymes Mailen, weil Informationen über den vorherigen Weg der Mail noch immer in den Headern stehen. Und sie unterläuft einen Teil der üblichen Anti-Spam-Maßnahmen (z.B. Greylisting oder SPF), weil die IP-Adresse des einliefernden Mailservers ja jetzt nicht mehr bekannt ist.

Es gibt also noch einiges an Hausaufgaben zu erledigen. Trotzdem: wenn Ihr Lust habt, baut die Sache nach und schickt eine Mail an mich über u2bhrnyodeqtmlt2.onion.

Freitag, 27. September 2013
[*]

#bcs6

, 23:39

Es war wieder Barcamp in Stuttgart. Zum sechsten mal, auch diesmal wieder im Literaturhaus zwischen Liederhalle und Boschareal.

Wir waren wieder mit der ganzen Familie da, aber anders als in den Vergangenen Jahren habe ich diesmal hauptsächlich vortragend teilgenommen (nach den ursprünglichen Barcamp-Regeln hätte ich das natürlich eigentlich schon beim ersten mal machen sollen, aber naja…).

Hier meine Sessions (gehaltene und besuchte) im einzelnen:

Samstag

  • Mailverschlüsselung / Keysigning
    Diese Doppelsession hatte sich Patrick Schneider (@Schiri) vorher gewünscht. Sie bestand aus einem Vortrag von Frank Stohl, der Mailverschlüsselung mit PGP/GnuPG erklärte. Daran wollte ich ursprünglich eine GPG-Keysigning-Party anschließen, doch der zweite Vortragsslot wurde von der Diskussion vollständig ausgefüllt: statt die Schlüssel zu signieren haben wir die Theorie besprochen, wie und unter welchen Vorbedingungen denn Schlüssel zu signieren sind. Das hat so wahrscheinlich für die Teilnehmer größeren Nutzen gehabt als anders. Es folgte zum Beispiel von Oliver Gassner schon kurz danach ein Artikel mit den notwendigen Daten, um eine sichere und überprüfte Verschlüsselung aufzubauen.
    GPG-Session
    Weiterführende Artikel: Kryptographie ist schwierig und Aktion: Zeig mir Deinen Key Fingerprint.
  • Iron-Blogger-Vorstellung
    Das wurde nur eine kleine Runde, in der ich ein wenig erzählt habe, was sich in Sachen Iron Blogger seit dem letzten Barcamp und insbesondere seit der re:publica 12 getan hat.
  • Whisky-Tasteup
    Nach dem Abendessen sind wir mit der ganzen Familie nach hause gegangen, haben die Kinder ins Bett gebracht, und dann durfte ich allein noch einmal zu den Abendsessions wiederkommen. Die erste davon war das Whisky-Tasteup, für dessen Eintritt eine Flasche Whisky mitzubringen war (hatte ich noch da). Einen Ausführlichen Bericht gibt es im  Tasteup-Blog, und ich habe meine eigenen Eindrücke den Abend über getwittert.
    Klarer Sieger (zumindest von denen, die ich probieren konnte) war der Ardberg Uigeadail (und der ist gar nicht so teuer wie befürchtet, drum muss ich den unbedingt kaufen).
  • IronBlogger-Lesung
    Die Whiskyverkostung musste ich zwischendurch leider unterbrechen, weil ich versprochen hatte, einen meiner eisern gebloggten Texte vorzulesen (ich könnte es natürlich auch so formulieren, dass die Tasteup-Session hoffnungslos überzogen hat…). Diese etwas eigenartige Sessionreihenfolge führte auch dazu, dass sich außer den Lesenden kaum jemand von Alkohol oder Werwolf zu uns verirrte.
    Gut gelaunt lasen wir uns eben gegenseitig vor:

    1. Mika Kienberger: Fruchtsalat Delux – Best Of Ananasdating
    2. Ich selbst: Kryptographie ist schwierig (siehe oben)
    3. Jürgen Kaiser: Unter OS X auf NTFS-formatierte Festplatten schreiben
    4. Stefan Sommer: Berlin 2012
    5. Ute Mündlein: Was wir von „Der Pate“ lernen können
    6. Patrick Schneider: Drehen sich Blogger um sich selbst?
    7. Franziska Köppe: Im Hamsterrad? Sieben Tipps, den Alltag loszulassen
    8. und Das beste Fahrradschloss der Welt (Wuff Lock)
    9. Barbara Hoisl: Lean Startup – Entering the Enterprise?

Sonntag

  • Gadgetsession
    Hier wurde lustiges Spielzeug vorgestellt, insbesondere ist mir der Leap Motion Sensor in Erinnerung geblieben, für den ich aber wohl keine Verwendung hätte. Wesentlich praktischer fände ich da schon den Kontaktlautsprecher, der den Schall eines Smartphonelautsprechers ohne Kabel- oder Funkverbindung verstärken kann. So etwas könnte ich in der Küche gebrauchen.

Am  Sonntagmittag haben wir uns dann zu einer Taufe im Bekanntenkreis davongemacht. Eigentlich wollten wir nur kurz die Kirche besuchen, wurden dann aber überraschend noch zum Essen eingeladen. Drum habe ich den Rest des Barcamps verpasst, wenn auch auf eine der angenehmstmöglichen Weisen.

Mein Dank geht wie immer an die hervorragende Organisation (also hauptsächlich an Jan), an die wieder großartige Kinderbetreuung, ohne die wir nicht so ausgiebig und entspannt am Programm hätten teilnehmen können und an die Sponsoren. Und an Esskultur, deren Catering so hervorragend wie in den vergangenen Jahren war.

Nächstes Jahr kommen wir wieder.

Dienstag, 16. Juli 2013
[*]

Aktion: Zeig mir Deinen Key Fingerprint

, 11:12

Das ist jetzt erstmal der letzte Artikel zur Mailverschlüsselung, dann kümmere ich mich wieder um was anderes. Versprochen!

In dem Erklärbärartikel letzte Woche schrieb ich über die Identitätsprüfung im Web Of Trust:

Dazu muss über einen zweiten Kanal (der so sicher wie möglich nicht unter der Kontrolle des MITM [„Man in the Middle“] steht, am besten also ein persönliches Treffen) der sogenannte Fingerabdruck des Schlüssels miteinander verglichen werden.

Persönliche Treffen sind leider selten. Trotzdem weiß ich bei vielen von Euch, wie ihr ausseht. Ich schlage daher vor, dass wir als „zweiten Kanal“ uns alle mal mit unseren PGP-Key-Fingerprints fotografieren, und die Bilder an möglichst vielen Stellen veröffentlichen.

7383 4d64 1725 fb40  f474 5cd7 78e6 a8fa e80d

Das sieht dann ein wenig so aus wie die Bilder von Entführten mit aktueller Tageszeitung und verleiht der Verschlüsselungssache auch gleich einen leichten Guerillatouch. 😉

An je mehr unterschiedlichen Stellen derselbe Fingerabdruck zu sehen ist — am besten noch auf verschiedenen Bildern, desto unwahrscheinlicher ist, dass der „Man in the Middle“ die Bilder verfälscht hat. Mein Bild gibt es daher auch auf instagram und flickr.

Schickt mir weiter Eure PGP-Schlüssel, zeigt mir Eure Fingerprints und taggt sie mit „KeyFingerprint“!

Freitag, 12. Juli 2013
[*]

Kryptographie ist schwierig

, 13:02

In den letzten Tagen ist viel über die Arroganz derer geschrieben worden, die jetzt Verschlüsselung empfehlen. Das gipfelte in Artikeln wie diesem von Friedemann Karig, der sich dazu versteigt, die Verschlüsselung zu einer der Ursachen der Überwachung zu erklären:

Die Hackerkaste, die jetzt auf Cryptopartys den DJ gibt und sich ganz avantgardistisch und clever vorkommt, leistet der Überwachung indirekt Vorschub, indem sie sich ihr publikumswirksam entzieht. Es ist die ewige Dialektik des Informationswettrennens. Und wenn wir mithecheln, statt “Stopp!” zu rufen, sind wir mit dafür verantwortlich.

Das, mit Verlaub, ist Quark. Verschlüsselung ist, wie Frank Rieger sagt, eher „[…] wie Wohnungstür abschließen. Wäre schön wenn unnötig, leider meistenorts notwendig“

Es waren aber auch vernünftige Argumente zu lesen wie z.B. bei Martin Pittenauer (aka @map):

Das eigentliche Problem: Niemand will die wirklich harte Arbeit machen. Sichere Kommunikation, die intuitiv benutzbar ist. Angefangen bei den Konzepten, bis hin zur UI. Vielleicht sogar transparent. Stattdessen machen wir Vorträge zu GPG, die nur uns helfen uns prometheisch zu fühlen.

Damit hat er mindestens teilweise recht. Und weil irgendwer irgendwo ja mal anfangen muss, versuche ich jetzt mal, die Konzepte hinter der gängigen Mailverschlüsselung zu erklären.

Wie? Was?

Wir wollen eMails verschlüsseln. Das tun wir, weil die sonst in jedem Zwischenschritt vom Betreiber des Servers mitgelesen und auch an andere Leute weitergegeben werden können. Diese Form von Angriffen heißt Man-in-the-middle-attack (aber es gibt noch einige andere Varianten davon), und damit hat der Bösewicht in unserem Szenario einen Namen: MITM.

Zeichensalat

Mailverschlüsselung ist üblicherweise sogenannte asymmetrische Kryptographie. Das bedeutet, dass der Schlüssel aus zwei Komponenten besteht, einen öffentlichen und einen privaten Teil. Die sind jeweils Blöcke von Zeichensalat, mit denen mathematische Operationen durchgeführt werden können (irgendwas mit Primzahlen, aber darum geht es jetzt gar nicht), auf deren Basis zwei Hauptfunktionen zur Verfügung stehen:

  • Daten mit dem öffentlichen Schlüssel so verschlüsseln, dass sie mit dem privaten Schlüssel wieder entschlüsselt werden können.
  • Mit Daten und dem privaten Schlüssel eine Prüfsumme erzeugen, die mit dem öffentlichen Schlüssel überprüft werden kann, so dass garantiert ist, dass die Daten nicht mehr verändert worden sind. Das ist die sogenannte kryptographische Signatur.

Mit passender Software in meinem Mailprogramm kann ich jetzt, wenn ich den öffentlichen Schlüssel des Empfängers habe, eine Mail schicken, in der der MITM nur Zeichensalat sieht. Außerdem kann ich Mails (verschlüsselte und unverschlüsselte) so verschicken, dass ihr Inhalt nachweislich nicht mehr verändert worden ist, seit sie mit meinem privaten Schlüssel unterschrieben wurden. Wenn der Empfänger auch meinen öffentlichen Schlüssel hat, dann kann er das überprüfen. So weit, so einfach.

Vertrauen und Kontrolle

Einen größeren Knoten im Kopf erzeugt schon der zweite Aspekt: das Vertrauen in die Echtheit der Schlüssel. Die ganze Verschlüsselung ist nämlich komplett nutzlos, wenn es dem MITM gelingt, mir für meinen Kommunikationspartner einen anderen öffentlichen Schlüssel unterzuschieben. Dann kann er nämlich die Nachrichten bei sich entschlüsseln, lesen und mit dem echten Schlüssel wieder verschlüsseln. Das ist dann nur noch so sicher wie De-Mail (SCNR — 😉 ).

Gut, dass wir ja eine Möglichkeit haben, Daten zu unterschreiben. Der öffentliche Schlüssel wird also zur Bestätigung seiner Echtheit einfach mit einem anderen privaten Schlüssel unterschrieben. Dabei gibt es zwei verschiedene Ansätze,  wem dieser private Schlüssel denn gehört. Jedes mit seinen eigenen Vor- und Nachteilen.

Der Zentralistisch-Hierarchischer Ansatz

Die erste Variante arbeitet mit einer Liste von vertrauenswürdigen Zertifizierungsstellen (CA). Die öffentlichen Schlüssel der Zertifizierungsstellen sind auf Euren Rechnern schon hinterlegt, so dass die Identität des Zertifikats sofort überprüft werden kann. Wer (initial) auf die Liste der „Vertrauenswürdigen“ kommt, entscheiden Betriebssystem- und/oder Browserhersteller.

Und genau da liegt auch das Problem: nicht jede dieser Zertifizierungsstellen hat das in sie gesetzte Vertrauen tatsächlich verdient; immer wieder sind besorgniserregende Geschichten zu lesen, und wer mal einen Blick in die Liste wirft, wie sie im Moment z.B. mit Windows ausgeliefert wird, sieht dort Verisign, Microsoft und die Deutsche Telekom (überhaupt die großen Telekommunikationsunternehmen der meisten Technologieländer) friedlich neben Behörden wie dem Finnischen Personenregister (VRK).

Vertrauenswürdig, soso.

Es gibt also allen Grund zu der Annahme, dass staatliche Stellen der verschiedensten Länder keine Probleme hätten, sich für jeden von uns auszugeben.

Zusätzlich verlangen die meisten der CAs eine  jährliche Gebühr dafür, dass sie die Identität überprüfen und bestätigen (es geht aber auch kostenlos).

Diesen Ansatz verfolgt X.509, das für TLS (also z.B. https) und S/MIME verwendet wird. Das ist wiederum sein großer Vorteil, denn S/MIME beherrschen die meisten Mailprogramme, sogar auf Telefonen, ohne Zusatzsoftware.

Das Web Of Trust

Bei der zweiten Variante wird auf zentrale Stellen verzichtet. Stattdessen kann jeder Schlüsselinhaber den Schlüssel eines anderen Schlüsselinhabers unterschreiben, wenn er hinreichend davon überzeugt ist, dass Schlüssel und Identität zusammengehören. Dazu muss über einen zweiten Kanal (der so sicher wie möglich nicht unter der Kontrolle des MITM steht, am besten also ein persönliches Treffen) der sogenannte Fingerabdruck des Schlüssels miteinander verglichen werden. Ist alles in Ordnung, so kann auch ich den Schlüssel unterschreiben und mit meiner Unterschrift öffentlich zur Verfügung stellen.

Sind erst einmal einige der Schlüssel im eigenen Schlüsselbund verifiziert, erlaubt ein einstellbares „Vertrauen“ mit einem Punktesystem, zukünftig auch Schlüssel ohne persönlichen Kontakt automatisch als echt anzuerkennen, wenn sie von genügend vertrauenswürdigen Benutzern verifiziert worden sind.

dentaku@nyx:~$ gpg --list-sigs --fingerprint A8FAE80D
pub   4096R/A8FAE80D 2013-02-17 [expires: 2018-02-16]
      Key fingerprint = 7383 4D64 1725 FB40 B119  F474 5CD7 78E6 A8FA E80D
uid                  Thomas Renger (Dentaku) <dentaku@wazong.de>
sig 3        A8FAE80D 2013-02-17  Thomas Renger (Dentaku) <dentaku@wazong.de>
sig 3        6752A51F 2013-07-11  Sven Schoengarth <sven.schoengarth@gmx.net>
sub   4096R/A0CFC2A5 2013-02-17 [expires: 2018-02-16]
sig          A8FAE80D 2013-02-17  Thomas Renger (Dentaku) <dentaku@wazong.de>

Das ist so kompliziert, wie es klingt, befreit aber von der Pflicht, irgendwelchen unkontrollierbaren Unternehmen und Behörden zu vertrauen (siehe oben).

Diesen Ansatz verfolgt PGP / GnuPG, und er ist auch der Grund für die im Moment zahlreich stattfindenden CryptoPartys.

Und was ist jetzt das Problem?

So, und jetzt ist die Aufgabe, für diese Operationen ein benutzbares User Interface zu bauen. Alles, was mit Kryptographie zu tun hat, ist im Moment nämlich hässlich und benutzerfeindlich. Zum Beweis habe ich hier ein Bild von gestern, auf dem zwei gestandene Nerds ratlos vor GPGTools sitzen (Foto: @baranek):

Das muss doch, warum geht das, ach...

Da ich aber ein „typischer“ Entwickler bin, muss ich an der Stelle passen. Denn uns darf man das User Interface nie machen lassen, wenn normale Leute damit klar kommen sollen (zur Verdeutlichung: das oben abgebildete Problem habe ich schließlich gelöst, indem ich auf die Kommandozeile ausgewichen bin).

Freitag, 5. Juli 2013
[*]

keygen

, 23:20

Ich muss Abbitte leisten, denn ich habe Unsinn erzählt. Da und da.

Ich habe gemutmaßt, günstige CAs wie StartSSL würden bei der Erzeugung der X.509-Client-Zertifikate sowohl den öffentlichen als auch den privaten Teil des Schlüssels auf ihrem Server erzeugen und dann dem Benutzer zur Verfügung stellen. Das hätte bedeutet, dass sie selbst — oder irgendwelche Strafverfolgungsbehörden, die sich den privaten Schlüssel  mit irgendwelchen Gerichtsbeschlüssen besorgt hätten — später meine verschlüsselten Mails hätten entschlüsseln können.

In Wirklichkeit funktioniert das ganz anders: das schöne HTML5-Tag <keygen> weist den Browser an, den Schlüssel lokal zu erzeugen und nur den CSR zur Zertifizierungsstelle zu schicken — so, wie es gedacht ist. Außer natürlich beim Internet Explorer, der kann das nicht.

Ich revidiere also meine Meinung: lasst Euch bei StartSSL (oder einem ähnlichen Anbieter) ein X.509-Zertifikat ausstellen, dann könnt Ihr Eure Mails mit S/MIME verschlüsseln und signieren.

Mittwoch, 3. Juli 2013
[*]

Schlüsseldings

, 11:44

Letztes Jahr hatte ich das Jahr der Computersicherheit ausgerufen. Viel ist daraus nicht geworden. Die Ereignisse der letzten Tage und Wochen aber haben die guten Absichten zurück ins Gedächtnis gerufen. Wir müssen es den Diensten ja nicht leichter als nötig machen. Mails verschlüsseln wäre mal ein erster Schritt. Eigentlich wissen wir ja alle mehr oder weniger, wie das geht, nur machen müssten wir es halt — oder wie Holgi treffend sagt:

Klar haben wir die Mittel, uns gegen den Überwachungsstaat zu schützen. Wir haben ja auch die Mittel, Masern auszurotten. #

Es ist viel zu viel Bequemlichkeit eingezogen, deshalb ziehe ich mal wieder PGP aus der Tasche. Mal wieder, denn auch das Thema hatten wir vor Jahren schon einmal (aus der letzten Aktion stammt auch das Artikelbild von Bulo).

Ich gebe Euch also meinen öffentlichen PGP-Schlüssel:

mehr…

Mittwoch, 4. Januar 2012
[*]

Sicherheit jetzt!

, 12:01

Auf Anregung von Johannes Kleske (via dailycoffeebreak) rufe ich mal das Jahr der Computersicherheit aus. Ich fange mit den Tipps aus Johannes Artikel an, werde mir aber in loser Folge weitere Änderungen ausdenken und Artikel darüber schreiben.

Als erstes habe ich auf meine MacBook einen neuen Administratorbenutzer  angelegt und mir selbst die Adminrechte weggenommen (fühlt sich gleich UNIXiger an). Als zweites richtet (wie hier schon versprochen) gerade FileVault eine Festplattenverschlüsselung ein:

Das dauert noch ein paar Stunden.

Demnächst weitere Ideen…

Donnerstag, 9. Oktober 2008
[*]

Bock, Gärtner?

, 16:33

PRUST! 😀

Bei der FTD und im Lawblog (via rivva) ist zu lesen, dass Herr Schäuble die Einführung einer eMail-Adresse für jeden Bundesbürger, der sogenannten De-Mail plant. Die soll es dann in der Kommunikation mit Behörden, Banken und Versicherungen erleichtern, die Identität des Verfassers zu verifizieren. Wie würden diese Adressen dann lauten? [Steuernummer]@deutschland.de? Welcher Mechanismus würde die Fälschung der Adresse verhindern? Wer soll dafür die Serverfarm aufbauen (sowas ist schließlich nicht billig — fragt mal GMX)?

Udo Vetter schreibt ganz richtig:

Herr Schäuble sollte vielleicht gleich noch die Nutzung anderer E-Mail-Dienste außer De-Mail zur Straftat machen. Ansonsten dürfte es schwer werden, mich zu einer Anmeldung zu bewegen.

Ach ja: die vernünftige Idee wäre übrigens eine zentrale und beglaubigte Ausgabe von X.509-Zertifikaten (für S/MIME), so dass jeder Bürger die an die o.g. Parteien gerichteten Dokumente einfach digital signieren und mit der existierenden eMail-Infrastruktur verschicken könnte … aber dann könnten die Leute ihre Mails auch plötzlich verschlüsseln und das kann der ÜberwachungsInnenminister ja nicht wollen.