Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable external freetz gui when external https access to avm gui is enabled #142

Open
WileC opened this issue Mar 29, 2019 · 5 comments
Open

Comments

@WileC
Copy link
Contributor

WileC commented Mar 29, 2019

No description provided.

@f-666
Copy link
Member

f-666 commented Apr 1, 2019

Ich verstehe aus dem Titel dieses Issues leider nicht, was gemeint ist.
Wenn man das Freetz Webinterface per https zugänglich machen will, kann man zum Beispiel stunnel verwenden.

@WileC
Copy link
Contributor Author

WileC commented Apr 1, 2019

Ich hatte die Idee, wenn ich im AVM-WebIf die FritzBox per MyFritz oder auf herkömmlichen Wege per https freigebe, dass dann auch automatisch das Freetz-WebIf mit freigegeben werden kann ...

Wenn man das Freetz Webinterface per https zugänglich machen will, kann man zum Beispiel stunnel verwenden.

Das kannte ich nicht und muss mir das mal näher ansehen.

@PeterPawn
Copy link
Contributor

Wie wäre es denn mit einem CGI-Wrapper, der unter einem anderen Pfad in der URL aufgerufen wird und damit das Freetz-GUI auch extern zur Verfügung stellen kann, ohne daß man dafür "stunnel" verwenden müßte und damit auch einen anderen Port?

Ich stelle mir da etwas in der Art vor, wie es AVM für TR-064 von der WAN-Seite verwendet - das hätte (richtig implementiert) dann auch noch den Vorteil, daß man die AAA-Mechanismen von AVM verwenden könnte und damit eine modernere und sicherere Authentifizierung, als Freetz sie derzeit bietet.

Das Freetz-GUI ist am Ende ohnehin immer CGI-basiert, oder? So ein Wrapper bräuchte also nach der Berechtigungsprüfung nur mit "execve()" (o.ä.) das passende Freetz-CGI aufrufen (wie das der "httpd" der BusyBox auch macht) - der Rest (Environment, STDIN) ist bereits vorbereitet. Wenn man aus STDIN liest, um die SID bei POST-Requests zu prüfen, muß man vielleicht zuvor noch den Pointer wieder auf Beginn setzen - aber ansonsten kriegt so ein eigenes CGI-Modul das alles schon auf dem Silbertablett. Da noch den passenden Header für die Authentifizierung hinzugefügt zum Environment und der Aufruf kann starten - praktisch ohne jede Änderung am Freetz-GUI, egal wie renovierungsbedürftig das ansonsten noch sein mag.

Das spart auch noch das Problem der zusätzlichen Portfreigabe auf die Box selbst, dem man sich ansonsten (bei der Benutzung von "stunnel") parallel widmen müßte - das ist bekanntlich auch nicht mehr so simpel, wie es vor PCP mal war.

Alternative wäre halt die VPN-Verbindung ... die setzt aber immer das passende Gerät voraus, auf dem dieser VPN-Zugang auch installiert ist oder zumindest (sicher) installiert werden kann. Das ist sicherlich auch nicht immer der Fall bzw. beschränkt den Zugang dann auf solche Geräte und man kann die Benutzung eines fremdem Computers (die ohnehin Risiken in sich birgt) per se schon vergessen.

@WileC
Copy link
Contributor Author

WileC commented Apr 1, 2019

Das klingt gut. Derzeit wird beim HTTPS-Zugriff auf das AVM-WebIf (von Außen) nach einem "klick" auf Freetz die Seite https://host.vpntome.de:450/cgi-bin/freetz_status aufgerufen und dann auf Port 81 weitergeleitet. Dieser ist ja natürlich nicht offen, bzw. kann nicht von außen auf die Box selber zeigen.

Daher finde ich den Ansatz von @PeterPawn gar nicht so schlecht, eine Lösung mittels CGI-Wrapper zu realisieren.

@PeterPawn
Copy link
Contributor

Das war aber nur die "Prinzipskizze" ... bitte nicht dahingehend falsch verstehen, daß ich das nun auch implementieren würde.

Erst mal sollte man klären, wie "dringend" so etwas tatsächlich gebraucht wird - wobei es eben nach meiner Ansicht (habe ich woanders bestimmt auch schon das eine oder andere Mal argumentiert) durchaus parallel auch notwendig wäre, das Interface "auf Aktualität zu prüfen" - zumindest in puncto Security, aber vielleicht ja auch mal im Hinblick auf Darstellungen, die kleiner als 600px in der Breite sind, was bei einen Smartphone (mit geringer Auflösung) im Hochkant-Format auch schon mal der Fall sein kann oder wo man dann (beim Zoomen, damit man den Inhalt in dem 600px-Fenster noch lesen kann) einen passenden Viewport als Lupe über die gesamte HTML-Seite schieben muß, wenn man von links bis rechts und von oben bis unten den Seiteninhalt lesen will.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants