Sicheres Surfen mit HTTPS in Facebook – Fluch und Segen!
- Gastbeitrag von Thomas Hutter –
Sicherheitsaspekte im Zusammenhang mit Facebook waren in der Vergangenheit öfters Inhalt von weitreichenden Diskussionen und einer der grössten Kritikpunkte gegenüber Facebook. Mit der Einführung des sicheren Surfens via „HTTPS“ (SSL) im Januar 2011 brachte Facebook eine von vielen Nutzern gewünschte Verbesserung der Plattform.
Segen für Surfer
Mit der Aktivierung des sicheren Surfens über die HTTPS-Funktion werden neben den Logindaten auch alle anderen vertraulichen Daten vor dem möglichen sind Mitlesen von Dritten geschützt. Die Gefahr eines Kompromittierens des Facebookbenutzerkontos ist bei aktiviertem HTTPS-Protokoll wesentlich vermindert.
Das „sichere Surfen“ kann in den Kontoeinstellungen im Abschnitt Kontosicherheit aktiviert werden:
Abbildung 1 Sicheres Durchstöbern (https) in den Kontoeinstellungen
Fluch für Seiten- und Applikationsbetreiber
Des einen Freud ist des anderen Leid, Betreiber von Facebookseiten und Facebookapplikationen sind mit der Einführung der HTTPS-Funktionalität laufend vor neue Herausforderungen gestellt. Die (vor-)schnelle Einführung der neuen Sicherheitsfunktionalität zog einige Umstellungen im Zusammenhang mit Facebookapplikationen nach sich. Anbieter und Betreiber von Facebookapplikationen mussten/müssen entsprechende Anpassungen in den Serverumgebungen ebenfalls vornehmen, vorausgesetzt sie möchten den Besuchern mit aktiviertem „sicheren Surfen“ die gleichen Inhalte anbieten, andernfalls werden entsprechende Reiter nicht angezeigt.
Welche Anwendungen sind von HTTPS betroffen?
Nicht alle Anwendungen sind von der HTTPS-Problematik betroffen. Seitenbetreiber, welche individuelle Reiter mit der Standard-FBML-Applikation von Facebook erstellt haben, können in diesem Zusammenhang aufatmen, die Reiter werden nach wie vor allen Surfern richtig angezeigt, unabhängig von der Verwendung von HTTPS oder HTTPS. Alle Seitenbetreiber, die individuelle Reiter oder Anwendungen in die Facebookseite integriert haben, welche über einen Drittserver und ohne Verwendung der Static-FBML-Applikation erstellt wurden, müssen Ihre Applikation entsprechend erweitern und anpassen, andernfalls werden die Reiter Besuchern mit aktiviertem HTTPS nicht angezeigt:
| Anpassung notwendig |
Keine Anpassung |
|
| Static FBML- Applikation | X | |
| FBML-Applikationen | X | |
| iFramePageTabs | X |
Welche Anpassungen müssen vorgenommen werden?
Betreiber von FBML-Applikationen und IFramePageTabs müssen in den Applikationseinstellungen Anpassungen für die Verwendung der Applikation im Zusammenhang mit dem HTTPS-Protokoll vornehmen:
- Leinwand
Sichere Canvas-URL - Seiten-Reiter
Secure Tab URL
Abbildung 2 Anpassung der Einstellungen bei Applikationen
Wird eine der beiden Einstellungen nicht vorgenommen, ist die Applikation, bzw. der Reiter innerhalb einer Facebookseite für den mit HTTPS-surfenden Benutzern nicht sichtbar.
Ebenfalls müssen Entwickler in der Applikation sicherstellen, dass Verlinkungen innerhalb der Applikation ebenfalls eine saubere Einbindung von HTTPS sicherstellen, Verlinkungen zu eingebetteten Scripts und Inhalten müssen ebenfalls via HTTPS-Aufruf verbunden werden, andernfalls kann es zu weiteren Problemen führen.
HTTPS ist nicht HTTPS – Probleme mit Google Chrome
Probleme mit HTTPS können aber auch bei der Verwendung von „shared“-SSL-Zertifikaten auftreten, allerdings macht in diesem Zusammenhang nicht Facebook ein Problem, sondern Google Chrome. Bei iFramePageTabs, welche auf Hostings mit „shared“-SSL-Zertifikaten eingerichtet sind, verweigert unter Umständen Google Chrome die Anzeige der Inhalte, anstelle der gewünschten Inhalte wird eine rote Seite mit einer Warnmeldung angezeigt.
Unzureichende Informationen von Facebook
Leider erwies sich Facebook im Zusammenhang mit den HTTPS-Umstellungen nicht als vorbildlicher Kommunikator. Die Umstellungen in den Applikationen waren bereits vor der Publikation der dazugehörigen Informationen notwendig, einige Seiten- und Applikationsbetreiber haben in den vergangenen Tagen stundenweise nach Ursachen und Fehler von nicht angezeigten Inhalten gesucht. Besonders mühsam sind solche „unangekündigten“ Umstellungen bei laufenden Kampagnen und Gewinnspielen – vor allem wenn diese mit aufwändigen AdKampagnen begleitet werden.
Viele „grosse“ Seiten sind betroffen
Auch Betreiber von grossen Facebookseiten sind von den Umstellungen betroffen und wurden für einmal nicht durch die Keyaccountmanager vorgewarnt. Die HTTPS-Problematik ist beim Vergleich einiger der Facebookseiten der Topbrands gut erkennbar:
Abbildung 3 Vergleich der HTTPS-Problematik bei Seiten der TobBrands
Bei Coca Cola und Starbucks fehlen die Landingtabs bei der HTTPS-Ansicht. Bei Starbucks fehlen sämtliche individuellen Inhaltsseiten. Auch bei Red Bull fehlen bei der HTTPS-Ansicht sämtliche individuellen Inhaltsseiten (Athlets, Web TV, Games und Red Bull), eine Landingpage ist inexistent. Ähnlich bei Disney, während bei Disney die Landingtab zwar bei beiden Versionen angezeigt wird, sind die weiteren individuellen Tabs (Disney Downloads und Fan Board) sowie besonders schmerzhaft der kommerziell interessante Tab „TicketsTogether“ nicht mehr sichtbar.
Fazit
Obwohl ich das sichere Surfen via HTTPS sehr begrüsse, zieht die neu gewonnene Sicherheit einige Probleme mit sich. Wünschenswert wäre eine verbesserte Informationspolitik mit Vorlaufzeit von Seiten Facebook, Entwickler und Betreiber von Facebookseiten hätten eine grössere Sicherheit und müssten sich weniger mit „Halsüberkopf-Aktionen“ um ihre Facebookseiten und –applikationen kümmern. Facebook würde mit einem „überlegteren“ Handeln an Seriosität bei den Kunden punkten, der Einsatz von Facebook wäre bei grossangelegten Kampagnen berechenbarer und würde so ein kleineres Risiko bürgen…
Über den Autor:
Thomas Hutter (35) ist Inhaber und Geschäftsführer der Hutter Consult GmbH. Er berät Unternehmen und Agenturen in der Schweiz, Deutschland und Österreich rund um Facebook Marketing und Social Media. Neben seiner Beratertätigkeit organisiert er Inhouse-Workshops/Seminare in Unternehmen und Agenturen und hält Vorträge. Er unterrichtet u.a. für na media workshop, Schweiz. Medienausbildungszentrum (MAZ), Hochschule für Wirtschaft Zürich (HWZ) und für diverse weitere Anbieter. In seinem Blog www.thomashutter.com berichtet er laufend über neue Entwicklungen im Bereich Facebook Marketing und Social Media.
Über den Autor:
Gastautor: Dieser Beitrag wurde von einem Gastautor erstellt (siehe Verweis im Beitrag). Wir sind laufend auf der Suche nach neuen Gastautoren die ihre Expertise in einem Themengebiet bei uns diskutieren und veröffentlichen wollen. Wenn du auch Lust hast bei uns im Blog einen Beitrag zu veröffentlichen kannst du dich einfach bei uns melden. Mehr...
März 23rd, 2011 at 13:04
Danke für den Beitrag! Das hätte i.d.T. gerne vorher angekündigt werden dürfen.
März 23rd, 2011 at 13:12
Danke für diesen Artikel Thomas. Das Problem beschäftigt uns derzeit sehr. Verstehe ich das richtig, dass man einfach die “Canvas-URL” und die “URL des Reiters” in die Felder “Sichere Canvas-URL” und “Secure Tab URL” übertragen muss (mit HTTPS davor), um sich einem Großteil des Problems zu entledigen?
März 23rd, 2011 at 13:17
Hab es im Posting vergessen, Thomas schreibt beim Thomas Hutter’s Social Media Blog auch regelmäßig über Themen Facebook & Social Media.
März 23rd, 2011 at 13:22
Danke für die detaillierte Darstellung. Wichtig, dass Sie auf die Problematik aufmerksam machen.
März 23rd, 2011 at 14:32
@Christian: Das mit der Synchronisierungsproblematik hab ich auch schon bemerkt. Https bringt mir auch nur Ärger.
März 23rd, 2011 at 14:33
Ist doch wieder so Feature was für die meisten Pages/Apps relativ unwichtig ist, da ohnehin keine relevanten Daten übertragen werden und der Nutzer i.d.R. noch nichtmal großartig Daten versendet sondern meistens eher Informationen abruft. Das hätte FB dann so implementieren sollen, dass bei solchen Pages die SSL Verschlüsselung wieder abgeschaltet wird, aber nun ist es nunmal anders gelöst worden, also SSL Zerti bestellen…..
März 23rd, 2011 at 14:52
Die Änderung zeigt mal wieder, wie wenig Wert Facebook auf Entwickler legt. Viel zu kurze Anpassungszeiten, kein Support und haufenweise Fehler in der Facebook Api selbst.
Bestes Beispiel ist das neue Formular zum einladen von Usern. Ab 20 Einladungen über https, zeigt Facebook eine 404 Seite.
März 23rd, 2011 at 14:55
Facebook hat noch nie Wert auf Entwickler gelegt. Sie sprechen zwar von “user experience”, aber bei null Support, schlechter Doku und zahlreichen Bugs, ist es einem Entwickler kaum möglich, die “user experience” umzusetzen.
März 23rd, 2011 at 21:37
Ich stehe vor dem Problem, dass mein Hoster kein Shared SSL anbietet. Gibt es solche Dienste, die nicht auf einen bestimmten Webhoster beschränkt sind und von jeder Domain genutzt werden können? Jeden Monat 10 Euro für ein SSL Zertifikat zu blechen lohnt sich für diesen Zweck dann auch wieder nicht.
März 24th, 2011 at 11:27
Unser Kunde hat genau in der Zeit der HTTPS Umstellung eine große Facebook Kampagne mit einer iFrames App gelauncht. Parallel dazu wurde sehr viel Geld in Facebook Engagement Ads investiert. Da die App durch die Umstellung nicht zuverlässig angezeigt wurde, war das Ergebnis entsprechend “nüchtern”.
Hier hat der Kunde sehr viel Geld “verloren” und ist nun entsprechend “gut” auf Facebook Marketing zu sprechen. Er wird sein Marketing- und Media-Budget in Zukunft wohl anderweitig investieren…
Die Kulanz von Facebook beschränkte sich in diesem Fall auf einen Werbegutschein in Höhe von 2% des investierten Werbebudgets…
Facebook sollte hier unbedingt an seiner Informationspolitik arbeiten. Das Argument, dass Facebook nichts kostet und man daher keinen Support leisten kann, zieht in diesem Falle nicht!
März 24th, 2011 at 18:32
Das Problem mit Google Chrome und Shared SSL sollte sich eigentlich mit der ursprünglichen Domain lösen lassen. Z. B. bei AllInkl setzt man dann https://ssl-accout.com/SUB.DOMAIN.TLD – Vorher setzt man für den entsprechenden Ordner auf dem Server, in dem die App ist einen Subdomain und dann knurrt auch Chrome nicht mehr mit dem Shared Certificate…
Mai 11th, 2011 at 09:35
Hallo,
ich habe irgendwie genau das andere Problem. Ich habe einen Facebook Page die nur bei HTTPS angezeigt wird. Wenn ich die Seite per HTTP aufrufe sehe ich nur die Überschrift und der Rest bleibt komplett weiss.
Hat da jemand einen Idee was ich tun kann ?
beste Grüße Tom
Mai 26th, 2011 at 13:23
Hallo,
stehe auch gerade vor der Entscheidung ein SSL Zertifikat für meinen Server zu ordern. Kann mir jemand sagen was für ein Zertifikat von nöten ist das Facebook oder der Browser nicht meckert? Muss es ein Zertifikat mit Validierung des Domaininhabers sein? Oder reicht ein Basis SSL Zertifikat. Ich bin z.B. bei Hosteurope und da gibt es viele verschiedene: http://www.hosteurope.de/produkte/SSL-Zertifikate
Vielen Dank für eure Hilfe
Juni 3rd, 2011 at 10:59
[...] Weitere Informationen zu diesem Thema hat Thomas Hutter im März schon bei uns als Gastbeitrag zusam… [...]
Juli 18th, 2011 at 11:43
[...] Bekanntermaßen müssen ab 1. Oktober 2011 alle Facebook Apps über ein SSL Zertifikat verfügen – ansonsten sollen diese laut Facebook Developer Roadmap nicht mehr erreichbar sein (auch für „nicht SSL Surfer“). Mit einem der großen Standard-Hoster (wie bspweise 1&1) wird die Einrichtung der Zertifikate wenig Probleme bereiten. Anders sieht es aus, wenn man einen Root-Server betreibt und dort eine Vielzahl von Apps hostet. Die Installation des ersten Zertifikats funktioniert in den meisten Fällen mehr oder weniger reibungslos, beim zweiten tauchen dann Probleme beim konfigurieren auf. Doch machen wir es kurz: Mit dem standardmäßig installierten „mod_ssl“ kann ein Apache Server nur ein (!) SSL Zertifikat behandeln. [...]
August 2nd, 2011 at 09:39
[...] Sicheres Surfen mit HTTPS in Facebook – Fluch und Segen! (März 2011) [...]
Oktober 4th, 2011 at 12:52
[...] Sicheres Surfen mit HTTPS in Facebook – Fluch und Segen! (März 2011) [...]
Januar 9th, 2012 at 11:14
[...] Hinweise und auch die von Sven Rabe scheinbar einiges bewirkt, dennoch gibt es auch nach Monaten (allfacebook informierte schon im März 2011, die tatsächliche endgültige Umstellung erfolgte im Oktober) noch die eine oder andere Seite, auf [...]