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

JohnDoe42 schrieb:

... den aktuell benutzten Schlüssel, ...

Zum Vergrößern anklicken....

Evtl. kannst Du den während der Verbindungsherstellung, auf deinem Client anzeigen lassen, mit z. B.:
(IP und Port der FB, evtl. anpassen).

JohnDoe42 schrieb:

Das würde ich gerne tun .... leider ist mein Client ein XP-PC ...

Zum Vergrößern anklicken....

In diesem Fall könntest Du ein Paket erstellen und ssldump mit Freetz, für deine FritzBox kompilieren. http://www.rtfm.com/ssldump/

Vermutlich reicht es, das Programm und alle evtl. benötigten Libraries auf die Box zu bringen.

Der normale Weg, um festzustellen, ob man mit dem richtigen Server verbunden ist, ist das Zertifikat zu prüfen.

PS:
Wenn ssldump aus den Paketen den Schlüssel extrahieren könnte, wäre das ein schwerwiegendes Problem mit dem SSL Protokoll. Dann bräuchte man sich keine Gedanken mehr darüber zu machen, ob Zertifikate oder Schlüssel übereinstimmen.

Ansonsten findest Du den von der Box benutzen Public-Key im Zertifikat der Box (bei neuer Firmware im GUI erreichbar) oder auch im Zertifikat im Dateisystem (/var/flash/websrv_ssl_cert.pem).

Wenn es Dir um die Sitzungsschlüssel geht, die bekommst Du meines Wissens nicht aus dem ctlmgr heraus (und das ist nun mal auch gut so, beim FF ist das ja auch nur für die Fehlersuche und ich hoffe mal, da stehen einige Warnungen neben der Information zu der Environment-Variablen).

Nur mit Kenntnis des privaten Schlüssels des Servers kannst Du den TLS-Handshake nachvollziehen, denn nur dann kannst Du die vom Client generierten Daten als Server entschlüsseln (RFC 5246, Punkt 7.4.7).

Je nach Verschlüsselung erfolgt dann eine abweichende Generierung des "master secrets", denn ansonsten würde ja immer die platte Kenntnis des privaten Serverschlüssels die nachträgliche Entschlüsselung des aufgezeichneten Verkehrs ermöglichen (wie es ohne PFS ja tatsächlich der Fall ist).

Bei PFS werden dann "flüchtige" (ephemeral) Komponenten in die Generierung eines gemeinsamen Schlüssels einbezogen, die ein Dritter nicht mehr aus dem aufgezeichneten Handshake ableiten kann ... anders als z.B. beim RSA-Handshake, wo einfach ein zufällig vom Client generierter Wert mit dem Public-Key des Servers verschlüsselt und an diesen gesendet wird -> kennt man den privaten Schlüssel, kann man diese Message 1:1 dekodieren und hat den genauen Weg zur Generierung des Session-Keys "frei Haus" (Punkt 8.1.1 im RFC) und damit "auf Ewigkeit" die Möglichkeit, den Verkehr zu entschlüsseln (auch dann, wenn man den privaten Schlüssel erst nachträglich "erbeutet"). Bei PFS nutzt die nachträgliche Kenntnis des privaten Schlüssels nichts ...

Der langen Ausführung kurzer Sinn:
Der "master key" ist wirklich symmetrisch, mit der Speicherung auf FF-Seite kann man dann mit Tools wie Wireshark oder ssldump den TLS-verschlüsselten Verkehr analysieren. Auf der FRITZ!Box-Seite gibt es (hoffentlich wirklich) keine Möglichkeit, an den Session-Key zu gelangen.

Ein kompletter Speicherdump bei aktiver Verbindung und das Wissen, wo man darin dann suchen muß, ist da ausdrücklich nicht eingeschlossen. Ein Angreifer, der eine gezielte Speicherung oder einen Dump auf irgendeinem Weg auslösen und die gespeicherten Daten dann auslesen kann, hat wieder beliebig lange die Möglichkeit, aufgezeichneten Verkehr im Nachhinein zu entschlüsseln (egal, ob da PFS zum Einsatz kommt oder nicht).
Ich glaube aber nicht an eine einfache Environment-Variable auf der FRITZ!Box, zumindest nicht mit einem "verdächtigen Namen". Da stehen genug "Schweinereien" im ctlmgr (z.B. ein Weg, die Unterscheidung zwischen internem und externem Zugriff zu umgehen), aber etwas in der von Dir gesuchten Richtung ist mir da noch nicht aufgefallen ... das heißt allerdings nicht automatisch, das es das wirklich nicht gibt.
Aber als Backdoor oder "bug door" ist das imho auch eher unpraktikabel ... da wäre nach erfolgreichem Key-Exchange (oder nach "Sammlung" einiger solcher Keys) irgendeine exotische DNS-Abfrage, die mangels Caching direkt bis zu einem "eigenen DNS-Server" durchschlägt und neben einem Hash über die beteiligten Adressen auch gleich noch den Session-Key "huckepack" abliefert (natürlich ebenfalls verschlüsselt, damit da nicht jeder DNS-Server unterwegs mitlesen kann), imho viel einfacher und unverfänglicher.
Das heißt selbstverständlich nicht, daß AVM da bei der verschlüsselten Kommunikation mit dem MyFRITZ!-Dienst irgendetwas ähnliches macht ... jedenfalls ist bei dem, was ich dort mit mitmproxy bisher mitgeschnitten habe, nie etwas in der Richtung dabei gewesen.

OT, aber eben mein "Lieblingsthema":
Das mit PFS ist auch der Pferdefuß an sich bei der TLS-Verschlüsselung für die gesamte Firmware zwischen September 2013 und 06.20 ... dort werden nur zwei Verfahren unterstützt (RC4-SHA und RC4-MD5). Bei RC4 besteht (spätestens seit Snowden bzw. seit den Äußerungen von Crypto-Experten zu einigen Papieren, die sie von ihm erhalten haben) der Verdacht, daß zumindest die NSA das "live" knackt, MD5 wird als Hash-Algorithmus auch nicht mehr als sicher angesehen.
Kommt jetzt jemand - meinetwegen der StA mit einem Durchsuchungs-/Beschlagnahmebeschluß - in den Besitz des privaten Schlüssels der FRITZ!Box (der steht in /var/flash/websrv_ssl_key.pem, ist aber noch einmal mit einem achtstelligen (internen) Kennwort geschützt vor dem direkten Auslesen), kann aufgezeichneter TLS-Verkehr von dieser Box (lawful interception, in D z.B. Artikel-10-Gesetz oder auch STPO §100a) problemlos auch im Nachhinein entschlüsselt werden.
Die einzig sicheren Möglichkeiten mit "DHE" wurden explizit aus der Firmware entfernt, eine sinnvolle Begründung dafür hat AVM meines Wissens nie abgeliefert. Vor der 06.xx gab es (SSLv3/TLS1/TLS1.1) unter anderem folgende (benutzbare) Algorithmen:
- ab 06.xx nur noch das schon erwähnte RC4.

Die ab der 06.20 mögliche ECDHE-Verschlüsselung ist - je nachdem, wen man fragt - auch mit Vorsicht zu genießen ... wer sich dafür interessiert, kann ja mal nach "BADA55 and EC" suchen oder gleich hier lesen.

Das Performance-Argument ist auch albern, denn erstens haben die Boxen mal mehr, mal weniger potente Prozessoren und zweitens ist eine sichere Session vollkommen ausreichend (zum Unterschied Session vs. Connection siehe RFC), meine FRITZ!Box soll jedenfalls kein "high performer" bei externen (oder internen) HTTPS-Zugriffen sein und schließlich drittens ... es geht beim VPN und dem FTP-Server ja offensichtlich auch anders, denn da gilt auch bei der 06.0x die Beschränkung auf RC4 nicht.

JohnDoe42 schrieb:

Angenommen, meine https-Verbindung muß über einen Proxy laufen, welcher im Verdacht steht, MITM-Attacken dergestalt durchzuführen, daß er sich meinem Client gegenüber als Partner für den initialen TLS-Handshake präsentiert (anstatt des eigentlich angezielten Servers, bspw. der FritzBox), den Traffic entschlüsselt, nach Gusto analysiert und im Anschluß wieder (im Zuge eines zweiten) Handshakes mit meiner Box) verschlüsselt ? Welche Möglichkeit hätte ich denn, ein solches Verhalten nachzuweisen, außer, daß ich die jeweils verwendeten Session-Keys vergleiche und feststelle, ob sie identisch sind oder nicht ?

Zum Vergrößern anklicken....

Wie schon geschrieben, allein dafür gibt es die Zertifikate. Der Proxy sollte kein Zertifikat haben, das zum privaten Schlüssel des SSL Servers passt, und ein anderes Zertifikat sollte nicht für die Adresse existieren, unter der man auf die Box zugreift. Speziell letzterer Punkt ist nicht so ganz sicher, da es etliche Zertifizierungsstellen gibt. Die Frage ist also, welche Möglichkeiten ein potentieller Angreifer hätte, an Zertifikate einer Zertifizierungsstelle zu kommen.
Sofern Du davon ausgehst, dass niemand an den privaten Schlüssel der Box kommt, kannst Du das Zertifikat bzw. den Hash-Wert (Fingerprint) des Zertifikats im Client untersuchen. Dieser sollte sich nicht ändern. Den Session-Key zu vergleichen ist sowieso nicht realistisch, die einzige Möglichkeit, an diesen heranzukommen wäre über die SSL Verbindung, und genau von dieser willst Du prüfen, ob sie wirklich sicher ist.

Ich traue es mich fast nicht, aber ich muß Ralf in einem entscheidenden Punkt widersprechen.

Für Deine Prüfung, ob die Gegenstelle die ist, die sie sein sollte/will, reicht es aus, den definitiv richtigen Public-Key der Gegenstelle (oder meinetwegen auch einen kryptographisch sicheren Hash des Schlüssels) zu kennen.

Ein Zertifikat für einen solchen Schlüssel kann jeder ausstellen, das ist ja gerade das, was da zertifiziert wird: "Der im Zertifikat enthaltene öffentliche Schlüssel gehört zu dieser Adresse/Institution (was auch immer da im "subject" steht)."

Allerdings nutzt (darauf beruht ja die asymmetrische Verschlüsselung mit privaten und öffentlichen Schlüsseln) der öffentliche Schlüssel einem Angreifer ja nur dann etwas (den kann schließlich jeder aus dem Zertifikat lesen), wenn er auch den zugehörigen privaten Schlüssel hat.

Die ganze Zertifizierung löst ja eigentlich nur das Problem, den öffentlichen Schlüssel auf einem sicheren Weg zum Client zu bringen und weil das eben nicht für jeden beliebigen öffentlichen Schlüssel möglich ist, gibt es die CAs, die attestieren, daß der öffentliche Schlüssel zusammen mit einem Identitätsnachweis des Inhabers bei ihnen vorgelegen hat ... das unterschreiben sie mit ihrem eigenen privaten Schlüssel. (Die zusätzliche oder alternative Aufnahme in irgendwelche Schlüsselverzeichnisse macht in einem begrenzten Szenario wie einer Firma noch Sinn (z.B. im AD oder einem anderen LDAP-Server), im globalen Web ist das Utopie.)

Wenn man den öffentlichen Schlüssel also - wie in Deinem Falle - auf einem gesonderten sicheren Kanal übertragen kann (indem man ihn einfach vor Ort aus der FRITZ!Box ausliest - per Dateisystem oder - mit gewissen Einschränkungen, der Browser darf eben keinesfalls schon manipuliert sein - per GUI/Browser (Schloß in der Adressleiste)) und den vom Server im Zertifikat angebotenen öffentlichen Schlüssel direkt (oder über einen sicheren Hash) mit diesem vergleichen kann, kann man sogar wesentlich sicherer sein als bei der Auswertung des restlichen Zertifikatinhalts ... der könnte durchaus von einer - eben nicht so vertrauenswürdigen - CA fälschlicherweise als "getestet und für richtig befunden" ausgewiesen werden. Im Firefox sähe der Public-Key dann so aus:
Anhang anzeigen 78802
Das ist zwar (bei meinem 4096-Bit-Schlüssel) ein Monster (512 Byte), aber wenn man das direkt in eine Software integriert, geht das i.d.R. auch ... man muß halt nur beachten, daß dann beim Schlüsselwechsel auch die Software geändert werden muß (diese Erpressungtrojaner arbeiten ja genauso, sie verschlüsseln den HDD-Inhalt mit einem fest einprogrammierten Public-Key und den zugehörigen Private-Key hat dann der Erpresser). Die Alternative, den Public-Key (ohne weitere Sicherungsmaßnahmen, wie eine eigene symmetrische Verschlüsselung) einfach in einer Datei abzulegen, ist dann wieder keine gute Idee ... man muß ja irgendwie die Manipulation des zum Vergleich dienenden Schlüssels verhindern (das gilt allerdings auch für einen "einkompilierten" Schlüssel, wenn man das Programm in fremde Hände geben will). Wenn ich AVM in einem Telefonat richtig verstanden habe (es ging um die MyFRITZ!App), wird auch das Schlüsselpaar von der Box nicht neu generiert, wenn das (selbst generierte) Zertifikat wegen der Änderung von (Dyn-)DNS-Einstellungen neu erstellt wird ... der Public-Key der Box wäre also "fest".

Wenn der öffentliche Schlüssel hingegen einen direkten Rückschluß auf den verwendeten privaten Schlüssel zuläßt - das hatten wir früher mal bei einem Fehler in Debian zwischen 2006 und 2008 -, dann krankt das nicht am Prinzip der asymmetrischen Verschlüsselung, sondern an der richtigen Umsetzung. Insofern muß man also darauf vertrauen (können), daß ein mit einem öffentlichen Schlüssel verschlüsselter Klartext nur mit dem richtigen privaten Schlüssel wieder in den Klartext übersetzt werden kann ... deshalb ist die Geheimhaltung des privaten Schlüssels auch so essentiell.

Wie sicher die von der FRITZ!Box automatisch generierten Schlüssel sind, ist dann noch ein weiteres Thema ... wenn Du wirklich sicher gehen willst, generierst Du für die FRITZ!Box einen eigenen Schlüssel und lädst ihn in die Box.

Angesichts fehlender Entropie beim Start einer "unkonfigurierten" Box, da die FB ja keine Echtzeituhr und auch weder Keyboard noch Maus hat, ist es wahrscheinlich mehr als fraglich, ob die von der Box selbst generierten Schlüssel die notwendige Vielfalt aufweisen. Das kann man allerdings nur mit einer großen Anzahl von FRITZ!Boxen (oder als Hersteller beim MyFRITZ!-Dienst) feststellen ... wenn es bei den von der Box selbst generierten Schlüsselpaaren nur wenige (sagen wir mal < 1024) gibt, ist das Anlegen einer entsprechenden Datenbank nur eine Frage der Zeit bzw. der Zugriffsmöglichkeiten auf verschiedene Boxen.
Da der öffentliche Schlüssel ja bekannt ist und zu diesem öffentlichen Schlüssel zwingend der entsprechende private gehören muß, ist das Belauschen von Verbindungen ohne PFS dann wieder kein Kunststück.
Die Problematik der fehlenden Entropie der PRNGs bei Embedded Devices wurde auch schon vor geraumer Zeit thematisiert, wie das bei AVM-Boxen im Kernel (also für /dev/random und /dev/urandom) ist, sollte eigentlich nicht unklar sein, da die betreffenden Kernel-Quellen ja offenliegen. Eine mögliche weitere Entropie-Quelle (das berühmte .rnd-File) ist bei einer FRITZ!Box auch nicht vorhanden, da sie dort schlicht nicht gespeichert wird.

Wenn also AVM da nicht im Closed-Source-Code eigene Vorkehrungen bei der Initialisierung des PRNG getroffen hat, dann reduzieren sich die zufälligen Einflüsse auf das generierte Schlüsselpaar soweit, daß man von einer entsprechend kleinen Zahl an Schlüsseln ausgehen kann, die nur deshalb noch nicht aufgefallen sind, weil sie niemand aktiv vergleicht.
Angesichts der Zeichenkette "string to make the random number generator think it has entropy", die 1:1 aus den OpenSSL-Testprogrammen stammt und sich z.B. bei AVM in der libikeossl.so genauso wiederfindet, bin ich da ehrlich gesagt etwas skeptisch und würde sogar von der überwiegenden Benutzung von /dev/urandom ausgehen, wenn ich nur mal die Suche in der Firmware als Anhaltspunkt nehme:
urandom hat aber nun mal den Nachteil, daß es bei "mangelndem Zufall" nicht blockiert und ein identisch geseedeter PRNG liefert eben deterministische Ergebnisse. Das ist also alles noch kein Beinbruch, wenn der Seed (bei anderen Prozessen) irgendwann mal paßt ... basiert der dann aber in erster Linie auf der seit dem Start vergangenen Zeit, weil das Gerät keine Echtzeituhr hat und immer am 01.01.1970 startet, dann wird es eben doch schnell wieder finster mit der Vielfalt. So groß ist die Streuung der Hardware dann auch wieder nicht, daß da nicht bei verschiedenen Boxen in hohem Maße identische "Zufallszahlen" aus dem Generator kommen und das ergibt am Ende dann eben identische Schlüsselpaare. So groß ist die Varianz beim Start einer FRITZ!Box nun mal nicht und die bis zum Start des ctlmgr (und damit zur Generierung des Schlüsselpaars, wenn dieses nicht vorhanden ist) vergehende Zeit dürfte (da dabei solche Sachen wie USB-Peripherie noch außen vor sind) weitgehend identisch sein. Man braucht nur mal die PIDs von laufenden ctlmgr-Instanzen vergleichen, auch daran kann man einen weitgehend immer gleichen Ablauf des Starts der Box ja festmachen.

Die vom BSI in Auftrag gegebene Untersuchung des Linux-PRNG aus 2013 beschäftigt sich erst mit dem Kernel 3.8, aber auch da wurden eben für das Prädikat "sicher" einige Randbedingungen definiert.

Ich würde am liebsten selbst mal eine Datenbank aufsetzen, wo FRITZ!Box-Besitzer in einer Webseite per Button eine Überprüfung ihres FRITZ!Box-Schlüsselpaars auf Dubletten durchführen können. Aber die damit verbundene Arbeit hält mich davon ab ... außerdem interessiert sich nach meiner Erfahrung am Ende kein Schw*in dafür, ob die FRITZ!Boxen nun sicher sind oder nicht, am wenigsten AVM selbst. :-(

Ich denke, wir sind im wesentlichen der gleichen Meinung, dass es auf den Schlüssel des Servers ankommt. Wenn man den ganzen Schlüssel vergleicht, ist man auf der sichern Seite, aber auch ein Hash über den Schlüssel, oder über ein Zertifikat, von den der öffentliche Schlüssel ein Bestandteil ist, sollte ausreichend sicher sein. Die Sicherheit von Zertifizierungsstellen ist da eher fraglich, wobei es darauf ankommt, gegen was man sich damit schützen möchte.
Die angesprochene fehlende Entropie beim Erstellen des Schlüssels auf der Box ist sicher ein Problem. Die Boxen haben kaum etwas, woraus sie diese herstellen können, bzw. AVM benutzt wohl nichts in der Art. Der String "string to make the random number generator think it has entropy" gibt da schon zu denken.

In Verbindung mit den schwachen Verschlüsselungsverfahren kommt es aber sowieso kaum darauf an, denn warum sollte jemand aktiv in die Verbindung eingreifen und riskieren, entdeckt zu werden, wenn man die Verbindung aus passiv entschlüsseln kann?

RalfFriedl schrieb:

In Verbindung mit den schwachen Verschlüsselungsverfahren kommt es aber sowieso kaum darauf an, denn warum sollte jemand aktiv in die Verbindung eingreifen und riskieren, entdeckt zu werden, wenn man die Verbindung aus passiv entschlüsseln kann?

Zum Vergrößern anklicken....

Das "Mistige" an der Entropie ist imho ja, daß auch bessere Verschlüsselung nicht hilft, wenn die Menge der Schlüsselpaare überschaubar (und handhabbar) ist und z.B. eine staatliche Institution die möglichen Paare komplett in der Sammlung hat. Dann hilft auch PFS nur noch gegen nachträgliche Entschlüsselung und einem MITM steht man ziemlich wehrlos gegenüber.

Aber Du hast natürlich recht ... wenn die FRITZ!Box ein self-signed-Zertifikat verwendet und dieses Zertifikat auch noch selbst neu erstellt, wenn man an den DNS-Einstellungen etwas ändert, dann ist es ohnehin Luxus, über die Identität der FRITZ!Box und sichere Verbindungen zu philosophieren.

Das Spannende ist für mich bei dieser Fragestellung, daß auch AVM bei der neuen Version der MyFRITZ!App selbst auf die Konstanz des Schlüsselpaars abstellt, da ansonsten das Generieren eines neuen Zertifikats auch in der App immer eine entsprechende Warnung auslösen würde. Das löst natürlich das "Browser-Problem" noch nicht ... mal sehen, ob und wann AVM die Idee mit der Intermediate CA (oder auch Root CA) in der Box umsetzt, so daß auch die Browser dann dieses Zertifikat einmalig importieren können und nicht jedesmal neu generierte Box-Zertifikate wieder mit einem Fehler zu Buche schlagen. Der Gewöhnungseffekt ist ja heute schon alles andere als ideal ... ich kenne (fast) keinen FRITZ!Box-Besitzer, der wenigstens ein bis zwei mal stutzt, wenn da eine "unbekanntes Zertifikat"-Meldung beim Zugriff auf die FRITZ!Box auftaucht.

JohnDoe42 schrieb:

Das hatte ich im Zuge des Betriebes von OpenVPN mit Zertifikaten schon erledigt ...

Zum Vergrößern anklicken....

Ja ... was soll man dazu nun sagen ? Auf der einen Seite ist die - aber immerhin vorhandene - Verschlüsselung des "private key" durch AVM nun wirklich nicht allzu schwer zu überlisten ... aber aus Deiner Bemerkung schließe ich jetzt mal ganz kühn, daß da der private Schlüssel für die Verwendung durch OpenVPN gleich noch einmal ohne Verschlüsselung auf der FRITZ!Box liegt (oder unterstützt Freetz jetzt ein Interface zum "Freischalten" von PrivKeys beim Start der Box ?) und das kann eigentlich auch keine wirklich gute Idee sein. Aber alles Gute ist eben nie beisammen ...

Jedenfalls hat sich AVM bei der Sicherung des privaten Schlüssels wirklich bemüht. Das verwendete Kennwort wird zwar auch aus boxspezifischen Daten berechnet, aber beim ftpd, der auch einen Zugriff auf den privaten Schlüssel braucht, um beim FTP "AUTH TLS" zu unterstützen, hat man extra ein neues Binary (getprivkeypass) erfunden, das mit einiger Raffinesse versucht, das Kennwort für die Datei mit dem privaten Schlüssel wirklich nur an den Aufrufer weiterzugeben, wenn es der ftpd ist.
Das ist natürlich nur ein relativ simpler und leicht zu knackender Schutz, aber es zeigt auch, daß AVM sich da wenigstens Gedanken gemacht hat. Früher wurde beim Start des ftpd einfach ein weiteres Schlüsselpaar generiert und das dann für FTP verwendet, damit war die Identität einer FRITZ!Box beim FTP-Zugriff über einen Neustart hinaus überhaupt nicht mehr sicherzustellen.

Trotzdem ist natürlich ein unverschlüsselter privater Schlüssel auf der Box ein Risiko für diese Datei ... hat ein Angreifer irgendwie (frag mich nicht wie, es ist leider nicht alles so sicher, wie es sein sollte) Zugriff auf diese unverschlüsselte Datei, kannst Du Dir die Antwort auf Deine Frage auch genüßlich "in die Haare schmieren".

Wäre das ein sicherer Beleg dafür, das die TLS-Verbindung auf dem Weg zwischem meinem Client und der Box nicht "umverschlüsselt" wurde ?

Zum Vergrößern anklicken....

Im Osten gab es eine Kategorie von Witzen, die dem "Radio Jerewan" zugeschrieben wurden. Auch hier würde ich jetzt antworten: "Im Prinzip ja, aber ...".

Der Theorie nach "ja" unter der Bedingung, daß der Angreifer nicht gleichzeitig den dazu passenden privaten Schlüssel hat ... dann ist dieses Schlüsselpaar "verbrannt". Aber wo sollte er den so einfach herbekommen, der liegt ja nicht einfach so irgendwo rum ...

Und der Vergleich des Public-Key als Identifikation setzt natürlich auch voraus, daß man nicht dabei schon "über's Ohr gehauen" wird und den Public-Key des Angreifers serviert bekommt, weil der schon in der Box oder im Browser sitzt, mit dem man den öffentlichen Schlüssel ausliest. Deshalb ja auch "sicherer Kanal", das schließt einen Angreifer per Definition aus ... ist er da schon drin, ist der Kanal eben nicht mehr sicher.

JohnDoe42 schrieb:

Wäre das ein sicherer Beleg dafür, das die TLS-Verbindung auf dem Weg zwischem meinem Client und der Box nicht "umverschlüsselt" wurde ?

Zum Vergrößern anklicken....

Ja, sofern der private Schlüssel tatsächlich noch privat ist.
Jeder kann den öffentlichen Teil des Schlüssels präsentieren, schließlich sendet der Server den öffentlichen Teil bei jedem Verbindungsaufbau freiwillig heraus. Es hat aber keiner etwas davon, der nicht auch den privaten Teil des Schlüssels kennt. Es hängt also alles davon ab, dass der private Teil auch wirklich geheim bleibt.

PeterPawn schrieb:

Auf der einen Seite ist die - aber immerhin vorhandene - Verschlüsselung des "private key" durch AVM nun wirklich nicht allzu schwer zu überlisten ... aber aus Deiner Bemerkung schließe ich jetzt mal ganz kühn, daß da der private Schlüssel für die Verwendung durch OpenVPN gleich noch einmal ohne Verschlüsselung auf der FRITZ!Box liegt (oder unterstützt Freetz jetzt ein Interface zum "Freischalten" von PrivKeys beim Start der Box ?) und das kann eigentlich auch keine wirklich gute Idee sein.

Zum Vergrößern anklicken....

Es ist wirklich seltsam, dass AVM an einigen Stellen so tut, als wäre es ihnen ernst mit der Sicherheit. Diese Verschlüsselung des Keys auf der Box bringt keinen prinzipiellen Gewinn an Sicherheit, ebenso wie die Entfernung von der Option zur Dekodierung von Passwörtern etwas bringt. Sie Software auf der Box muss prinzipiell in der Lage sein, den Schlüssel zu dekodieren, und daher müssen alle Informationen zur Entschlüsselung auf der Box vorhanden sein. Man kann sie mehr oder weniger verstecken, aber es ändert nichts daran, dass sie vorhanden sein müssen und gefunden werden können.

Selbst wenn man den Key von OpenVPN mit einem extern abgefragten Passwort entschlüsseln würde, was bei einem Neustart der Box sehr unbequem wäre, wäre der Schlüssel nachher doch im Speicher und könnte von einem Benutzer mit entsprechenden Rechten ausgelesen werden.

Und der Vergleich des Public-Key als Identifikation setzt natürlich auch voraus, daß man nicht dabei schon "über's Ohr gehauen" wird und den Public-Key des Angreifers serviert bekommt, weil der schon in der Box oder im Browser sitzt

Zum Vergrößern anklicken....

Wenn der Angreifer schon in der Box (oder im Browser) sitzt, was man nicht ausschließen kann, dann braucht man sich über die Sicherheit der Verschlüsselung keine Gedanken mehr zu machen. Und wie man weiß, sind alle Geheimdienste, auch die Deutschen, darauf aus, es den Kriminellen leichter zu machen, Verbindungen abzuhören.

RalfFriedl schrieb:

Selbst wenn man den Key von OpenVPN mit einem extern abgefragten Passwort entschlüsseln würde, was bei einem Neustart der Box sehr unbequem wäre, wäre der Schlüssel nachher doch im Speicher und könnte von einem Benutzer mit entsprechenden Rechten ausgelesen werden.

Zum Vergrößern anklicken....

Ganz klar ... die einzige wirklich sichere Lösung wäre eine Art TPM in der Box (das kann auch gerne gleich noch ein Crypto-Prozessor sein, der AES128 in Hardware macht), wo kein Schlüssel den Chip verläßt. Nicht ganz umsonst haben "nicht-Consumer"-Geräte mit VPN-Funktionen ihren Preis ...

Aber selbst der kleinste Schutz (auch wenn er leicht zu brechen ist) ist imho immer noch besser als keiner, wo dann ein einfaches "nc target port<xyz" schon für die Übertragung der Daten "im Klartext" ausreicht. Spätestens wenn dann irgendwelche Decisions getroffen werden müssen, verhindert das allzu simple Angriffe ... aber echte Sicherheit bringt es natürlich trotzdem nicht. Obwohl eben nicht jedes injizierte Kommando auch gleich ein kompletter Shell-Zugriff ist ...

Die SetLanguage-Lücke hat wahrscheinlich auch nur so gut funktioniert, weil es so simpel war, mit einem externen Kommando die komplette Einstellungsdatei auf einmal zu übertragen.

Je länger die notwendige Kommandofolge wird, um so geringer die Chance einer Injektion mal so eben nebenbei ... entsprechend steigt dann auch der Aufwand für das Ausnutzen von Lücken.

Ich habe mal in einem anderen Kontext versucht zu ermitteln, wieviele Zeichen ein Angreifer minimal irgendwo unterbringen muß, um eigene Kommandos auszuführen und bin - bei der 7490 - auf eine theoretische Untergrenze von 8 Zeichen + einen Domain-Namen (5 Zeichen bei .de minimal) oder eine IP-Adresse (7 minimal) gekommen - eine kürzere Variante habe ich (ooB) nicht gefunden.
Das ist natürlich schnell mal irgendwo eingebaut ... aber das erfordert dann - zumindest in Grenzen - schon einen "tailored access" und ist nicht mehr absolut generisch.

PeterPawn schrieb:

Die SetLanguage-Lücke hat wahrscheinlich auch nur so gut funktioniert, weil es so simpel war, mit einem externen Kommando die komplette Einstellungsdatei auf einmal zu übertragen.

Zum Vergrößern anklicken....

Wenn man erst einmal eine Shell hat, kann man alles benötigte nachladen, oder alle benötigten Informationen versenden, um sie anderswo zu verarbeiten.

JohnDoe42 schrieb:

Mein Verdacht hat sich inzwischen bestätigt

Zum Vergrößern anklicken....

Wie sieht denn das dazu gehörende Zertifikat aus? Du brauchst übrigens keine Sterne in den öffentlichen Schlüssel einzubauen, dieser Teil darf öffentlich sein und wird von Server sowieso an jeden gesendet.

Was mir noch zur ursprünglichen Frage eingefallen ist, wenn normales SSL ohne forward security verwendet wird, wählt der Client den Session Schlüssel aus und sendet ihn verschlüsselt an den Server. 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.