On Wed, Oct 28, 2020 at 12:00:01PM +0000, squid-users-request@xxxxxxxxxxxxxxxxxxxxx wrote: > Date: Thu, 29 Oct 2020 00:08:34 +1300 > From: Amos Jeffries <squid3@xxxxxxxxxxxxx> > To: squid-users@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: 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@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
