Mehr als nur HTTPS! Top Google Platzierung in Zukunft!

Warum es JETZT HTTPS sein MUSS!

Bereits seit einigen Monaten predigen die SEO (= Suchdienstoptimerung) Spezialisten, dass die Umstellung von unverschlüsselten Websites auf eine permanent verschlüsselte Auslieferung einen positiven Effekte auf das ach so beliebte Google Ranking hat. Natürlich, war dies doch bereits im August 2014 durch das Google Webmaster Blog mit dem Titel „https als Ranking Signal“ [1] bestätigt worden.

Und so erwarten auch wir, in den kommenden Wochen und Monaten, eine weitere deutliche Forcierung von HTTPS-Websites seitens Google und einen mehr oder minder dezenten Druck https als Standardprotokoll für die Auslieferung des eigenen Shop oder der Website einzurichten.

Doch die bloße Einrichtung eines SSL Zertifikates ist unseres Erachtens nur die „halbe Wahrheit“ und man sollte  bereits bekannten Fallstricke und Hindernisse bei der Umstellung im Auge behalten – und vor allem direkt sich bietende Chancen mit umsetzen.

Conversion (almost) killed Security

Zuletzt fragte mich ein einer unserer Kunden, wieso wir bei dem Launch des Onlineshops vor rund zwei Jahren eigentlich nicht direkt alle Seiten des Magento Shops auf HTTP-Auslieferung umgestellt haben. Damals hatten wir lediglich den Kassenprozess verschlüsselt.

Nach etwas überlegen, kam ich zu der Erkenntnis, dass hierfür maßgeblich wohl die beiden folgenden Tatsachen noch nicht gegeben waren:

  1. Websites, oder Unterseiten von Websites, die über eine SSL Verschlüsselung verfügten wurden in der Regel durch den Browser langsamer geladen als unverschlüsselte Websites. Und da ja Schnelligkeit quasi zum Mantra des Internet gehört, entschied man sich häufig nur das was wirklich erforderlich war, nämlich  Kassenprozesse, Logins oder Partnerbereiche oder ähnliches, zu verschlüsseln. Dieser Sachverhalt wurde häufig noch dadurch verschärft, dass man den zu dieser Zeit recht populären Proxy-Cache Varnish für eine noch schnelle Auslieferung von Websites vorschaltete. Leider unterstützt der Varnish Proxy Cache bis heute jedoch keine HTTPS-Verschlüsselung.
  2. Es gab zu diesem Zeitpunkt noch kein so starkes Bewusstsein für eine notwendige permanente Verschlüsselung, geschweige denn das dies das SSL Zertifikat als Marketing Instrument positiv bewertet wurde. Erst durch die bestätigte Einführung von SSL-Verschlüsselung als Ranking Signal bei Google im August 2014 [1] gewann SSL ein Stück an Bedeutung.

Wenn man jedoch ehrlich ist, war bis vor kurzem jedoch häufig noch immer Punkt 1 – die „Schnelligkeit“ der Website – das KO-Kriterium für die Implementierung von Punkt 2 – der „Sicherheit“.

SPDY, HTTP/2 – Schnell und Sicher auch ohne Proxy Cache

Angetrieben durch die Entwicklung des SPY-Protokoll von Google, begannen diverse Browser Hersteller bereits 2012 mit der Implementation des neuen Protokoll für ein „schnelleres Internet“. SPDY war der erste Protokollentwurf der gleichzeitig eine verschlüsselte und auch schnelle Datenübertragung ermöglichen sollte.

Erreicht wird der schnellere Seiteaufbau durch das sog. Multiplexen von Verbindungen, bei dem beliebig viele  „Datenleitungen“ vom Server zum Browser aufgebaut werden können [3] . Beim HTTP1 bzw. 1.1 Protokoll sind dies heutzutage üblicherweise noch in der Regel 6-8 Verbindungen, maximal jedoch 13 (IE 11) gleichzeitig.[4]

Im Mai 2015 wurde, als Nachfolger zu SPDY, dann letztendlich HTTP2 als neuer Protokoll-Standard verabschiedet und ist nun in den gängigsten Webservern wie Apache (10/2015), Microsoft IIS oder Nginx (ab 09/2015)  verfügbar.

Damit stand und steht seit nunmehr einem Jahr HTTP/2 als neuer Protokolltyp für Websites zur Verfügung und kann damit auch eine permanente Verschlüsselung bei gleichzeitig hoher Ladegeschwindigkeit erzielen, ohne das ein zusätzlicher Proxy Cache von Nöten ist.

„Hilfe, Google sagt meine Website ist unsicher?!“

Kaum zwei Wochen später, nach dem oben geschilderten Fall, erreichte mich erneut eine Kundenanfrage von einem Online Shop Betreiber. Er hatte festgestellt das folgender Hinweis bei der Auslieferung seines Online Shops im Browser zu sehen war:

Sicherheitshinweis im Google Chrome auf eine unverschlüsselte Seite.

Sicherheitshinweis im Google Chrome auf eine unverschlüsselte Seite.

Nachdem ich ihm ein paar prominente Beispiele für andere als vermeintlich unsicher eingestufte Website gezeigt hatte (stern.de, spiegel.de, focus.de ) zeigt er sich zuerst beruhigt.

Doch auch hier sollte man sich nicht mit dieser Aussage zu frieden geben und eventuell nicht nur einen sondern auch zwei Schritte weiterdenken.

Hatte Google bereits in der Vergangenheit  erstmals einen „sanften Einstieg“ für die Etablierung neuer Technologien gewählt, wurden dies über kurz oder lang zum Quasi-Standard und damit zum „Must Have“ für Website und Shop Betreiber.

Im Google Security Blog hat Google bereits für kommendes Jahr Januar 2017, weitere Änderungen an der Darstellung für unsichere Seiten angekündigt und plant bereits die für Januar 2017 erwartete Chrome Version 56 eine drastischere Darstellung der Information zu unverschlüsselten Seiten in künftigen Chrome Versionen einzusetzen. Hier wird dann bereits ein „Not secure“, bzw. die deutsche Übersetzung „Nicht sicher“ vermutlich zu sehen sein. [5]

Sicherheitshinweis im Google Chrome auf eine unverschlüsselte Seite ab Januar 2017.

„Not secure“ Sicherheitshinweis im Google Chrome auf eine unverschlüsselte Seite ab Januar 2017.

Besonders spannend dürfte in dem Artikel der Hinweis auf künftige, später folgende Versionen zur Kennzeichnung im Google Chrome sein, bei dem ein Rotes  Dreieck mit „Not Secure“ einen mögliche Darstellung ist.

"Not Secure" Hinweis in künftigen Google Chrome Versionen.

„Not Secure“ Hinweis in künftigen Google Chrome Versionen.

Google wird nicht müde weiterhin die Vorteile von HTTPS gegenüber HTTP zu betonen [6] und hat unlängst in Ihrem Google Transparency Report Statistiken über die Nutzung von HTTPS veröffentlicht. [7]

Prozentuale Entwicklung zum Laden von Websites über den Chrome Browser via HTTPS

Prozentuale Entwicklung zum Laden von Websites über den Chrome Browser via HTTPS

Exkurs: Google Suche – Jetzt mit „Mobile First“ in den Google Index

Prominentestes Beispiel für die Durchsetzungskraft von Google, dürfte wohl die zuerst schleichende und letztendlich massive Forderung für responsive Websites gewesen sein [8].

Wie unlängst Google angekündigt hat, wird wohl zeitnah der aktuell Mobile Index den bisherigen Desktop Index als Hauptindex ersetzen. D.h. hat Google bislang nachgesehen „Gibt es auch eine für Mobile optimierte Website?“, wird daraus nun ein „Gibt es für die Mobile Website auch eine Desktop Variante?“. [9]

Die eigentliche „Sensation“ dabei ist jedoch nicht, dass Google den Mobile Index als ersten Index einsetzen will – das ist nur logisch, da man wohl inzwischen mehr auf Smartphones im Web unterwegs ist, als auf traditionellen Computern.

Vielmehr ist die Forderung von „structured Data“ auch für mobile Geräte DAS Ding. Hat Google mit schema.org doch gerade zu eine Paradeplattform für structured Data geschaffen, sollte die Implementierung dieser Rich Data Snippet heutzutage in jede „Best Practice“ für den Website- oder Shop Relaunch gehören.

Zwischenfazit:

Neben HTTPS und Mobile First, gehören Rich Data Snippets zum „must have“ aktueller Websites und Shop und können damit das Zünglein an der Waage beim Ranking sein.

Zurück zum Thema: SSL Verschlüsselung

Hat man sich als Website- oder Shop Betreiber nun dazu durchgerungen letztendlich die vollständige Kommunikation mit dem Browser des Kunden nur noch verschlüsselt abzuwickeln, sollte man im Rahmen der Umstellung ein paar Fallstricke berücksichtigen, die einem echt ein paar  unschöne Abende oder gar Wochen bescheren können.

Hier unsere Checkliste für die Basic-Umstellung auf HTTPS:

  1. Welches SSL Zertifikat für welchen Einsatz?
    Heutzutage gibt es SSL Zertifikate, wie beispielsweise bei Let’s Encrypt, kostenlos. Aber passt das für für jeden? 
    Ist ein kostenfreies SSL Zertifikat als Betreiber eines renommierten Online Shops oder einer Website das richtige Signal für meine Kunden? Sind Sie sicher, dass Ihre Kunden nicht hinterfragen, wieso es bei Ihnen nur die „billigste“ aller Varianten sein darf, wenn es doch SSL-Zertifikate inklusive einer Garantiesumme von 500.000 €, 1.000.000 Mio €  und mehr ab 99,00 € pro Jahr gibt? Natürlich ist ein kostenfreies SSL Zertifikat ist besser als keines, aber gerade wenn man nach außen auch zeigen möchte „Hey Kunden, ihr seid mir wichtig!“, lohnt sich die Investition in ein Enhanced Validation Zertifikat, bei dem sogar das Unternehmen hinter dem Shop / der Website prominent und grün in der Browserzeile genannt wird. Schließlich sind diese Enhanced Validation Zertifikate nicht umsonst im Online Banking der De-Facto-Standard.

    Enhanced Validation SSL Zertifikat

    Enhanced Validation SSL Zertifikat

    Einige unserer Kunden nutzen dieses Unterscheidungsmerkmal bereits jetzt um sich gegenüber den Marktbegleitern positiv abzugrenzen.

    Wildcard Zertifikate können direkt mehrere Subdomains auf einmal absichern und somit die perfekte Wahl für alle, die mehrere unterschiedliche Applikationen oder gar Server auf unterschiedlichen Subdomains verteilt haben. Damit lassen sich dann bequem auch künftige, neue Subdomains verschlüsseln, ohne jedes Mal eine neue Verifizierungsrunde beim Zertikataussteller durchführen zu müssen.

  2. Planen Sie die Umstellung von HTTP auf HTTPS auf jeden zeitweise Fall zumindest zeitweise Ranking Verluste ein.
    Inzwischen sagt die  Google Webmaster Hilfe konkret, dass man bei der Umstellung von http auf https eine 301’er Weiterleitung (Redirect Permanent) vornehmen soll [2]. Bis noch vor wenigen Wochen, war hier seitens Google noch keine so klare Aussage zu finden. Obwohl gerne etwas anderes behauptet wird, gehen Sie davon aus das die Umstellung auf HTTPS nicht ohne Ranking Verlust passieren wird. In einem aktuellen Fall haben wir rd. 2-3 Wochen warten müssen, bis Google die Änderungen verarbeitet und damit die Rankings wieder nach oben korrigiert hatte. Danach sollten die Rankings jedoch eventuell schon ein kleines bisschen besser als zuvor sein. Idealerweise terminieren Sie die Umstellung zu einer Zeit wo Sie Ihnen weniger weh tut (Off Season).
  3. Erstellen Sie in den Google Search Console eine neue Property.
    Auch wenn es ein wenig paradox erscheint, kennt Google in der Search Console (aka. Google Webmaster Tools) keinen Protokollwechsel von HTTP auf HTTPS. Ergo muss man also die alte HTTP Property inaktivieren, eine neue Property anlegen und damit die URL Validieren erneut durchführen. Sollten Property Verknüpfungen wie beispielsweise zu Google Analytics vorhanden sein, sind auch diese zu ändern.
  4. Falls nicht bereits erledigt – ändern Sie die Auslieferung auf HTTP2 Protokoll und mehr!
    Die Umstellung auf permanente SSL Verschlüsselung ist wie oben geschildert eine prima Gelegenheit auch gleichzeitig auf das neue HTTP2 Protokoll umzustellen. Nutzen Sie diese Gelegenheit auch um weitere Optimierungsmaßmen in Sachen „Page Speed“ durchzuführen. Die Google PageSpeed Insights [10] liefert dazu wertvolle Hinweise. Generell sollte man überlegen, ob es nicht sinnvoll ist bestimmte Optimierungsmaßnahmen wie beispielsweise die Komprimierung von CSS (Stildefinitionen) und JavaScript direkt vom Server, statt von der Applikation, erledigten zu lassen. Bei der Gelegenheit, kann man auch direkt die dauerhafte Optimierung von Bildern durch den Server vornehmen und für eine komprimierte Übertragung sorgen die dann auch direkt dem Browser mit auf den Weg gibt, wie lange denn die Dateien in seinem Zwischenspeicher (Cache) gelagert werden sollen.
  5. Geben Sie sich und den Rankings Zeit.
    Auch wenn ich mich wiederhole, die Rankings werden abstürzen. Kaufen Sie Baldrian, fahren Sie in Urlaub oder nutzen die gewonnen Zeit dem Alltagsstress zu entgehen und machen endlich den lang ersehnten Yoga Kurs. Die Rankings werden sich erholen.

Jetzt haben wir SSL – ist doch alles super, oder?

Tatsache, Google führt Listen. Ach was?!  Doch wirklich wahr, und zwar protokolliert und veröffentlicht Google in mehr oder weniger unregelmäßigen Abständen eine Liste mit „Top-Websites, die standardmäßig modernes HTTPS verwenden“ [11].  Nun ist es jedoch für die meisten Website Betreiber eher unwahrscheinlich auf diese Liste zu landen, außer man heißt Amazon, Netflix oder auch wikipedia.org. Was die Liste jedoch zeigt ist WIE stark Googles Interesse an HTTPS und Security im Web ist.

Folgt man den o.g. Links zur Liste  kommt man nicht zufällig zu einer Best Practice für die Umstellung auf HTTPS, wo dann auch letztendlich bewiesen steht „Langfristig ist es möglich, dass HTTPS mehr Bedeutung beigemessen wird und der Ranking-Schub stärker ausfällt.“.

Indirekt verlinkt im selben Artikel, gelangt man dort zum Thema Content Security Policy [12]Und genau da sollte man direkt mit daran denken! (Hier sich noch mehr Ausrufezeichen denken).

ACHTUNG! Fachchinesisch. Wir versuchen es dennoch.

Inzwischen gibt es die Möglichkeit auf dem Server zusätzliche Informationen zur Steigerung der Sicherheit bei der Auslieferung der Website direkt an den Browser mit zu übergeben. Diese Informationen nennt man Secure Header und beeinflussen oder ändern nicht die Darstellung einer Website oder eines Shops. Ich möchte an dieser Stelle nicht zu sehr in die Tiefen und Konfigurationsoptionen der SecureHeader einsteigen und statt dessen diese einfache Empfehlungen geben:

Prüfen Sie Ihre Website oder Online Shop auf der folgenden Seite auf die Umsetzung der Secure Header: https://securityheaders.io [13].

 

Secure Header Test - keinerlei Secure Header aktiv!

Secure Header Test – keinerlei Secure Header aktiv!

 

Secure Header Test - alle Secure Header aktiv.

Secure Header Test – alle Secure Header aktiv.

Wenn Sie das Ergebnis nicht in der „Hall of Shame“ oder „Hall of Fame“ veröffentlich sehen wollen, haken Sie bitte „hide results“ an.“  Die Website generiert einen Report über die bereits umgesetzten Secure Header und verlinkt direkt auf eine englischsprachige Website, mit der ein Webentwickler oder eine Internetagentur letztendlich die Secure Header einrichten kann.

Nachfolgend eine kurze Erklärung der jeweiligen Secure Header, die gegen unterschiedliche Angriffsmöglichkeiten zusätzliche Schutzmechanismen im Browser aktivieren.

  • X-Xss-Protection
    Aktiviert die Cross-Site-Scripting Filterung die inzwischen in den meisten Browsern vorhanden ist.
  • X-Content-Type-Options
    Browser versuchen in Ihrer Standardeinstellung automatisch Dateien bestimmten Mime-Typen zuzuordnen und versuchen daher aktiv mittels „MIME-sniff“ für, vom Server gelieferte Inhalte, unterschiedliche Mime-Typen. Dies kann durch die Setzung des Headers auf „ X-Content-Type-Options: nosniff“ vermieden werden.
  • X-Powered-By
    Üblicherweise übertragen Server neben Ihrem Namen gern auch mal zusätzliche Informationen wie eingesetzte Webserver Version, das Betriebssystem oder die eingesetzte PHP Version. Um den Hackern dieser Welt ihre Arbeit nicht noch leichter zu machen, sollte man hier also wirklich nur das nötigste übertragen, also den eingesetzten Webserver (bespielsweise „nginx“, da dies ein erstes Indiz auf veraltete, mit Sicherheitslücken gespickte Software auf dem Server bietet.  Gerne stellen wir hier schon einmal „Commodore C64“ als X-Powered-By Information ein.

    X-Powered-By Header zeigt veraltete PHP Version.

    X-Powered-By Header zeigt veraltete PHP Version.

  • Strict-Transport-Security (HSTS)
    War bislang der Einsatz von SSL-Verschlüsselung häufig nur auf Teilbereiche einer Website oder eines Shops beschränkt (siehe obige Ausführen), weißt diese Header Angabe den Browser nun an, künftig für die Website immer das HTTPS Protokoll für alle Seiten anzufordern. In einer weiteren Einstellung kann man dafür den Prüfzeitraum des Browsers festlegen, weitere Subdomains einschließen und sogar das die Website über eine Preload-Liste im Browser vorgeladen wird.
    ACHTUNG: Dies sollte man natürlich erst dann aktivieren, wenn man langfristig bereit ist die Website über HTTPS ausliefern zu lassen, da die Entfernung von der Preload-Liste ein langwieriger Prozess ein kann. Prüfen ob eine Domain in der Preload Liste eingetragen ist kann man hier: https://hstspreload.appspot.com/ [14]
  • X-FRAME-OPTIONS
    Der Header X-FRAME-OPTIONS zeigt dem Browser an, welche anderen Websites die eigene per Frame oder iFrame einbinden dürfen oder nicht. Durch die Setzung dieses Headers können Sie sich gegen Clickjacking (LINK: Wikipedia) schützen.
  • Content-Security-Policy, X-Content-Security-Policy, X-Webkit-CSP
    Die unterschiedlichen Content Security Policy Header dienen in unterschiedlichen Browser zur Einschränkung und Ausführung von Daten jeglicher Art. In einer Whitelist gibt man an welche Inhaltstypen von welchen URLs und/oder mit welchen Protokollen zugelassen werden und in welchem Umfang sie auf der eigenen Website ausgeführt werden dürfen. Dadurch kann man beispielsweise vermeiden, dass externe JavaScripte von nicht autorisierten Domains nachgeladen und ausgeführt werden, die dann zum Abgreifen von Information dienen.
    Hinweis: Auf diese Header sollte man besonders viel wert legen, da man diese nicht nur ein- und ausschalten kann, sondern statt dessen eine sinnvolle Liste von autorisierten Websites / URLs zusammenstellt, die in der Lage sind Daten für die eigene Website zu liefern oder gar ausgeführt zu werden. Beispielsweise sollten hier Web Tracker wie Google Analytics, eTracker aber auch fremd gehostete Services und SAAS-Dienste wie Live Chats freigegeben werden.
  • Public-Key-Pins
    Die Public-Key-Pins sind die einzigen Header die ein wenig mehr Aufwand auf dem Server erfordern. Hier muss man quasi eine Signatur des eigenen SSL-Zertfikates erstellen und diese Signatur per Header dem Browser übergeben. So kann man sich vor einer „Man in the Middle“ Attacke schützen, bei mit einem kompromittiertes SSL-Zertifikat vermeintliche Sicherheit vorgegaukelt wird. Üblicherweise erstellt man zusätzliche noch auf dem Server ein Backup-Zertifikat von dem ebenfalls die Signatur übertragen wird.
  • Kein Header – aber auch wichtig – PHP Expose.
    Eine einfache aber simple Einstellung in der PHP Konfiguration führt häufig dazu, dass Angreifer über veraltete PHP Versionen bescheid wissen. PHP Expose steht bei  vielen Hostern immer noch standardmäßig auf ON. D.h. hier wird die genaue PHP Version übermittelt. Ist diese, aufgrund der eingesetzten Web Applikation oder schlicht auf Versäumnis des Hoster hin, nicht aktuell und mit den letzten Sicherheitsupdates versehen, bietet sich für einen mögliche Hacker direkt Informationen für einen möglichen Angriff. Die Sicherheitslücken sind ja für alle öffentlich einsehbar (z.B. PHP 5.4).

Und wieso hilft mir das eine Top Platzierung bei Google zu erlangen?

Gehen wir also davon aus, dass ab nächstes Jahr Google uns noch mehr zum Einsatz von SSL-Verschlüsselung überreden möchte. Gehen wir weiter davon aus, dass der dezent verlinkte Hinweis in der „Top 100 ….“ zu den „Content Security Policy“ vielleicht doch kein so großer Zufall ist, besteht die berechtigte Annahme das wir in 2017, vielleicht wie zuvor 2015 responsive Websites, der Einsatz von Secure Headern ein bestätigtes Signal für das Google Ranking werden wird. Und selbst wenn dies noch etwas länger dauert, ein wenig mehr Sicherheit hat noch niemandem geschadet.

Update vom 5.1.2017: Google Chrome zeigt verschlüsselte Webseiten als „Sicher“ an.

In der aktuellen Google Chrome 56 Beta Version werden, Webseiten die eine Passworteingabe erfordern oder Kreditkartendaten abfragen, jedoch über keine SSL Verschlüsselung verfügen, vom Browser als „Not Secure“ / „Nicht Sicher“  markiert. Wir gehen daher davon aus, dass diese Funktion innerhalb der nächsten Wochen und mit der nächsten Version des Chrome Browser ausgerollt wird.

Google Chrome Beta zeigt Website als "Nicht Sicher" an.

Google Chrome Beta zeigt Website als „Nicht Sicher“ an.

Bereits in der aktuellen stabilen und im Umlauf befindlichen Google Chrome 55 Version, werden aktuell Seiten mit SSL Verschlüsselung als „Sicher“ angezeigt – unabhängig davon, ob diese Passwörter oder Kreditkartendaten erfragen.

Google Chrome zeigt Website mit SSL Verschlüsselung als "Sicher" an.

Google Chrome zeigt Website mit SSL Verschlüsselung als „Sicher“ an.

Update vom 23.1.2017: Google Search Console versendet Warn-Emails als „erster Schritt eines langfristigen Plans“

Die Google Search Console (ehemals Google Webmastertools) versenden seit dem 23.1.2017 nun Emails mit Warnhinweisen an Webseiten, die unverschlüsselt Passwörter übertragen. Der genau Text der Email lautet:

Betreff: „Nicht sichere Passworterfassungen lösen in Chrome 56 Warnungen wegen http://url aus“

Text: „Nicht sichere Passworterfassungen lösen in Chrome 56 Warnungen wegen http://url/ aus

An: Inhaber von http://url/

Ab Januar 2017 kennzeichnet Chrome (Version 56 und höher) Seiten, die Passwörter oder Kreditkarteninformationen erfassen, als „nicht sicher“, es sei denn, die Seiten werden über HTTPS bereitgestellt.

Folgende URLs beinhalten Eingabefelder für Passwörter oder Kreditkarteninformationen, die die neue Chrome-Warnung auslösen. Anhand der Beispiele sehen Sie, wo die Warnungen angezeigt werden, und können so entsprechende Maßnahmen zum Schutz der Nutzerdaten ergreifen. Diese Liste ist nicht vollständig.

http://url/seite.html

Die neue Warnung ist der erste Schritt eines langfristigen Plans, nach dem letztlich alle Seiten, die über das unverschlüsselte HTTP-Protokoll bereitgestellt werden, als „nicht sicher“ gekennzeichnet werden sollen.“

Google Search Console Warnung "Nicht sichere Passworterfassungen"

Google Search Console Warnung „Nicht sichere Passworterfassungen“

Quellen Nachweise: