Kategorien
Infrastruktur seafolly.ch Security Shared Hosting Verschlüsselung

HTTPS erzwingen – ganz einfach

Du hast ein Zertifikat für deine Domain erstellt und deine Website ist nun über HTTPS erreichbar?
Das ist gut!

Es ist nach wie vor möglich, die Site auch in der unsicheren HTTP Variante aufzurufen, beispielsweise über alte Links oder gespeicherte Lesezeichen im Browser?
Das ist schlecht!

Hier bei Novatrend ist es sehr einfach, alle Zugriffe auf deine Website, die über HTTP erfolgen, auf HTTPS umzuleiten.

Kategorien
Infrastruktur Performance Webserver

Schnellere Antwortzeiten mit dem LiteSpeed Web Server

In den Monaten November und Dezember 2015 haben wir die Auslieferung der Websites für alle Webhostings bei Novatrend deutlich beschleunigt. Möglich wurde das durch die Nutzung eines anderen Web Servers. Vor November 2015 nutzten wir ausschliesslich den Apache HTTP Server. Nach und nach haben wir dann alle Web Hostings mit dem LiteSpeed Web Server versehen.

Gemäss w3techs.com wird LiteSpeed von mehr als 2 Prozent aller Websites weltweit genutzt, Tendenz steigend (http://w3techs.com/technologies/overview/web_server/all).

Usage of web servers for websites
Usage of web servers for websites

Mit Hilfe von Services wie site24x7.com kann man Antwortzeiten von Websites messen. Unser Kunde Adi Heutschi hat das für seine beiden Sites arbeitsrentner.ch und adiheutschi.ch mal genauer untersucht. Im Zeitraum der Untersuchung hat er seine Sites auf SSL umgestellt und wir haben den Web Server ausgetauscht. Alle Screenshots sind von Adi Heutschi erstellt worden.

Website – adiheutschi.ch

Die Website nutzt Joomla und läuft mit dem Apache HTTP Server. Am 18.11.2015 erhält Sie ein SSL/TLS Zertifikat und die Antwortzeiten werden größer. Hier ein Screenshot vom 19.11.2015.

adiheutschi.ch - SSL-Aktivierung/Apache
adiheutschi.ch – SSL-Aktivierung/Apache

Am 17. Dezember wird der Apache HTTP Server von unserer Seite durch den LiteSpeed Web Server ersetzt. Die Verbesserung der Antwortzeiten ist deutlich zu sehen.

adiheutschi.ch - Umstellung Apache -> LiteSpeed
adiheutschi.ch – Umstellung Apache -> LiteSpeed

Die erste Woche vom 20.12. – 26.12.2015 sieht dann so aus:

adiheutschi.ch - eine Woche - LiteSpeed mit SSL
adiheutschi.ch – eine Woche – LiteSpeed mit SSL

Website – arbeitsrentner.ch

Auch diese Site lief mit Joomla und dem Apache HTTP Server. Hier wurde SSL/TLS am 16.12.2015 um 11:00 Uhr aktiviert. Die Antwortzeiten werden grösser.

arbeitsrentner.ch - SSL-Aktivierung/Apache
arbeitsrentner.ch – SSL-Aktivierung/Apache

Am 17.12.2015, also einen Tag später wurde dann auf den LiteSpeed Server gewechselt. Die Antwortzeiten werden kürzer, es gibt aber vereinzelte Peaks (lange Antwortzeit).

arbeitsrentner.ch - Apache -> LiteSpeed
arbeitsrentner.ch – Apache -> LiteSpeed

Etwas besser kann man beide Effekte in diesem Chart sehen. Es deckt die Woche vom 13.12-19.12.2015 ab. Nach der SSL/TLS Aktivierung wird alles etwas langsamer, nach Einführung von LiteSpeed wieder schneller.

arbeitsrentner.ch - Umstellungszeitraum
arbeitsrentner.ch – Umstellungszeitraum

Wiederum eine Woche, in der Zeit vom 21.12-16.12.2015, später stabilisieren sich die Antwortzeiten im Durchschnitt auf 681 ms.

arbeitsrentner.ch - LiteSpeed Server mit SSL/TLS
arbeitsrentner.ch – LiteSpeed Server mit SSL/TLS

Hier zum Vergleich eine Woche Anfang Dezember (06.12. – 12.12.) mit dem Apache HTTP Server ohne SSL. Im Durchschnitt lagen dort die Antwortzeiten bei 869 ms, mehr als 20 Prozent besser als zuvor.

Fazit

Zunächst sagen die Werte in Millisekunden (ms) wenig über echte Antwortzeiten am Telefon oder dem heimischen PC aus, da diese von sehr vielen Faktoren abhängig sind. Interessant ist aber die sichtbare Beschleunigung nach Einsatz des LiteSpeed Web Servers.
Der Einsatz von SSL/TLS verlangsamt grundsätzlich die Auslieferung von Websites. Der LiteSpeed Web Server kann diesen Unterschied, verglichen mit dem Apache HTTP Server, jedoch mehr als ausgleichen. Durch den Einsatz von HTTP/2 (siehe auch Transportverschlüsselung und HTTP/2 für alle – kostenlos!) und weitere Massnahmen wird die Auslieferung aller Websites massiv beschleunigt. Auf der Benchmark Seite von LiteSpeed kann man das an verschiedenen Szenarien nachvollziehen (Statische Seiten, PHP – Hello World, HTTPS und mehr). Im Screenshot kannst du ein Beispiel für WordPress Sites sehen:

Benchmark - WordPress
Benchmark – WordPress

Es besteht auch die Möglichkeit den LiteSpeed Web Server auf deinem dedizierten Server und beim Cloud Hosting zu nutzen. Hier müssen wir allerdings Lizenzkosten in Höhe vom 50 CHF pro Monat erheben. Für Rückfragen kontaktiere uns einfach per E-Mail.


tl;dr: Durch einen Wechsel der Web Server Software antworten alle von uns gehosteten Websites schneller auf Anfragen

Kategorien
Allgemein News Security

Transportverschlüsselung und HTTP/2 für alle – kostenlos!

Seit ein paar Tagen können Sie bei uns kostenlose TLS Zertifikate für Ihre Domain zu erzeugen und einzusetzen.
Diese Art der Verschlüsselung macht es möglich, dass wir Ihnen bei dieser Gelegenheit auch die Nutzung des schnelleren Übertragungsprotokolls HTTPS/2 SPDY anbieten.

Kurz: Ihre Website wird dadurch sicherer UND schneller 🙂

Aber der Reihe nach:

TLS Zertifikate für alle Domains aller Webhosting Kunden

Wie bereits in mehreren Blogposts angesprochen, ist es nun so weit. Die Zertifizierungsstelle Let’s encrypt hat Ihren Betrieb aufgenommen und bietet kostenlose X.509-Zertifikate für Transport Layer Security (TLS) an. Also genau das, was gemeinhin als SSL Zertifikat bezeichnet wird. Wie versprochen (Natürlich wird es kostenlose SSL/TLS Zertifikate geben – auch bei uns 🙂 ) haben wir so schnell wie möglich dieses Feature auch für unsere Webhosting Kunden bereitgestellt.
Innerhalb der Verwaltungsoberfläsche cPanel gibt es dafür im Bereich Sicherheit ein neues Dialog-Icon – Let’s Encrypt SSL.

cPanel - Sicherheit
cPanel – Sicherheit

In unseren FAQ ist detailliert beschrieben, wie Sie sich ein Zertifikat installieren können (Wie kann ich ein kostenloses Let’s Encrypt Zertifikat installieren?).
Das Zertifikat wird nach Ablauf automatisch für Sie verlängert und bietet handfeste Vorteile:

  1. Der Datenverkehr zwischen dem Browser eines Besuchers und Ihrer Website ist verschlüsselt und erhöht so die Sicherheit bei der Übermittlung von privaten Daten wie beispielsweise Passwörtern und Zahlungsinformationen.
  2. Verschlüsselter Datenverkehr erhöht allgemein das Vertrauen Ihrer Kunden in die Sicherheit Ihrer Website
  3. Für die Benutzung eines SSL-Zertifikats gibt es im Ranking Faktor Ihrer Website bei Google einen Bonus.

HTTP/2 – was ist das?

Das Hypertext Transfer Protokoll (HTTP) ist ein zustandsloses Protokoll und wird hauptsächlich dazu eingesetzt Websites von einem Server zu laden. Das Wort zustandlos beschreibt auch gleich das grösste Problem bei der Kommunikation. Bei jeder neuen Anfrage muss die Verbindung neu „ausgehandelt“ werden. Das kostet Zeit und Ressourcen. Hier ein Beispiel aus dem Leben.

Mein Browser auf meinem PC spricht HTTP in der Version 1.1 und fragt den Host mit dem Namen serverblogger.ch nach seiner Seite (GET / HTTP/1.1 …). Dabei schickt mein Browser alle möglichen Informationen mit. Diese Informationen enthalten beispielsweise den Typ des Browsers (user-agent), die Art des gewünschten Dokuments (Accept), die bevorzugte Sprache (Accept-Language) und weitere Informationen. Diese Daten sind unverschlüsselt und werden an den Webserver geschickt.

GET / HTTP/1.1
Host: serverblogger.ch
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

Der Server antwortet (HTTP/1.1 200 OK) und schickt seinerseits (je nach Konfiguration) alle möglichen Daten mit. Der Webserver ist ein Apache, Betriebssystem ist Ubuntu, etc.

HTTP/1.1 200 OK
Date: Fri, 18 Dec 2015 14:49:43 GMT
Server: Apache/2.4.7 (Ubuntu)
X-Powered-By: PHP/5.5.9-1ubuntu4.14
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 105
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

Nach diesen „Headern“ wird dann der eigentliche Text der Website übertragen, den der Browser dann entsprechend darstellt. Das Beispiel stammt von unserem Testserver, den wir für die Artikel des Blogs nutzen.

Hier ein weiteres Beispiel von der aktuellen novatrend.ch Website.

Die Anfrage meines Browser ist die gleiche, die Antwort des Servers ist aber unterschiedlich:

GET /de/ HTTP/1.1
Host: www.novatrend.ch
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cache-Control: max-age=0

Mein Browser bietet als Protokoll HTTP/1.1 an, der Server antwortet jedoch mit HTTP/2.0. Als Server wird nicht Apache, sondern LiteSpeed benutzt und als letzter „Header“ wird noch ein X-Firefox-Spdy Wert mitgegeben. Der Server hat also bemerkt, dass ich den Firefox Browser benutze und entsprechend darauf reagiert. Je nach Website wird mehrmals nachgefragt, um alle Grafiken, CSS Dateien und was es zum Aufbau der Site benötigt, herunterzuladen.

HTTP/2.0 200 OK
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Date: Fri, 18 Dec 2015 15:04:30 GMT
Accept-Ranges: bytes
Server: LiteSpeed
X-Firefox-Spdy: h2

Nun sind wir in der Welt der vielen Protokolle angekommen und müssen etwas genauer hinsehen:

HTTP ist ein zustandloses Protokol, das jede Verbindung zwischen Client und Server neu aushandelt. Um das zu vereinfachen erfand man Cookies und Session-Ids und der Server seinerseits versucht mittels den Keep-Alive Einstellungen eine Verbindung so lange wie möglich „offen zu halten“. In Cookies und Sessions-IDs stecken jedoch hoch interessante Daten und viele offene Verbindungen machen den Server langsam, füllen dessen Speicher und machen ihn anfällig für Szenarien, bei denen ein Client nur eine GET Anfrage schickt aber nicht weiter kommuniziert. HTTPS ist die sichere Variante von HTTP, die noch einmal mehr Informationen hin und her schickt um eine verschlüsselte Verbindung zu ermöglichen.

HTTP/2 ist abwärtskompatibel zu HTTP1.1 und soll alles besser machen. Client Anfragen können zusammengefasst werden, Daten und andere Inhalte können binär kodiert und komprimiert übertragen werden und der Server kann selbst Datenübertragungen initieren (PUSH). Gerade das letzte Feature ist sehr hilfreich bei Web-Applikationen. HTTP/2 wurde massgeblich von Google (SPDY) und Microsoft (HTTP Speed) initiert. Googles SPDY setzte sich dann durch. Die Abkürzung SPDY steht übrigens für speedy, also schnell :).

Ursprünglich war geplant, das HTTP/2 standardmässig TLS, also verschlüsselte Verbindungen mit SSL Zertifikaten, nutzt. Im finalen Entwurf entfiel diese Option allerdings. Der Geschwindigkeitsvorteil des Protokolls wird in erster Linie über das Zusammenfassen von Anfragen erreicht.

Google (Chrome) und Mozilla (Firefox) kündigten jedoch an, HTTP/2 nicht ohne Verschlüsselung nutzen zu wollen und implementierten Googles SPDY in die Browser. Wenn nun ein Webserver wie Litespeed diese Technik mittels des Headers X-Firefox-Spdy: h2 anbietet, so nutzt der Firefox Browser das HTTP/2 Protokoll (für Chrome gibt es einen entsprechenden Header).

SPDY sorgt, wie der Name vermuten lässt, für eine Beschleunigung der verschlüsselten Kommunikation, verglichen mit dem HTTPS Protokoll. Die Kommunikation gesicherter Verbindungen wird „vereinfacht“ in dem die Wege der Datenpakete optimiert werden. Dadurch werden verschlüsselte Verbindungen ähnlich schnell wie unverschlüsselte Verbindungen.

An dieser Stelle kann man auch nachvollzieghen, warum Google verschlüsselten Verbindungen einen kleinen Bonus auf den Page Rank gibt. Zum einen setzt sich dadurch verschlüsselte Kommunikation schneller durch und zum anderen wird der Geschwindigkeitsnachteil ausgeglichen.

Im nächsten Schritt soll SPDY ebenfalls ein Standard werden. Der heisst dann Application-Layer Protocol Negotiation oder kurz ALPN und stellt eine Erweiterung von TLS dar.

Die HTTP Befehle zwischen Ihrem Browser und einem beliebigen Server lassen sich übrigens mit dem Live HTTP Headers Add-On für Firefox und Chrome beobachten.

Fazit

Auch wenn das jetzt vielleicht ein wenig zu technisch war, so bleiben hoffentlich zwei Dinge im Gedächtnis:
Ihre Website bei uns ist jetzt SICHERER und SCHNELLER 🙂

Links:


tl;dr: Novatrend bietet kostenlose TLS Zertifikate für Ihre Website und liefert sie mittels HTTP/2 aus. Das macht Ihre Website sicherer und schneller.

Kategorien
Security Verschlüsselung

Zertifikate, SSL, TLS und HTTPS – ein Crashkurs

Wir sind an dem Thema SSL, TLS, https, Zertifikate und Verschlüsselungsprotokolle nun so oft „vorbeigeschrammt“, dass ich mal näher darauf eingehen muss. Leider ist das wie so oft „nicht so einfach“ und falls Sie sich noch nie wirklich mit dem Thema beschäftigt haben, sollten Sie einen Moment innehalten und versuchen die Zusammenhänge zu verstehen. Hier ein kurzer Crashkurs mit wichtigen Begriffen und kurzen Erklärungen.

SSL/TLS

SSL ist die Abkürzung für Secure Sockets Layer und ist ein Verschlüsselungsprotokoll für die Datenübertragung im Internet. Bis zur Version 3.0 heisst es SSL, alle Versionen danach heissen TLS (Transport Layer Security). Diese Umbenennung fand schon im Jahr 1999 statt. Die Version TLS 1.0 entspricht der Version SSL 3.1. Die aktuelle Version von TLS ist 1.2.

In Zukunft und im weiteren Verlauf dieses Blogeintrags werde ich die Bezeichnung TLS verwenden.

Verschlüsselungsprotokoll und Schlüsselverteilungsproblem

Ein Verschlüsselungsprotokoll ist eine besondere Art des Netzwerkprotokolls. Eine grosse Herausforderung bei allen Verschlüsselungsverfahren ist das Schlüsselverteilungsproblem. Beide Teilnehmer müssen einen Schlüssel besitzen, um die Nachrichten zu ver- bzw. zu entschlüsseln.

Die einzige Möglichkeit verschlüsselt zu kommunizieren war lange Zeit die Übersendung des Schlüssels per Boten oder eben ihn persönlich zu überbringen!

Um diesen Aufwand zu vermeiden wurden in den siebziger Jahren des letzten Jahrhunderts symetrische und asymetrische Verschlüsselungsverfahren entwickelt.

Symmetrisches Verfahren

Beim symmetrisches Verfahren kommunizieren beide Partner mit demselben Schlüssel. Die Schlüssel müssen also sicher übertragen werden.

Asymmetrisches Verfahren

Beim asymetrischen Verfahren, auch Public-Key Verfahren genannt, erzeugt ein Benutzer ein Schlüsselpaar, das aus einem geheimen (private) und einem öffentlichen (public) Schlüssel besteht. Der öffentliche Schlüssel kann „öffentlich“ ausgetauscht werden. Er ermöglicht es jedem, Daten für den Inhaber des privaten Schlüssels zu verschlüsseln. Nur der Besitzer des geheimen Schlüssels kann diese Daten wieder entschlüsseln.

Damit entfällt die „komplizierte, geheime“ Übertragung des Schlüssels. Der öffentliche Schlüssel kann bedenkenlos geteilt werden werden und das Schlüsselverteilungsproblem ist gelöst.

Aber:

Um das Schlüsselpaar zu erzeugen, benötigt man eine zufällige Zahl. Und Zufall ist nicht ganz einfach zu erzeugen auf einem Computer. Normalerweise benutzt man dafür einen Zufallszahlengenerator (ein Stück Software). Diese Zufallszahlengenratoren können manipuliert werden (Beispiel 1, Beispiel 2). Im Artikel Ein Backup mit Duply hatten wir bereits das Problem mit der Entropie (dem Zufall).

Zweites aber:

Da der öffentliche Schlüssel jedem zur Verfügung steht, ist nicht sicher gestellt, dass genau dieser öffentliche Schlüssel auch dem gewünschten Empfänger zugeordnet werden kann. An dieser Stelle kommen digitale Zertifikate ins Spiel, die den öffentlichen Schlüssel einem privaten Schlüsselinhaber zuordnen, also gewissermassen zertifizieren, dass der öffentliche Schlüssel zu der entsprechenden Person oder Firma gehört.

Drittes aber:

Die asymetrische Verschlüsselung ist langsamer im Vergleich zur symmetrischen Verschlüsselung.

TLS kombiniert beide Verfahren

TLS ist ein hybrides Protokoll, es kombiniert symmetrische und asymmetrische Verfahren.

TLS funktioniert folgendermassen:

  1. Ein Client baut eine Verbindung zum Server auf (Aufruf von https://… im Browser)
  2. Der Server schickt dem Client sein Zertifikat
  3. Der Client überprüft ob Zertifikat und Servername zusammenpassen und schickt dem Server entweder eine mit dem öffentlichen Schlüssel des Servers verschlüsselte Zufallszahl oder beide Parteien berechnen ein gemeinsames Geheimnis (Diffie Hellman Schlüsseltausch)
  4. Aus der Zufallszahl oder dem Geheimnis wird ein Schlüssel berechnet, der dann beiden Parteien zur Verfügung steht und die dann folgende Kommunikation schützt (symmetrisches Verfahren).

Implementierungen des Protokolls finden sich in den Bibliotheken OpenSSL und GnuTLS.

Wichtige Anwendungsfälle für TLS, die auch hier im Blog immer wieder vorkommen, sind die Protokolle HTTP, POP3, SMTP, NNTP, SIP, IMAP, XMPP, IRC, LDAP, FTP und OpenVPN.

Hinweis: In diesem Zusammenhang haben Sie bestimmt schon vom Heartbleed-Bug gehört. Bei diesem „Fehler“ konnte ein „Angreifer“ über Jahre den Arbeitspeicher der beteiligten Partner auslesen und dort private Schlüssel, Benutzernamen und Passworte abgreifen. Der Web Comic xkcd erklärt Heartbleed sehr anschaulich:

HTTP und HTTPS

TLS-Verschlüsselung wird zum grössten Teil zur Absicherung des HTTP Protokolls verwendet. HTTP steht für Hypertext Transfer Protocol und ist das unverschlüselte Kommunikationsprotokoll im WWW. Wenn die Kommunikation über HTTP und TLS abgewickelt wird, spricht man vom HTTPS Protokoll (Hypertext Transfer Protocol Secure).

Wenn Sie beispielsweise Websites über das unverschlüsselte HTTP Protokoll

  • in einem ungesicherten WLAN ansehen, kann der Klartext Ihrer Kommunikation von jedem „Angreifer“ in Reichweite des WLANs mitgelesen werden.
  • in einem kabelgebundenen Netz oder verschlüsseltem WLAN ansehen, kann der Klartext von allen Teilnehmern des Netzes mitgelesen werden.

Wenn Sie Ihre Kommunikation über HTTP/TLS, also HTTPS abwickeln, so ist ein Mitlesen zwar möglich, aber der Netzwerkverkehr ist verschlüsselt und kann nicht „einfach so“ entschlüsselt werden.

Digitale Zertifikate

Ein digitales Zertifikat bestätigt bestimmte Eigenschaften von Personen und Objekten. Sie können Zertifikate selbst erzeugen oder bei einer Zertifizierungsstelle kaufen. Die technischen Vorgänge sind bei selbst zertifizierten und bei gekauften Zertifikaten die gleichen. Sie sind also „gleich sicher“. Der Unterschied besteht im Vertrauen in den Austeller des Zertifikats. Wenn Sie mit eine HTTPS Verbindung mit unserem Testserver herstellen (https://serverblogger.ch), erhalten Sie die Meldung Invalid Certificate.

Invalid Certificate
Invalid Certificate

Je nach Browsertyp erhalten Sie eine ähnliche Meldung. Der Text ist etwas irreführend. Das Zertifikat ist nicht ungültig, sondern einfach selbst zertifiziert. Die Situation ist ein vergleichbar mit einem Zertifikat über Ihren Bildungsstand. Sie könnten sich selbst zertifizieren, dass Sie einen bestimmten Kenntnisstand oder Bildungsabschluss haben. Die meisten Menschen würden dieser Bestätigung vermutlich wenig Glauben schenken (auch wenn sie wahr ist). Wenn dagegen eine dritte Instanz, wie die entsprechende Schule oder Ausbildungsstätte Ihren Kenntnisstand bestätigt, sieht die Sache schon ganz anders aus.

Wenn Sie auf die Website https://www.nsa.gov gehen, so vertraut Ihr Browser dem Zertifikat.

SSL Zertifikat
SSL Zertifikat

Es wurde von der Zertifizierungsstelle Geo Trust ausgegeben und ist gültig bis zum 02.12.2015. Ihr Browser ordnet das Zertifikat als gültig ein und stuft damit die Site als vertrauenswürdig ein. Damit ein Browser unterscheiden kann, welcher Zertifizierungsstelle er vertraut, und welcher nicht, schaut er einfach in eine Liste der Zertifizierungsstellen. Im Firefox Browser finden Sie die Liste der Authorities in den Sicherheitseinstellungen oder online hier.
BuiltInCAs Firefox
BuiltInCAs Firefox

Ihr Browser vertraut allen dort gelisteten Unternehmen! Sie können die Liste allerdings bearbeiten und einzelne Zertifizierungsstellen löschen. Das machen allerdings die wenigsten Menschen. Wenn Sie einen Root-Server betreiben und ganz normale Menschen mit ganz normalen Browsern Ihre Services nutzen, haben Sie keine echte Wahl.

Sie müssen ein Zertifikat kaufen, ansonsten gibt es den Fehlerhinweis im Browser Ihres Kunden und vermutlich wird er Ihre Site daraufhin nicht benutzen!

Die Zertifizierungsstellen sind wieder ähnlich wie beim Schulbeispiel – es gibt gute und schlechte Schulen und man kann sich natürlich auch Doktortitel kaufen. Bei den Zertifikaten ist es manchmal ebenso (Beispiele hier, hier und hier). Wegen der mangelnden Vertrauenswürdigkeit einiger Zertifizierungsstellen wird seit Anfang 2010 die Sicherheit von TLS grundsätzlich angezweifelt (Heise: EFF zweifelt an Abhörsicherheit von SSL). Durch die Deaktivierung fragwürdiger Zertifizierungsstellen im eigenen Browser lässt sich das Risiko jedoch weitgehend beseitigen.

Auch wenn das Zertifikatssystem weder perfekt, noch wirklich sicher ist, ist es der einzige Mechanismus, der momentan in der Masse zur Verfügung steht. Man kann es vielleicht mit dem Geschäftsmodell vieler Kreditkartenfirmen vergleichen. Es ist einfacher für diese Firmen einen finanziellen Schaden, den der Kunde im Einzelfall hatte, auszugleichen, als von Anfang an für bessere Sicherheit zu sorgen.

Damit Sie nun nicht völlig den Glauben an die Sicherheit verlieren, ein kleiner Hoffnungsschimmer.

Jede noch so nachlässig implementierte verschlüsselte Verbindung ist ein Quentchen besser als eine unverschlüsselte Verbindung.

Je nach dem Grad Ihres persönlichen Vertrauens und dem Inhalt Ihres Geldbeutels, können Sie sich bei der israelischen Firma StartCOM ein kostenloses Zertifikat ausstellen lassen oder ein Zertifikat bei einer Tochter der Schweizer Post kaufen (SwissSign).

Wir bei NOVATREND verkaufen Ihnen ebenfalls Zertifikate. Die kommen von GeoTrust (die kennen Sie ja schon 😉 ) und von VeriSign/Symantec. Und wir installieren Sie auch für Sie auf Ihrem Root-Server. Ich stelle das hier im Blog mal deutlich hervor, weil es für den professionellen Einsatz einfach eine praktische Dienstleistung ist.

Unterschiedliche Arten von Zertifikaten (blau und grün)

Um die Sache noch etwas spannender zu gestalten, gibt es unterschiedliche Arten von Zertifikaten. Ausser der Stärke der Verschlüsselung ist das in erste Linie die Domain- oder die Identitätsprüfung.

Bei der Domainprüfung gibt es Single, Wildcard und Multidomain Zertifikate. Single Zertifikate umfassen genau eine Domain, Wildcard Zertifikate die Hauptdomain und alle Subdomains, Multidomain-Zertifikate umfassen mehrere Domains. Überprüft wird von der Zertifizierungsstelle, ob der Auftraggeber der Inhaber der Domain ist. Dazu wird automatisiert eine E-Mail an den administrative Adresse im Whois Eintrag geschickt. Diese E-Mail muss auf unterschiedliche Art bestätigt werden. Der Vorgang geht innerhalb kurzer Zeit (Minuten) und man erkennt es auch im Browser (Domain Validation).

Facebook
Facebook

Hier ein Beispiel für ein wohl vergessenes Multidomain Zertifikat, dass zum Einsatz kommt, wenn ich die BMW Site über HTTPS aufrufe (https://www.bmw.com/). Das Zertifikat ist nicht für diese Domain zertifiziert.
BMW
BMW

Bei der Identitätsprüfung einer Organisation wird ausser der Domainprüfung auch ein Handelsregisterauszug verlangt und teilweise telefonisch Kontakt aufgenommen. Bei einer erweiterter Prüfung (Extended Validation Certificate) wird ausserdem eine grüne Addresszeile im Browser angezeigt .
Postbank
Postbank

Schauen Sie sich mal die Zertifikate der Websites an, mit denen Sie regelmässig Kontakt haben.


tl;dr: Jeglicher Netzwerkverkehr sollte, wenn möglich, über TLS abgewickelt werden um ein Mindestmass an Abhörsicherheit zu gewährleisten. Als Betreiber eines Root-Servers sollten Sie sich ein Zertifikat von einer Zertifizierungsstelle installieren oder installieren lassen, der die gängigen Browser und damit auch Ihre Kunden vertrauen.