Frage

Zitat

nutzt aber ssl um die quelle zu sichern

SSL sichert nicht die Endpunkte, SSL sichert die verschlüsselte Übertragung.

Zitat

wenn nun jemand eine möglichkeit diese seite aber mit dem gültigen zertifikat wieder zu geben

Du redest also davon den IFrame-Code via SSL auszuliefern und dabei ein valides Zertifikat zu verwenden?

Zitat

und die eingaben mitzuschneiden

Welche Eingaben? Die in Input-Feldern auf der attackierten Webseite? Dann würde er keinen IFrame verwenden, sondern den JS-Code direkt über einen script-Tag einschleusen.

Zitat

wäre die lücke dann browser basierend oder wäre sie einfach von der webseite ausgehend.

Wie du eingangs schreibst, hat die Webseite eine Schwachstelle. Noch sehe ich hier keinen Fehler des Browsers.

Zitat

das der browser auch die seite mit ssl überprüft und den externen content raushaut.

Mit Seite meinst du die externe Ressource? Natürlich prüft der Fx auch hier das SSL-Zertifikat. Aber wieso soll er den "externen Content" entfernen? Wie soll ein Programmcode entscheiden, ob die Einbindung einen potentieller Angriff oder gewolltes Verhalten des Webmasters darstellt?

Zitat

Der browser darf doch eigentlich nicht erlauben das jemand über eine auf der seite gelegene input validation den browser austrickst

Woher soll der Browser wissen, dass der Servercode, der die Webseite erzeugt fehlerhaft ist? In wiefern wird der Browser hier "ausgetrickst"?

Zitat

überprüft der browser den nicht das dort z.B. 2 urls drin sind und 1 zertifikat das dazwischen ist einfach ein anderes ist?

Für den Browser ist es unerheblich, von wo Ressourcen eingebunden werden, solange die Zertifikate gültig sind. Schau dir mal https://signin.ebay.de/ws/eBayISAPI.dll?SignIn an. Dort sind Inhalte von https://secureinclude.ebaystatic.com eingebunden. Woher soll der Browser wissen, dass diese Inhalte valide oder ein Angriff sind?

Zitat

wusste nicht wie ich es anders ausdrücken soll

Mit korrekter oder zumindest dem Anspruch nach richtiger Orthographie.

Zitat

weil der Browser 2 mal das gleiche zertifikat auf beiden seiten zr identifizierung hat ?

Auf welchen Seiten?

Zitat

wenn der Browser überrpüft ob das Zertifikat gültig ist und jemand hat eine externe (also komplett unzertifizierte url) eingebunden hat das zertifikat aber im FF als gültig angezeigt wird

Du beschreibst hier nun den Fall, dass eine mit SSL übertragene Seite Content von einer anderen Domain eingebunden hat, deren Inhalte nicht über SSL übertragen wurden. In dem Fall signalisiert das der Browser. Solltest du einen Test-Case haben, der dies widerlegt, dann her damit.

Zitat

aber die überprüfung im browser müsste doch zeigen das die seite mit dem gültigen zertifikat ein anderes ziel mit eingebaut hat oder?

Nochmals: SSL sichert nur die verschlüsselte Übertragung und sagt prinzipiell nichts über den Endpunkt aus. Solange der gesamte Content über SSL übertragen wurde, wird dies vom Fx auch so signalisiert. Dabei ist unerheblich von welchen Quellen die Inhalte stammen. Wie in dem eBay-Beispiel oben verdeutlicht, gibt es dafür legitime Anwendungsfälle. Diese von Angriffsszenarien zu unterscheiden ist einem Browser ad hoc nicht möglich und müsste über feste Regelsätze (bspw. in speziellen Erweiterung wie NoScript oder AdBlock Plus) im Fx implementiert werden.

*omfg* ist das grausam zu lesen. Das klingt wie durch einen automatischen Übersetzer gequält. Dadurch wird es zu einer Tortur dem Inhalt zu folgen.
So weit ich es verstanden habe, geht es im Kern um das von dir eingangs beschriebene Szenario.
Zur Wiederholung:
Eine HTTPS-Seite validiert die Eingaben nicht und hat dadurch eine XSS-Schwachstelle. Diese nutzt ein Angreifer vereinfacht zum Einschleusen von Skript-Code. Der Code liegt auf einer anderen Domain, bei der die Übertragung ebenfalls HTTPS nutzt (inkl. eines validen Zertifikats). Der Kritikpunkt sei, dass ein Browser dann trotzdem das Symbol für eine verschlüsselte Verbindung anzeigt.

Ich spare mir an der Stelle das bereits Vorgetragene zu wiederholen. Warum sich Browser an der Stelle normal und gemäß den Erwartungen verhalten wurde erklärt. Der Blog-Eintrag behandelt ein allgemein bekanntes Phänomen, das keinen überrascht. Wenn man das Update des Autors liest, wurde er scheinbar darauf hingewiesen, auch wenn er selbst seinen Irrtum nicht erkannt hat und sich weiterhin für den Hacker-Gott hält. Hat so ungefähr unteres Skript-Kiddie-Niveau, daher spare ich mir ebenso auf grausige Details aus dem Text einzugehen.

Da du selbst das Szenario aus dem Blog erkannt hast, bleibt für mich offen, was noch zu erklären wäre.

Zitat

Gleichzeitig zeigt er ja auch an alles wäre hoch verschlüsselt

Das ist es auch, die Übertragung von den in dem Fall mindestens zwei Servern über SSL ist verschlüsselt. Aber wie ich oben schon erwähnte, SSL sagt nichts über die Sicherheit an den Endpunkten aus.

Zitat

obwohl er einfach eine Eingabe abfängt

Das Abfangen von Eingabe hat mit SSL nichts zu tun. Wenn eine Seite derartig das beliebige Einschleusen von Code erlaubt, ist es eigentlich unerheblich, ob die Seite verschlüsselt übertragen wird. Handelt es sich bei der angegriffenen Seite um eine via HTTPS gelieferte, zwingt das lediglich den Angreifer dazu selbst ein Zertifikat für seinen Server zu verwenden, um im Browser nicht die Signalisierung für gemischten Content zu bedingen.

Zitat

Für mich ist das kein Kritikpunkt sondern eine Schwachstelle wenn der browser einfach den Button und das gültige Zertifikat anzeigt.

Wenn der Browser bei der Anzeige von verschlüsselten Verbindungen darauf bestehen würde alle Elemente aus der selben Domain zu beziehen, dann würde auch bspw. die eBay-Login-Seite nicht mehr als verschlüsselt übertragen signalisiert werden. Das wäre eine unsinnige Abkehr von seit Jahren geltenden Prinzipien.

Zitat

aber der Browser gibt es ja als vertrauenswürdig wieder

Ein letztes Mal: der Browser signalisiert lediglich die verschlüsselte Übertragung bei validen Zertifikaten. Dass die Webseite eine XSS-Schwachstelle enthält, kann der Browser nicht wissen und auch nicht von regulären Anwendungsfällen unterscheiden. Der Fehler liegt allein bei der Webseite, nicht beim Browser.

Zitat

weisst du eine quelle wo ich nachlesen kann über das problem oder wer es veröffentlicht hat?

Nirgends. Es ist kein Browser-Problem. So einfach ist das. Das Problem hier ist lediglich die XSS-Schwachstelle der Seite und diese ist unabhängig vom Browser.