Sicheres Surfen mit HTTPS in Facebook – Fluch und Segen!

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.

 

Share on FacebookTweet about this on TwitterShare on Google+Pin on PinterestShare on LinkedInBuffer this pageEmail this to someone

Es gibt 18 Kommentare

Deinen hinzufügen
  1. 2
    Stefan Lapsch

    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?

  2. 7
    Jason

    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.

  3. 9
    Wolfgang

    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.

  4. 10
    Collin Croome

    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!

  5. 11
    Olli

    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…

  6. 12
    Tom

    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

  7. 13
    Kai

    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

  8. 15
    allfacebook.de | Howto: Mehrere SSL Zertifikate auf Apache einrichten

    […] 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. […]

+ Hinterlasse einen Kommentar