Wer, anstatt mit Outlook, mit Thunderbird seine tägliche Arbeit auf einem Exchange-Server verrichtet, benötigt kleine Helferlein. U.a. auch das einst von Ericsson entwickelte und nun durch andere Entwickler übernommene ExchangeCalendar-Plugin. In Version 4.0.0 (Beta 5) kommt nun einiges an Verbesserungen und Fixes, u.a. auch der Kompatibilität zu Lightning 5.4.2.
Bill Hess von PixelPrivacy.com hat einen schönen Artikel erstellt, wie man sein iOS (11) sicherer macht. Ich kann alle Tipps unterschreiben und füge noch hinzu: Benutzt BoxCryptor um Eure Daten in der Cloud zu verschlüsseln. So ist es für Scanner, die evtl. auf versehentlich freigegebene, aber verschlüsselte Bilder- oder Dokumentenordner in der Cloud zugreifen nicht möglich die Datei selber auszulesen.
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.
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.xAls hilfreiches Tool sei hier KeyStore Explorer 5.5.2 (Windows) erwähnt, denn dort kann man die notwendigen Eintragungen beim Signaturprozess vornehmen.
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.
Modems, FIDO, Z-Netz, Usenet, UUCP, SLIP and ISDN….
Die Welt in der ich in das Datenfernübertragungszeitalter gestartet bin, hat Harald Welte (LaForge) auf dem 34C3 sehr schön erklärt 🙂 Anklicken und staunen ….
Entwickler, die in Sachen Performanz oder auch Sidechannels in Sachen Sicherheit auf die Schliche kommen wollen, sollten sich dTrace antun. Das sagt auch raichoo auf dem 34c3 (und ich seitdem Sun es erfunden hatte 🙂 und bitte, liebe Entwickler, schaut es Euch an…. macOS, Linux, FreeBSD, NetBSD, ….
Immer wieder schön zu sehen: Vincent Haupert demonstriert wie unsicher die mobilen Banking-Apps von heute sind – jedes Jahr auf dem CCC aufs Neue. Ich bete also, wie jedes Jahr die selbe Leier:
Liebe Banker, vor allem liebe Marketing-Leuts bei den Bankers,
ihr könnt Euch noch so aberwitzigen Blödsinn einfallen lassen, aber zwei Faktoren sind besser als einer um sich Euch gegenüber zu authentifizieren. chipTAN nach wie vor ganz weit vorne… OneAppForAll ist einfach nicht sicher zu machen.
Danke Vincent für Deine immer erfrischenden Vorträge!
Weitere Infos zum Angriff: https://www1.cs.fau.de/nomorp
Die meisten Menschen verbinden mit dem Begriff „Darknet“ Kriminelle, Drogen, Waffen, … aber sehen die andere Seite, die eine Verschleierung der Identität bietet, nicht.
In einer Broschüre von der Bundeszentrale für politische Bildung wird m.E. sehr gut erklärt, dass es auch andere Techniken gibt und das in nicht-demokratischen Ländern eine Verschleierungstechnik notwendig ist, um eine lebhafte Opposition zu fördern.
Zudem werden Dinge richtig gestellt, die immernoch im Netz kursieren:
Logo der Bundeszentrale für politische Bildung
KRACK Attacks: Breaking WPA2 titelt https://www.krackattacks.com/ und sollte nun allen WLAN-Junkies aufzeigen, das LAN-Kabel oftmals die bessere Idee sind 🙂