Umstellung auf https, was ist zu beachten (Guide)

Michael Schöttler

Michael Schöttler

Inhaber des Forums
Das https jetzt schon ein kleiner und bald ein etwas größerer Rankingfaktor ist wurde von Google offiziell bestätigt. Aus diesem Grunde schalten nun mehr und mehr Webseitenbetreiber auf https um. Leider gibt es einiges zu beachten und eine menge Tücken. Ein nicht beachten von Umleitungen kann z.B. auch zu massiven Rankingverlusten führen.
Aus diesem Grunde haben wir eine kleine Checkliste entwickelt und eine Anleitung geschrieben.

Sehr gerne erweitern wir diese mit Eurer Hilfe. Was ist Eure generelle Meinung zu https, welche Erfahrungen habt Ihr gemacht und was sollte in dem nachfolgenden Artikel noch mit rein?

https://imwebsein.de/das-1x1-zur-umstellung-auf-https/
 
Wie du das in deinem Guide entsprechend erwaehnst, gibt es da 3 wichtige Dinge zu beachten:

1. Verwendung eines gueltigen Zertifikates
2. Umleitung von HTTP auf HTTPS (301-Weiterleitung wenn moeglich, ansonsten 302)
3. Laden von ALLEN internen und externen Frontend-Ressourcen via HTTPS + interne Links

Die RewriteRule im htaccess ist gut und recht, doch verhindert den Aufruf von unverschluesselten HTTP-Anfragen durch falsch eingebundene interne Ressourcen nicht.

Alle internen und externen Frontend-Ressourcen (JS,CSS,IMG,Video etc.) sollten via HTTPS geladen werden. Um diesem Problem von Anfang an vorzubeugen, koennen beispielsweise all diese Ressourcen mittels '//a.b/c.d' anstelle von 'http(s)://a.b/c.d' eingebunden werden. Dies ist vorallem bei Webseiten die sowohl http als auch https Seiten beinhalten sehr nuetzlich.

Aktualisiere doch noch die restlichen HTTP-Ressourcen in deinem Guide:

IMG: http://imwebsein.de/wp-content/uploads/201...rheit_HTTPS.jpg (2x)
IMG: http://imwebsein.de/wp-content/uploads/201...ung-272x300.png
IMG: http://imwebsein.de/wp-content/uploads/201...k_imwebsein.jpg (5x)
IMG: http://imwebsein.de/wp-content/uploads/201...ebsein-logo.gif
IMG: http://imwebsein.de/wp-content/uploads/201...opie-300x57.jpg

Auch der Link zu http://imwebdesign.de sollte entsprechend angepasst werden.

Desweiteren sollten (sofern moeglich) auch Links zu externen Seiten via HTTPS geladen werden. In deinem Fall waeren das die Facebook Links zu http://www.facebook.com/patrick.posner. Auch wenn diese HTTP Aufrufe von Facebook entsprechend auf HTTPS umgeleitet werden, macht der User hier zuerst einen voellig unnoetigen unverschluesselten Aufruf zum Facebook-Server.
 
Ich habe bis heute keine nachvollziehbare Erklärung gefunden, weshalb jede Seite nur auf HTTPS laufen sollte. Komplett öffentliche Infoseiten, Angebote, News, Blogs... wieso sich den Stress antun da ein Zertifikat zu installieren (dafür in der Regel noch Geld ausgeben) und dieses dann noch jedes Jahr oder so zu erneuern? Den Gewinn an Sicherheit erschliesst sich mir hier nicht.

Dann kommt hinzu, dass Browser je nach dem noch komische Warnungen produzieren, insbesondere bei Verwendung der einfachen Zertifikate. Bei Firefox zum Beispiel: "This website does not supply ownership information". Mir ist klar wieso, aber ist das auch einem 08/15 Surfer klar? Die Meldung tönt nicht vertauenswerweckend und das sollte diese HTTPS Nummer ja hauptsächlich erreichen.

Und übrigens, es wäre wohl gut, wenn Michaels Infoseite wie von Wasi angetönt selbst die Empfehlungen korrekt umsetzen würde. "The connection to this website is not fully secure", motzt Firefox. Es sind also noch Elemente drin, die nicht per HTTPS geladen werden.
 
QUOTE (retok @ Sa 11.04.2015, 18:36) Ich habe bis heute keine nachvollziehbare Erklärung gefunden, weshalb jede Seite nur auf HTTPS laufen sollte. Komplett öffentliche Infoseiten, Angebote, News, Blogs... wieso sich den Stress antun da ein Zertifikat zu installieren (dafür in der Regel noch Geld ausgeben) und dieses dann noch jedes Jahr oder so zu erneuern? Den Gewinn an Sicherheit erschliesst sich mir hier nicht.

Dann kommt hinzu, dass Browser je nach dem noch komische Warnungen produzieren, insbesondere bei Verwendung der einfachen Zertifikate. Bei Firefox zum Beispiel: "This website does not supply ownership information". Mir ist klar wieso, aber ist das auch einem 08/15 Surfer klar? Die Meldung tönt nicht vertauenswerweckend und das sollte diese HTTPS Nummer ja hauptsächlich erreichen.

Und übrigens, es wäre wohl gut, wenn Michaels Infoseite wie von Wasi angetönt selbst die Empfehlungen korrekt umsetzen würde. "The connection to this website is not fully secure", motzt Firefox. Es sind also noch Elemente drin, die nicht per HTTPS geladen werden.

Das ist korrekt und das gehen wir Montag auch gleich an. Problem ist das wirklich jeder Link händisch auf https umgestellt werden muss. Da wir die Seite aber diesen Monat noch Anpassen und Verändern, da wir ein weiteres Projekt starten, werden wir das da dann auch gleich mit angehen. Zu einem Rankingvorteil hat es aber m.M.n. schon geführt die Umstellung.

Aber ich gebe dir Recht deine Bedenken sind sicherlich nicht verkehrt, auch wenn es um ganz einfache Infoseiten geht, die 0 Abfragen machen...
 
Wir koennten wohl Stunden lang darueber 'streiten', was HTTPS nun eigentlich genau bringt. Meine Kurzfassung hierzu ist: SSL/TLS wie es bisher kommerziell verwendet wird, bringt mehr Scheinsicherheit als wirkliche 'Security/Privacy' und ist somit sicherlich nicht die Loesung fuer ein 'sicheres' Web. Eines der grossen Probleme hierzu sind die Zertifikatstellen. Die Idee hier waere, dass ein Nutzer sicherstellen kann mit der entsprechenden Instanz (Firma,Organisation etc.) eine verschluesselte Verbindung zu deren Webseite(n) aufzubauen und aufrecht zu erhalten. Der Verifizierungsprozess beim Erstellen eines SSL-Zertifikats ueber solche Stellen ist meisst jedoch eher lachhaft. Das Einschalten von Authoritaeten in Form von Drittanbietern kann und wird hierzu nicht die Loesung sein. Doch bis wir fuer den kommerziellen Nutzen solcher Protokolle eine bessere Loesung haben, muessen wir mit dieser Implementierung wohl zurecht kommen.

Nun zu dem Thema "Soll ich fuer meine Seite(n) HTTPS verwenden?". Generell gesagt sollten Seiten die Aktionen auf Nutzerebene ausfuehren via HTTPS laufen. Fuer einfache Informationsseiten sehe ich keinen Grund dazu (bis auf das Kontaktformular).

Sicherheit der Webseite (HTTPS kaum relevant):
Via HTTP uebermittelte Login-Daten und Authentifizierungs-Cookies koennen dafuer sorgen, dass jemand sich bei der Kommunikation dazwischen schalten, diese Daten auslesen und somit diese Accounts misbrauchen kann. Dies ist jedoch erst ein Problem, sobald die 'gehackten' Nutzer-Accounts heikle Aktionen auf dem Server ausfuehren koennen, oder die verwendete Applikation kritische Sicherheitsmaengel aufweist. Als Beispiel bei Ayom haette es eine SQLi-Luecke im Moderatorenzenter und ein Angreifer kann ein Auth-Cookie eines Moderators ermitteln. Dies ist nur einer der vielen Moeglichkeiten eine Webseite zu gefaerden was via HTTPS zumindest den Einstieg fuer den Angreifer wenigstens etwas erschwaeren koennte. Btw: Auch ohne SQLi-Luecke kann dies entsprechenden Schaden anrichten. Wir hatten hier vor Jahren mal einen aehnlichen Vorfall. HTTPS ist fuer die Server- und Anwendungs-Sicherheit jedoch lediglich ein sehr sehr kleiner Aspekt.

Privatsphaere der Nutzer (HTTPS durchaus hilfreich):
Sobald Benutzer einer Webseite persoeliche Daten an den Server uebermitteln, sollten diese Aufrufe via HTTPS durchgefuehrt werden. Dies gilt beispielsweise fuer Kontaktformulare, Logins und Authentifizierungs-Cookies. Desweiteren sollten all diese Daten nicht via GET uebermittelt werden (verwende dafuer POST beziehungsweise Cookies). Dies ist insbesondere weil jegliche GET-Anfragen vollstaendig in der History der Nutzer gespeichert werden und wir kennen ja den Sicherheitslevel eines 0815-Computer-Nutzers
wink.gif
.

Marketing generell (HTTPS immer entscheidender, doch aus den falschen Gruenden):
Da den meisten Webnutzern nicht klar ist wie HTTPS technisch ablaeuft, koennen diese nicht abschaetzen, wann dies wirklich einen Vorteil mit sich bringt bzw. bringen kann. Der 0815 Webnutzer verwendet ja groessten teils nur Webseiten die HTTPS verwenden (und dies bei denen auch sinnvoll ist) wie Facebook, twitter, youtube etc. Desweiteren hoert man von immer mehr verschiedenen Quellen das HTTPS einen Nutzen bringen (kann). Das die Leute sich dann auf Webseiten mit korrekt implementiertem SSL sicherer fuehlen ist daher nicht verwunderlich.

SEO:
Eine Webseite auf HTTPS umzustellen, nur weil Google dies nun gegenueber HTTP-Seiten scheinbar bevorzugt ist m.E. etwas unnuetz. Ich bin mir sicher, dass Google in Zukunft in der Lage sein wird zu ermitteln ob fuer eine spezifische Seite HTTPS ueberhaupt sinnvoll/notwendig ist und lediglich diejenigen 'abstraffen' wird, die HTTPS verwenden sollten, dies aber nicht tun.
 
QUOTE (Wasi @ Sa 11.04.2015, 07:59) Wie du das in deinem Guide entsprechend erwaehnst, gibt es da 3 wichtige Dinge zu beachten:

1. Verwendung eines gueltigen Zertifikates
2. Umleitung von HTTP auf HTTPS (301-Weiterleitung wenn moeglich, ansonsten 302)
3. Laden von ALLEN internen und externen Frontend-Ressourcen via HTTPS + interne Links

Die RewriteRule im htaccess ist gut und recht, doch verhindert den Aufruf von unverschluesselten HTTP-Anfragen durch falsch eingebundene interne Ressourcen nicht.

Alle internen und externen Frontend-Ressourcen (JS,CSS,IMG,Video etc.) sollten via HTTPS geladen werden. Um diesem Problem von Anfang an vorzubeugen, koennen beispielsweise all diese Ressourcen mittels '//a.b/c.d' anstelle von 'http(s)://a.b/c.d' eingebunden werden. Dies ist vorallem bei Webseiten die sowohl http als auch https Seiten beinhalten sehr nuetzlich.

Aktualisiere doch noch die restlichen HTTP-Ressourcen in deinem Guide:

IMG: http://imwebsein.de/wp-content/uploads/201...rheit_HTTPS.jpg (2x)
IMG: http://imwebsein.de/wp-content/uploads/201...ung-272x300.png
IMG: http://imwebsein.de/wp-content/uploads/201...k_imwebsein.jpg (5x)
IMG: http://imwebsein.de/wp-content/uploads/201...ebsein-logo.gif
IMG: http://imwebsein.de/wp-content/uploads/201...opie-300x57.jpg

Auch der Link zu http://imwebdesign.de sollte entsprechend angepasst werden.

Desweiteren sollten (sofern moeglich) auch Links zu externen Seiten via HTTPS geladen werden. In deinem Fall waeren das die Facebook Links zu http://www.facebook.com/patrick.posner. Auch wenn diese HTTP Aufrufe von Facebook entsprechend auf HTTPS umgeleitet werden, macht der User hier zuerst einen voellig unnoetigen unverschluesselten Aufruf zum Facebook-Server.

Hallo Wasi,

vielen Dank für dein Feedback, den Tipp mit den internen/externen Ressourcen finde ich wirklich gut.
Schon etwas peinlich einen Beitrag über HTTPS zu schreiben und dann seinen eigenen Artikel nicht angepasst zu haben :) .
Ich habe nun die restlichen HTTP-Ressourcen entsprechend mit ihren HTTPS-Ressourcen ausgetauscht.

Den Facebook-Link hatte ich gar nicht beachtet, zu mal der Google+ Link ja mit HTTPS eingebunden ist. Hier muss ich wohl direkte Anpassungen im Plugin vornehmen,
bevor dieses Problem aus der Welt geschafft werden kann.

Aufruf von unverschlüsselten Ressourcen via .htaccess
Das stimmt wohl, ich nehme an du würdest das direkt über den Serverport machen, oder?

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]

Wenn du noch Anmerkungen hast, immer her damit ;-)


 
Um mal die Liste zu ergänzen:
Drittanbietertools/-skripte, die an den URL gebunden sind, funktionieren möglicherweise auch durch ein sauberes Redirect nicht mehr. Das schlimmste Beispiel sind hier Kommentarfunktionen, Facebook-Likes, Google +1, etc. Zum aktuellen Zeitpunkt verschwinden die (sichtbaren) Social-Signals bei einer Umstellung von http auf https.

Zum Thema Sinnhaftigkeit hat Wasi schon sehr ausführlich geschrieben. Besonders die Privatsphäre, die auch bei einer Stellensuche vom Arbeitnehmer-PC aus getätigt wird, weiß der Jobsuchende selten, dass sein Chef durch Protokollierungen die Möglichkeit hat, um zu sehen, wer welche Seiten aufruft. Ich selbst hatte auch sehr lange nach dem Grund dieses Rankingfaktors gesucht, bis Google-Mitarbeiter Johannes Müller dieses Beispiel gebracht hatte.
 
QUOTE (Steve Naumann @ Di 9.06.2015, 20:59) [...]
Besonders die Privatsphäre, die auch bei einer Stellensuche vom Arbeitnehmer-PC aus getätigt wird, weiß der Jobsuchende selten, dass sein Chef durch Protokollierungen die Möglichkeit hat, um zu sehen, wer welche Seiten aufruft. Ich selbst hatte auch sehr lange nach dem Grund dieses Rankingfaktors gesucht, bis Google-Mitarbeiter Johannes Müller dieses Beispiel gebracht hatte.

Das ist kein wirkliches Argument, wenn der Arbeitgeber es richtig abklärt, kann er auch den SSL-Traffic loggen, womit den Arbeitgeber wohl höhrere Auflagen auferlegt werden, es aber nicht unmöglich macht, dieses trotzdem durchzuführen.
Wobei es meistens eh keine Rolle spielt, wenn der Arbeitgeber klar sagt, dass das Internet nicht für private Zwecke verwendet werden darf, darunter fällt dann auch die Jobsuche am Arbeitnehmer-PC.

Und was ein Arbeitsnehmer ggf. mit entsprechener Abklärung noch alles darf, das geht noch viel weiter als diese Geringfügigkeit.
 
Ich habe mir auch immer die Frage gestellt, warum die Seiten auf HTTPS umgestellt werden sollen. Hier habe ich jetzt einige und gute Erklärungen gefunden.

Dass hier die Sicherheit eine große Rolle spielt, das ist mir jetzt auch klar.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben