Ist ein Zugriff aufs Freetz-WebIf auch per HTTPS möglich?

jupp...ich habe das mal mit xrelay und matrixtunnel gemacht...aber dann aus "zu selten genutzt" wieder verworfen...
wenn ich home komme(bin@work) stell ich das gern hier mal rein...(war von mir als usb version erstellt...daher kein xrelay im mod nötig gewesen)

du kannst auch einfach stunnel verwenden

der eintrag bei den services sieht dann z.B. so aus:

du kannst mit stunnel so viele Server definieren, wie du Port oder Ram auf der Box hast, also auch mehr als die drei.

Du solltest aber. stunnel die ssl-libary von freetz nutzt, ssl von avm deaktivieren und auch tr069, damit es nciht zu problemen kommt. Dann kannst du ohne Porbleme für alle Seiten deinen Server konfigurieren

matrixtunnel war lediglich eine Modifikation von stunnel, die statt der OpenSSL libraries Matrixssl verwendet hat. Das hat einiges an Platz gespart, wenn man die OpenSSL libraries nicht eh schon auf dem System hat.

xrelayd verwendet als SSL lib xyssl. Von der Funktionalität her sind sich alle ähnlich. Ob xrelayd auch eine Modifikation von stunnel ist, weiss ich nicht genau.

Wenn du eh die OpenSSL libs auf deiner Box hast, empfehl ich dir eher zu stunnel als zu matrixtunnel zu greifen, weil letzteres eben nur eine Modifikation ist, die von einer einzigen Person geschrieben wurde, im Test-Stadium ist und kaum (lebt das Projekt überhaupt noch?) gepflegt wird.

xrelayd ist noch nicht ganz so weit entwickelt wie stunnel und auch in freetz nicht ganz so bequem verwendbar, da du für jeden Dienst einen eigenen Prozess starten musst und diesem die Parameter mitgeben musst. Aber ansonsten sicher eine gute und vor allem kleine Variante !

Meine Beschreibung zu stunnel ist übrigens hier zu finden.

wonderdoc schrieb:

Sind bei dem Freetz-Paket auch schon std-Zertifikate enthalten?

Zum Vergrößern anklicken....

Nein, Zertifikate musst du immer für dich persönlich generieren ! Mit einem "Standard-Zertifikat" könntest du dir nämlich sonst die Verschlüsselung der Verbindung gerade schenken ...

Ist aber nicht schwierig, sich die zu generieren.

Die Idee, die wonderdoc hier angesprochen hat, ist nicht so ganz rübergekommen:

Ideal wäre es, wenn ALLE WebServer (Ports 80,81,82) über nur EINEN externen Port 443 sich "tunneln" ließen.

Ich weiß, dass es technisch ohne Weiteres nicht geht mehrere Ports auf einen zu binden, aber vielleicht gibt es eine andere Möglichkeit, die "sekundären" WebIFs (z.B. 80,82) als Unterverzeichnis von dem primären (z.B. 81) einzubinden, dass man z.B. AVM WebIF unter

http://fritz.box:81/AVM/

erreichen könnte. Danach könnte man Port 81 über 443 routen.

Der Hintergrund ist, dass man in solchen Fällen sehr oft hinter einer Proxy sitzt und nur auf bestimmte Ports zugreifen kann...

MfG

Hallo,
so etwas habe ich schon vor langer Zeit gemacht, wo ich Webmin (webbasiertes Administrationstool für Linux, standardmäßig auf Port 10000 zu erreichen) über den SSL-Port 443 des Apache Webservers erreichen wollte. Da gab es in der Apache Konfigurationsdatei so einen ähnlichen Eintrag wie:
Damit war Webmin über "https://<webserver_ip>/webmin" zu erreichen.
Aber ob es eine Rewrite-Engine für unseren kleinen httpd gibt, wage ich zu bezweifeln, ich konnte bisher nichts finden.

Gruß

naja, das scheint aber apache-spezifisch sein...
ich meinte eher etwas mit

MfG

mod_rewrite gibts auch für den lighttpd, der mittlerweile ja als Freetz-Paket vorhanden ist.
Werde mich mal damit beschäftigen.....
Heißt das, dass man dann wirklich nur den Port 443 benutzt oder wird man einfach nur weitergeleitet?

Bezüglich https wird es schwierig wegen Zertifikate. Selbst Apache kann im https-Modus nicht vernünftig mit Multiple-Zertifikaten (für unterschiedliche Domains) umgehen. Da gibt es zwar irgendwo ein Hack dafür im Umlauf, aber es ist relativ schwierig.
Deswegen würde ich dir anraten erstmal https rauszulassen und mit dem einfachen http anzufangen. Wenn es dann funktioniert, dann kann man weiter schauen.
So wie ich diese Funktion von Apache kenne, funktioniert es dort alles auf Apache-Basis anhand Apache-interner Konfigurationdateien. Vorstellen sollte man sich das folgendermassen. Alle Anfragen (mit unterschiedlichen Namen) landen irgendwann mal beim Apache (durch Konfiguration IPs und Ports konfigurierbar). Dann schaut Apache zu wem die Anfrage gehört. Das wird -denke ich- anhand vom Header gemacht. Und abhängig von dieser Information zeigt dann Apache das entsprechende Verzeichnis (auch festgelegt durch Konfiguration). Wenn das ganze Verschlüsselt abläuft, hat Apache Probleme Header auszulesen und braucht zusätzliche Module dafür, die leider noch nicht richtig multidomainfähig sind.

MfG

Apache kann hervorragend mit verschiedenen virtuellen Hosts auf einem Prot umgehen, zumindest in den aktuellen Versionen. Apache hat auch kein Problem mit Zertifikaten für verschiedene Domains, weil es dem Apache ziemlich egal ist, wofür ein Zertifikat überhaupt gültig ist. Das Zertifikat zu prüfen ist Sache des Clients.

Das Problem ist eher, ein Zertifikat zu bekommen, das verschiedene Domains enthält, und auch dieses Problem ist eher ein preisliches, wenn man es von einer der bekannten Zertifizierungsstellen haben will.

Wenn man aber das Zertifikat selbst erstellt, ist das kein Problem, zumal sich noch die Frage stellt, ob man wirklich verschiedene Host-Namen für seine Box hat oder braucht.

Wenn Apache (oder ein anderer Server) als Reverse Proxy läuft, wird sowieso dort schon die verschlüsselte Verbindung terminiert. Und eine neue verschlüsselte Verbindung auf der Box lokal zu nutzen ist zwar möglich, aber etwas übertrieben.

Danke!
Ja, also mir geht es ersteinmal ums Prinzip, ob sich auch alles durch einen einzigen Port machen lässt (Zertifikate erstmal egal).
Macht dieses mod_rewrite das dann so, dass man je nach Anfrage eine andere Website mit eigenem Homeverzeichnis bekommt (also zum Beispiel wenn man eingibt "fritz.box/wol" dass dann "/usr/mww-wol/index.html" angezeigt wird mit "/usr/mww-wol/" als Home) ? und das Alles dann immer über den gleichen Port (also z.B. 80) ? Oder wird man nur auf einen anderen Port weitergeleitet?

@RalfFriedl: Meine Infos über Apache sind leider etwas anders. Es kann mit Virtualhosts umgehen, das ist richtig. Es kann aber (zumindest in den mir bis jetzt bekannten Versionen) nicht unterschiedliche ssl-Zertifikate verwalten. Und für die Überprüfung der Zertifikate am Client ist es enorm wichtig, dass der Name der Domain zum Namen im Zertifikat passt. Es gibt aber ein alternatives SSL-Modul für Apache, welches das angeblich machen sollte. hier steht was dazu. Mag sein, dass meine Infos etwas veraltet sind, ich konnte aber bei meiner Recherche vor etwa einem halben Jahr nichts neueres finden.

MfG

Apache kann ein Zertifikat verwenden, das für mehrere Namen gültig ist.

Ein Zertifikat, das für mehrere Namen gültig ist, ist etwas anders als verschiedene Zertifikate, die für die verschiedenen Namen gültig sind.

Bei mehreren Zertifikaten auf einem Port stellt sich das grundsätzliche Problem, daß der Server laut Spezifikation erst das Zertifikat senden muß, bevor er vom Client Informationen (verschlüsselt) erhält. Die Auswahl einen virtuellen Hosts erfolgt aber erst aufgrund des Host-Headers, den der Client sendet. Der Server müßte also das richtige Zertifikat wählen, bevor er weiß, welches das richtige Zertifikat ist.

Bei einem Zertifikat, das für mehrere Namen gültig ist, stellt sich das Problem nicht. Der Server sendet dieses Zertifikat, und der (halbwegs aktuelle) Client prüft, ob das Zertifikat auch den angeforderten Namen enthält.

Ein potentieller Nachteil dieser Lösung ist, daß das Zertifikat alle Namen enthält, und für diese Namen der gleiche Inhaber eingetragen ist. Aber für mehrere Domain-Namen, die zum gleichen Inhaber gehören, ist es eine Möglichkeit.

@linuxkasten
Mit Apache kann man virtuelle Hosts definieren, die in Abhängigkeit des vom Client gesendeten Host-Headers ausgewählt werden. Diese virtuellen Hosts sind in der Konfiguration voneinander unabhängig, und benötigen auch kein mod_rewrite.

Das Zertifikat sollte Dir nicht egal sein, da nur das Zertifikat vor aktiven Angriffen schützt. Ohne Zertifikat ist man nur vor passiven Angriffen geschützt.

Was aber nicht unbedingt notwendig ist, ist ein teures Zertifikat von einer ger gängigen Stellen. Ein selbst erstelltes funktioniert genauso gut, muß aber dem Browser erst als vertrauenswürdig bekannt gemacht werden.

Danke, also das Stichwort ist virtuelle Hosts....
Das mit den Zertifikaten war nur so gemeint, dass ich erstmal die virtuellen Hosts nur per HTTP, also ohne Zertifikate probier. Wenn das klappt und ich dann https verwende, sind mir natürlich die Zertifikate nicht mehr egal