SSL überall - jetzt auch auf neunzehn83.de

{.main}
Künftige Versionen des Chrome Browsers sollen vor unverschlüsselten HTTP-Verbindungen warnen. Höchste Zeit also auch den kleinsten Blog fit für HTTPS zu machen. SSL-Zertifikat von bekannten Vergabestellen gibt es ab 15,- Euro im Jahr. Für kleine Seiten ist das aber wenig wirtschaftlich. Für diese Zwecke gibt es aber zum Glück die Möglichkeit bei StartSSL kostenlose SSL-Zertifikate zu beziehen. Das funktioniert nach ersten Tests in allen verbreiteten Browsern auch erstaunlich gut. Somit lassen sich Webseite und E-Mail einfach mit einem gültigen Zertifikat mit SSL absichern. Der Trend zu SSL und kostenlosen Zertifikaten wird sich in Zukunft wohl hoffentlich verstärken, spätestens wenn Mozilla mit Let's Encrypt ebenfalls kostenloses Zertifikate anbietet.

Die IP-Problematik

Eine weitere Hürde bei der Bereitstellung von SSL ist, neben den Kosten, die Notwendigkeit einer eigenen IP-Adresse pro SSL-Host. Insbesondere durch knapp werdende IP4-Adressen wird diese Problematik verschärft. Eigentlich wird der Host-Name ebenfalls verschlüsselt übertragen und somit ist Name-Based Virtual Hosting auf dem Server nicht möglich - denn der kennt den Hostnamen des Requests nicht. Abhilfe schafft die vor vielen Jahren eingeführte Server Name Indication (SNI). Dabei wird der Hostname als Teil des SSL-Handshakes ausgetauscht. Somit ist es dem Webserver möglich den Hostnamen auch bei SSL-geschützten Übertragungen zu unterscheiden.

Dummerweise wird diese Technik nicht von allen Browsern unterstützt, beispielsweise von keinem Internet Explorer unter XP. Da diese Versionen aber mittlerweile sehr geringe Anteile haben, spricht zunehmend weniger gegen den Einsatz von SNI. Außerdem wird bei nicht SNI-fähigen Browsern immer das erste (standard) Zertifikat ausgeliefert, so dass es nur auf zusätzlichen Seiten zu Zertifikatsfehlern kommt.

Wozu eigentlich?

Diese Frage scheint berechtigt zu sein. Schließlich schreibe ich ja hier nur etwas sowieso öffentlich zugängliches und auch nichts geheimes. Für das Lesen des Blogs scheint die Übertragung per HTTPS sinnlos zu sein. Ist sie aber nicht! Denn mit der Übertragung per SSL wird neben der Verschlüsselung des Inhalts auch sichergestellt, dass der gegenüberliegede Server auch derjenige ist, für den er sich ausgibt. So wird unter anderem sichergestellt, dass der Empfangene (und angezeigte) Inhalt, auch der ist, der vom Zielserver versandt wurde. Manipulationen auf dem Weg zum Client, beispielsweise durch den Provider oder Access-Point-Betreiber, sind somit nicht möglich. In Vergangenheit haben schon einige Provider Code in Webseiten eingeschleust um eigene Werbung anzuzeigen oder User zu tracken. Dies ist mit per SSL übertragenen Webseiten nicht möglich.

Dieser Blog-Post beschreibt die Problematik im Zusammenhang mit der Nutzung von öffentlichen "kostenlosen" Proxys - sehr interessant! Natürlich sind solche Manipulationen auch grundsätzlich durch jeden ISP oder VPN-Anbieter möglich. Da es sich hier aber um bezahlte Dienste handelt und zumindest die ISPs beim Nachweis von Manipulation in Erklärungsnot geraten würden, ist die Gefahr aber wohl eher gering. Anders sieht das natürlich mit zwielichtigen VPN-Anbietern auf den Caymans oder sonstwo aus, die u.a. Bitcoint als Zahlungsmittel akzeptieren.. Denkt mal darüber nach!

Selbst signierte Zertifikate

Eine Alternative zu Zertifikaten von Zertifizierungsstellen sind selbst signierte SSL Zertifikate. Für die Absicherung des Mail-Traffics ist dies oft sogar die bessere Methode. Hier sollten Zertifikate selbst erstellt werden und mit einem eigenen Root-Zertifikat signiert werden. Clients müssen dann nur das eigene Root-Zertifikat importieren und verbinden sich problemlos mit allen von diesem Root-Zertifikat aus erstellten Zertifikaten. Da das Root-Zertifikat "von Hand" (und natürlich über ein alternatives Medium) verteilt werden muss, eignet sich diese Methode nur für einen bestimmten Kreis von Nutzern. Beispielsweise für den eignen Mailserver oder interne Webseiten mit eingeschränktem Nutzerkreis. Für öffentliche Webseiten hingegen sind selbst-signierte SSL-Zertifikate ungeeignet.