Skip to content

Fingerprints von SSL-Seiten prüfen

Das Desaster um die niederländische Zertifizierungsstelle DigiNotar zieht derzeit immer noch seine Kreise. Mir scheint es noch zu früh, um hier etwas dazu zu schreiben. Vielmehr will ich ein paar Worte verlieren, wie ich „meine eigene CA betreibe“. Denn schon seit längerem vertraue ich nicht, den von den Browsern mitgelieferten Zertifizierungsstellen (CA). Zumeist lösche ich alle und gebe dann einzeln Vertrauen.

Der beste Weg, um einem SSL-Zertifikat zu vertrauen, wäre, sich bei dem Betreiber zu melden und über einen sicheren Kanal den Fingerprint des Zertifikats zu klären. Mein Browser zeigt mit für die Seite Wikipedia-SSL-Seite den Fingerprint (SHA-1) BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E an. Wenn ich bei der Wikipedia anrufe und diese mir denselben nennen, so habe ich das korrekte Zertifikat. Dabei nehme ich natürlich an, dass das Telefon ein sicherer Weg zum Austausch der Informationen ist. Aber beispielsweise druckt die lokale Sparkasse eben diesen Fingerprint auf ihre Dokumente. Damit kann ich das als Kunde leicht verifizieren.

Wie das Beispiel Wikipedia aber schon zeigt, ergibt sich da ein Problem.Woher bekomme ich den Fingerprint? Muss ich bei Jimmy Wales direkt anrufen oder gar nach FloridaKalifornien¹ reisen? Hier kam nun meine Idee ins Spiel.

Ich habe auf diversen Servern einen Zugang, d.h. ich kann mich von der Ferne einloggen und dann dort arbeiten. Die Rechner stehen in verschiedenen Netzen und zum Teil auf verschiedenen Kontinenten. Nun logge ich mich auf den Servern ein, lade das Zertifikat herunter und lasse mir den Fingerprint anzeigen. Wenn dieser auf allen Rechner gleich ist, dann gehe ich davon aus, dass ich das korrekte Zertifikat angezeigt bekomme. In dem Fall akzeptiere ich das und vertraue dem. Sollten die Fingerprints abweichen, dann akzeptiere ich das nicht und recherchiere dem in der Regel ein wenig hinterher.

Jörg Sommer hat das nun ein wenig automatisiert und ein zsh-Skript (Quelltext weiter unten) geschrieben. Das wird folgendermaßen aufgerufen:

ssl-fp-check [-l] sslsi.te[:port] ssh1 [ssh2] [ssh3] ...

Dabei ist sslsi.te die Webseite, die geprüft werden soll. Ohne die Angabe eines Ports verwendet das Skript standardmäßig 443. Danach wird eine oder mehrere SSH-Verbindungen angegeben. Das Skript wird nun versuchen, sich überall einzuloggen und gibt dann den Fingerprint aus. Für den Fall, dass es auf dem Zielsystem kein OpenSSL gibt, existiert die Option -l. Dabei wird dann ein Tunnel gebaut und das lokale installierte OpenSSL verwendet.

Also für Wikimedia habe ich folgendes eingeben:

ssl-fp-check secure.wikimedia.org a b c d
a: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E
b: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E
c: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E
d: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E

Die SSH-Server a, b, c und d gaben also denselben Fingerprint aus. Also würde ich dem ganzen doch vertrauen. :-)

Ich werde das Skript jetzt wahrscheinlich immer verwenden. Es macht das Leben doch deutlich einfacher.

Continue reading "Fingerprints von SSL-Seiten prüfen"

Tip #20: Effektive Suche in der History

Jeder Shellnutzer wird die Tastenkombination Strg+R kennen. In der Standardkonfiguration sucht diese in der Liste aller eingegebenen Befehle nach der Kombination. Also beispielsweise könnte Strg+R und die Eingabe von ls folgendes ergeben:

jens@huehnersuppe:~/ > ls -lart /usr/share/doc/fr*
bck-i-search: ls_

In der zsh ab Version 4.3.9 kann man diese Suche auch mit Mustern ergänzen. Im Normalfall ist Strg+R an history-incremental-search-forward gebunden. Für die Suche nach Mustern musst du ein neues Keybinding anlegen oder das alte überschreiben:

jens@huehnersuppe:~/ > bindkey “^R” history-incremental-pattern-search-forward
jens@huehnersuppe:~/ > grep -ls -E foo /usr/src/linux/kernel.java
bck-i-search: ls*kerne_

Im obigen Beispiel wurde das alte Keybinding überschrieben und dann nach einem Ausdruck gesucht, der ls gefolgt von kerne enthält. Das Feature wird mir sicher viel Spass bereiten. ;-)

Tip #19: Wo bin ich?

Falls ihr mal wieder die Orientierung verloren habt, so hilft euch folgende zsh-Funktion:

function whereami() {
  wget -q “http://maps.google.com/maps/geo?output=csv&oe=utf-8&ll=$1,$2” -O - | cut -f3- -d, 
}

Während des Verfassens des Blogeintrages befand ich mich also in, tipper, tipper, tipper whereami $(($RANDOM * 90/65535. )) $(($RANDOM * 180/65535. )), Amritsar, Punjab, India. :-)

In Anlehnung an Tip #872 Reverse geocode with bash.

Tip #17: Lieblingseditor nutzen

Gestern abend organisierte unsere lokale LUG ein zsh-Gespräch. Dort sollten verschiedene interessante Einstellungen zur zsh besprochen werden. Jörg hatte einen besonders netten Tip:

EDITOR=${$(whence -p vim emacs jed xjed nano mcedit ed)[1]}

Der Befehl whence sucht im Pfad nach den angegebenen Programmen und legt die gefundenen in einem Array ab. Das erste Element des Arrays wird dann ausgewählt und als Variable EDITOR gespeichert. Wenn auf dem System kein vim installiert ist, würde emacs (sofern vorhanden) als Editor festgelegt werden. Sollte keiner der aufgeführten Editoren vorhanden sein, wird der ed genutzt. Denn dieser sollte immer installiert sein.

Wer es noch ein wenig weiter treiben will, setzt einen Alias: alias vim=$EDITOR. So kann man immer vim eingeben und bekommt den passenden Editor. Jedoch kann das Nebenwirkungen haben und du solltest gut überlegen, ob das der richtige Weg ist.

Tip #16: Automatisch Zeit messen

Hin und wieder laufen Programme recht lange und im Nachhinein fällt mir ein, dass ich gern gewusst hätte, wie lange das Programm gelaufen ist. Jetzt könnte ich das Programm nochmal starten und entsprechende Befehle mitgeben. Viel einfacher ist jedoch die Variable REPORTTIME in der zsh. Dieser wird eine natürliche Zahl übergeben, welcher als Sekunden interpretiert wird. Wenn ein Programm länger läuft als der Wert, der in REPORTTIME gesetzt ist, dann gibt die Zsh automatisch, Statistiken zur Zeit aus:

jens@jurkki: ~> export REPORTTIME=2
jens@jurkki: ~> kommando --was --lange --dauert
12,23s user 28,76s system 98% cpu 23,812 total
tweetbackcheck