[squid-users] Reverse proxying Exchange OWA wembail with SSL offloading

[Eliezer Croitor]

Hey Scott,

In many frontends there is a basic way to signal about the existence of a Frontend and the relevant
details about the client and other factors of the connection.

Specifically with haproxy these settings are used:
    http-request set-header X-Forwarded-Host %[req.hdr(Host)]
    http-request set-header X-Forwarded-Proto https

https://www.haproxy.com/blog/ssl-offloading-impact-on-web-applications/
https://www.digitalocean.com/community/tutorials/how-to-implement-ssl-termination-with-haproxy-on-ubuntu-14-04

In nginx:
https://www.nginx.com/resources/wiki/start/topics/examples/forwarded/
https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-load-balancing-with-ssl-termination


In squid you can use:
http://www.squid-cache.org/Doc/config/request_header_replace/
http://www.squid-cache.org/Doc/config/request_header_add/

An example should be provided in wiki some day be someone(not me).

----
Eliezer Croitoru
Tech Support
Mobile: +972-5-28704261
Email: ngtech1ltd at gmail.com

-----Original Message-----
From: squid-users <squid-users-bounces at lists.squid-cache.org> On Behalf Of Scott
Sent: Thursday, October 29, 2020 1:07 AM
To: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] Reverse proxying Exchange OWA wembail with SSL offloading

On Wed, Oct 28, 2020 at 12:00:01PM +0000, squid-users-request at lists.squid-cache.org wrote:
> Date: Thu, 29 Oct 2020 00:08:34 +1300
> From: Amos Jeffries <squid3 at treenet.co.nz>
> To: squid-users at lists.squid-cache.org
> Subject: Re: [squid-users] Reverse proxying Exchange OWA wembail with SSL
>  offloading - not working on IE/Chrome
> 
> On 28/10/20 5:25 pm, Scott wrote:
> > 
> > Here are the logs (first not working, followed by working).
> > 
> > Note this is the login attempt, not the loading of the initial page.  You'll
> > see in the NOT WORKING section that the browser does NOT return a cookie to
> > the server, which is where the problem may be.  Again, I'm not sure why - I'm
> > thinking perhaps the browser/javascript is rejecting the cookie as it's
> > missing the "secure" attribute (because the back-end is talking plain HTTP).
> > 
> 
> The complete absence of a cookie may be expected to break something.
> 
> The absence of a "secure" flag should only make the cookie vulnerable to 
> leaking. It should not affect anything depending on that cookies value.
> 
> 
> Amos
> 

After some more research and experimentation I've confirmed that my 
suspicions are correct.

Recent browsers are no longer accepting cookies with the SameSite flag set 
without the Secure flag set.

It's not an issue with Squid (although one Squid could solve - but I'm unsure 
of the implications).

Here is a useful link:
https://docs.microsoft.com/en-us/office365/troubleshoot/miscellaneous/chrome-behavior-affects-applications

I tested Chrome 85 on Windows - the default settings DO NOT allow for these 
cookies.  However after setting
	Cookies without SameSite must be secure
to Disabled, these cookies are permitted and OWA works.

There are obvious implications for sites doing SSL offloading here.  Are 
sites no longer doing SSL offload?  Or are reverse proxies adding the Secure 
flag?

Interesting.
_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users