Sophos UTM blocking login - fix

[mdh42]

Just an FYI in case anyone else runs into this.

We are behind a Sophos UTM (version 9). Every time I would try to log in with the SQRL client (SG), I would get blocked (Unable to connect to website). Finally pulled a wireshark log and saw where the client was being blocked by the UTM asking for a proxy login.

I created an exception in the web protection, using the user agent "GRC SQRL Client". This did the trick.

Finally able to play with this and get the feel for how it will be working.

 

[Steve]

Thanks! That one needs to go under into our troubleshooting page. I'll make a note!

 

[PHolder]

There are workplaces where being proxied is NOT optional... if the client doesn't support a proxy and the OS doesn't do it for the client, then the standalone SQRL client would be unusable. (One presumes a browser plug-in would still work.)

 

[Steve]

The standalone SQRL client is fully proxy aware. During development we had at least one user whose enterprise was proxied. So I added proxy awareness and we confirmed that all was well. What @mdh42 is describing is more than a simple proxy. It's a blocking UTM device as demonstrated by the fact that informing it of the client's User Agent allowed it to function.

 

[MarkH]

The standalone SQRL client is fully proxy aware. During development we had at least one user whose enterprise was proxied. So I added proxy awareness and we confirmed that all was well. What @mdh42 is describing is more than a simple proxy. It's a blocking UTM device as demonstrated by the fact that informing it of the client's User Agent allowed it to function.

Steve,

I know this is an old topic but I'm currently sat behind two enterprise proxies (as in, a choice of two to get onto the Internet). It appears SQRL isn't "fully proxy aware", or at the very least, I'd be interested to know which RFC's you're talking about above?

We use two proxy systems: Bluecoat for one, Microsoft Threat Management Gateway for the other (legacy) one. If defined manually on a Win 10 1903 laptop I'm sat at now (having logged in with Jeff's client - a nod there to his work) I see the screen below when trying to login to https://sqrl.grc.com/demo using your Windows client using either proxy. This is also the case when using a pac file that passes back a particular proxy depending on the destination URL being requested (mainly for Office 365 support which bypasses the proxy and heads straight out of the firewall). In all other respects I can browse around grc.com and the forums without issue. Not sure if this is important but this machine isn't domain joined

I'm more than happy to assist with troubleshooting (network trace) if you can guide me as to how the communications are supposed to look from the proxy perspective. Our proxies are authenticating and are otherwise working with cached credentials. I feel to have this adopted in the enterprise would be the icing on the cake, and to that end perhaps a way to force SQRL to surface the proxy asking for credentials might be worth considering, so the Windows Credential cache can then take care of them.

Sorry if this is a spanner in the works, looking forward to release... and SR6.x / SR7

Thanks for all the great work

--

Mark

 

[Steve]

Hi @MarkH ...

The text you quoted (thank you for that) may carry the details of what needs to be done. It makes sense that outbound communications by unknown utilities would be blocked by default by edge-filtering MITM boxes. We know that Bluecoat is an aggressive TLS-intercepting middle-box. Filtering by User-Agent strikes me as dumb, since any web client can claim to be anything it wishes. But it seems wrong for SQRL clients to pretend to be something it isn't for the sake of passing through a default-deny firewall.

szSQRL_UserAgent    CHAR    'GRC SQRL Client',0

As @mdh42 indicated, and as can be seen in the code snippet above, GRC's SQRL client declares itself to be exactly that "GRC SQRL Client".

CAN you get your IT folks to add this User-Agent to your corporate permitted list??