Das verändert alles: In knapp mehr als einem Jahr hat es die kostenlose Zertifizierungsstelle Let’s Encrypt geschafft, den öffentlichen Betrieb aufzunehmen. Kostenlose SSL-Zertifikate werden so zum Allgemeingut. Ein wichtiger Schritt in der Internet-Geschichte, steht der flächendeckenden Verbreitung von verschlüsselten Verbindungen im Web damit doch nichts mehr im Weg.

Dank Let’s Encrypt gibt’s jetzt kostenlose SSL-Zertifikate für alle.

Kostenlose SSL-Zertifikate per Knopfdruck aktivieren

Wir hatten es angekündigt: Wir bieten Ihnen ab sofort die Zertifikate von Let’s Encrypt an. Gratis versteht sich. In gewohnter cyon-Manier aktivieren Sie die kostenlosen SSL-Zertifikate bequem via Knopfdruck im my.cyon.

Ein Klick und das kostenlose SSL-Zertifikat von Let’s Encrypt ist installiert.

Mit Zertifikaten von Let’s Encrypt ist nicht nur die Kommunikation zwischen Ihrer Website und Besuchern bestens abgesichert. Dank aktiviertem SSL-Zertifikat profitieren Ihre Besucher bei uns auch automatisch vom modernen und schnelleren HTTP/2-Protokoll. Zudem wertet Google verschlüsselte Verbindungen als positives Signal für Suchergebnisse.

Mitgebrachte SSL-Zertifikate komfortabel verwalten

Falls Sie eigene SSL-Zertifikate, wie z.B. Wildcard- oder EV-Zertifikate, installieren möchten, haben wir ebenfalls etwas für Sie. Ab dem Angebot Webhosting Double steht Ihnen automatisch die Option «Externe SSL-Zertifikate» zur Verfügung. Erstellen Sie Certificate Signing Requests (CSR) und installieren Sie extern bezogene Wildcard- oder EV-Zertifikate komfortabel in Ihrem my.cyon-Konto.

Externe SSL-Zertifikate lassen sich genauso bequem verwalten.

Let’s Encrypt + cyon = ❤️

Let’s Encrypt, das ist für uns eine Liebesgeschichte. Bereits bei der Ankündigung des Projekts vor über einem Jahr war uns klar: Da müssen wir mitmachen.

Let’s Encrypt hat sich zum Ziel gesetzt, HTTPS im Web zum neuen Standard zu machen. Um dieses Ziel zu erreichen, bietet Let’s Encrypt nicht nur kostenlose SSL-Zertifikate an, sondern hat mit dem sogenannten ACME-Protokoll gleich noch neue technische Grundlagen für eine vollautomatisierte Abwicklung von SSL-Zertifikaten gelegt.

Die Ausstellung und Erneuerung von SSL-Zertifikaten war bisher eher Frust als Lust. Mit ein Grund, warum wir bis anhin selbst keine SSL-Zertifikate angeboten haben. Dank Let’s Encrypt hat diese Durststrecke nun ein Ende, weshalb wir das Projekt auch finanziell unterstützen. Schön zu sehen, dass andere Schweizer Unternehmen unserem Beispiel gefolgt sind und Let’s Encrypt ebenfalls sponsern. Damit stammt fast ein Drittel der Let’s Encrypt-Sponsoren aus der Schweiz.

Blick in die Zukunft

Damit wir dem Ziel, alle Websites dieser Welt mit HTTPS auszustatten, ein Stück näher kommen, werkelt unser Entwicklungsteam kräftig an weiteren Funktionen, die Ihnen das Leben in Sachen SSL-Zertifikaten noch einfacher machen werden. Mit unserem «SSL-Autopiloten» wird sogar der obligate Knopfdruck für die Aktivierung von Let’s Encrypt-Zertifikaten entfallen.

Loggen Sie sich jetzt in Ihr my.cyon-Konto ein und aktivieren Sie Let’s Encrypt-Zertifikate für Domains und Subdomains. Alle Vorteile, die kostenlose SSL-Zertifikate bieten, haben wir im neuen Bereich Sicherheit auf unserer Website zusammengestellt.

Ab 3. Dezember ist es endlich soweit: Let’s Encrypt geht an den Start. Seit wir die Zusammenarbeit mit der kostenlosen Zertifizierungsstelle angekündigt haben, erreichen uns viele Anfragen zum Thema. Die drei häufigsten Fragen zu Let’s Encrypt beantworten wir im heutigen Blogpost.

Kostenlose SSL-Zertifikate sind bald der neue Standard.

Let’s Encrypt-Zertifikate sind nur 90 Tage lang gültig. Muss ich ständig mein Zertifikat verlängern lassen?

Let’s Encrypt nennt selbst zwei Gründe für den 90-Tage-Turnus.

1.
Ihr Let’s Encrypt-Zertifikat wird von uns völlig automatisch verlängert. Die kurze Laufzeit von SSL-Zertifikaten fördert diese Automatisierung. Es ist an der Zeit, dass Verschlüsselung vereinfacht und automatisiert wird. Nur so kann die Verbreitung von verschlüsselter Kommunikation vorangetrieben werden.
2.
Wird ein Zertifikat missbraucht oder ein privater Schlüssel entwendet, ist dies dank der kurzen Laufzeit der Zertifikate maximal 90 Tage möglich. Zwar bestehen Mechanismen, um im Ernstfall Zertifikate für ungültig zu erklären. Diese sind aber in den meisten Anwendungen schlecht integriert, weshalb diese sogenannte «Certificate-Revocation» in Fachkreisen kritisch beäugt wird.

Können jetzt auch Kriminelle ihre Phishing-Sites verschlüsseln? Bringen SSL-Zertifikate dann noch Vorteile?

Let’s Encrypt hat ausführlich zum Thema Stellung genommen und erklärt, was die Zertifizierungsstelle gegen Missbrauch von SSL-Zertifikaten unternimmt.

Zertifizierungsstellen eignen sich grundsätzlich schlecht, um im Kampf gegen Phishing und Malware eine führende Rolle einzunehmen. Die grosse Anzahl an verschiedenen Zertifizierungsstellen führt dazu, dass sich Kriminelle immer das schwächste Glied in einem solchen Verbund aussuchen. Let’s Encrypt gehört dank Transparenz und Offenheit bestimmt nicht zu den bevorzugten Zielen böswilliger Angreifer, die im Versteckten operieren. Nichtsdestotrotz hat Let’s Encrypt Prüfmechanismen eingebaut, die unter anderem auf die Google Safe Browsing API zurückgreifen. Den Browserherstellern kommt in dieser Frage eine ganz zentrale Rolle zu. Positiv, dass mit Mozilla einer der grössten Browserhersteller zu den treibenden Kräften hinter Let’s Encrypt gehört.

Von der Verschlüsselung von Kommunikation einmal abgesehen, bringen SSL-Zertifikate auch Geschwindigkeitsvorteile. HTTP/2, die neue, schnelle Version des Verbindungsprotokolls für Websites, wird von Browsern nämlich nur über verschlüsselte Verbindungen genutzt. Dass Google die Verschlüsselung von Websites als positiven Faktor in sein Suchresultate einfliessen lässt, ist ebenfalls nicht zu verachten.

Sind kostenpflichtige SSL-Zertifikate sicherer?

In technischer Hinsicht unterscheiden sich kostenlose Zertifikate wie jene von Let’s Encrypt und Zertifikate, die viele hundert Franken pro Jahr kosten, in keinster Weise. Die Kommunikation zwischen Website und Browser ist mit beiden Zertifikaten genau gleich sicher verschlüsselt.

SSL-Zertifikate werden jedoch in drei Klassen unterteilt, die sich in gewissen Merkmalen unterscheiden:

• Domain-Validated-Zertifikate (DV)
• Organisation-Validated-Zertifikate (OV)
• Extended-Validated-Zertifikate (EV)

Let’s Encrypt stellt DV-Zertifikate aus, bei denen geprüft wird, ob der Zertifikate-Antragssteller die Kontrolle über die zu sichernde Domain beweisen kann. Dieser Vorgang lässt sich vollständig automatisieren, trotzdem waren DV-Zertifikate bis anhin (mit Ausnahmen) kostenpflichtig und in den meisten Fällen überteuert. Ein DV-Zertifikat beweist dem Website-Besucher, dass er sich auf der Website befindet, die er besuchen wollte. Dazu ist im Zertifikat die Domain hinterlegt, zu der die Kommunikation verschlüsselt wird. Browser signalisieren die so verschlüsselte Verbindung mit einem Schloss-Symbol.

Bei der Ausstellung von OV- und EV-Zertifikaten prüft die Zertifizierungsstelle zusätzliche Informationen über den Zertifikatbesitzer, zum Beispiel ob dieser im Handelsregister eingetragen oder die angegebene Telefonnummer erreichbar ist. OV-Zertifikate enthalten denn auch nicht nur die gesicherte Domain sondern weitere Informationen zur Organisation, der das Zertifikat gehört. EV-Zertifikate werden in Browsern zusätzlich mit visuellen Merkmalen wie einem grünen Balken dargestellt.

Bonusfrage: Wäre nicht «TLS-Zertifikate» der korrekte Begriff?

Doch, denn die Bezeichnung SSL ist eigentlich hoffnungslos veraltet. Das SSL-Protokoll (Secure Sockets Layer) wurde bereits 1999 durch TLS (Transport Layer Security) abgelöst. Konsequenterweise müssten wir also von TLS-Verschlüsselung und TLS-Zertifikaten sprechen.

Das Thema wird bei uns im Team heiss diskutiert. Wir haben uns vorerst darauf geeinigt, weiterhin den Begriff SSL-Zertifikate zu verwenden. Dieser Begriff ist etabliert und für die meisten Leute verständlicher, wie die vergangenen 16 Jahre bewiesen haben.

Wenn Sie mit uns in Kontakt stehen, dürfen Sie SSL-Zertifikate ungeniert TLS-Zertifikate nennen. Dem entsprechenden Mitarbeiter wird das mit Bestimmtheit ein Lächeln ins Gesicht zaubern ;)

Mit HTTP/2 steht Webentwicklern eine Veränderung ins Haus, die es in sich hat. Bewährte Performance-Tricks werden über den Haufen geworfen und Workflows bei der Entwicklung von Webapplikationen dürfen angepasst werden. Wir zeigen, in welchen Bereichen ein Umdenken angesagt ist und warum das für Ihre Website gut ist.

Die Geschichte von HTTP/2

HTTP, also das Hypertext Transfer Protocol, ist für digitale Verhältnisse uralt. Es wurde 1991 eingeführt und trägt seit 1999 die Versionsnummer 1.1. Entwickelt wurde es unter anderem von Tim Berners-Lee, dem Vater des World-Wide-Webs.

Seit 16 Jahren hat sich an dieser Technologie, die für die Übertragung von Websites genutzt wird, nicht viel verändert. Web- und Computerriesen wie Google und Microsoft begannen deshalb, eigene Nachfolger für HTTP/1.1 zu entwickeln.

Die grössten Wellen schlug dabei Google mit seinem Protokoll SPDY (ausgesprochen Speedy), welches nun auch als Basis für HTTP/2 dient. Der HTTP/2-Standard wurde von der Internet Engineering Taskforce (IETF) im Mai 2015 verabschiedet. Der Rakete HTTP/2 ist damit auch ganz offiziell der Start geglückt.

Bandbreite vs. Latenz

Vergleich des Einflusses von steigender Bandbreite gegenüber sinkender Latenz auf Website-Ladezeiten. Quelle: Ilya Grigorik

Das Hauptziel hinter HTTP/2 ist die Vermeidung von Zeitverlusten durch Latenz. Untersuchungen haben gezeigt, dass ab einer Bandbreite von 5 Mbit/s keine grossen Geschwindigkeitsverbesserungen mehr erreicht werden.

In der Schweiz beträgt die durchschnittliche Bandbreite eines Internetanschlusses 15,6 Mbit/s. Der globale Durchschnitt liegt bei 5,1 Mbit/s.

— Quelle: Akamai’s State of the Internet

Die Verringerung der Latenz bringt hingegen linear Verbesserungen, wenn es um die Ladezeiten von Webseiten geht.

Während auch bei mobilen Verbindungen die Bandbreiten in den letzten Jahren in die Höhe geschnellt sind, sind Latenzen in mobilen 3G- und 4G-Netzwerken aufgrund des eingesetzten Radio Resource Controller (RRC) grundsätzlich höher als bei kabelgebundenen Anbindungen. Der Umschwung der Internetnutzung auf mobile Geräte macht die Verringerung von Latenzen, wie z.B. durch HTTP/2, umso nötiger.

Das macht HTTP/2 besser

Der neue Standard ist vollständig abwärtskompatibel, was die schnelle Verbreitung unterstützt. Die wichtigsten Verbesserungen gegenüber der Version 1.1 sind:

• Kommunikation auf einem Kanal
  Bis anhin musste der Browser für jede einzelne Datei eine eigene TCP-Verbindung öffnen. Das erzeugte unnötigen Datenverkehr und drückte auf die Geschwindigkeit. Mit HTTP/2 wird die Kommunikation zwischen Browser und Server über eine einzige Verbindung abgewickelt.
• Stream Dependency
  Die Kommunikation auf einem einzelnen Kanal benötigt eine gewisse Intelligenz im Hintergrund, damit sich die Datenpaketen nicht in die Quere kommen. Der Browser kann dem Server mitteilen, welche der zu ladenden Dateien für ihn wichtiger sind und die darum zuerst vom Server an den Browser geschickt werden sollen.
• Kompression der Kopfzeilen
  Die sogenannten HTTP-Header beinhalten die wichtigen Zusatzinformationen zu der angeforderten Datei. HTTP/1.1 erzeugt hier viele redundante Daten, was unnötigen Datenverkehr produziert. Mit HTTP/2 lassen sich diese Header drastisch in der Grösse reduzieren. Damit müssen weniger Daten ausgetauscht werden.
• Server Push
  Der Server kann dem Browser bereits Dateien schicken, bevor der Browser die entsprechende Dateien überhaupt angefordert hat. Das verhindert zeitintensive Roundtrips der Datenpakete zwischen dem Browser und dem Server.

  Update: Server Push ist seit September 2017 auf unseren Servern verfügbar.

Alte Hörner abstossen

HTTP/1.1. ist zwar bereits 16 Jahre alt, das Web wäre aber nicht das Web, hätten sich Webentwickler in der Zwischenzeit nicht mit Tricks beholfen.

Um die Nachteile von HTTP/1.1 zu umgehen, ist der Einsatz von Methoden wie CSS-Sprites, Code-Inlining oder Domain-Sharding gang und gäbe. Mit HTTP/2 sind solche Methoden nicht mehr nötig, um eine bessere Performance herauszuholen. In einigen Fällen sind sie sogar kontraproduktiv.

• Concatenation und Sprites
  Das Problem des Head-of-Line-Blocking bei HTTP/1.1 wird mit Concatenation, also dem Zusammenführen von JavaScript- oder CSS-Dateien und dem Spriting von Bildern, dem Verpacken von unterschiedlichen Design-Elementen in einziges Bild, umschifft. Wer schon einmal Anpassungen an einem Sprite und dessen Ausrichtung via CSS machen musste, weiss wie mühsam diese Arbeit sein kann. Ganz zu schweigen von kleinen Änderungen an JavaScript-Code und CSS-Anweisungen, die dazu führen, dass das gesamte Dateipaket neu generiert werden und der Seitencache erneuert werden muss.

Mit HTTP/2 müssen keine Monsterdateien mehr erzeugt werden. Einzelne Dateien dürfen eigenständig bleiben, was die Entwicklung von komplexeren Webapplikationen wieder vereinfacht. Concatenation und Sprites lohnen sich mit HTTP/2 nur dann, wenn mit den Methoden spürbare Verbesserung bei der Kompression von Daten erzielt werden.

• Resource-Inlining
  Eine weitere Methode, um das Head-of-Line-Blocking-Problem zu umgehen, ist das Resource-Inlining. Dabei werden JavaScript, CSS oder sogar Bilder (in hexadezimalem Format) Teil einer HTML-Datei. Die Dateien werden sowieso benötigt, also kann man sich die zusätzlichen Schlaufen für die Beschaffung der einzelnen Dateien damit sparen.

Mit HTTP/2 dürfen wieder granulierte Konstrukte gebaut werden, ohne dass mit Geschwindigkeitseinbussen gerechnet werden muss. Mit Server Push lassen sich die Vorteile von Ressource-Inlining intelligenter lösen. Wie bei Concatenation und Sprites sprechen ausschliesslich Performancegewinne durch Kompression für den Einsatz der Ressource-Inlining-Technik bei HTTP/2.

• Domain-Sharding
  Die bei HTTP/1.1 fehlende Möglichkeit des Multiplexings und die von Browsern limitierte Anzahl von möglichen gleichzeitigen Verbindungen pro Domain hat dazu geführt, dass viele Websites dem Browser vorgaukeln, statische Dateien wie Bilder seien an einem anderen Ort oder sogar in einem Content-Delivery-Network (CDN) gespeichert. Die Folge davon: Der Browser öffnet zusätzliche parallele Verbindungen zur Subdomain, wobei jede dieser Verbindungen Ressourcen wie Arbeitsspeicher, Prozessorzeit und co. kostet. Von der höheren Komplexität einer Webapplikation durch unterschiedliche Hostnamen ganz abgesehen.

Mit HTTP/2 ist Domain-Sharding nicht mehr nötig und kann sogar negative Auswirkungen auf die Performance haben.

Kann ich HTTP/2 schon nutzen?

HTTP/2 wird von den beliebtesten Browsern bereits unterstützt. (Quelle: caniuse.com)

Während die populärsten Browser HTTP/2 bereits länger unterstützen, hat auf der Seite der Webserver-Hersteller die grosse Adaption erst in den letzten Monaten und Wochen stattgefunden. Die beiden Marktführer Apache und nginx unterstützen HTTP/2 in den aktuellen Versionen von Haus aus. Der von uns eingesetzte Webserver war der erste mit signifikantem Marktanteil, der HTTP/2 für seine Benutzer verfügbar gemacht hat.

Ist Ihre Website mit einem SSL/TLS-Zertifikat verschlüsselt und damit per HTTPS erreichbar, nutzen die Besucher Ihrer Website bereits HTTP/2. War der Einsatz eines SSL/TLS-Zertifikats für Sie bislang kein Thema, werden Sie spätestens mit der Lancierung von Let’s Encrypt per Mausklick und ohne zusätzliche Kosten von HTTP/2 profitieren können.

Machen Sie den Test

Ob eine Website per HTTP/2 ausgeliefert wird, lässt sich mit Browser-Plugins oder in den eingebauten Entwickler-Tools überprüfen. Wir können für Chrome und Firefox diese beiden Plugins empfehlen:

• HTTP/2 and SPDY indicator für Chrome
• HTTP/2 Indicator für Firefox

Was HTTP/2 an Geschwindigkeit bringen kann, zeigen Demo-Seiten wie diese von Akamai.

Möchten Sie sich weiter in das Thema einlesen? Dann bietet sich die HTTP/2-Website der IETF HTTP Working Group als erste Anlaufstelle an. Wenn es auch ein bisschen technischer sein darf, lohnt sich ein Blick in das Buch High Performance Browser Networking von Ilya Grigorik.