Vorsicht vor base64-Bildern in SSL-Umgebungen

Weil ich es gerade mühsam herausfinden musste: IE6 und IE7 reagieren (völlig zurecht) allergisch auf vermischte Protokolle. Wenn eine Seite unter https:// aufgerufen wird, dürfen eingebettete Inhalte ausschließlich ebenfalls mit https:// daherkommen.

Problem ist leider, dass ein Hintergrundbild, welches ich im CSS mittels der base64-Methode inline in das CSS-File reingeschrieben habe, vom IE6 und IE7 als extern per http:// eingebundenes Bild gewertet wird, und damit die »Mixed Content« Warnung ausgeworfen wird!

Ich bin drauf reingefallen, weil ich das beliebte CSS-Gradient-Tool verwendet habe, welches solchen Code ausspuckt:

background: #1e5799; /* Old browsers */
/* IE9 SVG, needs conditional override of 'filter' to 'none' */
background: url(data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiA/Pgo8c3ZnIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgdmlld0JveD0iMCAwIDEgMSIgcHJlc2VydmVBc3BlY3RSYXRpbz0ibm9uZSI+CiAgPGxpbmVhckdyYWRpZW50IGlkPSJncmFkLXVjZ2ctZ2VuZXJhdGVkIiBncmFkaWVudFVuaXRzPSJ1c2VyU3BhY2VPblVzZSIgeDE9IjAlIiB5MT0iMCUiIHgyPSIwJSIgeTI9IjEwMCUiPgogICAgPHN0b3Agb2Zmc2V0PSIwJSIgc3RvcC1jb2xvcj0iIzFlNTc5OSIgc3RvcC1vcGFjaXR5PSIxIi8+CiAgICA8c3RvcCBvZmZzZXQ9IjUwJSIgc3RvcC1jb2xvcj0iIzI5ODlkOCIgc3RvcC1vcGFjaXR5PSIxIi8+CiAgICA8c3RvcCBvZmZzZXQ9IjUxJSIgc3RvcC1jb2xvcj0iIzIwN2NjYSIgc3RvcC1vcGFjaXR5PSIxIi8+CiAgICA8c3RvcCBvZmZzZXQ9IjEwMCUiIHN0b3AtY29sb3I9IiM3ZGI5ZTgiIHN0b3Atb3BhY2l0eT0iMSIvPgogIDwvbGluZWFyR3JhZGllbnQ+CiAgPHJlY3QgeD0iMCIgeT0iMCIgd2lkdGg9IjEiIGhlaWdodD0iMSIgZmlsbD0idXJsKCNncmFkLXVjZ2ctZ2VuZXJhdGVkKSIgLz4KPC9zdmc+);
background: -moz-linear-gradient(top,  #1e5799 0%, #2989d8 50%, #207cca 51%, #7db9e8 100%); /* FF3.6+ */
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#1e5799), color-stop(50%,#2989d8), color-stop(51%,#207cca), color-stop(100%,#7db9e8)); /* Chrome,Safari4+ */
background: -webkit-linear-gradient(top,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* Chrome10+,Safari5.1+ */
background: -o-linear-gradient(top,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* Opera 11.10+ */
background: -ms-linear-gradient(top,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* IE10+ */
background: linear-gradient(to bottom,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* W3C */
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#1e5799', endColorstr='#7db9e8',GradientType=0 ); /* IE6-8 */

11 Kommentare

Dirk

Na, das ist aber mal wieder ein IE-Bug. Denn wenn das eingebettet ist und per SSL übertragen wurde, ist ein Fehler vom IE, wenn es das als HTTP wertet.

Wobei ich jetzt nicht nachgeprüft habe, was irgendein Standard dazu sagt.

Markus

Das erklärt einiges.
Vielen Dank für den Hinweis!

Gerrit

@Dirk: Klar ist das ein Bug. Deswegen schreibe ich das ja hier.

florian

Das ist ein bekanntes Verhalten?! (Seit 2001 …)

Im Standard ist die Einbindung von Quellcode (oder hier: base64-images) nicht explizit geregelt.

Und gemessen am Standard ist das Verhalten des IE <=7 durchaus richtig; das ist also kein Bug sondern von Mikrosaft nicht benutzerfreundlich gelöst …

Richtige Browser und sogar neuere Versionen des IE weisen einfach etwas subtiler darauf hin, dass man den SSL-Bereich verlassen hat (also dass wenigstens eine zu implementierende Datei NICHT per https angeboten wird).

Gerrit

@florian: Naja, der Clou ist ja, dass bei base64-Bildern keine externe Datei aufgerufen wird, sondern die Bilder Teil des CSS-Files sind, welches ja korrekt über https eingebunden ist. Insofern schon ein Bug, in meinen Augen.

florian

@Gerrit: Nein, das ist nicht (zumindest war es damals nicht) im Standard geregelt. Daher kann man nicht von einem Bug sprechen.

Auch wenn sich im IE dieser Einzelfall »falsch« anfühlt, hat MS sich damals an die Vorgaben gehalten. Das ist aus heutiger Sicht Irrsin, ist von zeitgenössischen Browsern aber genauso geregelt worden.

Das Problem ist auch hier eher, dass immernoch 5 bzw 10 Jahre alte Browser genutzt werden.

(Das ist ein bisschen so, als würde ich ein Buch von 1993 heute korrekturlesen und dem Verlag vorwerfen, dass er sich gar nicht an die geltende Rechtschreibung hält.)

Also: Bug nein, Benutzerunfreundlich ja.

Gero

Ob der Standard von damals Inline-Bilder vorgesehen hat oder nicht, sei mal völlig dahingestellt – ich sehe hier den Anlass für die „Salvatorische Klausel“: „An die Stelle der unwirksamen oder undurchführbaren Bestimmung soll diejenige wirksame und durchführbare Regelung treten, deren Wirkungen der […] Zielsetzung am nächsten kommen […]“

Anders gesagt: Was nicht mehr einzeln übertragen wird, weil es schon inline per CSS vorliegt und deswegen nicht mehr übertragen werden muss, kann nicht als „,mit irgendwas übertragen“ gewertet werden. Insbesondere die Einstufung als „http = nicht-https = unsicher im https-Umfeld“ ist microsoft-browser-typisch … sagen wir … weltfremd, ehe ich hier zu Kraftausdrücken greife.

Sagen wir so: Wenn es aussieht wie ein Bug und dabei quakt und flattert wie ein Bug, dann ist es höchstwahrscheinlich auch ein Bug.

Anderer Gero

„data“ ist kein Ãœbertragungsprotokoll, sondern ein Pseudo-Protokoll wie etwa „mailto“ und tritt daher nicht in Konkurrenz zu HTTP oder HTTPS. Das verwendete Ãœbertragungsprotokoll ist, wie bereits ausgeführt, zweifelsfrei HTTPS.

Natürlich gibt es keine Norm, die regelt, wann ein Browser welche Warnmeldungen auszuspucken hat, aber die Aussage der Meldung, die Seite enthalte „unsichere“ Objekte, ist aufgrund der durchgängigen Verwendung von HTTPS objektiv falsch.

Die Frage, ob es sich nun um einen Bug handelt oder nicht, sollte damit eigentlich beantwortet sein.

Ingo Chao

Für

body{background: url(mama:); }

sagen IE6,7,8 und Google Chrome, dass hier unsicherer Inhalt sei.

Nicht Firefox und nicht IE9.

Ich gehe mal davon aus, dass es dem IE6 und IE7 egal ist, ob sie nun das unbekannte Protokoll mama: oder eben data: vor sich sehen.

florian

@Ingo Chao: Rilsch.
Um das (gefühlt) korrekte Verhalten zu bekommen, müsste der Browser für die Ressource »mama« die Sicherheitsstufe vom Stylesheet vererben.

Das machen nicht alle. Die alten IEs sowie Chrome pauschalieren hier auf ein »unsicher«.

Das ist natürlich schade. Aber auch ein spezieller Fall, der so noch nicht im Standard geregelt ist. (Wobei es auch nicht so aussieht, als wäre https gegenüber http sicherer und wird offenbar in den nächsten paar Jahren abgelöst bzw gestrichen.)

wa3awte

@florian:

Das sich der Internet Explorer nicht gegen einen Standard verstößt mag sein, aber falsch ist es dennoch. Wenn lediglich https-Ressourcen verwendet verstößt ist eine Meldung über unsichere Objekte schlichtweg gegen die Logik. Im übrigen verzichtest du darauf »im Standard« näher zu beschreiben.

Erstaunt hat mich dann noch deine Behauptung, dass HTTPS nicht sicherer ist als HTTP. Die Zertifizierungsstruktur mag vielleicht angreifbar sein, aber generell ist das Protokoll sicher. Zumal sich TLS (früher SSL oder im Fall von HTTP eben HTTPS) nicht auf bestimmte Verschlüsselungsalgorithmen festlegt, welche durchaus anfällig sein könnten. Auch hier gilt es, einfach mal die Logik zu rate zu ziehen. Ich rate dir dringen dich mal mit dem Thema zu beschäftigen. Zumal eine Ablösung weder benötigt wird noch in Aussicht steht oder innerhalb ein paar Jahren umsetzbar wäre. Von einer Streichung mal ganz zu schweigen. Momentan gibt es ja noch nicht mal eine praktikable Alternative zur hierarchischen Struktur der Zertifizierungsstellen und als normaler Computerbenutzer hat man immer irgendwo einen Punkt des Blinden Vertrauens.

Man kann also nur hoffen, dass du an diesen Themen nur hobbymäßig interessiert bist.

Kommentar verfassen

Mit dem Absenden dieses Formulars erklären Sie sich damit einverstanden, dass ich die von Ihnen eingegeben Daten auf meinem Webserver speichere. Ihr Name, der Kommentartext und die angegeben Website werden für die anderen Besucher von praegnanz.de angezeigt. Ich gebe jedoch insbesondere Ihre E-Mail-Adresse nicht an Dritte weiter und nutze diese auch nicht zu Marketing- oder Statistik-Zwecken. Sie können alle Daten zu einem späteren Zeitpunkt wieder entfernen lassen.