Was ist also das konkrete Problem? AVM hat früher DHE unterstützt und jetzt nicht mehr? Hast Du schon mal nachgefragt, warum das so ist?
Mehrfach ... seit November 2013 eigentlich regelmäßig bis zum Februar diesen Jahres.
Warum sie seit Herbst 2013 systematisch alle stärkeren Verfahren als RC4-SHA und RC4-MD5 aus allen neuen Versionen (zumindest für die Modelle, auf die ich Zugriff habe) ausgebaut haben, habe ich aber nie erfahren - offenbar genauso wenig wie Jürgen Schmidt von heise Security.
Also kann man nur spekulieren und testen, ob DHE gegen andere Implementierungen funktioniert (das sagt noch nichts über die Qualität der Verschlüsselung). Dazu muß es aber erst einmal laufen ...
Ich vermute mal, es geht um diesen String:
Im Prinzip ja, in den Laborversionen mit ECDHE-Unterstützung und OpenSSL 1.0.1g ist er etwas länger geworden.
sofern sich OpenSSL nicht daran stört, wenn man nicht existierende Kombinationen verbietet. Auch wenn das nicht geht, werden sich Strings finden lassen, die von der Länge her gleich bleiben.
OpenSSL stört sich an syntaktisch falschen Cipher-Selects.
Aber das ist auch nicht der Punkt, es gäbe da ja auch einen Binärmodus beim sed und dann kann man den String mit einem NUL-Byte per sed "abschneiden". Wenn der sed in der busybox das nicht kann, nimmt man eben ein anderes Tool.
Der Einsatz von "normalen" sed-Anweisungen für eine Binärdatei ist - nach meinen Erfahrungen - eher nicht zu empfehlen. Und ich will ja (Copyright) permanente Änderungen vermeiden ...
Die grundsätzliche Funktion der Idee habe ich selbstverständlich bei mir selbst schon vor längerer Zeit mit einem per Hexeditor geänderten ctlmgr getestet, vor kurzem auch für die neue Laborversion der 7490.
Das erfordert dann aber eben entweder eine Modifikation des ctlmgr schon im SquashFS oder einen zusätzlichen Neustart des ctlmgr nach remount mit bind-Option.
Da der ctlmgr gerade beim Booten der Box aber ordentlich zu tun hat, um die verschiedenen Aktivitäten unter einen Hut zu bringen, ist es keine sehr gute Idee, ihn zu früh abzuschießen und man muß die Box erst "settlen" lassen. Das ist in meinen Augen zwar für die private Bastelei gut genug, bringt aber über verschiedene Modelle mit ggf. verschiedenen vom ctlmgr abhängigen Diensten eher mehr Probleme, als durch die "Wiederauferstehung" von DHE gelöst werden.
Um den String im Speicher zu ändern ist vermutlich ein eigens dazu erstelltes Programm der einfachste Weg.
Die Frage zielte ja darauf ab, ob jemand so ein Tool kennt oder selbst eines geschrieben hat. Wenn die Antwort auch nach etwas Warten nur "nein" lautet, werfe ich meinen Editor an.
Die Frage ist aber, ob das etwas bringt. Vermutlich ist zu dem Zeitpunkt OpenSSL bereits initialisiert und der String wird danach gar nicht mehr verwendet. Ich gehe zumindest nicht davon aus, dass OpenSSL bei jeder neuen Verbindung neu den String untersucht.
Das weiß ich allerdings auch noch nicht so genau. Bei der "alten" Version verhielt sich der ctlmgr beim Aufbau einer HTTPS-Verbindung noch ähnlich wie z.B. der inetd. Er nahm die TCP-Verbindung an, initialisierte den Tunnel und reichte die Daten aus dem Tunnel quasi unverschlüsselt an sich selbst durch. Eine Änderung der Cipher-Suites mit gdb wurde berücksichtigt.
Ob das jetzt bei der neuen Möglichkeit mit dem ständig laufenden HTTPS-Listener (es geht ja jetzt auch HTTPS von innen, ohne daß man dafür externes HTTPS auch zulassen müßte) anders ist, teste ich einfach später. Ich glaube im Moment fest daran, daß - nach Patchen im Datensegment - der ctlmgr auch unterhalb der Reizschwelle eines Neustarts irgendwie über IPC-Mechanismen (vielleicht per "msgsend dsld reconnect_button" ?) zu einer Reinitialisierung des SSL-Stacks überredet werden kann, wenn das nötig sein sollte. Allerdings kann ich es für die neuen Laborversionen ja wirklich noch einmal testen ...
Zwar kann man beim Erzeugen eines neuen SSL_CTX (immer auf OpenSSL bezogen) generell die Protokollversion festlegen (SSLv2/v3/TLS), aber die zu verwendenden Cipher-Suites kommen eigentlich erst nach einem SSL_accept ins Spiel, wenn der Handshake ansteht. Solange AVM da jetzt nicht eine Kopie des Strings aus dem Datensegment irgendwo auf den Stack legt (wozu sollten sie das machen), dürfte die Änderung im Datensegment für künftige Verbindungen berücksichtigt werden.
AVM hat früher DHE unterstützt und jetzt nicht mehr? Hast Du schon mal nachgefragt, warum das so ist?
Wenn AVM das DHE wirklich wegen Implementierungsfehlern abgeschaltet haben sollte, dann sollten sie in meinen Augen auch ganz klar "die Hosen runterlassen". Schließlich wurden mit diesen Verfahren lange genug auch vertrauliche Daten übertragen und der Kunde sollte schon das Recht haben, wenigstens nachträglich über dabei (potentiell) entstandenen Schaden informiert zu werden.
Wenn ich mir aber dann wieder ansehe, daß für den Einsatz von ECDHE-Verfahren (in OpenSSL seit 1.x enthalten) die bisher genutzte OpenSSL-Version 0.9.8irgendwas_fürchterlich_altes gegen eine Version 1.0.1g ausgetauscht wurde, dann verleitet mich das irgendwie zu der Annahme, daß AVM auch vorher auf die Funktionen in der libssl.so gesetzt hat und nur eigene Wrapper dafür verwendete.
Definitiv OT: Wurde das Thema AVM und SSL-Stack jemals wirklich bis zum Ende aufgeklärt ? Es gab ja mal Bestrebungen, die AVM-eigene libssl durch eine "native" openssl-Lib zu ersetzen. War da nicht mal etwas mit einem "Freetz"-Wrapper dafür ? Ist das irgendwann einmal "stable" geworden ? Ich gebe zu, das habe ich nicht weiter verfolgt ...
Jedenfalls wäre dann (bei richtiger Initialisierung des PRNG, das muß bei Embedded Devices aber nicht immer der Fall sein) gegen die grundsätzliche Implementierung der DHE-Verfahren nicht einzuwenden gewesen bzw. jetzt bei der 1.0.1g nichts mehr einzuwenden. Eine mangelnde Entropie des PRNG würde ja genauso die ECDHE-Verfahren betreffen, wie die DHE-Verfahren ... und diese Blöße gibt sich AVM hoffentlich nicht.
Du siehst, einiges ist spekulativ, einiges getestet ... eine Antwort/Stellungnahme von AVM zu den Beweggründen für die - genau genommen - Abschaffung der HTTPS-Verschlüsselung seit Herbst 2013 und die jetzt in den Laborversionen stattfindende zaghafte Wiedereinführung sinnvoller Verfahren, würde da ungemein helfen. So werden Verschwörungstheorien jedenfalls nicht entkräftet ...
Und ECDHE ist eben - je nachdem, wen man fragt und wem man glaubt - nicht immer das Gelbe vom Ei, dafür aber schneller als DHE.
Die wenigsten werden "das Problem der Berechnung des diskreten Logarithmus in elliptischen Kurven" nachvollziehen können, ich definitiv auch nicht ... aber dafür gibt es international anerkannte - und unabhängige - Crypto-Experten. Und wenn diese zu dem Schluß kommen, bestimmte standardisierte Kurven (beschrieben durch ihre Parametersätze) könnten so augewählt worden sein, daß einigen Organisationen "kürzere" Wege zur Lösung des zugrunde liegenden mathematischen Problems bekannt sind, dann bin ich bereit, diesen Glauben zu schenken ... besonders dann, wenn sie nachweislich Einblick in eigentlich geheime Dokumente hatten.
Sorry, wird immer mehr OT, habe mich mal wieder hinreißen lassen ... ich habe fertig.
) oder muß ich selbst ran ?
