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

[Scott]

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.