Erstellt vor 9 Jahren

Zuletzt geändert vor 19 Monaten

#723 assigned addition

axTLS as SSL/TLS wrapper

Erstellt von: kriegaex Verantwortlicher: MaxMuster
Priorität: low Meilenstein: freetz-next
Komponente: packages Version: devel
Stichworte: SSL, TLS, axTLS, network, tunnel Beobachter:
Product Id: Firmware Version:

Beschreibung

Maybe there is an alternative to stunnel, matrixtunnel, xrelayd. I have not really looked into it, just read about it on the BusyBox mailing list. The memory footprint seems to be low (40K).

Maybe somebody wants to check it out: http://axtls.sourceforge.net/

Anhänge (1)

axtls.patch (5.5 KB) - hinzugefügt von MaxMuster vor 4 Jahren.
Key-, Zertifikat- und Passwort-Parameter für axtlswrap

Alle Anhänge herunterladen als: .zip

Änderungshistorie (24)

comment:1 Geändert vor 9 Jahren durch kriegaex

  • Stichworte network tunnel hinzugefügt

comment:2 Geändert vor 9 Jahren durch kriegaex

  • Zusammenfassung von axTLS als SSL-Wrapper nach axTLS as SSL/TLS wrapper geändert

comment:3 Geändert vor 8 Jahren durch cuma

  • Typ von enhancement nach addition geändert

comment:4 Geändert vor 6 Jahren durch cuma

  • Meilenstein von freetz-1.3 nach freetz-future geändert

comment:5 Geändert vor 4 Jahren durch MaxMuster

Ist ja seit r12449 im Trunk. Mein Problem: Damit kann ich keine Zertifikate nutzen.

Die "Triviallösung" wäre die Vorgabe von Pfaden, an die man dann Zertifikat und Schlüssel kopieren oder verlinken kann:

Index: make/axtlswrap/Config.axtls
===================================================================
--- make/axtlswrap/Config.axtls	(Revision 12461)
+++ make/axtlswrap/Config.axtls	(Arbeitskopie)
@@ -33,9 +33,9 @@
 # CONFIG_SSL_PROT_MEDIUM is not set
 CONFIG_SSL_PROT_HIGH=y
 # CONFIG_SSL_USE_DEFAULT_KEY is not set
-CONFIG_SSL_PRIVATE_KEY_LOCATION=""
+CONFIG_SSL_PRIVATE_KEY_LOCATION="/tmp/flash/axtls.key"
 CONFIG_SSL_PRIVATE_KEY_PASSWORD=""
-CONFIG_SSL_X509_CERT_LOCATION=""
+CONFIG_SSL_X509_CERT_LOCATION="/tmp/flash/axtls.cert"
 # CONFIG_SSL_GENERATE_X509_CERT is not set
 CONFIG_SSL_X509_COMMON_NAME=""
 CONFIG_SSL_X509_ORGANIZATION_NAME=""

Etwas "eleganter" wäre, wenn das Programm auch Parameter für diese Pfade hätte. Ich hab dafür mal was ganz einfaches vorbereitet, Anpassung nur für den Wrapper und nur "auf die Schnelle". Blöd ist, dass der C-Source für den Wrapper als DOS-Datei vorliegt, ein "normaler" Patch schlägt fehl, daher noch ein Workaround im Makefile. Vielleicht geht das ja auch noch einfacher …

Kurz getestet geht bei mir damit dieser "inetd.conf"-Eintrag:

443    stream    tcp    nowait    root    /usr/sbin/axtlswrap -v -c /tmp/my_cert -k /tmp/my_key /usr/bin/webcfg    webcfg -i

Geändert vor 4 Jahren durch MaxMuster

Key-, Zertifikat- und Passwort-Parameter für axtlswrap

comment:6 Antwort: Geändert vor 4 Jahren durch er13

Cool, habe an sowas ähnliches gedacht, habe aber noch nichts in die Richtung gemacht, sondern bisher mit CONFIG_SSL_GENERATE_X509_CERT=y gespielt/getestet.

Einige Anmerkungen zu Deinem Patch. Ich glaube nach Deiner Anpassung reicht es nicht mehr einfach nur

if (strlen(certpath))

zu testen, es müsste

if (certpath && strlen(certpath))

heißen. Das gleiche für keypath. In Bezug auf keypwd bin ich mir nicht sicher.

Es wäre besser, wenn man das dem -p-Parameter entsprechende argv kopiert und argv dann mit etwas überschreibt bzw. gänzlich entfernt. Tut man nicht, wird der Wert von -p in jeder Prozessübersicht angezeigt, was nicht so gut wäre.

Passwort wird im Englischen Password geschrieben ;-)

Ansosnten könnte man sich noch überlegen, wie man es etwas sauberer machen könnte, damit der Patch upstream akzeptiert werden könnte. Sprich es muss wirklich als Zusatzfeature umgesetzt werden ohne dabei die bestehende Funktionalität zu zerstören (egal wie sinnvoll oder nicht sinnvoll diese zur Compile-Zeit hartkodierten Pfade sind).

Ansonsten sehe folgende Probleme noch bei der ganzen Geschichte:

  • Ich habe es immer noch nicht verstanden, ob und wie man axtlswrap als daemon starten kann (i.e. nicht über inetd). Ich glaube der Modus ist gar nicht vorgesehen.
  • Was mir sonst nicht gefällt ist, dass axTLS den eigentlichen - den nicht secured - daemon (in dem Fall busybox httpd) selber starten möchte. Mir wäre es viel lieber, wenn man den httpd und den Wrapper getrennt voneinander starten könnte. Der Wrapper müsste aus meiner Sicht in etwa folgende Parameter zusätzlich erhalten: horche am Port X, leite an den Port Y weiter.

p.s. Du darfst Dich in Bezug auf axTLS austoben, wie Du möchtest ;-) Commit-Rechte hast Du ja…

comment:7 als Antwort auf: ↑ 6 ; Antwort: Geändert vor 4 Jahren durch MaxMuster

Replying to er13:

Einige Anmerkungen zu Deinem Patch.

Darauf hatte ich gehofft!

… es müsste

if (certpath && strlen(certpath))

heißen. Das gleiche für keypath. In Bezug auf keypwd bin ich mir nicht sicher.

Ich hatte gedacht, durch die vorherige Zuweisung

char *opt_keypath = CONFIG_SSL_PRIVATE_KEY_LOCATION;
char *opt_keypwd = CONFIG_SSL_PRIVATE_KEY_PASSWORD;
char *opt_certpath = CONFIG_SSL_X509_CERT_LOCATION;

wäre ich "auf der sicheren Seite", damit sind die immer mindestens leere Strings?!?

Es wäre besser, wenn man das dem -p-Parameter entsprechende argv kopiert und argv dann mit etwas überschreibt bzw. gänzlich entfernt. Tut man nicht, wird der Wert von -p in jeder Prozessübersicht angezeigt, was nicht so gut wäre.

Ja, oder ich nehme die Option ganz raus. Ich kenne es eigentlich immer so, dass nur Keys ohne PW auf dem Server sind…

ALternativ könnte man ja noch an eine Config-Datei denken, in der Pfade und ggf. PW stehen…

Passwort wird im Englischen Password geschrieben ;-)

Klar! War wohl etwas spät ;-)

Ansosnten könnte man sich noch überlegen, wie man es etwas sauberer machen könnte, damit der Patch upstream akzeptiert werden könnte. Sprich es muss wirklich als Zusatzfeature umgesetzt werden ohne dabei die bestehende Funktionalität zu zerstören (egal wie sinnvoll oder nicht sinnvoll diese zur Compile-Zeit hartkodierten Pfade sind).

s.o. (z.B. Config-Datei?), sonst muss man die anderen Binaries noch anpassen…

Ansonsten sehe folgende Probleme noch bei der ganzen Geschichte:

  • Ich habe es immer noch nicht verstanden, ob und wie man axtlswrap als daemon starten kann (i.e. nicht über inetd). Ich glaube der Modus ist gar nicht vorgesehen.

Ja, denke ich auch.

  • Was mir sonst nicht gefällt ist, dass axTLS den eigentlichen - den nicht secured - daemon (in dem Fall busybox httpd) selber starten möchte. Mir wäre es viel lieber, wenn man den httpd und den Wrapper getrennt voneinander starten könnte. Der Wrapper müsste aus meiner Sicht in etwa folgende Parameter zusätzlich erhalten: horche am Port X, leite an den Port Y weiter.

Ja und Nein, denke ich. Das wäre gut, weil er den httpd nicht starten muss (geht also auch ohne inetd). Das wäre aber auch schlecht, weil es damit nicht ohne den (unsicheren) HTTP-Dienst ginge, der müsste immer laufen (den könnte/müsste man dann auf 127.0.0.1:XY binden)

p.s. Du darfst Dich in Bezug auf axTLS austoben, wie Du möchtest ;-) Commit-Rechte hast Du ja…

Mal schauen, wie weit ich komme.
Momentan hab ich nochmal "matrixtunnel" angesehen, der "kann (auch) ohne inetd" kennt schon Pfade zu den Certs und macht das genau auf die von dir vorgeschlagene Weise (horche am Port X, leite an den Port Y weiter). Mit dem "semi-statischen" Binary wie axtlswrapper (ssl-lib mit drin) ist matrixtunnel 88k (axtlswrap ist 66k)..

comment:8 Geändert vor 4 Jahren durch MaxMuster

In 12473:

axtls:

  • refs #723
  • axtlswrap: introduce command line arguments for key path and cert path
  • still work in progress

comment:9 Geändert vor 4 Jahren durch er13

In 12449:

comment:10 als Antwort auf: ↑ 7 ; Antwort: Geändert vor 4 Jahren durch ralf

Replying to MaxMuster:

Das wäre aber auch schlecht, weil es damit nicht ohne den (unsicheren) HTTP-Dienst ginge, der müsste immer laufen

Was ist das Problem, wenn man den HTTP Dienst weiter laufen lässt? Auf den kleineren Boxen ist es vermutlich sowieso notwendig, und auch auf den größeren ist nicht sicher, dass man den Platz im Flash unbedingt mit einen HTTPS Server füllen möchte.

Im Moment haben wir einen HTTP Server und verschiedene SSL Wrapper zur Auswahl. Wer möchte, kann diese auch nutzen, aber ich sehe keinen Sinn darin, jemanden dazu zu zwingen. Ich persönlich würde für Fernwartung einen SSH Tunnel verwenden und keinen SSL Wrapper.

comment:11 Geändert vor 4 Jahren durch er13

  • Meilenstein von freetz-future nach freetz-next geändert
  • Status von new nach assigned geändert
  • Verantwortlicher auf MaxMuster gesetzt

comment:12 als Antwort auf: ↑ 10 ; Antwort: Geändert vor 4 Jahren durch MaxMuster

Replying to ralf:

Was ist das Problem, wenn man den HTTP Dienst weiter laufen lässt? …Platz im Flash …

Kein "Problem", deine Punkte sind richtig. Mein Ansatz/Ausgangspunkt war die "Security" Diskussion und eine Möglichkeit, die im Busybox-httpd nur mögliche "Basic Authentication" mit einem HTTPS-Ansatz zu umgehen. Alternativ wäre z.B. ein Hash-basiertes Login nicht schlecht und vermutlich Ressourcenschonender.

Ich persönlich würde für Fernwartung einen SSH Tunnel verwenden und keinen SSL Wrapper.

Ich auch ;-). Wie gesagt, ich meinte das oben gesagte fürs LAN.

Zuletzt geändert vor 4 Jahren von MaxMuster (vorher) (Diff)

comment:13 Antwort: Geändert vor 4 Jahren durch er13

Man sollte httpd definitiv laufen lassen. Um Zertifikat/Key abzulegen, muss der User sich einmal unverschlüsselt anmelden können.

@r12475: man könnte noch mit EXTRA_CFLAGS="-ffunction-sections -fdata-sections" / EXTRA_LDFLAGS="-Wl,--gc-sections" spielen, dann wäre das Binary noch kleiner.

comment:14 als Antwort auf: ↑ 13 Geändert vor 4 Jahren durch MaxMuster

Danke fürs "ordentlich machen" der ganzen Dinge ;-). Mehr als den Ansatz schaffe ich meist nicht …

Replying to er13:

@r12475: man könnte noch mit EXTRA_CFLAGS="-ffunction-sections -fdata-sections" / EXTRA_LDFLAGS="-Wl,--gc-sections" spielen, dann wäre das Binary noch kleiner.

Hatte ich schon versucht, hat aber bei mir schienbar nix gebracht (hab nur beim "semistatic" geschaut)?!?
Aber jetzt, nachdem du in r12480 auch libmatrixssl "verzaubert" hast, geht es.

comment:15 als Antwort auf: ↑ 12 ; Antworten: Geändert vor 4 Jahren durch ralf

Replying to MaxMuster:

Kein "Problem", deine Punkte sind richtig. Mein Ansatz/Ausgangspunkt war die "Security" Diskussion und eine Möglichkeit, die im Busybox-httpd nur mögliche "Basic Authentication" mit einem HTTPS-Ansatz zu umgehen. Alternativ wäre z.B. ein Hash-basiertes Login nicht schlecht und vermutlich Ressourcenschonender.

Das Problem bei "Basic Authentication" ist, dass man sich nicht abmelden kann, und das wird durch HTTPS nicht gelöst.

Wie gesagt, ich meinte das oben gesagte fürs LAN.

Wenn jemand im LAN mithört, hat man grundsätzlichere Probleme, wobei ich niemanden davon abhalten will, auch im LAN HTTPS zu nutzen. Ich wollte nur darauf hinweisen, dass wir bereits alles für HTTPS an Bord haben.

comment:16 als Antwort auf: ↑ 15 Geändert vor 4 Jahren durch MaxMuster

Replying to ralf:

Das Problem bei "Basic Authentication" ist, dass man sich nicht abmelden kann, und das wird durch HTTPS nicht gelöst.

Das sehe ich dann wirklich anders. Ob es "wahrscheinlicher ist", dass sich jemand Zugang zu meinem "offenen" (nicht gesperrten) PC verschafft, an dem ich so lange den Browser auf Freetz noch offen habe oder ein "Böser" im LAN was mitliest halte ich nicht für gesagt ;-).

Wenn jemand im LAN mithört, hat man grundsätzlichere Probleme,

Wenn jemand "zu bösen Zwecken" an meinen PC geht, dann auch ;-)

wobei ich niemanden davon abhalten will, auch im LAN HTTPS zu nutzen. Ich wollte nur darauf hinweisen, dass wir bereits alles für HTTPS an Bord haben.

Ja, danke dafür.

comment:17 als Antwort auf: ↑ 15 Geändert vor 4 Jahren durch er13

Replying to ralf:

Ich wollte nur darauf hinweisen, dass wir bereits alles für HTTPS an Bord haben.

Das stimmt einerseits, andererseits liegt für mich (und ich hoffe Jörg Du hast es genauso aufgefasst) der Schwerpunkt von "HTTPS für Freetz-Webif" nicht darin, ein Paket anzubieten, mit dem es theoretisch geht, wenn der User daran denkt, es im menuconfig auswählen und dann, wenn es auf der Box ist, auch konfiguriert, sondern wirklich darin, dass "HTTPS für Freetz-Webif" ein (fester) Bestandteil der Freetz-Default-Menuconfig-Konfiguration wird. Die Konfiguration zur Laufzeit sollte mit wenig Aufwand auch für nicht versierten User möglich sein oder anders ausgedrückt, der nicht so sehr sicherheitsbewusster bzw. sich nicht so auskennender User sollte es nicht als lästig empfinden, dass wir ihm da irgendein HTTPS aufzwingen.

Ideal wäre in dieser Hinsicht eine für alle Boxen einheitliche Lösung (und nicht wie Hippie auf der ML vorgeschlagen hat, für fette Boxen eine Lösung, für weniger fette dann irgendeine andere ⇒ Pflegeaufwand/unnötige Fall-Unterscheidung, usw.). Ich verstehe es so, dass wir gerade in der Phase sind, zu finden, welches Binary von der Größe her das kleinste ist und was alles mit diesem möglich ist (Stichwort axTLS und als Daemon starten). Und das muss man leider als erstes machen, denn die Pakete bieten zwar die Lösung fürs gleiche Problem, unterscheiden sich jedoch dahingehend, wie genau sie gestartet werden (der eine Wrapper möchte den Hauptprozess selbst starten, dem anderen reicht es, wenn ihm mitgeteilt wird, an welchem Port der "unverschlüsselte" Prozess horcht). Das Austauschen eines Wrappers durch den anderen besteht also nicht einfach darin, schreib einen anderen Namen/passe zwei/drei Parameter an.

Wenn die Entscheidung dann für eins der Pakete gefallen ist, hoffe ich, wird es dann auch zeitnah mit allen nötigen Konfigurationseinstellungen in Freetz-Webif eingebaut.

Zuletzt geändert vor 4 Jahren von er13 (vorher) (Diff)

comment:18 Antwort: Geändert vor 4 Jahren durch er13

Nebenbei gesagt, es wäre nicht schlecht, wenn wir als Key/Certificate dieselben verwenden würden, die AVM auch für die Fernwartung verwendet. Der Key von diesem ist mit einem Passwort geschützt. Kenn jemand dieses Passwort, ist dieses identisch auf allen Boxen oder wird dieses dynamisch generiert und irgendwo gespeichert? Das Passwort rauszufinden sollte nicht das Problem sein (Details bei Bedarf bitte per Mail oder auf der ML).

comment:19 als Antwort auf: ↑ 18 Geändert vor 4 Jahren durch ralf

Replying to er13 (and er13):

Nebenbei gesagt, es wäre nicht schlecht, wenn wir als Key/Certificate dieselben verwenden würden, die AVM auch für die Fernwartung verwendet. Der Key von diesem ist mit einem Passwort geschützt. Kenn jemand dieses Passwort, ist dieses identisch auf allen Boxen oder wird dieses dynamisch generiert und irgendwo gespeichert?

SSL ist immer mit einem Zertifikat verbunden, und die Frage ist, ob jeder Benutzer eines erstellen will. Die Idee, das Zertifikat zu verwenden, das AVM für die Box erstellt ist gut, es gibt nur einige praktische Probleme:

  • Wenn AVM auf allen Boxen das gleiche Passwort für das Zertifikat verwenden würde, könnten sie sich das Passwort auch gleich sparen. (Das heißt nicht, dass es nicht so ist.)
  • Wenn wir einen Weg finden, das Passwort zu entschlüsseln, kann das auch jeder andere, und die Verschlüsselung wäre wiederum sinnlos. AVM könnte dies entweder ignorieren oder die Verschlüsselung ändern.

Wenn AVM es also mit der Verschlüsselung ernst meint, oder auch nur so tun will, als ob, müssten sie dafür sorgen, dass unsere Methode, den Schlüssel auszulesen, in zukünftigen Versionen nicht mehr funktioniert.

Generell sehe ich keinen Sinn darin, einen Freetz User HTTPS aufzuzwingen.

Replying to MaxMuster

Ob es "wahrscheinlicher ist", dass sich jemand Zugang zu meinem "offenen" (nicht gesperrten) PC verschafft, an dem ich so lange den Browser auf Freetz noch offen habe.

Es muss sich niemand Zugang zum PC verschaffen, es reicht, wenn man Dich dazu bringt, eine Seite aufzurufen, die eine URL von Freetz aufruft, zum Beispiel dadurch, dass man ein entsprechendes Werbebanner im IPPF bringt.

Ich melde mich auch nicht so häufig an der Box an, und lasse auch nicht den Browser ewig offen, aber Hippie schreibt, dass er den Browser wochenlang offen lässt, und vielleicht machen das andere auch so.

comment:20 Geändert vor 3 Jahren durch PeterPawn

Da das ja hier schon ein paar Monate her ist und ich im Moment gerade an einer Lösung zur Nachnutzung des AVM-Zertifikats sitze, stelle ich hier auch noch einmal die Frage, ob nach wie vor Interesse an einer solchen Lösung besteht und wenn ja, welcher Wrapper es denn dann am Ende sein sollte.

Diesen würde ich dann ggf. so anpassen, daß er das Box-Zertifikat benutzen kann, auch ohne das Kennwort irgendwo permanent vorzuhalten (also wieder über eine passende Callback-Funktion, wenn man von OpenSSL als TLS-Stack ausgeht).

Das Henne-Ei-Problem (bei standardmäßig aktiviertem HTTPS für das Freetz-GUI, wenn man diese Entscheidung treffen sollte - comment:13) wäre ja insofern seit der 06.20 gelöst, als die Box selbst bereits ein Zertifikat generiert hat bzw. der Nutzer das vor der Verwendung von Freetz über das AVM-GUI konfigurieren kann.

Zur Frage, wie "stabil" die AVM-Verschlüsselung ist, kann man naturgemäß nur spekulieren. Aber die Möglichkeit, das Kennwort zu ermitteln und den Key zu entschlüsseln, macht die AVM-Vorkehrungen mit verschlüsselter Speicherung ja nicht automatisch sinnlos. Es sichert immer noch den privaten Schlüssel gegen simples Dumpen einer TFFS-Partition ab und auch die Verwendung des Kennworts nur für die Entschlüsselung beim Zugriff auf den PrivKey (im Gegensatz zur (semi-)permanenten Speicherung einer unverschlüsselten Key-Datei in den Freetz-Settings oder auch in /var zur Laufzeit) verhindert einige Angriffsvektoren. Daß das auf einer Box ohne funktionierendes Rechtekonzept nie ideal gelöst werden kann, ist auch klar … aber die vorhandenen Mechanismen sind ja ein Anfang. Besser als die erwähnte Speicherung "im Klartext" ist das allemal …

Und auch die Frage, ob man im LAN nun HTTPS benutzen sollte oder nicht, dürfte sich inzwischen im Lichte immer neuer Erkenntnisse/Meldungen zu Schwachstellen eher nicht mehr stellen … heute ist es eben nicht mehr die Frage, wie man sich gegen einen Lauscher im LAN verteidigt (wer das definitiv immer kann, erntet meinen Respekt - und meine Skepsis), sondern wie man den Schaden minimiert, den ein solcher Lauscher anrichten kann. Ich stimme zwar zu, daß man beim Vorhandensein eines solchen Lauschers ein grundsätzlicheres Problem hat, aber das spricht für mich nicht dagegen, entsprechende Vorsorgemaßnahmen zu ergreifen und es einem erfolgreichen Angreifer im LAN nicht ganz so leicht zu machen, dann auch noch in die Box einzudringen.

comment:21 Geändert vor 19 Monaten durch er13

axTLS gibt es inzwischen in Version 2.1.3. Könnte bitte jemand die Version in Freetz aktualisieren und außerdem schauen, was hier sonst noch alles gemacht werden muss, damit das Ticket als umgesetzt betrachtet (sprich geschlossen) werden kann.

Jörg?

Danke!

comment:22 Geändert vor 19 Monaten durch MaxMuster

In 14204:

axtls:

  • refs #723
  • axtls: Bump to 2.1.3
  • compile test only
  • still work in progress

comment:23 Geändert vor 19 Monaten durch er13

In 14217:

axtls:

Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.