Ankündigung

**yachti** · 14.10.2017, 21:17

sslab_a.PNG

so fertig der DH 4096 key ist generiert und eingebunden.
Nachfolgend meine SSL Konfiguration.
Wer sie benutzt sollte wissen was er tut. Die Konfiguration ist für nginx Reverse Proxy und auf meine Clients abgestimmt und nicht für öffentliche Webserver geeignet.

nginx.config

Code:

user www-data;
worker_processes 2;
pid /run/nginx.pid;

events {
    worker_connections 768;
    # multi_accept on;
}
http {
    ##
    #Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    server_tokens off;
    client_max_body_size 2000M;    
    server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    #SSL Settings
    ##
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_protocols TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers AES256+EECDH:AES256+EDH:!aNULL;
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_dhparam /etc/ssl/private/dhparam.pem;
    ssl_ecdh_curve secp384r1;
    add_header Strict-Transport-Security "max-age=31536000; includeSubdomains" always;
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;    

    ##
    #Logging Settings
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    #Gzip Settings
    ##
    gzip on;
    gzip_disable "msie6";

    gzip_min_length 1100;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_buffers 16 8k;
    gzip_http_version 1.1;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    ##
    #Virtual Host Configs
    ##
    include /etc/nginx/sites-enabled/*;

    ##
    #DDOS
    ##

    client_header_timeout 10;
    client_body_timeout   10;


}

Konfiguration für Smartvisu und Alexa
Smartvisu getestet mit Windows 10, Chrome, Firefox, Edge, IE in den aktuellen Versionen.
Die SmartVISU für den Reverse Proxy funktioniert nicht mit IOS was aber nichts mit der nginx Konfiguration zu tun hat.

vhost für visu und alexa

Code:

# SSL-Redirect & LetsEncrypt Endpoint
server {
    listen 80 default_server;
    root /var/www/html;
    index index.html;
#    location / {
#        return 301 https://$host$request_uri;
#    }

    # LetsEncrypt Endpoint
    location /.well-known {
      alias /var/www/html/.well-known;
      allow all;
    }
}

server {
    server_tokens off;
    listen 443 ssl ;
    server_name visu.domainA.de;

    # gzip should not be used with ssl
    gzip off;

    ##
    # SSL
    # Global SSL in nginx.conf
    ##
    ssl on;
    ssl_certificate /etc/letsencrypt/live/visu.domainA.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/visu.domainA.de/privkey.pem;

    ##
    # global
    ##
    root /var/www/html;
    index index.php index.htm index.html;
    access_log /var/log/nginx/visu.log combined;

    # Weiterleitung zu SmartHomeNG (Websocket Schnittstelle) mit Basic Auth
    location / {
    auth_basic "Restricted Area: smartVISU";
        auth_basic_user_file /etc/nginx/.smartvisu;


        # Nur Websocket Verbindungen gegen "/" durchlassen!
        if ($http_upgrade = websocket) {
                proxy_pass http://10.x.x.20:2424;
        }
        if ($http_upgrade != websocket) {
                return 403;
        }
    }
    # Zugriff auf die SmartVISU mit Basic Auth
    location /smartVISU {      
    auth_basic "Restricted Area: smartVISU";
        auth_basic_user_file /etc/nginx/.smartvisu;


        proxy_pass http://10.x.x.20/smartVISU;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
    # Network Plugin Weiterleitung
    location /shng {
        auth_basic "Restricted Area: SmartHomeNG";
        auth_basic_user_file /etc/nginx/.shng;

        proxy_pass http://10.x.x.20:8383/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
#    location /.well-known {
#      alias /var/www/html/.well-known;
#      allow all;
#    }
}

# Alexa
server {
    server_tokens off;
    listen 444 ssl;
    server_name alexa.domainA.de;

    # gzip should not be used with ssl
    gzip off;
    ##
    # SSL
    # Global SSL in nginx.conf
    ##
    ssl on;
    ssl_certificate /etc/letsencrypt/live/alexa.domainA.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/alexa.domainA.de/privkey.pem;

# maintain the .well-known directory alias for letsencrypt & renewals
location /.well-known {
  auth_basic off;
  alias /var/www/html/.well-known;
}
    access_log /var/log/nginx/alexa.log combined;
    auth_basic "Alexa";
    auth_basic_user_file /etc/nginx/htpasswd;


    location / {
        proxy_pass http://10.x.x.20:9000/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Nachfolgend die Konfiguration für Exchange getestet mit Version 2013 und 2016

vhost für owa, active sync und outlook web access

Code:

#Abschnitt 1
server {
        listen       80;
        server_name owa.domainB.de autodiscover.domainB.de;

        # Redirect any HTTP request to HTTPS
        return 301 https://$server_name$request_uri;

        error_log  /var/log/nginx/exchange-error.log;
        access_log /var/log/nginx/exchange-access.log;
}

#Abschnitt 2
server {
     server_tokens off;
    listen       443;
    # gzip should not be used with ssl
    gzip off;

        server_name owa.domainB..de autodiscover.domainB.de;

        ssl on;
        ssl_certificate /etc/letsencrypt/live/owa.domainB.de/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/owa.domainB.de/privkey.pem;


        # Set global proxy settings
        proxy_read_timeout      360;

        proxy_http_version 1.1;
        proxy_pass_request_headers on;

        proxy_pass_header       Date;
        proxy_pass_header       Server;

        proxy_set_header        Host $host;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        Accept-Encoding "";

        more_set_input_headers 'Authorization: $http_authorization';
        proxy_set_header Accept-Encoding "";
        more_set_headers -s 401 'WWW-Authenticate: Basic realm="host-intern.domainB.de"';

        location /owa           { proxy_pass https://host-intern.domainB.de/owa; }
        location /OWA           { proxy_pass https://host-intern.domainB.de/owa; }        
        location /EWS          { proxy_pass https://host-intern.domainB.de/EWS; }
        location /ews          { proxy_pass https://host-intern.domainB.de/EWS; }        
        location /Microsoft-Server-ActiveSync { proxy_pass https://host-intern.domainB.de/Microsoft-Server-ActiveSync; }
        location /mapi           { proxy_pass https://host-intern.domainB.de/mapi; }
        location /MAPI          { proxy_pass https://host-intern.domainB.de/mapi; }        
        location /rpc           { proxy_pass https://host-intern.domainB.de/Rpc; }
        location /RPC           { proxy_pass https://host-intern.domainB.de/Rpc; }        
        location /oab            { proxy_pass https://host-intern.domainB.de/OAB; }
        location /OAB            { proxy_pass https://host-intern.domainB.de/OAB; }        
        location /autodiscover           { proxy_pass https://host-intern.domainB.de/Autodiscover; }
        location /Autodiscover           { proxy_pass https://host-intern.domainB.de/Autodiscover; }

        error_log /var/log/nginx/exchange-ssl-error.log;
        access_log /var/log/nginx/exchange-ssl-access.log;
        }

**psilo** · 15.10.2017, 06:22

Ich bin jetzt auch "im Club" ;-) Nachdem die Generierung nach 24 h ohne Erfolg war, weil ich Sudo vergessen hatte, habe ich gerade in der VirtualBox am PC nochmal generiert (dauerte nur 20 Minuten ;-) ). Jetzt ein A+

vv.PNG

**yachti** · 15.10.2017, 07:28

Na dann Glückwunsch und Willkommen im Club ;-).
Nicht drauf Ausruhen sondern immer wieder regelmäßig überprüfen. Ich checke es monatlich nach dem Windows Patchday
Ich bin auch schon mal auf ein C zurück gefallen Anfang des Jahres

Beim 2. Mal ging bei mir die Generierung auch viel schneller. Da war mein RProxy wohl noch nit anderen Dingen beschäftigt.
Hab dem 1 CPU und nur 512K RAM gegeben.

**yachti** · 28.10.2017, 09:47

https://knx-user-forum.de/forum/supp...53#post1149053

Nein geht bei mir auch nicht. Getestet in der SV2.8 u. 2.9

Ich habe für IOS keine Lösung gefunden. IOS hat mit dem wss Probleme

**psilo** · 28.10.2017, 09:53

yachti ich hatte einen link gefunden, wo stand, dass die zertifikatesache offiziell bei apple als bug eingesteuert ist. offenbar wird aber nichts gefixt.. naja zumindest weiss ich, warum ich android habe

notfalls halt am ipad mit vpn und lan ip...

**yachti** · 28.10.2017, 10:00

Zitat von psilo Beitrag anzeigen

notfalls halt am ipad mit vpn und lan ip...

ja so mache ich das mit nem Client SSL VPN. Brauche das aber vom Ipad nur selten(Urlaub) und unterwegs dann mal gelegentlich vom Iphone wenns nen WAF Problem gibt.
Ich habe nen 2. Wohnsitz in Nürnberg da habe ich nen S2S VPN

**yachti** · 28.10.2017, 10:03

naja zumindest weiss ich, warum ich android habe

Wenn ich meiner Frau das Ipad wegnehme und Android einführe hängt der Haussegen schief. Da verzichte ich lieber auf den Reverse Proxy für die SV

**Max2612** · 02.11.2017, 18:17

Zitat von TCr82 Beitrag anzeigen

Also ich habe in der config.ini das drin stehen (bin auf develop, in master wohl wirklich noch nicht drin):

Code:

driver_address = ""
driver_port = ""

Das führt dazu, dass der driver den host+port automatisch ermittelt. Naja, das mit dem Port hatte nicht ganz funktioniert wenn man einen alternativen Port benutzt (was man bei einem Zugriff von Extern immer machen sollte), dazu mein patch (vielleicht komme ich irgendwann mal dazu das zu pushen):

Code:

diff --git a/driver/io_smarthome.py.js b/driver/io_smarthome.py.js
index ebd60ce..66fc792 100755
--- a/driver/io_smarthome.py.js
+++ b/driver/io_smarthome.py.js
@@ -151,6 +151,12 @@ var io = {
// use url of current page if not defined
io.address = location.hostname;
}
+ if (!io.port) {
+ // use port of current page if not defined and needed
+ if ( ! ((location.protocol == 'https' && location.port == '443') || (location.protocol == 'http' && location.port == '80')) ) {
+ io.port = location.port;
+ }
+ }
}
io.socket = new WebSocket(protocol + io.address + ':' + io.port);

Gruß

Hallo!

Verstehe ich das richtig, dass mit dieser Änderung, die Websocket Verbindung in beiden Fällen funktionieren sollte?

1. lokale IP/smartVISU (vom internen LAN)
2. https://meine-domain/smartVISU (von extern, über Reverse Proxy)

Gruß, Max

EDIT: Hat sich erledigt. Funktioniert.

**TCr82** · 28.11.2017, 23:00

hab gerade ein Patch gepusht, der den IE Zugriff fixt. Ist mir heute Abend zufällig aufgefallen dass der nicht mehr funktioniert.

https://github.com/Martin-Gleiss/smartvisu/pull/178

**smai** · 29.11.2017, 09:28

Danke Thomas, ich habe den Pull Request eben gemerget.

**psilo** · 29.11.2017, 10:19

doofe frage zur umsetzung: der port wäre in beiden fällen (lokal, remote) aber identisch oder? ich frage, weil ich bei mir den io_smarthome so patchen musste, dass er bei lanzugriff auf die 2424 und bei dyndns zugriff auf die 443 geht..

ah ich sehe gerade, der 8b97fe2446e1fdfd319213aca365ea76779069cb könnte das behoben haben.
wobei nein, eigentlich müsste das else als if vorangestellt werden... so dass der konfigurierte port nur greift, wenn das ganze per ws oder wss eingeht..

jetziger patch bei mir:

Code:

            if (!io.port) {
                // use port of current page if not defined and needed
                if (location.port != '') {
                    io.port = location.port;
                } else {                    
                    if (location.protocol == 'http:') io.port = '80';
                    if (location.protocol == 'https:') io.port = '443';
                    if (io.address == '192.168.178.100') io.port = '2424'
                }
            }

Evtl machts Sinn, für die Websockets einen LAN und einen WAN Port spezifizierbar zu machen? Ich brauch das so, da das Apple-Zeug in meinem Haushalt die ReverseProxy Security Sachen ja für Websockets nicht kann und daher nur im LAN bzw im VPN genutzt werden kann.

**smai** · 29.11.2017, 10:40

Die Logik ist relativ einfach:
Wenn kein Port für SHNG konfiguriert ist, wird derselbe benutzt, welcher in der URL der smartVISU verwendet wurde.
Es findet also keine Unterscheidung nach Quelle oder Ziel statt. Ich wüsste auch nicht, wie WAN oder LAN zu erkennen wäre, wenn müsste man da individuell IP-Ranges konfigurieren können.

Eine Möglichkeit wäre, dass du die smartVISU aus dem LAN per http aufrufst und aus dem WAN per https. Das läuft zwar trotzdem beides über den Reverse Proxy, die nicht unterstützten Security Sachen müsstest du dann aber nur für Port 443 aktivieren. Den Zugriff auf Port 80 sperrst du vom WAN (ist er hoffentlich eh, weil Authentication über eine unverschlüsselte Verbindung keinen Sinn macht).

**psilo** · 29.11.2017, 10:58

smai wäre vielleicht eine Idee ja. die eine Zeile im Treiber lokal bei mir zu "maintainen" ist jetzt aber auch nicht viel mehr Aufwand und weniger fehleranfällig, in Bezug darauf dass am Ende doch was offen im Netz steht. Du hast aber Recht.. LAN von WAN unterscheidbar machen könnte eklig werden.

**smai** · 29.11.2017, 11:17

Zitat von psilo Beitrag anzeigen

weniger fehleranfällig

Das bezweifle ich. Du hast schon öfters bei einem Pull vergessen, eine deiner angepassten Dateien zu aktualisieren.

**TCr82** · 29.11.2017, 18:46

psilo - hast du es mal versucht den Server und Port in der SH Konfig der SV raus zu lassen? Wie smai schon schrieb, sollte das all deine Probleme lösen.

Ankündigung

Reverse Proxy

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar