SSL-ZertifikateSSL-Verschlüsselung richtig einsetzen

SSL-Verschlüsselung ist ein wichtiges Sicherheitsmerkmal

SSL-Zertifikate

Sicherheit gehört für Nutzer zu den wichtigsten Entscheidungskriterien bei der Wahl ihres Online-Shops. Und auch das Backend eines Content-Management-Systems will geschützt werden, wenn sich Redakteure beispielsweise über ein ungeschütztes WLAN einwählen. Für all diese Zwecke greift man im Web gern zur SSL-Verschlüsselung.

Aber was passiert da eigentlich, wo liegen die Grenzen und wie setzt man SSL ein? Dieser Artikel antwortet auf die häufigsten Fragen und versucht, einen Überblick über das Thema zu geben.

Auf SSL umschalten

Um eine gesicherte SSL-Verbindung zu nutzen, müssen Sie keine besonderen Funktionen in Ihren Skripts aufrufen oder Ähnliches. Es reicht aus, auf die zu verschlüsselnde Seite mit https:// statt http:// zu verlinken – ein SSL-Zertifikat auf dem Server natürlich vorausgesetzt. Die meisten Web-Anwendungen wie Shops oder Login-Bereiche von Content-Management-Systemen bringen dafür in der Administrationsoberfläche einen Schalter mit, mit dem die SSL-Verschlüsselung aktiviert werden kann.

Um SSL für alle Seiten zu erzwingen, gibt es mehrere Varianten: Entweder Sie verwenden Ihre serverseitige Technik und lehnen HTTP-Verbindungen ab, oder Sie erzwingen per Redirect des Webservers den sicheren Umweg.

Hintergründe

SSL-Zertifikate

Die Basis von SSL sind URLs mit HTTPS, die eine gesicherte Verbindung zwischen Browser und Server herstellen. Das Ganze funktioniert technisch sehr einfach: Das SSL-Zertifikat wird vom Server an den Browser geschickt. Das SSL-Zertifikat besteht aus einem öffentlichen Schlüssel für die Verschlüsselung der Daten und einem privaten zum Entschlüsseln. Wenn der Browser per HTTPS eine gesicherte Verbindung aufbaut, authentifizieren sich Browser und Server mit einem so genannten SSL-Handshake. Dabei wird ein Verschlüsselungsverfahren vereinbart und ein Sitzungsschlüssel für die aktuelle Sitzung eingerichtet. Rein technisch gesehen ist SSL in mehrere Schichten unterteilt: Die eine ist für Handshake und Abklärung zuständig und enthält unter anderem das SSL Handshake Protocol, die andere bildet das SSL Record Protocol, das für die eigentliche Verschlüsselung sorgt.

SSL heißt in der Langform Secure Sockets Layer und klinkt sich im OSI-Schichtenmodell zwischen der Transportschicht (TCP) und der Anwendungsschicht (HTTP oder SMTP) ein. SSL ist ursprünglich eine Erfindung vom Browser-Pionier Netscape und der Firma RSA Data Security und stammt schon aus dem Jahr 1994. Microsoft reagierte damals mit einer Konkurrenztechnik, Private Communication Technology. Die Vorteile dieser Technik wurden dann in SSL 3.0 aufgenommen und haben sich als Quasi-Standard etabliert.

1999 wurde aus SSL das neue Akronym TLS. TLS steht für Transport Layer Security und TLS 1.0 ist aus SSL 3.0 mit einigen leichten Anpassungen hervorgegangen. Der Standard wird bei der Internet Engineering Task Force (IETF) unter der Nummer 2246 geführt. Mittlerweile gibt es die TLS-Version 1.1 unter der Nummer 4346. In der Praxis sind allerdings vor allem SSL 3.0 und TLS 1.0 im Einsatz.

Zertifikate

SSL-Zertifikate

Der wichtigste Bestandteil einer SSL-Verbindung ist das Zertifikat, das vom Server geschickt wird. Technisch handelt es sich dabei um ein X.509-Zertifikat. X.509 ist ein Standard der International Telecommunication Union. Zwar kann eine SSL-Verbindung auch ohne Zertifikat des Servers aufgebaut werden, in der Praxis kommt dies aber kaum vor, da der Sinn einer SSL-Verbindung ja ist, einen Gegenpart zu identifizieren.

Auf der anderen Seite kann auch der Client ein Zertifikat besitzen, das beispielsweise im Browser verwaltet wird. Mit diesem Zertifikat identifiziert er sich beim Server. Das kommt in der normalen Webpraxis selten vor, ist aber beispielsweise sinnvoll, wenn zwei Server über Web Services miteinander funken. In diesem Fall sollte sich auch der Service-Konsument im SSL-Handshake mit einem eigenen Zertifikat identifizieren.

In der SSL-Architektur ist es wichtig, dass das Zertifikat identifizierbar ist. Das heißt, es muss eine Zertifikatsvergabestelle geben, die für die Echtheit des Zertifikats bürgt. Zu den bekannten Zertifizierungsstellen gehören Verisign, Globalsign, RSA, Thawte, Equifax und auch Unternehmen und Institutionen wie AOL, die ihre Funktion als Zertifizierungsstelle nicht allzu stark vermarkten.

Sie können Zertifikate zu recht unterschiedlichen Preisen direkt bei einigen Zertifizierungsstellen kaufen. Oder Sie erwerben das Zertifikat beim Hoster. Vor allem die größeren Zertifizierungsanbieter verkaufen ihre Zertifikate relativ teuer. Prinzipiell gibt es in der Anwendung und auch gegenüber dem Kunden aber kaum einen Unterschied, ob das Zertifikat von einer bekannten oder weniger bekannten Registrierungsstelle ausgeliefert wird. Wichtig ist nur, dass sie als Zertifizierungsstelle in den Browsern bekannt ist, denn wenn das nicht der Fall wäre, würde der Nutzer eine Warnmeldung erhalten, die nicht gerade vertrauensfördernd ist. Im Internet Explorer 6 finden Sie die anerkannten Zertifizierungsstellen unter Extras, Internetoptionen und dort im Register Inhalte unter Herausgeber. Firefox zeigt sie unter Extras, Einstellungen im Register Erweitert unter Sicherheit und dann in Zertifikate anzeigen, Zertifizierungsstellen.

Beschränkungen

SSL-Zertifikate

Neben einer vertrauenswürdigen Zertifikatsstelle gibt es noch vier weitere Beschränkungen für Zertifikate: Ein Zertifikat ist immer an eine IP gebunden. Das bedeutet, eine IP kann nur genau ein Zertifikat besitzen. Zwar gibt es in der Standardisierung Ansätze, das zu ändern, aber das wird wohl noch eine Weile dauern. Im Umkehrschluss müssen Sie für ein SSL-Zertifikat auch eine eigene IP besitzen – ein Umstand, der bei vielen Webhosting-Paketen nicht erfüllt ist. Hier lauern also noch versteckte Kosten, wenn Sie für die eigene IP auf ein größeres Paket oder gar einen eigenen, eventuell virtuellen Server wechseln müssen.

Die zweite Beschränkung besteht darin, dass ein Zertifikat nur auf eine Subdomain ausgestellt werden kann. Sprich, Sie müssen sich entscheiden, ob es www.xyz.de sein soll, oder doch nur xyz.de. Sie können das Zertifikat zwar auch für alle anderen Subdomains der jeweiligen IP einsetzen, der Nutzer erhält daraufhin allerdings eine Warnmeldung und muss erst bestätigen, bevor das Zertifikat weiterverwendet wird.

Die dritte Beschränkung liegt in der Ablaufzeit. Ein Zertifikat wird normalerweise auf ein Jahr ausgestellt. Danach bleibt es auf dem Server bestehen, löst aber im Browser des Nutzers eine Warnmeldung aus, dass es abgelaufen ist. Eine Sperrung von Zertifikaten ist aktuell kaum in Gebrauch. Zwar gibt es das Online Certificate Status Protocol (OCSP), das Rücksprache mit der Zertifizierungsstelle hält und den Status eines Zertifikats mitliefert, aber dieses Protokoll ist kaum im Einsatz.

Die vierte Beschränkung sind Performance-Anforderungen: Je länger der Zertifikatsschlüssel, desto stärker wird der Webserver gefordert. In der Praxis wird deswegen oft ein Kompromiss gewählt und beispielsweise das Login gesichert, die Übertragung von Daten aber nicht. Aus Sicherheitsgründen ist das natürlich bedenklich, denn es geht ja nicht nur um das Auslesen der Daten, sondern auch um eine eventuelle Mani
pulation.

SSL auf dem Server

SSL-Zertifikate

Die Einrichtung von SSL-Zertifikaten auf dem Server kann auf viele unterschiedliche Arten erfolgen. Hoster erledigen teilweise die Einrichtung direkt oder erlauben die Einrichtung über eine Konfigurationsoberfläche wie Confixx. Für den eigenen Server hängt das Vorgehen natürlich vom Webserver und vom Einsatzzweck ab. Zu Testzwecken vor allem unter Windows bieten sich vorgefertigte Pakete wie Xampp an, die den Apache bereits mit SSL-Unterstützung und einem Testzertifikat ausliefern.

Die Standard-SSL-Lösung für den Apache ist Open SSL, eine Open-Source-Bibliothek für SSL-Unterstützung. Sie wird für Apache 1.3 per mod_ssl mit dem Apache gekoppelt. Informationen dazu finden Sie unter www.modssl.org. Die offizielle Anleitung für Apache 2.0 und SSL finden Sie unter httpd.apache.org/docs/ 2.0/ssl/ssl_intro.html. Für Microsofts Webserver IIS steht ein Assistent zum Einrichten von Server-Zertifikaten zur Verfügung. Sie finden ihn in der Internet-Informationsdienste-Managementkonsole (Systemsteuerung, Verwaltung), wenn Sie auf eine Website mit der rechten Maustaste klicken, Eigenschaften wählen und in das Register Verzeichnissicherheit wechseln. Eine gute Anleitung finden Sie unter www.msexchangefaq.de/howto/iisssl.htm.

Wenn Sie ein neues Zertifikat anlegen, erhalten Sie vom Server einen so genannten CSR (Certificate Signing Request). Diese verwendet dann die Zertifizierungsstelle, um das Zertifikat zu erzeugen. Gerade für Unternehmensnetzwerke ist noch die Option interessant, eine eigene Zertifizierungsstelle zu werden, die sowohl Open SSL als auch die Microsoft-Alternative bietet. Als eigene Zertifizierungsstelle ist Ihre Zertifikatsstelle natürlich im Internet nicht anerkannt. Sie können aber eigene Zertifikate für das Unternehmensnetzwerk ausgeben.

Kostenfaktor

SSL-Zertifikate

Der Einsatz von SSL ist mit Kosten verbunden: Das Zertifikat kostet je nach Hoster oder Zertifizierungsstelle im Schnitt 50 bis 150 Euro im Jahr beziehungsweise bei einigen Zertifizierungsstellen wie Verisign oder bei längeren Schlüsseln auch noch mehr. Da sind die Webhosting-Provider meist deutlich günstiger. Eine Auswahl finden Sie im Kasten auf der folgenden Seite. Das Zertifikat ist aber nicht der einzige Kostenpunkt. Daneben muss der Webspace noch eine eigene IP haben, damit das Ganze funktioniert, und die Beschränkung auf eine Subdomain erfordert sicherlich auch den einen oder anderen Kompromiss.

Der Rest ist allerdings einfach: Shops und CMS – ganz gleich ob kommerziell oder Open Source – erlauben oft das einfache Umschalten auf HTTPS für Bestellprozess und Backend oder den Login-Bereich. Und das Ergebnis, nämlich mehr Sicherheit, lohnt auf jeden Fall.