EDOMI-Releases/Updates | Aktuell: Version 2.03

[gaert]

Clientseitig ist WSS kein Problem - aber Serverseitig Da EDOMI keine fertigen Libs nutzt, bedeutet das sehr viel Arbeit für mich... Und die setze ich lieber sinnvoll ein, statt Portforwarding etc. zu unterstützen

Die "Sicherheitsdebatte" hatten wir ja bereits in der Vergangenheit - daher hier nur kurz: EDOMI ist prinzipiell *unsicher* konfiguriert und das ist auch nicht's Schlimmes, da EDOMI typischer Weise im Heimnetz Verwendung findet (dort sind eher selten Hacker und Man-In-The-Middle zu erwarten). Ein Zugriff von extern ist m.E. nur über ein VPN sinnvoll und praktikabel - insb. Portforwarding/etc. sind Schwachsinn und MUSS vermieden werden. Natürlich kann man jetzt noch SSL/etc. druffpacken - und sich mit 1000 Details plagen (Kamera-Streams, Browser-Gedöhns, abgelaufene Zertifikate, Serverabsicherung, uvm.), aber warum sollte man sich das antun?!

@gulk2k
Im Grunde jederzeit möglich... Das nächste Update ist auch schon in Planung - ich wollte nur noch ein paar Dinge von der Liste reinnehmen, daher dauert's noch ein paar Tage.

[eriche]

geht ein VPN "on demand" auch unter Android?

[trollmar]

geht ein VPN "on demand" auch unter Android?

Ich würde vorschlagen zu diesem Thema.
VPN ios und Android einen eigenen thread zu öffnen.

Nur soviel. Ich mache das mit "Tasker"

[ThorstenGehrig]

Hi
@Gaert: es ist OK wenn EDOMI kein https/ssl unterstützt - und simples portforwarding sehe ich auch als unsicher.
Allerdings ist das ganze was einige (u.a. ich) hier machen nicht völlig unsicher und unsinn.
Anstatt einem simplen portforwarding setze ich hier einen Apache-Reverse proxy mit zertifikatsbasierender authentifizierung ein.
Apache prüft ob der client zugelassen ist - und setzt dann das HTTPS auf HTTP um.
So ist das ganze VIEL kompfortabler als ein VPN (es funktioniert "unsichtbar" auf authorisierten clients).
VPNs muss man ein/ausschalten - oder bei "vpn on demand" spezifisch auf die App einschränken oder einen Split-Tunnel machen (um nicht den ganzen regulären Internet-Traffic durch das VPN zu leiten).
So gesehen finde ich ein VPN eher antequiert B-)

Ich denke der richtige weg müsste - wie von Ratzi vorgeschalten - den reverse proxy auch für den websocket WS/WSS zu konfiguieren... jetzt hab ich nur relavtiv wenig ahnung von dem Websocket-Kram... aber irgendwie kriegen wir das hin.

Gruß Thorsten

[trollmar]

Hi
@Gaert: es ist OK wenn EDOMI kein https/ssl unterstützt - und simples portforwarding sehe ich auch als unsicher.
Allerdings ist das ganze was einige (u.a. ich) hier machen nicht völlig unsicher und unsinn.
Anstatt einem simplen portforwarding setze ich hier einen Apache-Reverse proxy mit zertifikatsbasierender authentifizierung ein.
Apache prüft ob der client zugelassen ist - und setzt dann das HTTPS auf HTTP um.
So ist das ganze VIEL kompfortabler als ein VPN (es funktioniert "unsichtbar" auf authorisierten clients).
VPNs muss man ein/ausschalten - oder bei "vpn on demand" spezifisch auf die App einschränken oder einen Split-Tunnel machen (um nicht den ganzen regulären Internet-Traffic durch das VPN zu leiten).
So gesehen finde ich ein VPN eher antequiert B-)

Ich denke der richtige weg müsste - wie von Ratzi vorgeschalten - den reverse proxy auch für den websocket WS/WSS zu konfiguieren... jetzt hab ich nur relavtiv wenig ahnung von dem Websocket-Kram... aber irgendwie kriegen wir das hin.

Gruß Thorsten

Schon interessant wie unterschiedlich doch wir alle an sowas gehen.
Interessant ist das alles.

Ich möchte z. B in fremden WLANs meinen gesamten traffic durch den vpn leiten.
Aber vielleicht bin ich auch nur paranoid

[Ing-Dom]

Clientseitig ist WSS kein Problem - aber Serverseitig Da EDOMI keine fertigen Libs nutzt, bedeutet das sehr viel Arbeit für mich... Und die setze ich lieber sinnvoll ein, statt Portforwarding etc. zu unterstützen

Hi
@Gaert: es ist OK wenn EDOMI kein https/ssl unterstützt - und simples portforwarding sehe ich auch als unsicher.
Allerdings ist das ganze was einige (u.a. ich) hier machen nicht völlig unsicher und unsinn.

Ich denke der richtige weg müsste - wie von Ratzi vorgeschalten - den reverse proxy auch für den websocket WS/WSS zu konfiguieren... jetzt hab ich nur relavtiv wenig ahnung von dem Websocket-Kram... aber irgendwie kriegen wir das hin.

Gruß Thorsten

Für eine Zugriffsmöglichkeit ohne VPN gibt es Use-Cases. z.B. hinter einem kastrierten Internetzugang (besser: Webzugang) mit HTTP-Proxy.

Serverseitig müsste edomi wohl kein SSL bei den WSS können, das könnte ja der proxy übernehmen.
Nur müsste der edomi-client dann wss:// aufrufen statt ws:// - es sei denn man kann das mit mod_rewrite genauso umbiegen wie bei http/https...

Vielleicht kommt ich am Sonntag dazu etwas rumzuprobieren. Wetter erlaubt eh keine Arbeiten im Garten.

[starwarsfan]

Hallo miteinander,

vermutlich lässt sich da was mit mod_proxy_wstunnel machen, oder?

[coliflower]

starwarsfan Hi Yves, das wurde schon hier vorgeschlagen ...

ThorstenGehrig

Ich nutze Edomi zwar selber nicht, aber evtl. könnte das hier https://httpd.apache.org/docs/2.4/mo..._wstunnel.html weiterhelfen.

Gruß

[ThorstenGehrig]

Hi
bin ein bisschen am recherchieren. Der proxy_wstunnel scheint nicht zu reichen... weil der client ja ws:// abfragt.
Aber hier bin ich fündig geworden:
https://stackoverflow.com/questions/...s-to-ws-apache

So ähnlich müsste es vermutlich in
/usr/local/edomi/www/visu/include/js/main.js rein um Zeile 634 rein, oder?

var protocol = 'ws://'; 
if (window.location.protocol === 'https:') {
            protocol = 'wss://';
   }socket=new WebSocket(protocol+serverIp+':'+serverPort);

Damit wird der websocket bei http-verbindung mit ws:// geöffnet und bei https:// mit wss://

Jetzt müsste man noch mit dem proxy_wstunnel das redirect auf den edomi machen bei gleichzeitiger umsetzung auf ws://

Gruß
Thorsten

[Ing-Dom]

So ähnlich müsste es vermutlich in
/usr/local/edomi/www/visu/include/js/main.js rein um Zeile 634 rein, oder?

var protocol = 'ws://';
if (window.location.protocol === 'https:') {
protocol = 'wss://';
}socket=new WebSocket(protocol+serverIp+':'+serverPort);

Damit wird der websocket bei http-verbindung mit ws:// geöffnet und bei https:// mit wss://

Ich denke, dass es reichen önnte, wenn man im proxy ein URL-Rewrite vornimmt - so wie man es bei einer Weiterleitung von https auf http macht.
Der client will ws://xxxxx
Server (proxy) antwortet mit 301 moved permanently => wss://xxxxx
client holt sich wss://xxxxxx

so zumindest bei "normalem" http. Ob das bei websocket so geht, kann ich nicht sicher sagen, glaube aber schon!

[gaert]

Bitte macht doch einen neuen Thread dafür auf... Wird ein bisschen OT hier

[gaert]

Da ist was im Busch... Noch nicht fertig, aber die Richtung stimmt:

Bildschirmfoto 2017-09-03 um 08.53.00.png

[Brick]

schick...

[panzaeron]

Top! Wird das "dynamisch" von der .ini generiert? Denn das wäre auch eine tolle Sache wenn man als LBS-Entwickler auf zugehörige LBSxxx.ini Dateien zurück greifen könnte. Denn das würde bei komplexen LBS vieles vereinfachen und teilweise eine Menge Eingänge sparen...

[gaert]

Die edomi.ini wird ausgelesen und daraus ein "Formular" erstellt. Es bleibt also alles beim Alten - die edomi.ini kann also wie gehabt auch per Texteditor modifiziert werden. Das ist auch gut so, denn ggf. ist nach einer Installation die Adminseite noch gar nicht erreichbar.

LBS-INI-Dateien sind m.E. überflüssig, denn ein Rechtsklick auf einen LBS (Konfiguration) öffnet den LBS-Editor - und dort könnte man ggf. doch diverse Parameter im Quelltext verfügbar machen...