© Andrey Kiselev, Fotolia.com

Bestimmte Handshakes im SSL-Protokoll führen dazu, dass es nur einen einzigen SSL-geschützten Service pro IP und Port erlaubt. Server Name Indication, eine Erweiterung für das Nachfolgeprotokoll TLS, beseitigt dieses Problem und spart damit Adressen.

Onlinebestellung abgehört, Kreditkartennummer mitprotokolliert, Konto leergeräumt – das will kein Benutzer und kann sich kein Shop-Anbieter leisten. Zum Glück nutzen sie seit Mitte der 90er Jahre das Secure Socket Layer (SSL, [1]), das Daten verschlüsselt überträgt und auch dafür sorgt, dass die Kommunikationspartner – in der Praxis zumeist nur der Server – sich verlässlich ausweisen. Das ist für Anwender besonders dann von Interesse, wenn sie beispielsweise Onlinebanking betreiben.

SSL in Verbindung mit HTTP bedeutet heute fast immer die Protokollvariante HTTPS. Sie baut zuerst eine gesicherte Verbindung auf, die als Transportschicht für die zu sendenden Daten arbeitet (das ist bei S-HTTP zum Beispiel anders, wie der Kasten “Begriffsverwirrung” zeigt). Die Verhandlung der Parameter für die Verschlüsselung findet auf Basis des DNS-Namens des Servers statt, mit dem ein Client kommuniziert.

Diese Parameter handeln Server und Client bei SSL aber bereits aus, bevor der Client den Namen seines konkreten Kommunikationspartners nennt. Das führt nun zu Problemen für jeden, der auf einer IP-Adresse virtuelle Server mit verschiedenen Namen anbieten möchte.

Davon sind besonders Webhoster oder Anbieter mehrerer Sites unterschiedlichen Namens betroffen. Neue DNS-Namen und virtuelle Server sind einfach und schnell eingerichtet, aber IP-Adressen sind ein knappes Gut. Der Protokollablauf zwischen Client und Server beim Aufbau der gesicherten Verbindung ist das Problem. Dabei ruft ein Client Seiten vom Webserver über authentifiziertes HTTPS ab: Anfangs ermittelt der Client per DNS die IP-Adresse des Servers, dessen Namen er beispielsweise von der Benutzereingabe im Browser des Anwenders hat.

Kontaktaufnahme im Detail

Der Client kontaktiert den SSL-Server über IP an der angegebenen Adresse und gibt bekannt, dass er verschlüsseln will. Er präsentiert dazu die kryptographischen Optionen, die er unterstützt. Der Server bestätigt diese Anfrage, präsentiert ein Zertifikat und schlägt eine Algorithmenkombination vor, die beide unterstützen. Wenn die seinen Vorstellungen entsprechen und zu seiner Anfrage passen, akzeptiert der Client das Zertifikat und die Optionen. Alle folgenden HTTP-Anfragen wickeln die Partner über den verschlüsselten Kanal ab (Abbildung 1).

Abbildung 1: Von der Eingabe einer URL in den Browser bis zur sicheren Übertragung von Webinhalten sind mehrere Schritte notwendig. Über einen DNS-Server findet der Client die IP-Adresse zum Namen der URL. Von dort erhält er als Teil einer SSL-Sitzung ein Zertifikat. Nur wenn dieses gültig ist und der darin enthaltene Name mit dem aus der Anfrage übereinstimmt, überträgt SSL die Inhalte.

Für den korrekten Aufbau der abgesicherten Verbindung ist ein Zertifikat notwendig, das der Server übermittelt. Ein Zertifikat ist eine elektronische Unterschrift unter einem öffentlichen Schlüssel sowie diversen assoziierten Daten. Zu ihnen gehört auch der Name des Servers, dem das Zertifikat zugeordnet ist. Per Konvention steht der DNS-Name der Website, unter dem der Webserver den virtuellen Server verwaltet, im Feld des »CommonName«. X.509v3-Zertifikate tragen diese Information als Wert in das »CN:«-Attribut ein.

Von Hennen und Eiern

Nachdem er das Zertifikat erhalten hat, schickt der Client die HTTP-Anfrage. Sie enthält jedoch auch den Namen des Servers, dem sie gilt. Folge: Laufen unter der gleichen IP-Adresse mehrere Websites, kann nur die vertraulich kommunizieren, deren Name im Zertifikat steht.

Aber nicht nur der Client kann sich mit seiner Anfrage in einer solchen Situation nicht genügend verständlich machen, wenn ein Betreiber mehrere HTTPS-Services auf einer IP-Adresse laufen lässt. Auch der Server steht vor einem ernsten Problem: Denn müsste er nach Aufbau der gesicherten Verbindung selber herausfinden, welchen privaten Schlüssel er zu wählen hat, um die verschlüsselte Anfrage des Clients zu verarbeiten, benötigte er Zugriff auf den »Host:«-Header in der HTTP-Anfrage. Die Anfrage, einschließlich des gesuchtem Headers, ist aber verschlüsselt.

Clients benötigen somit eine Möglichkeit, schon beim Aufbau der SSL-Verbindung mit dem Server an einer bestimmten IP-Adresse anzuzeigen, mit welchem Namen sie kommunizieren möchten. Mit bisherigen Mitteln war das nicht möglich.

Früher miteinander reden

Glücklicherweise ist TLS, der von der IETF spezifizierte Nachfolger von SSL, erweiterbar. So ermöglicht es die Protokollbeschreibung im RFC, bereits in der Protokollverhandlung aus der obigen Abfolge zusätzliche Daten zu übertragen [2]. Im »ClientHello« genannten Schritt erlaubt TLS, beim Verbindungsaufbau ein optionales Feld zu übertragen. Dieses Verfahren ist anderen erweiterbaren Protokollen, etwa IPv6 nicht unähnlich. In dem Feld gibt der Client den Namen des Partners an, mit dem er kommunizieren möchte. Übermittelt der Server im nächsten Schritt das korrekte Zertifikat, weiß der Client, welchen privaten Schlüssel er für die Kommunikation zu verwenden hat (siehe Abbildung 2).

Abbildung 2: Server Name Indication (SNI) macht sich den Erweiterungsmechanismus der Transport Layer Security (TLS) zunutze. Den angefragten Servernamen übergibt der Client hier bereits in der Verhandlungsphase, sodass der Server ein passendes Zertifikat präsentieren kann.

Im Grunde sind alle Teilnehmer mit dieser Übermittlung des Servernamens, die Autoren des RFC zu TLS nennen sie in Abschnitt 3.1 Server Name Indication (SNI), zufrieden. Doch die Software auf Client und Server muss das Verfahren auch unterstützen. Der Kasten “TLS-Erweiterungen in Bibliotheken” fasst die Situation für die drei Bibliotheken Gnutls, OpenSSL und NSS (Network Security Services) aus der Perspektive des Programmierers zusammen.

Als Benutzer verläuft der Einsatz des neuen Standards im besten Fall transparent. Das ist im Großen und Ganzen auch der Fall, eine Übersicht der unterstützten Clients und Server zeigt Tabelle 1. Als erster Webbrowser hat Opera SNI seit Version 8.0 unterstützt, Firefox ist seit Version 2.0 dabei. Beide erfordern es, TLS explizit einzuschalten. Dies ist aber ohnehin eine sinnvolle Einstellung, zu der viele Sicherheitsexperten raten. Der Internet Explorer beherrscht SNI ab Version 7.0, allerdings nur für Vista, nicht für Windows XP. Wer seinen Browser testen möchte, findet im Web eine Testsite, mit der er die Eigenschaften von SNI ausprobieren kann [3].

E-Mail hat es besser

Das Problem stellt sich für andere Protokolle übrigens nicht unbedingt auf die gleiche Weise wie für HTTP. So gibt es für SMTP – genauer für ESTMP – einen Mechanismus mit dem Namen STARTTLS, bei dem der Client eine normale SMTP-Verbindung aufbaut und als Begrüßung sein »EHLO« schickt [4]. Der Server antwortet mit einer Liste unterstützter Befehle. Ist »STARTTLS« darunter, schickt ein Client mit dem Wunsch, transparent zu verschlüsseln, eben diesen Befehl. Das erinnert an S-HTTP und ermöglicht auch die Kommunikation (oder doch zumindest den Austausch von Fehlermeldungen) mit Clients, die das verschlüsselte Protokoll nicht unterstützen.

Wer Sicherheitstests bei Webservern durchführt, für den lohnt sich das Wissen um SNI, bietet es doch einem möglichen Angreifer bei fehlerhafter Konfiguration einige Angriffspunkte. So könnte dieser zusätzliche Informationen über Server erlangen, die mehrere virtuelle Server auf einer IP beherbergen.

Erhält der Webserver eine Anfrage mit einem angepassten »Host:«-Header, etwa nach einem generischen Namen wie »intranet«, dann liefert er unter Umständen die Inhalte dieser Site aus. Mit der HTTP-Methode »CONNECT« lässt sich manchmal ähnlich tricksen, um illegitime interne Proxy-Verbindungen herzustellen. SNI liefert selbstverständlich nicht absichtlich interne Dokumente in ungeschützte Netzwerke aus, ein Administrator hat mit ihm allerdings eine zusätzliche Gelegenheit, um Konfigurationsfehler zu begehen. Immerhin soll der Webserver ja explizit auch Anfragen nach Inhalten von Websites verschiedener Servernamen bearbeiten.

Nützliche Erweiterung

Server Name Indication löst ein Detailproblem, das sich die Entwicklergemeinde im Rahmen des rasanten Erfolgs eingehandelt hat: Durch eine Erweiterung des TLS-Standards können Website-Betreiber nun auch mehrere Zertifikate unter einer einzigen IP-Adresse einbinden. Das ist eine notwendige Voraussetzung, um sichere virtuelle Server auf einer IP zu betreiben. Effektiv sparen Anbieter von Webanwendungen dadurch Geld und Ressourcen. Vorsicht ist allerdings geboten, wenn Hoster nun beginnen, sehr viele Webangebote auf einer einzelnen Betriebssystem-Instanz anzubieten. Ein Webshop etwa sollte doch lieber einen dedizierten Server nutzen, um bei Fehlern der Hosting-Nachbarn auf der sicheren Seite zu sein.

Technologie bereitstellen ist eine Sache, praktisch nutzbare Technik zu liefern, ist eine andere. Die wichtigsten Clients und Server haben sich des Themas Server Name Indication mittlerweile angenommen und bieten Unterstützung. Nun ist es an den Anwendern, das System auch zu nutzen, indem sie TLS in ihren Browsern auch aktivieren. (mg)