#!/bin/blog

April 14, 2014

Die Täuschung

Filed under: Open Source, Paranoia, Sicherheit — Tags: , — martin @ 7:15 am

heartbleedDer Begriff “Perfect Forward Secrecy” ist in dieser Zeit enorm populär. Ohne geht es einfach nicht mehr. Perfect. Perfektion. In Teilbereichen der Informationsverarbeitung ist Perfektion möglich. “Höchste Vollendung in der technischen Beherrschung und Ausführung von etwas. Vollkommene Meisterschaft.” (Duden)

Es scheint, als hätte es einen ähnlich absoluten Begriff wie “Wired Equivalent Privacy” nie gegeben. Es ist 2014 und Perfektion in Algorithmen und Software ist möglich.

Mitten in dieses Idyll platzt ein profaner und in wenigen dürren Worten beschreibbarer Bug in OpenSSL, bei dem ein paar Kilobyte aus dem Speicher des Webservers abgegriffen werden können. Das bedeutet: Updates installieren, SSL-Zertifikate tauschen, Kunden auffordern, ihre Passwörter zu ändern. Unangenehmes Zeugs.

Aber mit welcher Wahrnehmung. Der Super-GAU (noch dazu der “erste des Internets”) ist da. Der Horror-Bug. Die 11 auf einer Skala von 10. Und dabei ist es doch nur ein Bug, ein Implementierungsfehler, den ein normaler Mensch an einem normalen Tag in den Sand gesetzt hat.

Wer wirklich geglaubt hat, dass es Perfektion geben kann, dass in Sicherheit und Software so etwas wie Vollkommenheit existieren kann und dass man existenzielle Dinge von Perfektion in äußerst komplexer Software wie OpenSSL abhängig machen darf, sollte sich glücklich schätzen, wenn er rechtzeitig durch Heartbleed schonend auf den Boden der Tatsachen zurückgeholt wurde, ohne dass jemand an Leib und Leben Schaden genommen hat.

Macht weiter. Bleibt so sicher, wie ihr es im Hier und Jetzt könnt. Fallt nicht auf falsche Versprechungen rein. Lasst die Finger von der verdammten Hybris.

Alles ist nicht nur genauso in Ordnung, wie vor dem 7. April 2014, sondern sogar besser.

January 26, 2013

Kinderzimmer-Crypto by Telekom & Verisign

Filed under: Internet, Sicherheit — Tags: , , — martin @ 3:49 pm

Ich muss ja gestehen, obwohl ich mich sporadisch mit Sicherheitsgedöns auseinandersetze, war mir bisher nicht bewusst, dass der Zugriff auf das Konfigurations-Interface meines VDSL-Routers “Speedport W 722V” SSL-verschlüsselt erfolgt. Bis heute der Browser eine Fehlermeldung auswarf. Mal schauen:

20130126151658

Was ist hier passiert? Das SSL-Zertifikat ist vor 3 Wochen nach 4 Jahren Gültigkeit abgelaufen. Naja. Kommt vor. Aber Moment? Nochmal genau hinschauen:

Issuer: O=VeriSign Trust Network, OU=VeriSign, Inc., OU=VeriSign International Server CA – Class 3, OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
Validity
Not Before: Jan  7 00:00:00 2009 GMT
Not After : Jan  6 23:59:59 2013 GMT
Subject: C=DE, ST=Hessen, L=Darmstadt, O=Deutsche Telekom AG, OU=P&I PSO/DCS, CN=speedport.ip

Die Deutsche Telekom besorgt sich also beim SSL-Weltmarktführer Symantec/Verisign ein SSL-Zertifikat, ausgestellt auf einen Fantasie-Hostnamen, mit fetten 4 Jahren Laufzeit, obwohl eigene SSL-Root-Zertifikate der Telekom in jedem Browser hinterlegt sind. Da wollten die hausinternen Kollegen wohl nicht mitspielen, so dass man irgendeinen windigen Deal mit Verisign abwickeln musste. Abenteuerlich Nummer 1.

Zum anderen hat der Telekom-Support im hauseigenen Forum bereits verlautbart, dass für solche alten Geräte kein Firmware-Update kommen wird. Ist ja auch nur ein VDSL-Router, sowas benutzt heute bestimmt niemand mehr. Abenteuerlich Nummer 2:

20130126153228

Verlinkt ist ein Artikel, in dem beschrieben ist, wie man den Zertifikatshinweis im Browser dauerhaft unterdrücken kann. Abenteuerlich Nummer 3.

Die Deutsche Telekom wirft also auf ein Web-Interface im privaten LAN, oder gar im verschlüsselten WLAN, eine aufgrund des fehlenden Angriffsszenario sowieso schon unnötige Transportverschlüsselung drauf, versucht es mit dieser Verisign-Nummer halbwegs richtig zu machen, hat aber keinen Plan für den Fall, dass das Gerät länger als 3-4 Jahre beim Kunden im Einsatz ist. (Das ist nebenbei bemerkt der Grund, warum ich meinen Kunden von länger als 1 Jahr laufenden SSL-Zertifikaten abrate: Schon allein, damit man nicht in die Versuchung kommt, keinen Prozess für den Zertifikatsablauf zu etablieren.)

Als Workaround werden die Telekom-Kunden schließlich mit einer Klickanleitung trainiert dafür, wie man den Browser zwingt, auf Webseiten mit kaputten SSL-Zertifikaten zuzugreifen. Diese Zivilisationstechnik kann man ja immer mal gebrauchen. Dafür herzlichen Dank.

Endnutzer zu einem verantwortungsvollen und aufmerksamen Umgang mit solchen Sicherheitsverfahren zu erziehen, geht aber anders, liebe Telekom.

February 24, 2006

PGP-Dateinamenscodierung

Filed under: Sicherheit — martin @ 10:19 pm

Von einem Entwickler einer Firma, die ein Verschlüsselungsgateway vertreibt, wird mir grade zugerufen, was es mit der vermeintlich proprietären Codierung der Dateinamen unter PGP Universal auf sich hat. Diese Codierung ist im OpenPGP-RFC 2440 beschrieben und auch unter GnuPG implementiert. Der ursprüngliche Klartext-Dateiname kann über die Option “--status-fd” beim Entschlüsseln ermittelt werden:

$ gpg -e -r 1234ABCD foo.txt
$ mv foo.txt.gpg bar.gpg
$ gpg --status-fd=1 bar.gpg
..
[GNUPG:] PLAINTEXT 62 1140815742 foo.txt
..

December 15, 2005

PGP Universal = Braindead

Filed under: Sicherheit — martin @ 5:39 pm

Kurze Niederschrift von ein paar Sachen, die ich heute über den PGP Universal Server gelernt zu haben glaube.

Ein Anwender bei $KUNDE beschwerte sich, daß bei verschlüsselten Mails, die er von bestimmten externen Absendern bekommt, die Namen der Dateianhänge nur “Attachment1”, “Attachment2” usw. lauten und die Dateien umbenannt werden müssen, um geöffnet werden zu können. Viel Spaß damit, wenn man nicht weiß, wie die Dateien heißen sollen, in welchem Programm man sie öffnen soll, und man auch nicht unter Linux arbeitet, wo man den file-Befehl zur Hand hätte.

Mir fiel darüber hinaus auf, daß bei Multipart/Alternative-Mails der HTML-Teil als Attachment mit dem Namen “PGPExch.htm” anhängt. Bei näherer Betrachtung des Body der besagten Multipart/Alternative-Mail findet sich im MIME-Header des “PGPExch.htm”-Anhangs Header-Zeilen nach folgenden Muster:

X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable
X-Content-PGP-Universal-Saved-Content-Type: text/html;
	charset="iso-8859-2"
Content-Type: application/octet-stream;
  name="PGPexch.htm"
Content-Disposition: attachment;
  filename="PGPexch.htm"
X-PGP-MIME-Structure: alternative
Content-Transfer-Encoding: base64

Was hier passiert ist, ist dann wohl klar: PGP Universal packt den Dateinamen irgendwie ins Ergebnis der Verschlüsselung, gibt dem Anhang einen generischen Namen und eine generisches Encoding und speichert die alten Daten (bis auf den Namen natürlich) in den “X-Content-PGP-Universal-Saved”-Headern ab.
(more…)

December 11, 2004

SSH um die Ecke(n) bringen

Filed under: Notizen, Sicherheit, UNIX/Linux/BSD — martin @ 11:41 am

Die Ausgangslage

Auf einer bestimmten Baustelle muß ich, wenn ich an meine Mails kommen will, über zwei DMZ-Gateways (eins von der Baustelle und unser eigenes) sowie unseren im Rechenzentrum stehenden Webserver gehen, um schließlich auf dem Server im Büro zu landen. Als ich noch mit dem textbasierten Mutt gearbeitet habe, war das eine ganz einfache Sache, denn ich konnte mich immer der Nase nach per SSH über ein System nach dem anderen durchhangeln und dann auf der Kommandozeile des Zielsystems mutt starten:

martin@workstation:~$ cat bin/bring-mich-office.sh
#!/bin/sh
ssh -A -t dmzbox.baustelle.invalid \
 ssh -A -t webbox.example.com \
 ssh -A -t dmzbox.example.com \
 ssh officebox.example.com
martin@workstation:~$ bin/bring-mich-office.sh
martin@officebox:~$ mutt -y

Die Frickelvariante

Seit ich unter die Mausschubser gegangen bin, gestaltet sich das ganze deutlich schwieriger, denn über diese ganze Kette müssen jetzt die Ports 143 und 25 für IMAP und SMTP getunnelt werden. Dies soll geschehen, ohne daß diese Ports auf den in der Mitte der Kette befindlichen Systemen ansprechbar sind. Wenn auf den Zwischenstationen jedermann auf die weitergeleiteten Ports zugreifen könnte, hätte ich riesige unerwünschte Löcher in Firewalls gebohrt, und das will sicherlich niemand.

Um diesen Tunnel vollautomatisch aufbauen zu können, habe ich mich dann eine ganze Weile mit einer wüsten Konstruktion herumgeschlagen, bei der zunächst über alle beteiligten Funkhäuser ein “verlegter” SSH-Port durchgetunnelt wurde. In einer zweiten SSH-Sitzung habe ich über diesen dann meine beiden Applikationsports getunnelt:

#!/bin/sh
# Erste Verbindung
ssh -A -L 10022:localhost:10022 dmzbox.baustelle.invalid \
 ssh -A -L 10022:localhost:10022 webbox.examle.com \
 ssh -A -L 10022:localhost:10022 dmzbox.example.com \
 ssh -L 10022:localhost:22 officebox.example.com sleep 20 &
# Gedenkpause
sleep 10
# Zweite Verbindung
ssh -t -C -p 10022 -L 10025:localhost:25 -L 10143:localhost:143 127.0.0.1

Ich denke, ich muß nicht näher erläutern, warum das nicht nur furchtbar aussieht, sondern auch ganz schön bescheiden funktioniert hat. Bei fünf ineinandergestöpselten Port-Weiterleitungen ist die Wahrscheinlichkeit, daß alles klappt, wirklich nicht besonders hoch.
(more…)

Blog at WordPress.com.