Search squid archive

Re: Reverse proxying Exchange OWA wembail with SSL offloading

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 29/10/20 12:06 pm, Scott wrote:
On Wed, Oct 28, 2020 at 12:00:01PM +0000, squid-users-reques wrote:
Date: Thu, 29 Oct 2020 00:08:34 +1300
From: Amos Jeffries

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).

Implications are that the server may have intentionally used the combination it did, no mistakes.

The server is given "Front-End-Https: On" so that it is aware the client is using HTTPS and can set (or not) the secure flag appropriately to what it needs. Squid is not aware of whether the cookie is safe to use on HTTP or restrict to just HTTPS.



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?


Neither. When a site frontend is entirely https:// with no http:// resources mixed in the Secure flag can be used by the server regardless of what the internal connections are.


Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux