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

[PeterPawn]

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.

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 ?

 

[RalfFriedl]

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?

 

[JohnDoe42]

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 ?

Ja, ich bin mir sicher. Der Aufruf der Seite lautet:

https://ip-adresse-der-fritzbox

In der Box habe ich genau zu diesem (Test-)Zweck kurzzeitig den https-Zugang geöffnet. Ich spreche also explizit den gesicherten Zugang zum AVM-WebIF an. Detaillierte Infos über das Zertifikat möchte ich hier immer noch nicht veröffentlichen. Und da ich (aus im I-Net frei zugänglichen Infos) einige Kenntnis über die Funktionsweise des Proxys, wie ich in #9 erwähnte, erhalten habe, bin ich mir sicher, daß es sich um eine MITM-Attacke handelt.

@ RalfFriedl:

Ich bekomme den abweichenden öffentlichen Schlüssel nur bei Zugriffen aus einem bestimmten Netz. Der Aussteller des Zertifikates ist der Betreiber dieses Netzes.

 

[RalfFriedl]

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]

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. Ich zitiere:

Das Zertifikat für * ist vom unbekannten Zertifikatsaussteller ** unterzeichnet. Es kann nicht festgestellt werden, ob dieses ein gültiges Zertifikat ist.

 

[PeterPawn]

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.

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.

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 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).

 

[JohnDoe42]

Allerdings sollte die Existenz eines solchen Proxy entweder klar kommuniziert sein oder generell die "private Nutzung" verboten sein.
...
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.

Ich möchte Nichts weiter zu dem konkreten Netz bzw. zum Proxy sagen, da, Dank Eurer Hilfe, sich mein Anfangsverdacht ja nun bestätigt hat. Selbtverständlich habe ich bereits einige Dokumentation des Sachverhaltes vorgenommen. Zwar erst mal nur für mich privat, aber man weiß ja nie ...

Allerdings möchte ich anmerken, daß es aus dem betreffenden Netz heraus täglich einige TLS-bzw. SSL-verschlüsselte Sitzungen ins I-Net gibt und sich dies im Sinne eines vertretbaren Aufwandes auch gar nicht anders realisieren läßt. Beispielsweise zahlreiche Aufrufe auf Online-Banking-Seiten und/oder https-Zugänge zu Mail-Frontends (Horde etc.) sind hierin ebenso unumgänglich wie Buchungen auf Reiseplattformen und Online-Shops.

Eine weitere Recherche hierzu scheint allerdings nach meinem Verständnis zu ergeben, daß es sich hier, sehr zurückhaltend formuliert, um eine juristische Grauzone handelt. Interessierte können nach § 202a,b, 303a,b Abs. 1 StGB googlen. Hier nur ein Beispiel.
Danke nochmal und Grüße,

JD.

 

[RalfFriedl]

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).

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.

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.

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.

 

[PeterPawn]

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.

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.

 

[JohnDoe42]

Wenn Du also auf https://google.de/ zugreifst, steht dann im Zertifikat auch ausgestellt für google.de, oder etwas allgemeines, wie '*'?

Bei Google speziell müßte ich morgen nachschauen, aber bei einigen Seiten Letzteres.

Wenn Firefox das Zertifikat nicht bestätigen kann, bringt er dann eine Warnung ...?

Ja.

Ist das Zertifikat dann bei den Ausnahmen abgelegt?

Wenn ich dies zulasse, schon. Wie z.B. auch im Fall meiner Fritzbox, wobei dies aufgrund des Selbtsignierens wohl eher ein schlechtes Beispiel ist.

Generell kam bei mir der Verdacht auf, als ich zunächst ein wenig in den abgelegten (Server-)Zertifikaten von Firefox aufgeräumt hatte, d.h. solche Zertifikate entfernt hatte, deren Ablaufdatum mehr oder weniger lange überschritten war und danach zwei Dinge nahezu zeitgleich passierten: Warnungen beim Aufruf von unverfänglichen Seiten wie Heise.de, Yahoo.de und/oder Spiegel.de, welche irgendwelche eingebetteten Objekte beherbergten, die dann augenscheinlich via https eine Verbindung herstellen wollten (z.B. farm4.static.*********** auf yahoo.de) und eben daraufhin eine weitergehende Recherche zu diesem speziellen Proxy(system).

 

[RalfFriedl]

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]

Hallo zusammen,

hier noch ein paar Details.
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. Dies könnte daran liegen, daß man im verwendeten Proxy für den Scan auf bestimmte https-Seiten auch Ausnahmen anlegen kann.
Beim Aufruf des https-Zugangs zu meiner Box passiert Folgendes:


Ich denke, daß die interessanten Zusammenhänge in Bild 3 und 4 zu sehen sind.
Es sei nochmal deutlich darauf hingewiesen, daß der öffentliche Schlüssel, welchen ich als Ausnahme dauerhaft speichern kann, nicht der meiner Box ist (vgl. #18)
Grüße,

JD.

 

[RalfFriedl]

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.

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?

 

[JohnDoe42]

Wenn Du Google aufrufst, erscheint dann auch das Zertifikat von Google?

Falls Du etwas in PopUp-Art meinst: Nein.
Wo genau könnte/sollte ich, alternativ zu Bild 4 in #32, noch suchen ?

Google mit Proxy:


Google ohne Proxy:


Welche "ungewöhnlicheren" Seiten z.B. ?

 

[RalfFriedl]

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

Modulus (2048 bits):
80 a0 65 83 18 72 b6 b3 9a fe 59 d7 8e 39 32 25 
...

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.

 

[JohnDoe42]

Google mit Proxy:

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.

Sehe ich ähnlich, also die Wahrschenilichkeit für eine "White List" und den Aspekt, daß man nicht konkret hinter meiner Box her ist .

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 Verdacht mit händisch eingetragenen IP-Adressen kam mir auch schon - deshalb hatte ich (für meine Box) beides versucht. Und in der Tat ist es so, daß eine Auflösung über einen DynDNS-Namen schon viel früher, also vor dem TLS-Handshake, mit einer Meldung vom Proxy beendet wird. Der Aufruf meiner Box via IP-Adresse zeigt die o.g. Symptomatik.

Google via der von Dir genannten IP:



Zumindest der öffentliche Schlüssel weicht von jenem des Aufrufs via https://google.de ab ...

 

[RalfFriedl]

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.

 

[JohnDoe42]

Okay, aber nun doch noch einmal rein für 's technische Protokoll:

Würdest Du mir zustimmen, das in meinem konkreten Fall laut den hier dokumentierten Infos sich ein Proxy mit SSL-Scan-Funktionalität "dazwischen" geschaltet hat ? Selbstverständlich wird diese meine Verbindung nicht das Ziel der Übung sein, aber eben auch eine, die nicht Teil dieser "Whitelist" ist ?

 

[RalfFriedl]

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 "*"?

 

[JohnDoe42]

Die Whitelist scheint dann eher nach Adressen als nach Namen zu sein, oder es sind Namen, die aber auf Adressen aufgelöst wurden.

Ich habe bei einigen SSL-Seiten im Netz noch einmal ein wenig recherchiert - bei den meisten scheint es so zu sein, daß, sofern die entsprechende händisch eingetragene (statische) IP-Adresse aufgerufen wird und hierzu auch ein "Name" gehört, das Zertifikat "durchgewunken" wird. Im umgekehrten Fall beendet der Proxy z.B. den Aufruf von typischen Dyn-DNS Namen schon vor dem eigentlichen TLS-Handshake. Ruft man dann die zugehörige IP-Adresse auf, ergibt sich das beschriebene Bild. So z.B. auch hier:



Kurioserweise öffnet sich obiges IE-Fenster, obwohl ich die Seite im FF öffne ... aber da scheint wohl nur mit der "Verdrahtung" im System etwas nicht zu stimmen ...