[Frage] SSL-Key einer HTTPS-Session bei Server und Client vergleichen

RalfFriedl schrieb:

Der Proxy könnte dann den Session Schlüssel, den er vom Client bekommt, weiter an den Server senden statt einen eigenen zu generieren. Dann wären diese Schlüssel zwar gleich, aber trotzdem der Proxy dazwischen.

Zum Vergrößern anklicken....

Das verstehe ich jetzt nicht.

Bei Plain-RSA generiert der Client einen 48-Byte premaster key, den er mit dem public key des Servers verschlüsselt und an diesen sendet. Parallel dazu ermittelt er mit dem premaster key seinen master key und geht davon aus, daß der Server anschließend Daten schickt, die genau mit diesem master key symmetrisch verschlüsselt wurden.

Wenn also der public key des Servers beim Client stimmt und der Proxy selbst keine Kenntnis des privaten Schlüssels hat, kann der Proxy den vom Client gesendeten premaster key beim Durchleiten nicht entschlüsseln, in der Folge selbst keinen gültigen master key generieren und an den Client keine von ihm (dem Proxy) selbst verschlüsselten Pakete schicken, die sich mit dem vom Client (auch wieder unabhängig, s.o.) berechneten master key entschlüsseln ließen.

Wenn der Proxy den premaster key des Clients ungeändert an den Server durchreicht, kennt er den premaster key nicht, kann in der Folge den vom Server berechneten master key nicht kennen und damit auch keine Pakete ver-/entschlüsseln.

Da am Ende nur der Server und der Client jeweils über den gültigen master key verfügen, sind mit diesem verschlüsselte Pakete auch dem Transportweg abgesichert und müssen auch von der richtigen Gegenstelle stammen.

Oder wo habe ich Dich falsch verstanden ?

@JD:
RSA/1024-bit ? Schon daran kann man deutlich sehen - da braucht es den Inhalt des Schlüssels gar nicht -, daß das zwei unterschiedliche sind.

Du bist Dir sicher, daß da ein MITM dazwischen hängt ? Wie Ralf schon schrieb: Was sagt denn das zu diesem Schlüssel gehörende Zertifikat, wer das sein soll ? Wenn da der MyFRITZ!-/DynDNS-Name oder die IP-Adresse Deiner FRITZ!Box drin stehen, dann ist es event. wirklich ein Angriff. Kurz noch zur IP: Eine FRITZ!Box ohne MyFRITZ!- oder DynDNS-Account generiert i.d.R. sogar beim Wechsel der IP-Adresse ein neues Zertifikat, wenn der externe Zugriff aktiviert ist (der Key bleibt aber derselbe).

Vielleicht vergleichst Du ja auch Äpfel mit Birnen und sprichst einen Dienst auf der Box an, der nicht auf den ctlmgr-Key zugreift ? Wenn man z.B. irgendeinen Java-Server oder einen eigenen Apache startet, verwendet der nicht den Schlüssel der AVM-Firmware ... das ist Dir aber sicherlich auch klar, oder ?

Wenn ich jetzt die Details nicht durcheinander bringe, funktioniert es so, dass der Client den premaster key mit dem public key des Servers verschlüsselt und an diesen sendet. Der Server wiederum entschlüsselt diesen mit dem nur ihm bekannten private key. Aus diesem wiederum wird auf beiden Seiten durch die gleichen Operationen der Session Key erstellt.

Beim MITM Angriff präsentiert der Proxy seinen eigenen public key und kann folglich mit dem dazugehörenden private key den premaster key entschlüsseln. Wenn der Proxy jetzt zum Server eine Verbindung aufbaut, kann er entweder selbst einen zufälligen premaster key generieren, oder eben den des Clients verwenden. In dem Fall bekommt der Server den gleichen premaster key, den der Client gesendet hat, und beide sollten daraus den gleichen session key berechnen.

@JohnDoe42
Bekommst Du den abweichenden Host-Key schon dann angezeigt, wenn Du im LAN auf die Box zugreifst, oder nur bei Zugriffen von Außen aus einem bestimmten Netz?

Was den MITM betrifft, offensichtlich gab es ja Gründe, diesen zu vermuten, sonst hätte sich die Frage erst gar nicht gestellt.
Eine wahrscheinliche Erklärung ist, dass entweder die Organisation (Arbeitgeber?) einen derartigen Proxy im Netz hat, aus welchem Grund auch immer. In diesem Fall müsste das Zertifikat im Browser als Vertrauenswürdig markiert werden, was sich durch Group Policies auch auf vielen Rechnern ohne großen Aufwand erledigen lässt.
Eine andere Erklärung wäre, dass ein Provider dies tut. In diesem Fall wäre es unwahrscheinlich, dass es einen aus Sicht des Kunden guten Grund dafür gibt, und vermutlich würde nichts dagegen sprechen, diesen zu benennen. Da dieser nicht bei allen Browsern sein Zertifikat installieren könnte, bräuchte er ein Wildcard Zertifikat einer bekannten Stelle, und diese hätte damit jegliches Vertrauen verspielt.

Im einen wie im anderen Fall wird der MITM nicht nur Verbindungen zu Fritzboxen abgreifen, sondern auch zu Banken und Online-Shops, und sollte folglich nicht für irgendwelche wichtigen Informationen verwendet werden.
Für den Fall, dass es sich um einen Arbeitgeber handelt, sollte dieser vorab darauf hinweisen, dass auch alle SSL Verbindungen abgefangen werden.

Wenn Du keine Details zu Zertifikat nennen willst, kannst Du wenigstens sagen, von wem es ausgestellt ist?

Ich hoffe dann mal, dass der Betreiber dieses Netzes nicht ein öffentlicher Provider ist?

Wenn der Browser das Zertifikat akzeptiert, muss es sich entweder um ein Wildcard Zertifikat handeln, oder es wird dynamisch bei jedem Aufruf ein zum Ziel passendes Zertifikat generiert. Kannst Du das mal überprüfen?
Kannst Du außerdem sagen, ob das Zertifikat von einer öffentlichen Stelle signiert ist oder nicht? Also das oberste Zertifikat in der Kette, nicht das Zertifikat der konkreten Seite.

JohnDoe42 schrieb:

Der Betreiber des Netzes ist kein öffentlicher Provider.
Das Zertifikat ist, jedenfalls nach den Infos die ich (beim Aufruf irgendeiner anderen https-Seite) durch Firefox gezeigt bekomme, nicht von einer öffentlichen Stelle signiert.

Zum Vergrößern anklicken....

Ein Proxy in einer Firma kann u.U. auch als MITM tätig sein, wenn er auch externen SSL-Verkehr stellvertretend abfertigt und z.B. auf Viren o.ä. testet. Allerdings sollte dann - wie Ralf Dir wahrscheinlich auch sagen wollte - jeder Client, der über diesen Proxy auf einen öffentlichen Dienst zugreift, eine entsprechende Warnmeldung ausgeben. Das ließe sich nur verhindern, wenn der Proxy für jeden Zielservice seinerseits das Zertifikat "fälscht" und diese Fälschung mit einem CA-Key unterschreibt, dem der Client (unberechtigterweise ja dann) vertraut (meist dann von der Administration installiert/verteilt).

Allerdings sollte die Existenz eines solchen Proxy entweder klar kommuniziert sein oder generell die "private Nutzung" verboten sein.

Da ein argloser User damit auch seine Credentials bei der Anmeldung an der FRITZ!Box nutzt und die wenigsten sich "richtig abmelden", bleibt diesem Proxy-Server auch nach dem Ende der Client-Verbindung weiterhin die Möglichkeit, mit der abgefangenen SID auf die FRITZ!Box weiter zuzugreifen. Da er ohnehin schon der "Gesprächspartner" war, muß er nicht mal den ansonsten notwendigen Aufwand des Spoofings der IP-Adresse für die Sitzung auf der FRITZ!Box betreiben. Das ist letzten Endes genau das Szenario, daß ich ursprünglich an der MyFRITZ!App kritisiert hatte, daß sie ohne genaue Kenntnis der Identität der Gegenstelle eine SSL-Sitzung auf der FRITZ!Box begann und dann diese Sitzung, z.B. von einem solchen Proxy in einer Firma oder auch einem Internet-Cafe oder wo auch immer, weiter genutzt werden konnte, denn selbst wenn die App versucht hätte, sich ordentlich abzumelden, hätte der Proxy natürlich diesen Zugriff einfach abblocken können.

So ein SSL-Proxy macht dann natürlich nicht nur bei der FRITZ!Box Probleme, eigentlich für jede Seite, wo man eine Anmeldung über SSL für sicher hält, von PayPal bis zur Webmail, ist das Abfangen der Credentials oder zumindest die nachträgliche Weiternutzung einer nicht terminierten Sitzung dann möglich. Wenn da kein generelles Verbot der Benutzung solcher Dienste aus dem Firmennetz besteht (das wäre dann imho nicht nur das Recht, sondern die Pflicht des Arbeitgebers), würde ich mich aus dem Stand in Gernot Hassknecht verwandeln.

RalfFriedl schrieb:

Beim MITM Angriff präsentiert der Proxy seinen eigenen public key und kann folglich mit dem dazugehörenden private key den premaster key entschlüsseln.

Zum Vergrößern anklicken....

Wenn der Client sich von der Identität des Servers überzeugt (durch Kenntnis des richtigen public key bzw. durch Prüfung der Zertifizierung), sollte doch aber der public key des Proxy gar nicht akzeptiert werden.
Wenn ich jetzt nicht meinerseits etwas durcheinander bringe oder falsch verstehe ... oder ich habe zwischendrin etwas verpaßt, was als Kontext wichtig wäre. Die Eingangsannahme von JD, daß erst ein Session-Key (aka master key) ausgehandelt und dann heimlich ausgetauscht wird, funktioniert ja so nicht ... wenn ein MITM da drin hängt, muß er von Anfang an dabei sein und den Handshake manipulieren, eine nachträgliche Änderung ist ohne neuen Handshake imho nicht drin (bei HTTPS ja m.W. nicht mal rekeying).

PeterPawn schrieb:

Allerdings sollte dann jeder Client, der über diesen Proxy auf einen öffentlichen Dienst zugreift, eine entsprechende Warnmeldung ausgeben. Das ließe sich nur verhindern, wenn der Proxy für jeden Zielservice seinerseits das Zertifikat "fälscht" und diese Fälschung mit einem CA-Key unterschreibt, dem der Client (unberechtigterweise ja dann) vertraut (meist dann von der Administration installiert/verteilt).

Zum Vergrößern anklicken....

Wir können davon ausgehen, dass auf dem Client ein entsprechendes Zertifikat installiert ist, so dass keine Warnmeldung kommt. Ob berechtigt oder unberechtigt, die Administration vertraut vermutlich dem Proxy.

Da ein argloser User damit auch seine Credentials bei der Anmeldung an der FRITZ!Box nutzt und die wenigsten sich "richtig abmelden", bleibt diesem Proxy-Server auch nach dem Ende der Client-Verbindung weiterhin die Möglichkeit, mit der abgefangenen SID auf die FRITZ!Box weiter zuzugreifen.

Zum Vergrößern anklicken....

Der Proxy-Server hat nicht nur eine SID, er hat auch Benutzername und Passwort. Er kann sich also auch lange nach Ablauf der Session wieder anmelden.

Wenn der Client sich von der Identität des Servers überzeugt (durch Kenntnis des richtigen public key bzw. durch Prüfung der Zertifizierung), sollte doch aber der public key des Proxy gar nicht akzeptiert werden.
Die Eingangsannahme von JD, daß erst ein Session-Key (aka master key) ausgehandelt und dann heimlich ausgetauscht wird, funktioniert ja so nicht ... wenn ein MITM da drin hängt, muß er von Anfang an dabei sein und den Handshake manipulieren.

Zum Vergrößern anklicken....

Der Client kennt normalerweise nicht den richtigen public key, dieses Problem wird durch ein Zertifikat gelöst. In diesem Fall ist im Client ein Zertifikat vom Proxy installiert, der Client betrachtet es folglich als gültig und akzeptiert den Key des Proxy. Die Eingangsannahme war nicht, dass Session-Key nachträglich ausgetauscht wird, sondern dass es möglicherweise überhaupt einen Proxy gibt. Dies wollte er durch Vergleich der Session Keys nachweisen. Wie wir festgestellt haben, funktioniert dies wesentlich einfacher durch Vergleich der öffentlichen Server Schlüssel, da man hierfür nicht über einen möglicherweise unsicheren Kanal den Session-Key am Server herausfinden und übertragen muss.
Möglicherweise, ich bin da mit den Details nicht so vertraut, kann sogar der Proxy, dem der Client ja vertraut, sogar den gleichen Session Key in der Verbindung zum Server erreichen, indem er die Daten des Clients entschlüsselt und an den Server weiterleitet.

@JohnDoe42
Kannst Du trotzdem sagen, ob der Proxy jeweils ein individuelles Zertifikat präsentiert oder nicht? Wenn Du also auf https://google.de/ zugreifst, steht dann im Zertifikat auch ausgestellt für google.de, oder etwas allgemeines, wie '*'?
Wenn Firefox das Zertifikat nicht bestätigen kann, bringt er dann eine Warnung oder nicht? Ich vermute eher, dass nicht. Ist das Zertifikat dann bei den Ausnahmen abgelegt? Wenn ja, wäre das eine der ersten Stellen, wo man nachschauen kann, wenn man den Verdacht hat.

RalfFriedl schrieb:

Der Proxy-Server hat nicht nur eine SID, er hat auch Benutzername und Passwort. Er kann sich also auch lange nach Ablauf der Session wieder anmelden.

Zum Vergrößern anklicken....

Die Authentifizierung im FRITZ!Box-GUI gibt zwar den Benutzernamen preis, das Kennwort wird jedoch nur in Form eines MD5-Hashes über eine 'challenge' (vom Server gesendet) und das eigentliche Kennwort übermittelt ... das ist schon seit geraumer Zeit so, ich würde sagen, mindestens seit Lua, das muß aber nicht korrelieren.

Solange der Proxy also nicht zusätzliche Angriffshandlungen vornimmt, wie eine Modifikation der Challenge auf "leer" (selbst dann hat der Proxy aber nur den Hash über einen Bindestrich und das Kennwort) oder einen Austausch der Javascript-Datei mit der Hash-Berechnung (md5.js) oder auch eine Modifikation des Javascript-Files login.js, wo die Berechnung des Hashes erfolgt, solange kommt das Kennwort nicht im Klartext beim Proxy vorbei (einzige Ausnahme wäre das Setzen eines neuen Kennworts in der Benutzerverwaltung, da ist es logischerweise nicht hashed).

Eine Replay-Attacke funktioniert(e) auch nicht, die übermittelte Response enthält zwar die Challenge noch einmal im Klartext, aber auf einen Login-Request mit einem alten Challenge-Wert reagiert(e) der ctlmgr ganz ordentlich mit einer neuen (aktuellen) Challenge und der erneuten Aufforderung zur Anmeldung. Allerdings teste ich das nicht immer als erstes bei einer neuen Version, deshalb gilt das explizit nur als Erfahrung mit der 06.20 für 7490.

Angriffe mit einer Rainbow-Table auf den MD5-Hash lasse ich dabei bewußt außen vor, selbst wenn die Challenge manipuliert wird, gibt es mit der frei zugänglichen SID einfachere Wege.

Oder wir reden einfach schon wieder aneinander vorbei ... wir lesen ja auch den zweiten Satz in #1 - jeder für sich - anders.

Stimmt, an den MD5 Hash habe ich nicht gedacht. Ich vermute, dass in diesem Fall AVM eine Ausnahme ist, weil die Anmeldung sonst ohne https auch möglich ist. Die meisten anderen Server, die nur eine Anmeldung über https vorsehen, werden wohl nichts in der Art haben, weil sie von einer sicheren Verbindung ausgehen.

JohnDoe42 schrieb:

Bei Aufruf von https://google.de passiert Garnichts, d.h. FF gibt keine Warnung aus, allerdings taucht in der Zertifikatsliste auch kein Google-Zertifikat bei den Servern auf.

Zum Vergrößern anklicken....

Wenn Du Google aufrufst, erscheint dann auch das Zertifikat von Google? Der gleiche Schlüssel, wie wenn Du Google aus einem anderen Netzwerk ohne Proxy aufrufst?
Wenn ja, wie sieht es mit "ungewöhnlicheren" Seiten aus?

Wenn Du auf das Schloss Symbol links von der URL klickst, erscheint ein neues Fensterchen, dann mehr Informationen und Zertifikat anzeigen.
Bei mir kommt da eine Zertifikatskette von Equifax Secure CA über GeoTrust Global CA und Google Internet Authority G2 zu www.google.de, mit Public Key
Dass in beiden Bildern Google Inc erwähnt wird, könnte dafür sprechen, dass es das original Zertifikat von Google ist. Es könnte aber auch ein nachgemachtes Zertifikat sein, in dem nur dieser Text aus dem original Zertifikat übernommen wurde.

Wenn für Google das original Zertifikat mit dem original Schlüssel angezeigt wird, spricht dies dafür, dass es eine Liste gibt, welche Verbindungen direkt durchgelassen werden und welche nicht. Wenn es eine derartige Liste gibt, stehen wahrscheinlich auch die größeren Email-Provider und Banken drauf.
Mit "ungewöhnlicheren" Seiten meine ich Seiten, die SSL verwenden, aber nicht zu den gängigen Anbietern gehören. Also kleinere Shops oder andere Seiten, die SSL verwenden. Es wäre ja eher weniger wahrscheinlich, dass der ganze Aufwand nur betrieben wurde, um die Verbindung zu Deiner Box abzuhören.
Vielleicht betrifft es auch nur Verbindungen zu IP Adressen? Wenn ich es richtig verstanden habe, hast Du oben die Verbindung zu Deiner Box über die IP-Adresse und nicht über den Namen aufgebaut.
Eine Adresse von google.de ist 173.194.116.111. Kannst Du mal versuchen, eine Verbindung zu dieser Adresse aufzubauen? Der Browser wird sich beschweren, dass die Adresse nicht zum Zertifikat passt, aber unter technische Details kann man dann nachschauen, ob es tatsächlich das Google Zertifikat ist oder ein anderes. Das Google Zertifikat hat eine sehr lange Liste von allen möglichen Google Namen.

Ich bekomme bei https://173.194.116.111/ auch den gleichen Schlüssel wie Du, also 94 17 ...
Das Zertifikat stammt auch von Google, ist aber nur gültig für google.com, im Gegensatz u dem Zertifikat, das man bekommt, wenn man sich mit google.de verbindet.
Die Whitelist scheint dann eher nach Adressen als nach Namen zu sein, oder es sind Namen, die aber auf Adressen aufgelöst wurden.

Da Du einen anderen SSL Schlüssel präsentiert bekommst, der sogar eine andere Länge hat, ist es offensichtlich, dass die Verbindung nicht direkt zu Deiner Box aufgebaut wird, sondern zu einem SSL Proxy. Ebenso ist es sicher, dass die Verbindungen zu Google, ob über den Namen oder die IP-Adresse, direkt zu Google aufgebaut werden. Das spricht dafür, dass es eine Art White-List gibt. Außerdem hast Du geschrieben, dass als Aussteller des Zertifikats der Betreiber der Netzwerks angegeben ist.

Du kannst mal bei Google https eingeben und irgendeinen Begriff, der Dir interessant erscheint, und dort einige Seiten aufrufen, die https verwenden. Dabei solltest Du feststellen können, bei welchen Seiten deren eigenes Zertifikat angezeigt wird und bei welchen das vom Proxy.
Ich gehe nicht davon aus, dass der Proxy für verschiedene Seiten unterschiedliche Keys erzeugt, das ist relativ aufwändig und wenig nützlich. Ich könnte mir vorstellen, dass für jede Seite ein eigenes Zertifikat erstellt wird oder das ein Wildcard-Zertifikat erstellt wurde. Ist das Zertifikat, das für Deine Box angezeigt wird, auf die Adresse der Box ausgestellt, oder etwas allgemeines wie "*"?