Ich habe mich heute dazu überwunden auch meinen letzten vServer bei der Firma Strato zu kündigen.

Dies habe ich primär deswegen getan weil ich mit der eingesetzten Technik OpenVZ nicht länger arbeiten möchte. Da ich gerne diverse Sicherheitsextensions vom Kernel (TOMOYO, AppArmor) verwende ist dies für mich sehr hinderlich. Auch werden neue Kernel die kritische Updates enthalten nur mit großer Verzögerung eingespielt.

Meinen neuen vServer habe ich bei Loomes angemietet, dieser dient erstmal aber nur als Spielwiese. Meine ganzen Produktiven Sachen liegen eh schon lange bei Hetzner.

Self signed SSL Zertifikate

Viele von uns kennen diese nervigen Meldungen die man bekommt wenn man auf eine Seite geht die sog. Self signed SSL Zertifikate verwendet.

Doch leider wissen die meisten nicht warum man gerade diese eben nicht verwenden sollte! Das möchte ich in diesem Artikel mal etwas erklären, so das man sich in Zukunft darüber etwas mehr Gedanken machen. Ich lege dabei keinen Wert darauf das ich alles bis ins letzte Detail erkläre, dafür gibt es mehr als genug andere Ressourcen im Internet.

CA - Certificate Authority

Das ist die Basis, jedes SSL Zertifikat wird von einer sog. CA unterschrieben. Mit der Unterschrift wird nicht bestätigt das es sich dabei um ein sicheres, gutes oder vertrauenswürdiges Angebot handelt. Es wird nur (mehr oder weniger brauchbar) geprüft ob eine bestimmte Domain einem bestimmten Eigentümer gehört. So soll verhindert werden das ich mir ein Zertifikat für ubuntuusers.de erstellen kann, um damit Unfug zu treiben.

Die CA prüft also nur ob der Eigentümer berechtigt ist für diese Domain ein Zertifikat zu bekomme. In der Regel werden hierzu Mails an den Admin Benutzer von einer Domain gesendet oder der WHOIS überprüft. Wie genau die geprüft wird hängt von der jeweiligen CA ab, jedoch haben die meisten Browser bestimmte Mindestanforderungen an eine CA.

Die sog. Root-Zertifikate (also Hauptzertifikate) dieser CAs sind in dem meisten Browsern bereits vorinstalliert. Das heißt der Anbieter vom Browser (z.b. Microsoft, Mozilla, Apple, ...) traut einem Anbieter soweit das er in der Lage ist zu prüfen wem die Domain gehört. Auch das hat nichts mit dem Angebot an sich zu tun, sondern nur mit der Domain!

Somit legt also der Anbieter von deinem Browser fest welche Seite du ohne Fehlermeldung ansehen kannst, und welche nicht.

Zertifikat

Jeder Server benötigt ein Zertifikat um mit SSL Arbeiten zu können. In diesem Zertifikat stehen viele Informationen drin, wie z.b. wie lange es gültig ist und für welche Domain es genutzt werden kann.

Ein solches Zertifikat wird in der Regel von der CA unterschrieben, somit kann der Browser (oder auch der Mail Client) prüfen ob ein bestimmtes Zertifikat auch wirklich von einer Vertrauenswürdigen CA kommt.

Autogrammstunde

Dieses Zertifikat können auf 3 verschiedene Arten unterschrieben werden:

• Von einer CA die viele Browser kennen
• Von einer CA die man selbst erstellt hat oder die frei ist (z.B. CACert)
• Von einem selbst

Unterschrift durch eine CA die der Browser kennt

Dies ist eine gängige Variante für viele Firmeninternetseiten. Der Vorteil ist das jeder gängige Browser ohne Fehlermeldung einen Zugang zu der Seite ermöglicht. Der Nachteil ist das dies je nach Anbieter sehr viel Geld kostet. Gerade für kleine Projekte ist daher ein kommerzielles SSL Zertifikat einfach zu teuer.

Auch ist diese Variante ab und an etwas unflexibel, z.B. wenn man Zertifikate für den internen Firmengebrauch (Intranet) benötigt. Je nachdem für welche kommerzielle CA man sich entschieden hat, gibt es mehr oder weniger Nachteile.

Unterschrift durch eine CA die nicht der Browser kennt

Dies ist eine Variante die ich auch sehr gerne verwendet wird. Der Vorteil ist dabei, das keine Kosten entstehen und man nicht einen Anbieter fördert der ggf. eh nur Unsinn mit dem vielen Geld macht.

Der Nachteil ist das ein Browser natürlich die eigene CA oder die CA von z.B. CACert nicht im Zertifikatsmanager hat. Dadurch bekommt man auch diese nervigen Fehlermeldungen. Allerdings hat man einen großen Vorteil: Man muss nur ein Root-Cert in die Browser importieren und schon kann man alle Dienste dieser CA verwenden. Z.b. kann sich eine Firma eine eigene CA bauen die für die Mitarbeiterdienste verwendet wird. Die Mitarbeiter können dieses Root-Cert importieren und somit alle Dienste ohne Fehlermeldungen sicher verwenden.

Auch wird dieses Verfahren gerne bei OpenVPN verwendet. Dort traut dann OpenVPN allen Zertifikaten die von dieser CA unterschrieben worden sind. So spart man sich viel Arbeit mit Pre-Shared-Keys usw...

Unterschrift von einem selbst

Dies ist die einfachste, aber schlechteste Möglichkeit. Den jeder Benutzer bekommt mindestens beim ersten Aufruf des Dienstes eine nervige Fehlermeldung das etwas mit der Verschlüsselung nicht stimmt.

Viele Leute haben hier die Faustregel "Das Spiel muss weitergehen!", und sorgen dafür das der Browser mit dem Jammern aufhört. D.h. der Benutzer importiert das Zertifikat in seinen Browser und stuft es als Vertrauenswürdig ein.

Hierbei gibt es aber ein ganz wichtiges Problem: Woher weiß der Benutzer das dieses Zertifikat wirklich von dem Server kommt auf den er gerade zugreift? Es gibt nämlich mehr als genug Hackertools die ein Zertifikat sehr gut fälschen können.

Der Benutzer bestätigt somit also ein Zertifikat als Vertrauenswürdig das es überhaupt nicht ist. So kommt der böse Hacker aus dem McDonals z.B. ganz leicht an dein PayPal Passwort oder deinen eBay Account.

Das Problem ist nämlich nicht das Zertifikat an sich, sondern das ein durchschnittlicher User einfach nicht in der Lage ist ein Zertifikat zu prüfen. Den folgende Daten sollten bei einem Zertifikat passen und müssen vom Anwender überprüft werden wenn es nicht von einer bekannten CA kommt:

• Fingerabdruck vom Zertifikat
• Name / Domain vom Zertifikat
• Ablaufdatum des Zertifikates
• Fingerabdruck der CA
• Name / Aussteller der CA
• Ist das Zertifikat auf einer Widerrufsliste der CA

Ich denke die meisten Anwender werden keine dieser Daten aus dem Kopf kennen, daher sollte man davon abraten vertrauliche Daten wie Passwort, Adressen, Bankverbindung über eine solche Verbindung anzugeben. Auch sollte man ein selbst signiertes Zertifikat nie ohne guten Grund dauerhaft in den Browser importieren.

Fazit

Mit wenigen Schritten kommt ein Hacker auch bei einer verschlüsselten Verbindung an deine Daten, wenn man einfach mal ohne sich groß Gedanken zu machen eine Fehlermeldung vom Browser weg klickt. Es ist daher ratsam zumindest eine CA wie z.b. CAcert zu verwenden so das der Endanwender sich relativ leicht gegen solche Angriffe absichern kann. Wünschenswert für die Anwender wäre es natürlich das CAcert direkt in den großen Browsern vertreten wäre, doch daran wird natürlich schon gearbeitet!

Gleichzeitig hat eine verschlüsselte Verbindung überhaupt nichts mit der Vertrauenswürdigkeit der Anbieter zu tun, auch wenn immer wieder mit 128 Bit SSL Verschlüsselung geworben wird. Dies ist ein reines Sicherungsmerkmal für die Datenübertragung, was der Anbieter mit den Daten macht ist wieder was komplett anderes und würde den Rahmen dieses Artikels sprengen.

Dirk hat ja auch schon darauf verlinkt, dass es ein Ranking der OpenSource Blogs gibt.

Bei mir hat es (bis jetzt!!!) nur für Platz 53 gereicht, was für mich ein Indikator ist das ich da noch einiges dran arbeiten muss. Vermutlich liegt das aber einfach nur daran, dass ich vergesse, viele Sachen die ich täglich mache zu bloggen :-/

Auf der anderen Seite wäre natürlich auch interessant zu Wissen was ihr hier eigentlich lesen wollt!

Endlich ist das Programm der Ubucon 2010 Online. Ich selbst habe mir natürlich gleich ein paar Vorträge ausgesucht die ich auf jeden Fall besuchen werde.

Freitag

Freitag haben wir natürlich erstmal die Anreise in Leipzig, danach geht es (wie jedes Jahr) direkt auf die Ubucon um beim Aufbauen mit zu helfen. Es gibt hierzu auch eine Helferliste, in welcher ich mich selbst aber noch nicht eingetragen habe. Da ich aber schon jedes Jahr mitgeholfen haben kann man natürlich wieder mit mir Rechnen.

Abgesehen davon werde ich zusammen mit einigen Kollegen eine Diskussion über unsere ganzen Server welche wir für Ubuntuusers.de und den Ubuntu Deutschland e.V. verwenden mitmachen. Dies ist mir sehr wichtig da eine bessere / zuverlässigere Serverbasis natürlich wichtig für die vielen Dienste ist, welche wir den Anwendern kostenfrei und in unserer Freizeit zu Verfügung stellen.

Samstag

Am Samstag werde ich mir auf jeden Fall den Talk / Workshop über Mercurial ansehen, welches ich zwar schon lange verwende, aber wo man doch immer wieder was neues lernen kann.

Die Server-Fragestunde steht natürlich auch wieder auf meinem Programm, was es mit Verschlüsselung auf sich hat konnte mit das Programm leider nicht verraten :-/

Sonntag

Am Sonntag ist natürlich der IPv6 Talk / Workshop genau das was ich Suche. Ich verwende IPv6 bei mir Zuhause ja schon eine Weile über einen SixXS Tunnel oder bei Hetzner für meinen Server, aber auch hier kann man noch viel lernen.

Das Closing-Event ist natürlich wie jedes Jahr ein Pflichtbesuch, zumindest wenn es sich mit der Abfahrtszeit von meinem Zug vereinbaren lässt.

Wer neulich meinen Artikel SSH-Tuning gelesen hat, dürfte auch bemerkt haben das Mercurial z.B. erst mit STRG-C das Terminal wieder hergibt. Das ganze ist natürlich relativ nervig, da es aber wohl nur wenige Programme gibt die damit Probleme haben, würde ich es in der Programmspezifischen Konfiguration beheben.

Für Mercurial müsste hierzu die ~/.hgrc so aussehen:

[ui]
ssh = ssh -C -o ControlMaster=no -o ControlPersist=no

Dies deaktiviert das SSH Multiplexing für Mercurial und schon ist das Problem natürlich verschwunden. Schöner wäre es natürlich wenn Mercurial direkt damit umgehen könnte ;-)

Ich habe mir diese Woche mal eine neue Speicherkarte für meine DSLR gegönnt. Bisher hatte ich eine SanDisk Extreme III SDHC mit 4GB Kapazität.

Mit dieser Karte war ich an und für sich ganz zufrieden, jedoch sind 4GB für eine DSLR natürlich nicht die Welt, wenn man bedenkt das ein 10 Megapixel Foto mal eben 10MB hat. Daher habe ich mich für eine 16GB große SDHC Karte von Transcend entschieden (Transcend Extreme-Speed SDHC Class 10 erhältlich u.a. bei Amazon).

Diese Karte ist, obwohl Class 10 (im Vergleich zu meiner alten Class 6 Karte von SanDisk) relativ langsam. Meine 1000D schafft so ca. ein Bild pro Sekunde wenn man mit RAW fotografiert. Bei meiner alten Speicherkarte konnte ich hier Serienbildaufnahmen machen ohne das es mal langsamer wurde, bei der neuen Karte bricht die Performance nach 5-6 Bildern auf ungefähr ein Bild alle 2-3 Sekunden ein.

Hier die Meinung von bonnie++ zu den beiden Karten. Es ist also mit Bonnie nicht sofort ersichtlich das die neue Karte wesentlich langsam ist wie die alte, was wiedereinmal zeigt wie unbrauchbar manch theoretisches Benchmark doch für die Praxis ist.

Es ist immer wieder erstaunlich wie stabil doch ein DSL Anschluss, auf einer eigentlich schlechten Leitung, läuft. Aber seht einfach selbst was mir DMT bei einem Kunden für ein Teledat 431 LAN verraten hat:

Da die Telekom ja schon seit längerem an der Bitratenadaptiven-Schaltung rumprobiert, wäre es interessant zu wissen ob das bei dieser Leitung noch einen Tick mehr Bandbreite bringen würde.

DMT ist übrigens eines meiner Lieblingstools für Windows, es gibt auch eine Alternative für Linux doch diese habe ich bis jetzt noch nicht kompiliert bekommen.

Da mir Ubuntu 10.04 nicht wirklich gefällt habe ich heute meinen Homeserver von Ubuntu Hardy auf Debian Lenny aktualisiert.

Das ganze habe ich natürlich ohne Neuinstallation gemacht, sonst hätte sich dieser Post wohl auch kaum gelohnt!

Es gibt dabei ein paar Sachen zu beachten, die ich hier nur mal grob auflisten möchte:

1. Man muss die Debian Keys importieren, damit apt nicht wegen Paketen jammert die nicht vertrauenswürdig sein sollen.
2. Es müssen vor dem Reboot und nach dem dist-upgrade, alle Pakete von Ubuntu durch die von Debian getauscht werden. Tut man das nicht wird das System ggf. nicht booten, da die Initramfs fehlerhaft sein könnte.
3. Das Paket locales muss installiert werden (wirft einem das dist-upgrade leider runter), und man muss libc6 neu installieren da sonst localedef nicht gefunden werden kann und so das erzeugen der locales fehlschlägt.

Das waren eigentlich die 3 wichtigsten Punkte die mir dabei aufgefallen sind.

Natürlich sollte man ein solches Update nur machen wenn man weis was man tut, und auch in der Lage ist die entstandenen Probleme selbst wieder fixen.

Wer wie ich oft SSH verwendet und sich gerne darüber aufregt das ein Login bei großen Schlüsseln (z.b. 4096 Bit) oft lange dauert kann SSH etwas pimpen.

OpenSSH kann nämlich sog. Multiplexing, d.h. es kann mehrere Sessions zum gleichen Server über nur eine Verbindung verwalten. Der Vorteil ist das man sich nicht über jeden Channel neu Authentifizieren muss, und somit die neue Session ziemlich schnell verfügbar ist. Nachteil ist natürlich das beim Abbruch der einen TCP Verbindung auch alle Sessions auf einmal weg sind :-/

Das ganze wird folgendermaßen in der ~/.ssh/ssh_config konfiguriert:

ControlMaster auto
ControlPath /tmp/ssh-%h-%r-%p

ControlPath sorgt dafür das der Modus aktiviert wird und automatisch eine neue multiplex Session gestartet wird wenn es noch keine gibt. Als Pfad für das nötige Controlsocket wird der unter ControlPath angegebene Pfad verwendet. Die Platzhalter werden prima in der Manpage von ssh_config erklärt (man 5 ssh_config).

Wenn man in der ssh_config spezifische Einstellungen für bestimmte Hosts hat sollte man diese Einstellungen ganz oben in die Datei schreiben, so das diese für jeden Host gelten.

Mit dem neuen OpenSSH 5.6 das gestern veröffentlich wurde gibt es noch eine zusätzliche, aber sehr nützliche Option:

ControlPersist on

Was dafür sorgt das auch beim schließen der letzten noch aktiven Session die Verbindung für immer aktiv bleibt. Natürlich sollte man aus Sicherheitsgründen statt on lieber 10m Eintragen was für 10 Minuten steht.

Lange Zeit habe ich VirtualBox als Virtualisierung, auch gerne auf Servern, verwendet. Dies hatte vor allem den Grund das VirtualBox schon 2007/2008 viele Funktionen hatte die ich bei KVM noch vermisst habe. Insbesondere libvirt steckte damals ja noch in den Kinderschuhen.

Das hat sich meiner Meinung nach deutlich verbessert, gleichzeitig versuche ich Aufgrund der aktuellen Ereignisse Oracle Produkte wenn möglich und sinnvoll zu vermeiden.

Aktuell verwende ich auf meinen Server noch Debian Lenny, welches leider ein KVM verwendet das mir viel zu alt ist. Gut das es in den Backports schon wesentlich neuere KVM Versionen gibt!

Da die Installation natürlich 1:1 in vielen Wikis erklärt wird gehe ich darauf nicht weiter ein, stattdessen hier noch ein Tipp wie man Windows Gäste von VirtualBox auf KVM portiert.

Zuerst sollte man alle Snapshots löschen und auch die VirtualBox Gasterweiterungen deinstallieren, ein Backup sollte ohnehin immer erstellt werden bevor man "mal eben" die Virtualisierung austauscht.

Der nächste Schrift ist eine Konvertierung der virtuellen Platte, welches mit diesem Befehl erledigt werden kann:

VBoxManage clonehd --format RAW datei-alt.vdi datei-neu.img

Man sollte dabei beachten das eine 40GB große Platten dann auch wirklich 40GB an Platz benötigt und das VirtualBox für diese Konvertierung einiges an Zeit benötigen kann.

Der erste Start mit KVM funktioniert mit dieser Platte dann erstmal prima, aber man sollte unbedingt noch folgende Keys in der Registry vom Windows auf 4 stellen:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Processor\Start
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Intelppm\Start

Den zweiten Key gibt es nicht auf jedem System. Nach einem reboot und der erneuten Produktaktivierung sollte nun alles wieder wie gewohnt funktionieren.