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

[Amos Jeffries]

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