Hatte ich schon mal erwähnt, was für ein Krampf es ist, mehrere SSL-Pages auf einer IP zu hosten? Glaube nicht. Wäre das also grad einmal der richtige Zeitpunkt dafür, das einfach mal nachzuholen. Zumal Debian in letzter Zeit wiedereinmal Spaß daran gefunden zu haben, Testing als Beta-Tester einzuspannen. Aber gut, alles zu seiner Zeit.
Da ich derzeit auf dem Server etwa 10 Domains habe (Subdomains nicht mitgerechnet), und ein Teil dieser auch über SSL erreichbar sein soll, war ich länger am Suchen, wie man am besten den SSL-Support implementiert und welche Bibliothek sich dazu am besten eignet. Da bei mir auf dem Server ein Apache werkelt (mehr oder weniger durch andere Abhängigkeiten begründet), gibt es eigentlich nur zwei Möglichkeiten: mod_ssl, den die meisten kennen dürften, oder mod_gnutls. Nun ist es so: SSL und TLS sind zwar ähnlich, aber nicht gleich. Gerade nicht, wenn es darum geht, dem Server mitzuteilen, welche Domain man denn erreichen möchte.
Und hier liegt auch der eigentliche Knackpunkt: Mit mod_ssl gar nicht und mit mod_gnutls nur als stochastisches Zufallsexperiment. Das Unvermögen von mod_ssl liegt dabei weniger am Protokoll, als vielmehr daran, dass OpenSSL, was als zugrundeliegende Implementierung genutzt wird, eine Reihe von Erweiterungen, die für SNI (Server Name Indication) benötigt werden, nicht unterstützt. Zumindest nicht in den Versionen, die Debian in Pakete packt.
Bleibt als Alternative mod_gnutls. Hier sind zwar alle nötigen Funktionen und Protokoll-Erweiterungen implementiert, dafür scheitert es oftmals an der Umsetzung und Mithilfe des Clients, da die Nutzung von TLS 1.0 wegen verschiedener Protokoll-Inkompatibilitäten mit SSL v2/3 nicht standardmäßig aktiviert ist.
Was macht man also? Nicht vorhandenen oder kaputten Support installieren? Ich hab mich vorerst für mod_gnutls entschieden: Ganz einfach aus der Notwendigkeit heraus, dass ich SSL für mehrere Subdomains mit unterschiedlichen Zertifikaten brauchte. Die Lösung mit mehreren Domains in einem Zertifikat war für meinen Server nämlich leider nicht umsetzbar.
Also das entsprechende Debian-Paket libapache2-mod-gnutls 0.5.1-1 installiert und gefreut, dass alles ging. Bis der Apache von 2.2.11-2 auf 2.2.11-3 geupdated werden musste und ein richtig netter Bug zuschlug und das inzwischen erfolgreich auf Version 0.5.2-1 aktualisierte Paket mit einem Fehler beim Apache-Start seinen Dienst quittierte:
apache2: Syntax error on line 187 of /etc/apache2/apache2.conf:
Syntax error on line 1 of /etc/apache2/mods-enabled/gnutls.load: Cannot load
/usr/lib/apache2/modules/mod_gnutls.so into server:
/usr/lib/apache2/modules/mod_gnutls.so: undefined symbol: gnutls_malloc
Je nach Variation der Paket-Versionen konnte man zwar auch noch weitere undefinierte Symbole entlocken, die Tatsache, dass das Paket nicht lief, blieb aber erhalten. Also musste SSL erstmal radikal abgeschaltet werden und die zugehörigen Subdomains lahmgelegt werden.
Doch die Abhilfe für das Problem kam jetzt gesternn in Form einer Antwort im Bugtracker, die ich dann gleich mal ausprobiert hab. Nach dem dpkgbuildpackage zuerst zwar noch über 2-3 fehlende Dev-Pakete gemeckert hat (wunderte mich zwar, da ich die meist gleich mitinstallier – inklusive der DBGs 😉 – war das installieren in 10 Minuten erledigt. Die 0.5.4 ist im System zwar derzeit als 0.5.2-1 installiert, das macht aber nichts, da somit die Rückkehr zu den gebrochenen Debian-Paketen sobald es ein Update gibt wieder erfolgt.
Apropos Debian und Qualität. Das Wort Qualität setzt sich ja bekanntlich aus dem Wort Qual und einem Rest zusammen. Anschaulich machten die Debian-Maintainer dies die Tage mit dem Paket sasl2-bin, dem sie einfach mal ausredeten SASL-Datenbank-Dateien lesen oder verarbeiten zu wollen. Nach dem ich also auf diese defekte Paketversion updated, stellte ich mehr oder weniger durch Zufall fest, dass meine Verwaltungsoberfläche Probleme dabei hatte, neue Mailkonten im Mailserver anzulegen und stattdessen mit recht bizarren Fehlermeldungen den Dienst verweigerte. Die Reparatur der Login-DBs benötigte ein Downgrad, ein Version-Forbid und ein vollständiges Rebuild der SASL-DB durch die Admin-Software. Dieses war mittels eines UPDATE-Befehls in der Datenbank recht schnell eingeleitet, auf Grund diverser Nettigkeiten der Verwaltungssoftware konnte ich sogar einen netten Bug beobachten: Befand sich ein Mailpostfach mit Weiterleitung noch im Status „change“, so ließ sich der Debugger der Verwaltungsoberfläche nicht aufrufen. Stattdessen erschien einn FIXME mit Datei und Zeilennummer. Wird die Tage als Report noch an die Entwickler rausgehen, da das dann doch etwas zu heftig reagiert ist, auf etwas, was man nicht kennt 🙂
Aber bitte Debian-Entwickler: Könnt ihr eure Spiel-Versionen nicht bitte mit dem Versionstag playground in der Version kennzeichnen? Ich dachte für Spielereien gibt es unstable 😉
Soweit ich das bisher verstanden habe findet ja wenn ich normal ssl (via mod_ssl) benutzte die komplette Kommunikation zur IP verschlüsselt über das Zertifikat der jeweiligen IP/Domain statt, also sogar schon die informationen über die angeforderte Domain und so die man nutzen will, wie kann mod-gnutls da etwas anders machen, dass pro ip mehrere zertifikate genutzt werden können womit wird dann die erste Verbindung verschlüsselt ? Weil wenn hier auf einmal mit einem anderen Zertifikat gearbeitet wird, müsste das doch beim Wechsel Probleme mit dem Client machen ?
Oder hab ich da was falsch verstanden ?
Weil ich stand auch vor dem problem mehrere Domains mit eigenen SSL-Zertifikaten schützen zu wollen und hab letztendlich die ganzen geschützen Bereich dann auf eine Domain umgezogen und als Subdomains angelegt und arbeite dort mit einem *.domain.tld-Zertifikat, unschön, aber funktioniert zumindest.
Kommentar by robo47 — 13.05.2009 @ 20:20:12
Ganz vollständig verschlüsseln der Verbindung geht nicht, da Du ja eh erstmal die Verbindung mit Hilfe eines Schlüsselaustausches iniitalisieren musst. Und genau hier liegt der Unterschied zwischen den beiden Modulen: Bei mod_gnutls wird eine Erweiterung von SSL\TLS mit dem Namen SNI (Server Name Indication) verwendet, d.h. der Client sendet beim Start der Verschlüsslungsinitialisierung neben den Informationen zum Aufbau des Sitzungsschlüssels auch die Information über die Domain mit, die er erwartet. Somit kann der Server nun beim Vorzeigen „seines“ Zertifikates aussuchen, ob er für a.example.org oder b.example.org das Zertifikat vorzeigt, da er weiß, auf welche Domain der Client zugreifen will. Diese Information fehlt jedoch beim klassischen SSL (v2 immer, für SSLv3 soll es da wohl etwas analog zu SNI geben IIRC). mod_ssl implementiert AFAIK im Wesentlichen SSLv3, kann jedoch in dem Stand, der zu den meisten Distributionen mitgeliefert wird (0.9.8 bzw. 0.9.9) eben diese Erweiterung noch nicht. Die Version 1.0.0 von OpenSSL (auf der mod_ssl aufsetzt) besitzt den Support dafür, aber ich habe noch nicht gesehen, dass mod_ssl das auch wirklich an den Apache durchreicht.
Die Lösung mit dem Wildcard-Zertifikat bleibt im Endeffekt immer noch, ist aber mit gewissen Risiken verbunden, da der Angreifer im Zweifelsfalle nicht eine bestehende Subdomain manipulieren muss, sondern ein nicht-existente verwenden kann, was in Bezug auf Cache Poisoning die einfachere Wahl ist (AFAIK). Im Endeffekt muss man aber immer schauen, wie sicher es sein muss: Mit TLS haben nämlich einige Browser so ihre Schwierigkeiten, gerade in Bezug auf Timeouts und dem Silent Fallback auf SSLv3 (mit FF 3.0.x kann ich ein Lied davon singen; bei FF 3.5b4 geht es inzwischen), bzw. ob TLS überhaupt per Default aktiv ist (ist im IE 6 nicht der Fall, muss dort von Hand eingeschaltet werden).
Kommentar by BenBE — 16.05.2009 @ 11:51:38
Ah okay, vielen Danke für die Infos, dann werde ich mir mod_gnutls wohl auch mal zu gemüte führen, für die ein oder andere Domain wäre das durchaus interessant.
Kommentar by robo47 — 16.05.2009 @ 14:40:39
[…] habe ja die Tage über diverse kaputte Pakete bei Debian rumgemeckert und dabei auch mod_gnutls mit erwähnt, woraufhin es eine interessierte Zuschrift gab, […]
Pingback by BenBE’s humble thoughts » GnuTLS: Eine Alternative zu mod_ssl — 17.05.2009 @ 19:06:52
Hi,
ich habe da noch eine schöne Sache mit mod_gnutls (version 0.5.1-1).
Ich musste, wie solls auch anders sein, 2 vHosts mit SSL versehen. Der eine sollte zudem noch proxy für usermin spielen. Wenn mann nun bei diesem vHost GnuTLS verwendet – hat man eine schöne – aber feine Endlosschleife…
Auch schön in der Log zu sehen. Erst dauert es ewig, bis da überhaupt was passiert – und wenn, bricht er ab und versucht die Seite erneut zu holen. Zumindest so lange bis beim Client der timeout zuschlägt.
Noch was zum IE6, ich kann nicht bestätigen, das TLS1.0 funktioniert. Er liefert immer das falsche CRT aus.
Das selbe spielchen ist auch beim IE8.
Der FF3.5.5 und 2.5.x machen es perfekt.
Kommentar by raiserle — 30.04.2010 @ 17:36:04
Damit der IE TLS1.0 wirklich nutzt, muss dies in den Sicherheitsoptionen extra eingestellt werden. Zumindest hab ich das auf mehreren Systemen festgestellt, dass die Verwendung von TLS1.0 und SSL3 nicht von Haus aus gegeben ist.
In Bezug auf die Proxy-Konfiguration wäre interessant, inwiefern es ohne SSL\GnuTLS funktioniert, da das am eigentlichen Verhalten des Proxies nix ändern sollte. Als Workaround sollte man aber den Proxy-Host nicht als Default ausliefern, da es sonst einfach zu solchen Endlosschleifen kommen kann.
Kommentar by BenBE — 30.04.2010 @ 17:43:17
TLS1.0 ist aktiviert.
Wenn der Proxy ohne GnuTLS an den Client ausliefert – funktioniert es.
Auch wenn man mit mod_SSL an den Client ausliefert – geht es.
Kommentar by raiserle — 01.05.2010 @ 16:32:23