Nachrichtenverschlüsselung für iOS und Thunderbird

Ich benutze seit vielen Jahren PGP um meine Nachrichten zu verschlüsseln, jedoch benutzen wenige meiner Briefbekanntschaften PGP, da es mit der Schlüsselverwaltung auch nicht jedemanns Sache ist.

Als Stern am Horizont tauchte in den letzten Jahren das Pretty Easy Privacy project, kurz pEp, auf, wo u.a. auch die Bielefelder vom Digitalcourage e.V. mitmischen.

Der „Default“ soll eben sein Verschlüsselung an- und nicht ausgeschaltet zu haben. Für Windows und Outlook habe ich nach dem dritten Anlauf die Version auch fehlerfrei installieren können und so läuft das Plugin nun mit. Für Thunderbird ist nun auch Besserung in Sicht: Enigmail’s nightly Build enthält nun pEp junior als Bestandteil. Enigmail ist wohl die bekannteste PGP-Implementierung und in der 2.0 ist u.a. nun auch die Betreffzeile verschlüsselt bzw. wird in den verschlüsselten Teil gezogen und im Betreff steht nur noch encrypted message – was ich nach mehreren Jahrzehnten PGP auch mal geil finde 🙂

Für iOS ist ebenfalls Besserung in Sicht und ein Testflight steht zur Verfügung. Ich spiele da mal mit, da auf iOS die PGP-Implementierung echt megaumständlich ist.

NET::ERR_CERT_COMMON_NAME_INVALID oder SSL ist nicht mehr Dein Freund

In einer Testumgebung teste ich Websocket-Verbindungen (wss://) und benutze dazu Ready!API von SmartBear mit SOAP UI Pro und WebSocket-Plugin. Soweit so gut. Nun haben wir ein Testenvironment mittels vagrant, ansible und VirtualBox aufgesetzt und was bisher lokal auf meiner Maschine funktionierte, indem ich die „self-signed“ Zertifikate auf CN=localhost in die JRE von Ready!API importierte (keytool -import -alias myalias -file <path_to>\localhost.crt -keystore cacerts -storepass changeit), funktionierte auch bestens mit einem Testnetzwerk im LAN (ohne den Import, da ein LoadBalancer wunderschön gültige Zertifikate lieferte).

Nun funktionierte es aber nicht mehr auf dem lokale „virtuellen“ VirtualBox-Netzwerk und auch Onkel Google (Chrome) verweigerte den Dienst mit

NET::ERR_CERT_COMMON_NAME_INVALID

Glücklicherweise war Onkel Google auskunftsfreudig und meinte das CN=<hostname> nicht mehr ausreiche, sondern man durch die „Extensions“ im Zertifikat möge man doch „alternative Namen“ mitgeben. Hä?

Tja, nicht der Zertifikats-Antragsteller muss die mit angeben, sondern die CA, die das Zertifikat signiert! D.h. beim Signierprozess in den Extensions

.... -ext san=dns:test1,ip:1xx.1xx.x.x

Als hilfreiches Tool sei hier KeyStore Explorer 5.5.2 (Windows) erwähnt, denn dort kann man die notwendigen Eintragungen beim Signaturprozess vornehmen.

Bleed statt Naketano ab 2019?

Heute ließ ein Fahrgast in der R80 seine Lübecker Nachrichten-Ausgabe liegen und ich nahm diese Offerte dankbar an. Was muss ich da lesen? Naketano gibt es ab Ende 2018 nicht mehr???? Alter, das ist ein Familiendrama, denn wir lieben diese Dingers!

Unsere Winterjacken sind so kuschelig, dass selbst Schweden neidisch werden…. anne Küste laufen alle mit den Bommels…ähh Kordeln am Sweater rum, eben weil es schön kuschelig ist, auch wenn man abends beim Flens im Frühling draußen sitzt.

Okay, denken wir auch mal über Nachhaltigkeit und so nach, könnte man vielleicht auf Bleed ausweichen, dann bleiben wenigstens die Kordeln erhalten und schick sind sie auch… Mal gugge, aber das Jahr fängt schon mal uncool an.