HAProxy and 'Loading mixed (insecure) display content' warnings on http backend



  • My homelab is hosting a node.js app. I'm using HAProxy on pfSense in front of it so that I can if needed scale up the number of backend VMs running the app. I'm also using HAProxy for SSL offloading. The backend node.js, and it's mongoDB are http. All is fine with my 3rd party TLS certs being seen on the homepage (green padlock etc). However when a user goes into the site there are many warnings about 'loading mixed (insecure) display content', coming through from the app, and the padlock gives a warning that the connection is 'not secure' as result. they're mostly linked with calls to the db.

    This seems to be a common issue, but I'm struggling to grasp which option (for the frontend?) I need to add to solve this.
    Would one of the http-request-header or http-resposne-header' actions' apply https to all responses coming out the backend server (I think that's what I need to achieve)

    Here's my HAProxy config:

    
    # Automaticaly generated, dont edit manually.
    # Generated on: 2019-12-19 09:41
    global
    	maxconn			100
    	stats socket /tmp/haproxy.socket level admin 
    	uid			80
    	gid			80
    	nbproc			1
    	hard-stop-after		15m
    	chroot				/tmp/haproxy_chroot
    	daemon
    	tune.ssl.default-dh-param	2048
    	server-state-file /tmp/haproxy_server_state
    
    listen HAProxyLocalStats
    	bind 127.0.0.1:2200 name localstats
    	mode http
    	stats enable
    	stats admin if TRUE
    	stats show-legends
    	stats uri /haproxy/haproxy_stats.php?haproxystats=1
    	timeout client 5000
    	timeout connect 5000
    	timeout server 5000
    
    frontend SpottingTrains_FE1
    	bind			192.168.1.100:443 name 192.168.1.100:443   ssl crt-list /var/etc/haproxy/SpottingTrains_FE1.crt_list  
    	mode			http
    	log			global
    	option			http-keep-alive
    	timeout client		30000
    	http-request add-header X-Forwarded-Proto https
    	acl			aclcrt_SpottingTrains_FE1	var(txn.txnhost) -m reg -i ^www\.spottingtrains\.com(:([0-9]){1,5})?$
    	acl			aclcrt_SpottingTrains_FE1	var(txn.txnhost) -m reg -i ^spottingtrains\.com(:([0-9]){1,5})?$
    	http-request set-var(txn.txnhost) hdr(host)
    	use_backend PengellyBeckett1_BE_ipvANY  if   aclcrt_SpottingTrains_FE1
    
    backend PengellyBeckett1_BE_ipvANY
    	mode			http
    	id			100
    	log			global
    	timeout connect		30000
    	timeout server		30000
    	retries			3
    	option			httpchk OPTIONS / 
    	server			pengellybeckettvm1 10.10.20.10:7331 id 101 check inter 1000
    

    [192.168.1.100 is the WAN IP from another router]



  • @revmarkp
    A browser will usually not connect to a DB.. not sure where you got that idea..

    As for the app, it might load javascript, or perform additional requests for some json data or include a image or anything that should be loaded from the webserver...
    If the page that is served contains absolute url's to such resources and points them to http://x.y.z/resource.js then then the browser will complain about mixed content for your https site.. The best solution is probably to get rid of those absolute urls.. As a workaround you could possibly add the "Content-Security-Policy: upgrade-insecure-requests;" header in the responses from haproxy.. That can be done with a 'Action' in the package..



  • Many thanks for your response PIBa...

    Since posting my question I have learned that re-writing the headers, using actions in HAProxy is not going to help rewrite the content of the pages themselves (my bad, I'm a noob). The calls to the MongoDB were not direct as you suggested, they were indirect responses from the parseserver app. The solution has been to simply tell the db to declare these https:// urls and that works fine. I had assumed if the db and the parse server weren't actually TLS themselves this might not work, but that was over thinking it perhaps.


Log in to reply