8
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:
Danke schonmal für eure Hilfe
Athi
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:80Danke schonmal für eure Hilfe
Athi
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 648553
Url: https://administrator.de/contentid/648553
Ausgedruckt am: 22.11.2024 um 02:11 Uhr
8 Kommentare
Neuester Kommentar
Hi,
wahrscheinlich übersiehst du eher was in der Konfiguration der Anwendung dahinter
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
wahrscheinlich übersiehst du eher was in der Konfiguration der Anwendung dahinter
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
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?
Normalerweise gibst du per Header ans Backend "X-Forwarded-Proto: https", was dann vom Backend-Server oder der Anwendung selbst interpretiert wird.
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.
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.
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.
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
https://github.com/snipe/snipe-it/issues/6280
1
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 
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.
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.
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...
Der HAProxy hat also alles richtig gemacht...
