Linux

ACHTUNG: Folgende Anleitung ist mehr ein dreckiger Hack, als "the way to do it"! Eine der Nettigkeiten des Apache Webservers (und jedes anderen modernen Webservers) ist das sogenannte "name based virtual hosting". Will heißen: eine IP, mehrere Domains und jede kriegt ihren eigenen Webinhalt. Bei Massenhostern wie 1&1 oder Strato wird sowas zu hauf eingesetzt um Sachen wie Webvisitenkarten und wie das ganze Kleingeraffel heißt zu realisieren. Technisch basiert das Verfahren auf dem Host:-Header, den HTTP 1.1 definiert: der Browser schickt beim Seitenabruf eine Information an den Server, in der er mitteilt, wie der eigentliche Hostname war, zu dem der Request gehen sollte. Anhand dieser Information kann der Server nun die passenden Seiten ausliefern. Ein kleines Problem ergibt sich hierbei mit der Nutzung von SSL. Da die Aushandlung des sicheren SSL-Kanals (und damit der wichtige Austausch der Zertifikate) bereits vor der Übertragung des ersten Bytes geschieht, kann der Server zu dem Zeitpunkt schlicht und ergreifend nicht wissen, auf welchen virtuellen Host der Client zugreifen wollte. Daher ist pro Server-IP immer nur ein Zertifikat möglich. Man muss sich also beim Common Name des Zertifikates für einen der Hosts entscheiden und damit leben, daß alle anderen, die dieses mit verwenden eine Warnung im Browser des Anwenders erzeugen. Diese Warnung ist sicherlich für Webshops und ähnliches nicht tragbar, aber für die reine Verschlüsselung einer Verbindung für einen begrenzten Nutzerkreis (wie beispielsweise der Zugriff auf das Admin-Interface meines Blogs) ist das ausreichend. Dem begrenzten Nutzerkreis kann man zumuten, das Zertifikat gegebenenfalls in den Browser zu importieren. Das Ziel ist hier ja schließlich weniger die sichere Identifikation eines vorher unbekannten Rechners, sondern vielmehr die reine Verschlüsselung der Verbindung. Was tut man nun also? Hinweis: Die Anweisungen sind mehr oder minder generisch für einen installierten Apache. Abhängig vom Maintainer, der das Paket gebaut hat können leicht andere Dateien verwendet werden. Das grundsätzliche Vorgehen ist aber gleich. Zuersteinmal benötigen wir ein Zertifikat. Die Erzeugung eines solchen ist hier nicht Bestandteil und kann zum Beispiel unter http://www.faqs.org/docs/apache-compile/apache.html (ganz unten) nachgelesen werden. Das Zertifikat und den zugehörigen Schlüssel legen wir in /etc/apache2/ssl ab (/etc/apache2 ist unser Konfigurationsverzeichnis). Danach müssen wir dem Server mitteilen, wo er sein SSL-Zertifikat findet. Dazu tragen wir in die apache2.conf folgendes ein:

SSLCertificateFile    /etc/apache2/ssl/webserver-cert.pem
SSLCertificateKeyFile /etc/apache2/ssl/webserver-key.pem

(Wir nehmen hier an, daß die Dateien entsprechend benannt worden sind.). Nun verlinken wir noch die Dateien /etc/mods-available/ssl.conf und /etc/mods-available/ssl.load jeweils nach /etc/mods-enabled, soweit das nicht schon der Fall ist, um den Apache dazu zu bringen, mod_ssl zu laden. Dieses Modul übernimmt die gesamte Arbeit hinsichtlich SSL. Außerdem tragen wir noch die Zeile Listen 443 in die httpd.conf ein, damit der Apache den HTTPS-Port öffnet. Damit ist der Server erstmal prinzipiell soweit, HTTPS-Verbindungen entgegenzunehmen. Allerdings müssen wir ihm nun noch mitteilen, daß er auf dem HTTPS-Port auf dieses Protokoll sprechen soll. Im Moment spricht er dort nämlich noch normales HTTP. Die Festlegung, daß der Server HTTPS sprechen soll wird pro Virtual Host getroffen. Im Apache 2 werden die Virtual Hosts praktischerweise meist als einzelne Dateien im Verzeichnis /etc/apache2/sites-available konfiguriert. Dort legen wir jetzt eine Datei namens ssl-secured an. In diese kommt eine Kopie des Default Virtual Host (normalerweise in default hinterlegt), an der wir einige Änderungen vornehmen. Zuerst wird die Zeile NameVirtualHost * abgeändert in NameVirtualHost <ip>:443. Damit teilen wir dem Apache mit, daß wir einen neuen name based Virtual Host auf <ip>, Port 443 anlegen wollen. <ip> ist durch die IP-Adresse des Webservers zu ersetzen. Den zugehörigen <VirtualHost *>-Eintrag ersetzen wir durch <VirtualHost <ip>:443> und tragen zusätzlich die Direktive SSLEngine on ein. Das ganze sieht dann also in etwa so aus:

<VirtualHost <ip>:443>
...
SSLEngine on
...
</VirtualHost>

Soweit, so gut. Damit haben wir für den Default-Host des Webservers (quasi alles, wofür kein spezieller VirtualHost-Eintrag exsitiert) die SSL-Konfiguration erledigt. Nun gehen wir nach und nach alle anderen Virtuellen Hosts durch (die jeweils in einzelnen Dateien liegen sollten) und kopieren dort den gesammten <VirtualHost..>...</VirtualHost>-Block, tragen im Kopf immer <ip>:443 ein und fügen die Direktive SSLEngine on hinzu. Abschließend verlinken wir die Datei ssl-secured noch nach /etc/sites-enabled/ um dem Webserver zu sagen, daß er sie laden soll und starten diesen neu. Danach sollte jeder virtuelle Host auch per HTTPS erreichbar sein. NOCHMAL: da das Zertifikat nur zu einem Host passt (der, dessen Name im CN-Feld des Zertifikats steht), ist diese Vorgehensweise nur zu empfehlen, wenn die SSL-Verbindungen von einem kleinen Nutzerkreis verwendet werden, dem man notfalls dem Import zutraut. Manche Browser werden sich trotzdem bei jeder Verbindung beschweren, daß das Zertifikat nicht zum Host passt. Bitte kommt NICHT auf die Idee, sowas generell zu verwenden. Für geschäftliche Dinge sieht das ganze schlicht unprofessionell aus, wenn man bspw. einen Webshop betritt und einem als erstes ein freundliches "Hey, da fummelt möglicherweise einer an deiner sicheren Verbindung rum" entgegenschallt.

Meine bessere Hälfte hat sich nun also ein Bluetooth-Headset geholt. Nicht um es ans Telefon anzuschließen (ihr altehrwürdiges M45 von Siemens hat keinen blauen Zahn), sondern zum skypen. An wem bleibt natürlich wieder die Einrichtung hängen? Naja... Erstmal ein Bildchen: So sieht die Hardware also aus. Zusammen etwa 70 EUR. Der USB-Adapter ist zwar vom Hersteller nicht explizit für den Betrieb mit Linux freigegeben, aber er funktioniert. Das Headset wirk insgesamt recht durchdacht. Es sitzt sicher am Ohr (egal, ob links oder rechts) und drückt auch nicht. Die auf dem Bild zu sehende Transportschale dient gleichzeitig als Ladegerät. Man legt das Headset in die Halterung und schon wird der Akku geladen. Kein Gefummel mit Steckern und ähnlichem. Sehr nett. Um die beiden Geräte für den Einsatz als Skype-Headset klarzumachen, müssen wir zuersteinmal im Kernel die Bluetooth-Unterstützung und dort zusätzlich zum offensichtlichen SCO-Support (nein, nicht die Firma) auch noch L2CAP-Support, insbesondere RFCOMM, aktivieren. Außerdem muss für den später noch zu installierenden Soundtreiber die Alsa-Unterstützung aktiv sein und mindestens ein Treiber ausgewählt. So steht es zumindest auf der Webseite des Bluetooth-Alsa-Projektes. Leider ist diese Angabe etwas ungenau. Korrekterweise muss nämlich ein Treiber ausgewählt sein, der das Symbol snd_hwdep_new benutzt. Bei meinem VIA-AC97-Treiber war das nicht der Fall, weswegen sich das Kernelmodul für das Headset beim Kompilieren über das fehlen eben jenes Moduls beschwert. Das Nachkompilieren eines anderen Soundtreibers, welcher das Symbol verwendet schafft hier Abhilfe (der Treiber muss nicht geladen werden, nur kompiliert). Ich habe dafür mal den EMU10K1-Treiber genommen. Wenn all das soweit ist, dann installiert man die Bluetooth-Alsa-Software und das Kernelmodul nach Anleitung auf der Projektwebseite. Danach noch das Bluetooth-Subsystem starten (bei Debian bspw. /etc/init.d/bluez-utils start), das rfcomm- und das snd-bt-sco-Modul laden (letzteres hängt vom ersten ab. Leider lädt es das trotzdem nicht selbständig nach, sondern beschwert sich wieder über das Fehlen von snd_hwdep_new). Wenn man dann aus der Bluetooth-Alsa-Software das Program btsco startet (mittels btsco <hwaddr>), kann man fast schon telefonieren. <hwaaddr> ist die Hardwareadresse des Headsets, welche man bekommt, indem man es in den Pairing-Modus schaltet und dann auf dem PC mittels hcitool scan nach neuen Devices sucht. Das Headset sollte dann typischerweise unter /dev/dsp1 zu erreichen sein (was man prima mit dem xmms-alsa-Plugin testen kann). Insgesamt ein sehr nettes Spielzeug. Vor allem ist bei der vorgestellten Kombination die Reichweite recht gut. knapp 9 Meter durch zwei Wände lassen die Verbindung nicht abreißen. Allerdings ist die Sprache dann nur noch schwer verständlich. Hm... ich brauch auch so ein Ding...