Oft fragt man sich, in welchen Situationen ein SSL Zertifikat wirklich Sinn macht. In diesem Tutorial zeigen wir Ihnen, wann und wo Zertifikate genutzt werden sollten um von Verschlüsselung zu profitieren.
Ein Zertifikat besteht meist aus zwei Teilen, einem privaten und einem öffentlichem Schlüssel.
Um das Verfahren genauer zu verstehen, haben wir folgende Abbildung angefertigt.
Der Client kontaktiert den Server und bietet dem Server seine unterstützten Verschlüsselungsmodi an, am Ende einigen sich beide auf eine Verschlüsselungsart. Nun sendet der Server dem Client den öffentlichen Schlüssel, mit diesem Schlüssel kann der Client seine Daten verschlüsseln. Startet man nun einen Paketmitschnitt bekommt man nur verschlüsselte Daten. Man benötigt den privaten Schlüssel, um verschlüsselte Daten entschlüsseln zu können, diesen Schlüssel hat nur der Server. Der private Schlüssel darf auf keinen Fall Dritten zugänglich gemacht werden, das birgt ein enormes Sicherheitsrisiko weil jegliche verschlüsselte Daten der Clients entschlüsselt werden können.
Für einen kleinen Test haben wir ein HTML Formular erstellt, in dem man einen Nutzernamen und ein Passwort eingeben kann, eine solche Login-Maske findet man sehr häufig auf Webseiten.
Unser Loginname war: [email protected]
Das Passwort war : „unencryptedpassword“
Mit einem gängigen Netzwerktool wurden Pakete mitgeschnitten um den Unterschied deutlich zu machen.
Ohne Verschlüsselung konnten wir mühelos den Nutzernamen und das Passwort in Klartext sehen, theoretisch könnten wir auch nachvollziehen, welche Seiten aufgerufen wurden.
Mit Verschlüsselung konnten wir keinerlei Passwörter, Benutzernamen oder die Seiten, die aufgerufen worden sind, darstellen.
Es zeigt sich uns nur ein Datenpaket, was dieses Paket beinhaltet, kann ohne Entschlüsselung nicht festgestellt werden.
In diesem Fall sollte der Benutzername und das Passwort in folgendem Paket übermittelt worden sein (ganz genau kann man es nicht bestimmen).
Um wirklich professionell aufzutreten, sollte man seinen Kunden in jedem Fall eine verschlüsselte Verbindung zur Verfügung stellen, vor allem dann, wenn sensible Daten wie E-Mail Adressen, Benutzernamen, Passwörter oder auch Kreditkarteninformationen eines Kunden übermittelt, verarbeitet und gespeichert werden.
Es gibt natürlich verschiedene Arten von Verschlüsselungen, wir befassen uns hier jedoch nur mit dem Thema der SSL-Zertifikate, die für eine Verschlüsselung benötigt werden. Selbst Verschlüsselungsalgorithmen aus den 90er Jahren bieten einen sehr guten Schutz, hier muss man sich prinzipiell nur bei einem „Finetuning“ wirklich Gedanken machen.
Das Mysterium der unsicheren Verbindungen wird gelüftet:
Jene, die ein Webinterface (cPanel, Plesk, Webmin etc.) installiert haben, haben sicherlich schon einmal folgende Warnmeldung gesehen:
„Dem Zertifikat wird nicht vertraut, da es vom Aussteller selbst signiert wurde“, normalerweise sollte man sich jetzt zweimal überlegen ob man trotzdem die Seite laden möchte, unter Umständen wurde man auf einen anderen Server umgeleitet, in unserem Fall besteht hier keine Gefahr. Die Warnung besagt nur, dass keine öffentliche Institution das Zertifikat unterzeichnet hat. Das Zertifikat an sich hat nichts mit der Stärke der Verschlüsselung zu tun, die Verschlüsselung wird vom Client und Server ausgehandelt.
Es ist natürlich ärgerlich, wenn jeder Kunde eine solche Meldung bekommt – diese Meldung wird oft falsch interpretiert, die Verbindung ist selbstverständlich „sicher“ und verschlüsselt.
Abhilfe schafft hier nur ein Zertifikat, welches von einer öffentlichen Institution signiert wurde, die Preise für solche Zertifikate sind meist extrem hoch und übersteigen schnell das Budget. Daher sollte man sich vorher überlegen wie viel Sicherheit man selbst benötigt, bzw. wie viel Sicherheit man seinen Kunden zur Verfügung stellen möchte.
Zertifikate von Institutionen, wie bspw. „Lets Encrypt“ sind eine tolle kostenlose Alternative, vor allem wenn man ansonsten unverschlüsselt übertragen würde. Sicherheit für die eigene Website bieten domainvalidierte Zertifikate, welche Sie auch bei uns erwerben können. Diese Art von Zertifikaten ist sehr weit verbreitet, es erfolgt hier eine einfache Prüfung der Domain, das Zertifikat ist dann für diese Domain gültig.
Diese Prüfungen gehen so weit, dass zum Teil notariell beglaubigte Urkunden eingesendet werden müssen, dies nennt man dann „Extended Validation“. Ziel ist natürlich immer ein möglichst seriöser Auftritt im Web.
Sobald man sich für ein Zertifikat entschieden hat, egal ob domainvalidiert oder eines mit einer Extended Validation, verschwindet die Warnmeldung und die Website ist fortan für jedermann ohne Warnmeldung erreichbar.
Ebenfalls sehr wichtig ist die Entscheidung, ob man das Zertifikat für eine oder gleich mehrere Domains, bzw. Subdomains benötigt. Ein Wildcard-Zertifikat gilt für eine Vielzahl an Domains, bspw. *.domain.tld, während ein einfaches Zertifikat meist nur für eine Domain gültig ist, z.B. subdomain.domain.tld. Oft wird auch die „www“ Subdomain in das Zertifikat integriert, sodass ein Zertifikat durchaus für mehrere Subdomains gültig sein kann. Ein solches Zertifikat, das für mehrere Domains gültig ist, nennt man Multi-Domain-Zertifikat oder auch UCC (Unified Communications Certificate).
Ist die Suche nach dem passenden Zertifikat abgeschlossen und das Zertifikat bestellt, muss lediglich die Konfiguration des Webservers angepasst werden. Anleitungen bekommt man meist von der ausstellenden Institution.
Wichtig :
Zertifikate bzw. Verschlüsselung spielen nicht nur bei Webservern eine Rolle, Nutzernamen und Passwörter können überall im Klartext abgegriffen werden, egal ob beim Mailversand, FTP Transfer oder sonst einem Dienst. Man sollte möglichst eine verschlüsselte Verbindung vorziehen oder eine unverschlüsselte Verbindung verweigern.