athi1234
Goto Top

HAProxy SSL-Termination mit HTTP-Backend-Server

Moin zusammen,

ich habe einen HAProxy in Betrieb genommen und blicke da noch nicht so ganz durch. Ich hab ein Zertifikat auf meinem HAProxy laufen und eine URL, die dieses Zertifikat auch schon korrekt nutzt. D.h. der HAProxy übernimmt die SSL-Verbindung, der Webserver im Backend liefert weiterhin HTTP aus. Nun ist es so, dass im Quelltext der Webseiten nachwievor alle URLs auf http und nicht https lauten und dadurch nicht richtig dargestellt werden, wegen Mixed-Mode. Was übersehe ich hier in meiner HAProxy-Konfiguration?

So sieht meine aktuelle Konfiguration aus:
global
        log /dev/log    local0
        log /dev/log    local1 notice
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
        stats timeout 30s
        user haproxy
        group haproxy
        daemon

        # Default SSL material locations
        ca-base /etc/ssl/certs
        crt-base /etc/ssl/private

        # See: https:{{comment_single_line_double_slash:0}}
        ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACH>
        ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
        ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets
        tune.ssl.default-dh-param 2048

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http

listen stats
        bind 192.168.200.20:8443 ssl crt /etc/ssl/certs/wildcard.domain.de.pem
        stats enable                    # enable statistics reports
        stats hide-version              # Hide the version of HAProxy
        stats refresh 30s               # HAProxy refresh time
        stats show-node                 # Shows the hostname of the node
        stats auth haadmin:P@ssword     # Enforce Basic authentication for Stats page
        stats uri /stats                # Statistics URL

frontend hdhaproxy001.domain.de
        bind *:80
        bind *:443 ssl crt /etc/ssl/certs/wildcard.domain.de.pem
	http-request redirect scheme https unless { ssl_fc }
        
        acl ticket.domain.de hdr(host) -i ticket.domain.de

        use_backend ticket.domain.de if ticket.domain.de

backend ticket.domain.de
        option httpchk HEAD /
        default-server check maxconn 20
        server ticket.domain.de 172.28.220.119:80

Danke schonmal für eure Hilfe
Athi

Content-Key: 648553

Url: https://administrator.de/contentid/648553

Printed on: February 22, 2024 at 05:02 o'clock

Member: ASP.NET.Core
ASP.NET.Core Feb 05, 2021 at 16:53:18 (UTC)
Goto Top
Zitat von @athi1234:
Was übersehe ich hier in meiner HAProxy-Konfiguration?
Hi,
wahrscheinlich übersiehst du eher was in der Konfiguration der Anwendung dahinter face-wink
Manche haben eine Basis-URL gesetzt, die man ändern muss. Es gibt aber auch Anwendungen die prüfen die Anfrage, und setzen ihre Basis-URL entsprechend auf HTTP wenn die Anfrage auf HTTP rein gekommen ist bzw. HTTPS bei HTTPS-Anfrage. Das stimmt nach vorne hin natürlich nicht, wenn wie bei dir nicht durchgehend TLS genutzt wird sondern der HAProxy die SSL-Terminierung übernimmt.

Was du da machen kannst hängt stark von der Anwendung ab. Bei vernünftigen Anwendungen lässt sich das konfigurieren. Bei schlecht programmierten Anwendungen kannst du das im besten falle selbst fixen, wenns Open Source ist. Bei proprietären Anwendungen kann man nur versuchen soweit es geht gegen an zu murksen, in dem man die URLs ersetzt, z.B. so: https://u-labs.de/portal/urls-und-andere-zeichenketten-in-http-anfragen- ...

Falls das zu viel Gebastel hin gibt, bleibt nur
a) den internen Traffic zwischen HAProxy und Anwendungsserver auch zu verschlüsseln (je nach Infrastruktur ggf auch sinnvoll)
b) den HAProxy als Layer 4 LB laufen zu lassen und TLS beim Applikationsserver zu terminieren
Member: athi1234
athi1234 Feb 05, 2021 at 16:55:14 (UTC)
Goto Top
Ok, das klingt sinnvoll, dass die Applikation möglicherweise auf SSL gehen muss. Was mich stutzig macht, ist, dass ich einen parallen Aufbau mit einem nginx mit der gleichen Aufgabenstellung habe, dort aber im Quelltext alles auf https umgeschrieben wurde. Kann das der HAProxy nicht?
Member: LordGurke
Solution LordGurke Feb 05, 2021 at 18:42:33 (UTC)
Goto Top
Normalerweise gibst du per Header ans Backend "X-Forwarded-Proto: https", was dann vom Backend-Server oder der Anwendung selbst interpretiert wird.
Mitglied: 137960
Solution 137960 Feb 06, 2021 at 09:09:48 (UTC)
Goto Top
Welche Anwendung läuft auf 172.28.220.119:80 ?

Wie Vorkommentatoren schon schrieben: es ist wahrscheinlich nicht HAproxy, sondern die Anwendung. Speziell, weil Du was von "mixed mode" erwähnt hast.

Wenn Du z.B. eine Webanwendung hast, die auf Tomcat bzw. Spring bzw. Spring Boot basiert, dann musst Du in der Webanwendung Einstellungen vornehmen, wo man einen SSL-Proxy angibt (scheme, proxyHost, proxyPort, ...)

Es scheint außerdem so, dass "option forwardfor" nicht vorhanden ist. Das kannst Du im Frontend oder Backend eintragen.

Ins Backend könnte noch "http-request add-header X-Forwarded-Proto https if { ssl_fc }" und "http-request set-header X-Forwarded-Port %[dst_port]" rein. Manche Webanwendungen wollen das so.
Member: athi1234
athi1234 Feb 06, 2021 at 09:18:56 (UTC)
Goto Top
Danke für eure Tipps! Ich werde das mit optionfor testen und habe auch entdeckt, dass die Applikation auch noch Settings benötigt... Es handelt sich um SnipeIT.
Member: athi1234
athi1234 Feb 07, 2021 at 07:40:00 (UTC)
Goto Top
Habs nun hinbekommen. Nachdem ich die empfohlenen Optionen in HAProxy gesetzt habe und noch eine Einstellung in SnipeIT vorgenommen habe, klappt es nun. Es gibt wohl auch noch einen Fehler in SnipeIT...
https://github.com/snipe/snipe-it/issues/6280
Member: ASP.NET.Core
Solution ASP.NET.Core Feb 07, 2021 updated at 13:09:06 (UTC)
Goto Top
https://github.com/snipe/snipe-it/issues/6280#issuecomment-607163265 das ist was ich vorher meinte: APP_URL scheint die Basis-URL zu sein, die auf https gesetzt werden muss face-smile Zusätzlich scheint eine Prüfung der reverse Proxy drin zu sein. Da kannst du ja einfach APP_TRUSTED_PROXIES auf die IP von deinem HAProxy setzen.
Member: athi1234
athi1234 Feb 07, 2021 at 20:05:10 (UTC)
Goto Top
Yupp, genau das habe ich auch gemacht. Aber SnipeIT hat wohl noch nen Bug, dass APP_TRUSTED_PROXIES nicht übernommen wird. Man muss den Wert direkt in der passenden PHP-Datei ändern - und läuft Gefahr, dass es beim nächsten Update wieder rausfliegt...

Der HAProxy hat also alles richtig gemacht...