Let´s Encrypt – Kostenlose SSL-Zertifikate Frei Haus

Obwohl es signierte TLS-Zertifikate bereits seit einigen Jahren kostenlos gibt und Google im August 2014 ankündigte, dass die Verschlüsselung von Webseiten ein Rankingfaktor ist, werden die meisten Daten noch immer unverschlüsselt ausgeliefert. Denn vielen Webmastern ist das Beantragen und Einrichten eines Zertifikats zu kompliziert. Die Zertifizierungsstelle Let´s Enrypt will das nun durch ein automatisiertes System ändern.

Als Netscape 1994 die erste Version von SSL veröffentlichte, hat wohl niemand damit gerechnet, wie wichtig diese Technologie 22 Jahre später werden würde. Deshalb verwundert es noch mehr, dass trotz der hohen Bedeutung, die nicht zuletzt durch die vielen Abhörskandale nachgewiesen wurde, noch immer ein Großteil des Datenverkehrs unverschlüsselt übertragen wird. Allerdings ist Licht am Horizont zu sehen, denn 2014 haben Branchengrößen wie Mozilla, Cisco, die University of Michigan und Akamai die Internet Security Research Group (ISRG) mit dem Ziel gegründet, das Internet sicherer zu machen. Neben bekannten Größen hat auch die Nichtregierungsorganisation (NGO) Electronic Frontier Foundation einen Posten als Beobachter innerhalb der ISRG. Die erste Initiative der Organisation ist die Zertifizierungsstelle (CA, Certificate Authority) Let´s Encrypt, die durch einen automatisierten Prozess den Zugang zu kostenlosen Zertifikaten erleichtern soll.

Wie funktioniert Let´s Encrypt?

Zum Erhalt eines domainvalidierten Zertifikats muss der Antragsteller gegenüber der Zertifizierungsstelle nachweisen, dass die Domain unter seiner Kontrolle steht. Im Gegensatz zu anderen Anbietern, die dazu eine E-Mail mit einem Link, der zum erfolgreichen Validieren angeklickt werden muss, an den Webmaster, Hostmaster oder Administrator der Domain schicken, nutzt Let´s Encrypt ein selbst entwickeltes Protokoll mit dem Namen Automated Certificate Management Enviroment (ACME). Damit ein Zertifikat über dieses Protokoll angefordert werden kann, muss auf dem Server ein entsprechender Client installiert sein. Das kann sowohl der Offizielle von Let`s Encrypt sein, als auch ein eigener, der das offene ACME-Protokoll implementiert. Wird nun ein Zertifikat für eine Domain angefordert, stellt die Zertifizierungsstelle eine Aufgabe, mit dessen Lösung die Hoheit über die Domain nachgewiesen wird. Dieser Vorgang ist allerdings nur bei der Erstausstellung möglich. Bei nachfolgenden Zertifikaten wird eine alternative Validierung genutzt, bei der die Kontrolle über die Domain durch das alte Zertifikat sichergestellt wird. Jedes von Let´s Encrypt ausgestellte Zertifikat ist maximal drei Monate gültig. Der Vorgang zur Neuausstellung kann jedoch vollständig automatisiert werden, sodass ein manuelles Eingreifen nicht mehr notwendig ist. Dazu kann der offizielle Client auch die verwalteten Domains auslesen und nach erfolgreichem Beantragen der Zertifikate auch den Webserver einrichten. Wobei dieses aktuell nur unter Debian-basierten Distributionen mit dem Webserver Apache2 möglich ist. Alle, die ein anderes Betriebssystem oder einen anderen Webserver nutzen, können sich dennoch das Zertifikat automatisch erstellen lassen. Müssen dabei die Domains jedoch beim Beantragen als Parameter mit angeben und auch den Webserver selbst einrichten.

Browsererkennung

Da die Browser dem Root-Zertifikat der ISRG, dass die Zwischenzertifikate von Let´s Encrypt signiert, noch nicht vertrauen, wurde es zusätzlich mit dem Root-Zertifikat von IdenTrust cross-signed. Dadurch vertrauen alle aktuellen Browser den Zertifikaten von Let´s Encrypt.

Installation unter Debian

Debian Stretch und Debian Sid, die aktuellen test und unstable Branches, enthalten zwar den Let´s Encrypt Client bereits als Paket, sollten aber nicht auf einem Produktivsystem genutzt werden. Wer jedoch nur ein Testsystem aufsetzen möchte, um Let´s Encrypt zu testen, kann den Client bei beiden Versionen bequem über die Paketverwaltung installieren.

Bei allen anderen Versionen von Debian bleibt nur das manuelle Herunterladen oder Klonen mit Git. Sofern noch nicht vorhanden, kann git über den Paketmanager installiert werden und anschließend, mit dem zweiten Befehl, der aktuelle Branch von Let´s Encrypt auf den Server kopiert werden.

Anschließend lässt sich die Software im Unterverzeichnis letsencrypt finden.

Alle weiteren Befehle können direkt per letsencrypt oder dem Wrapper letsencrypt-auto ausgeführt werden. Der Wrapper bietet den Vorteil, dass er fehlende Abhängigkeiten, wie zum Beispiel die benötigte Python-Umgebung, automatisch installiert und auch die Software aktualisiert. Außerdem werden zum Ausführen, des in Phyton geschriebenen Scripts, Root-Rechte benötigt.

Wird das Script ausgeführt, liest es zunächst die Konfigurationsdateien des Webservers ein, sodass es anschließend weiß, welche Domains vom Webserver verwaltet werden. Es werden sowohl die Domains, die als ServerName angegeben sind, also auch die ServerAliases erfasst, die im späteren Zertifikat als SubjectAltName eingetragen werden. Die gefundenen Domains können, nachdem eine E-Mail Adresse angegeben wurde, vor dem Erstellen des Zertifikats selektiert werden. Standardmäßig werden alle Domains in einem Zertifikat zusammengefasst. Wer mehr als ein Zertifikat nutzen möchte, muss das Script mehrfach ausführen.

Standardmäßig werden Zertifikate mit einer Schlüssellänge von 2048 Bit ausgeliefert. Wem diese nicht reicht, kann beim Ausführen über den nachfolgend gezeigten Parameter einen individuellen Wert angeben.

Außerdem können mit dem Parameter certonly auch ausschließlich die Zertifikate erstellt werden, sodass die Software nicht auf die Konfigurationsdateien der Websoftware zugreifen muss.

Auch die Authentifikation kann, wenn der Parameter –a angegeben wird, manuell durchgeführt werden.

Zertifikate unter Debian automatisch erneuern lassen

Wie eingangs erwähnt, sind die Zertifikate von Let´s Encrypt nur drei Monate gültig und müssen deshalb regelmäßig erneuert werden. Damit wollen die Verantwortlichen sicherstellen, dass Sicherheitslücken in den Verschlüsselungsprogrammen auf allen Servern, die ein Zertifikat von Let´s Encrypt einsetzen, zeitnah behoben werden. Manuell geht das mit nachfolgendem Begehl.

Damit werden die Zertifikate mit den bei der Ersterstellung gemachten Angaben erneuert. Natürlich ist das manuelle Auffrischen der Zertifikate nicht nur mühsam, sondern birgt auch das Risiko, dass es vergessen wird. Deshalb sollte dieser Prozess automatisiert werden. Das geht am einfachsten, indem der Befehl durch einen Cronjob regelmäßig ausgeführt wird. Im nachfolgenden Beispiel werden alle 10 Tage die Zertifikate erneuert, die noch weniger als 30 Tage gültig sind.

Fazit

Aktuell befindet sich Let´s Encrypt zwar noch in der Betaphase, sorgt aber bereits für hitzige Diskussionen. Denn zwar werden kostenlose Zertifikate angeboten, die sich sogar automatisch einrichten und erneuern lässt, doch dafür auch einige Zugeständnisse gefordert. Zum einen, weil das Script Root-Rechte benötigt, wodurch nicht nur eine Angriffsfläche geschaffen wird, sondern auch der Administrator Vertrauen in das Script setzen muss. Zusätzlich ist, sofern der offizielle Client genutzt wird, ein Interpreter für Phyton notwendig, der ansonsten auf vielen Webservern wohl nicht installiert werden würde. Deshalb wird Let´s Enrypt am Ende nicht jeden glücklich machen und auch ich setze es aktuell bisher nur bei Projekten ein, bei denen der Webserver durch Plesk verwaltet wird. Allerdings sehe ich auch noch einen weiteren Vorteil. Denn dadurch, dass viele Hoster bereits Let´s Encrypt anbieten, erreicht die Initiative auch den Massenmarkt. Das sorgt nicht nur für mehr verschlüsselten Datenverkehr, sondern auch dafür, dass sehr wahrscheinlich weniger Zertifikate verkauft werden, wodurch die kostenpflichtigen Zertifizierungsstellen hoffentlich ihre Preispolitik überdenken. Auch die fehlende Unterstützung von großen Anbietern wie domainfactory sorgt nicht nur dafür, dass kleinere Anbieter wieder etwas haben, mit dem sie sich von den großen abheben können, sondern zeigt wahrscheinlich auch, dass einige das Geschäft mit Zertifikaten nicht so schnell aufgeben wollen.

Sicheres löschen von Dateien und Partitionen

Trotz der Tatsache, dass bei den aktuellen Linux-Dateisystemen ext3 und ext4 eine Wiederherstellung von gelöschten Dateien im Vergleich zu ext2 nur schwer möglich ist, gibt es dennoch welche, bei denen auch das kleinste Risiko schon zu groß ist. Wie lassen sich also Daten so löschen, dass sie nicht wiederhergestellt werden können?

Wird eine Datei gelöscht, dann wird der eigentliche Inhalt, der in Datenblöcken gespeichert ist, nicht vernichtet, sondern nur als frei markiert und die Einträge in den Verzeichnisdateien, in denen die Zuordnungen der Dateinamen zu den Inodes zu finden sind, entfernt. Bei den Dateisystemen ext3 und ext4 werden zusätzlich auf Verwaltungsebene, den Inodes, auch die Zeiger auf die Datenblöcken überschrieben. Damit ist das Wiederherstellen von Dateien unter aktuellen Linux-Dateisystemen zwar komplizierter, aber bei Weitem nicht unmöglich. Erst wenn die Datenblöcke überschrieben wurden, kann die ursprüngliche Datei nicht wiederhergestellt werden. Dieses geschieht zwar auch automatisch, wenn das Betriebssystem den Speicher z.B. für eine neue Datei braucht, kann aber je nach Größe der Festplatte sehr lange dauern.

Sicheres löschen von Dateien

Zum sicheren Löschen einzelnen Dateien gibt es für Linux zwei sehr bekannte Programme, die auch bei Debian und Ubuntu in den offiziellen Paketquellen vorhanden sind. Diese überschreiben die Dateien vor dem löschen mehrmals mit Zufallsdaten oder Nullen, sodass diese anschließend weder per Programm, noch per forensischer Analyse wiederherstellen werden können.

shred

Installation unter Debian:

Eine Datei mit shred 25 Mal überschreiben und anschließend löschen:

Mit dem Parameter –n lässt sich die Anzahl der Schreibzyklen anpassen. Im nachfolgenden Beispiel wurde der Wert auf 3 gesenkt. Außerdem wird durch Hinzufügen des Parameters –v ein Fortschrittsbalken angezeigt.

Mit dem Parameter –z wird die Datei am Ende noch einmal mit Nullen überschrieben. Damit kann das Überschreiben nicht nur verschleiert werden, sondern in Verbindung mit dem Herabsetzen auf null Zyklen auch ausschließlich mit Nullen überschreiben werden. Alternativ kann dafür auch das Programm dd genutzt werden, welches im Kapitel „Sicheres löschen von Partitionen“ vorgestellt wird.

wipe

Das Programm wipe bietet im Vergleich zu shred nicht nur wesentlich mehr Einstellungsmöglichkeiten, sondern auch die Möglichkeit ganze Ordner zu überschreiben. Dieses lässt sich bei shred zwar auch in Verbindung mit find realisieren, ist dadurch aber komplizierter.

Installation unter Debian:

Eine Datei mit wipe Überschreiben und Löschen:

Durch den Parameter –r lassen sich rekursiv auch Ordner mit all ihren Unterordnern und Dateien überschreiben und löschen. Mit dem Parameter –f lässt sich zudem das Nachfragen, ob die Datei wirklich gelöscht werden soll, unterbinden.

Einschränkungen bei SSDs

Da die einzelnen Speicherzellen des bei SSDs verwendeten Flash-Speichers nur über eine begrenzte Anzahl an Schreibzyklen verfügen, werden die Schreibvorgänge mittels der Wear-Leveling-Algorithmen durch den Controller auf alle Zellen gleichmäßig verteilt. Das sorgt zwar für eine längere Lebensdauer der SSD, verhindert aber auch, dass beim Überschreiben einer Datei tatsächlich die ursprünglichen Speicherzellen genutzt werden. Weshalb ein sicheres Löschen mit den oben genannten Programmen bei SSDs nicht möglich ist.

Sicheres löschen von Partitionen

Zwar lassen sich auch ganze Partitionen mit den bereits vorgestellten Programmen überschreiben, da diese jedoch um einiges größer sind und das Überschreiben sehr lange dauern würde, ist hier das nutzen schnellerer Methoden ratsam. Zudem haben 2008 die Forensikexperten Craig Wright, Dave Kleiman und Shyaam Sundhar R.S. nachgewiesen, dass bereits nach einmaligem Überschreiben gelöschte Daten nicht wiederhergestellt werden können (siehe Overwriting Hard Drive Data: The Great Wiping Controversy).

Am einfachsten und schnellsten geht das Überschreiben von Partitionen mit dem Programm dd. Als Parameter werden die Eingabedatei (if=/dev/zero) und Ausgabedatei (of=PARTITION) angegeben. Bei der Eingabedatei wird im Beispiel /dev/zero verwendet, welches bei jedem Lesezugriff ein Nullzeichen zurückliefert, und als Ausgabedatei die zu überschreibende Partition (z.B. /dev/sda).

Außerdem kann auch die Größe der Blöcke, die standardmäßig bei 512 liegt, mit dem Parameter bs vergrößert werden, wodurch ein schnelleres lesen und schreiben möglich ist. Für den idealen Wert sollte zunächst mit dem Programm hdparm die Größe des internen Zwischenspeichers der Festplatte ermittelt werden. Dieser kann dann als Wert für die Blockgröße (bs) genutzt werden.

 

Die Geschichte eines 1,45 € günstigen vServers

Anfang 2015 wurde unter united-itsolutions.com ein vServer beworben, der mit 4 vCores und 1 GB Arbeitsspeicher nur 1,45€ im Monat kosten sollte. Auch wenn die Preise in den letzten Jahren in diesem Bereich nur eines sind, nämlich gefallen, war ich gegenüber dem Angebot doch sehr skeptisch. Dennoch konnte ich mich nicht beherrschen und habe einen für zunächst drei Monate gemietet.

Die erste Überraschung erlebte ich beim Bezahlen. Zwar gab es bei der vierteljährigen Abrechnung noch einen Rabatt, sodass drei Monate nur 3,95 € statt 4,35 € kosteten, doch kamen noch Gebühren für die Zahlungsart von 0,43 € hinzu. Das ist zwar nicht viel, da es jedoch bei der Bestellung nicht aufgelistet wurde, fühlte ich mich schon ein wenig getäuscht. Ausgeliefert wurde der vServer dann nach etwas mehr als einer Stunde.

Hardware und Erstinstallation

  • CPU: Intel XEON E5 2530v3
  • CPU Core´s: 4 vCore
  • RAM (garantiert): 1024 MB
  • RAM (Swap): 1024 MB
  • Festplatte: 20 GB SSD
  • IPv4 Adresse/n ink.: 1x
  • Traffic: Unlimitied (Fair Use/500GB)

Die nächste Überraschung gab es bei der Erstinstallation. Gerne hätte ich Debian 7 installiert, es stand aber nur die Version 6 zur Verfügung. Zur Verdeutlichung: Ich hatte den Server am 12. April 2015 bestellt. Damals war der Nachfolger, Debian 8, bereits angekündigt und erschien nur wenige Wochen später. Bei Ubuntu, Fedora und CentOS sah es nicht besser aus. Ubuntu konnte in der Version 12.04 LTS installiert werden, Fedora in der Versionen 17 und CentOS in den Versionen 5, 6 und 6.5. Aktuell wäre bei Ubuntu damals die Version 14.04.2 LTS, bei Fedora die Version 21 und bei CentOS die Version 6.6 gewesen.

Nichtsdestotrotz konnte ich mich weiterhin über die versprochene Leistung freuen. Denn der Server wurde nicht nur mit üppigen vier vCores ausgeliefert, diese sollten laut Anbieter auch noch uneingeschränkt nutzbar sein. Das war ungewöhnlich, denn der vServer war mit OpenVZ virtualisiert und damit lässt sich die CPU-Leistung nur schwer begrenzen. Die meisten Anbieter lösen dieses Problem mit einem eigenen Script, welches CPU lastige Prozesse killt. Diese Einschränkung ist meistens in den AGBs zu finden. Frei nach dem Motto „Versprechen ist gut, Kontrolle ist besser.“ habe ich zum Auslasten der CPU einen Bitcoin-Miner installiert. Nicht dass ich die Hoffnung auf den großen Gewinn hatte, aber der Miner war die erste Anwendung, die mir eingefallen ist, die bei einem tatsächlichen Nutzen die CPU voll auslasten konnte. Aber natürlich kam es, wie es kommen musste, der entsprechende Prozess wurde vom Anbieter beendet. Auch wenn ich dass genau so erwartet hatte, ist es, nachdem die AGBs die CPU-Nutzung nicht einschränken und der Anbieter die volle Leistung beworben hat, natürlich nicht in Ordnung gewesen. In einem Gespräch mit dem Anbieter habe ich das auch so zum Ausdruck gebracht, aber auch gesagt, dass ich das Script nur für einen Test installiert hatte.

United-ITSolutions SolusVM
SolusVM zeigt 8 TB Arbeitsspeicher an.

Ein weiteres Problem gab es mir dem Arbeitsspeicher. Nicht nur das sowohl Linux, also auch die Verwaltungsoberfläche SolusVM 8 TB als verfügbar anzeigten, diese ließen sich anfangs auch allokieren (Reservieren von Hauptspeicher). Erst nachdem mehrere Kunden das Problem gemeldet hatten, beschränkte United-ITSolutions den Arbeitsspeicher auf 1 GB pro Prozess. Der Anzeigefehler, sofern es einer ist, wurde jedoch bis heute nicht behoben.

Gameserver

Einige Wochen später hatte mich ein Freund gefragt, ob ich ihm ein Gameserver für das Spiel 7 Days to Die zur Verfügung stellen könnte. Mit einem Grinsen auf dem Gesicht bejahte ich seine Anfrage. Er war natürlich etwas verwundert, wusste ja nicht, dass ich diesen auf einen vServer für 1,45 € installieren wollte. Für die 10 von ihm gewünschten Slots wären bei einem Gameserver Anbieter etwa 8 € pro Monat fällig gewesen. Der mit durchschnittlich 3 Spielern belegte Server lief aber auf dem vServer ohne Probleme. Zumindest zwei Wochen lang, dann gab es auf einmal Probleme beim Verbinden. Da ich zu dem Zeitpunkt gerade wenig Zeit für Uhrsachenforschung hatte, wollte ich einfach schaue, ob ein einfacher Neustart das Problem lösen könnte. Zu meinem Leid ist der Server nicht wieder gestartet. Auch über die vom Anbieter angebotene Verwaltungsoberfläche SolusVM ließ sich der vServer nicht mehr starten. Also musste ich mich an den Support wenden. Nachdem der Support von United-ITSolutions fragte, was ich zuletzt gemacht hatte, obwohl dieses bereits in der Anfrage stand, konnte er ausschließen, dass der Fehler in deren Verantwortung liegt, und bad mich erneut, damit der Fehler gefunden werden kann, um eine genaue Beschreibung meiner letzten Handlungen. Da habe ich mich doch ernsthaft gefragt, wie ein Anbieter, ohne zu Wissen wo der Fehler liegt, seine eigene Schuld ausschließen kann. Auf lange Diskussionen, die wahrscheinlich auch zu keinem Ergebnis geführt hätte, hatte ich jedoch keine Lust. Also habe ich den Gamesrver anderswo installiert und den vServer bei United-ITSolutions einfach neu aufgesetzt. Anschließend lief er auch wieder und wurde ab und zu für Test und Ähnliches verwendet.

Übernahme durch ITP-Solutions UG & Co. KG

Am 25. November 2015 erhielt ich dann überraschend eine Mail, in der die Übernahme aller Kunden und Verträge von United-ITSolutions durch ITP-Solutions UG & Co. KG angekündigt wurde. Die vServer sollten bereits am nächsten Tag in das Rechenzentrum des neuen Anbieters migriert werden. Für mich persönlich war das, insbesondere weil ich meinen Server aktuell nicht brauchte und heruntergefahren hatte, kein Problem. Diejenigen, die dort aber einen Webserver betrieben und nun ihre DNS Einträge ändern mussten, waren sicherlich nicht so gelassen.

Probleme mit den Images und DNS-Servern

Kurz vor Weihnachten hatte ich schließlich wieder Bedarf an einem kleinen vServer. Doch neu aufsetzen ging nicht, denn ich hatte zwar die Zugangsdaten zum neuen Kundenbereich, aber keine zu einem vServer Verwaltungssystem. Also den Support angeschrieben und gefragt, wie ich den Server neu installieren könnte. Einen Tag später erhielt ich dann Zugangsdaten zu deren SolusVM. Die Frage, weshalb es die nicht bereits bei der Migration gab, habe ich mir einfach mal gespart. Anhand des generischen Benutzernamens vermute ich jedoch, dass nicht viele danach gefragt haben.

Erfreulich überrascht war ich, als ich gesehen habe, dass nun auch aktuelle Betriebssysteme wie Debian 8, CentOS 7 und Ubuntu 15.04 LTS zur Verfügung stehen. Die Freude hielt jedoch nur kurz, denn Debian 8 und co ließen sich zwar installieren, jedoch nicht starten. Der Support bestätigte mir dieses mit der Aussage, dass das Hostsystem noch kein Debian 8 unterstützt. Normalerweise gehe ich davon aus, dass die Voraussetzungen für die zur Verfügung stehenden Betriebssysteme erfüllt sind. Das nächste Problem war, das alle anderen Images bereits Dienste wie Apache2, bind und Samba vorinstalliert hatten oder einfach viel zu alt waren. Ein aktuelles Image ohne vorinstallierte Dienste, wie es oft als minimal bezeichnet wird, gab es einfach nicht. Also habe ich Debian 7 installiert, um dann festzustellen, dass die hinterlegten DNS Server nicht mehr existieren. Da ich das nicht selbst ändern konnte, musste ich erneut den Support von 24H-Hosting anschreiben, der die des alten Anbieters durch öffentliche ersetzt. Anschließend konnte ich endlich Debian 7 installieren, die unerwünschten Dienste entfernen und das Betriebssystem aktualisieren.

Neuer Anbieter neue Hardware?

  • CPU: Intel XEON E5 2620
  • CPU Core´s: 4 vCore
  • RAM (garantiert): 2048 MB
  • RAM (Swap): 0 MB
  • Festplatte: 80 GB
  • IPv4 Adresse/n ink.: 1x
  • Traffic: 1,95 TB

Bei der Übernahme durch die ITP-Solutions UG & Co. KG hieß es, dass sich an der zu erbringenden Leistung nichts ändern würde. Tatsächlich ist bei mir kaum noch eine Spezifikation so, wie sie vor fast einem Jahr vereinbart wurde. Zwar hat der vServer noch vier Kerne, aber anstelle eines Intel XEON E5 2530v3 mit 2,4 GHz pro Core ist nun ein Intel XEON E5 2620 mit 2 GHz pro Core verbaut. Statt 1 GB Arbeitsspeicher sind es nun 2 GB, bei dem Traffic können nun 1,95 TB anstelle der 500GB Fair Use verbraucht werden und auch die 20GB SSD wurden durch eine 80GB große HDD ersetzt. Trotz der schlechteren CPU und Festplatte ist der vServer meiner Meinung nach nun insgesamt besser, als der ursprünglich vereinbarte. Entsprechend sehe ich hier auch keinen Grund das ursprünglich Vereinbarte zu Vordern.