Securly SSL Issues

[m_m]

Hello,

 

Is anyone else experiencing issues with some websites with Securly filtering? Amazon, Tesco, LinkedIn and a variety of other websites are throwing up SSL errors for us. Issues have been ongoing since Tuesday morning but haven't heard back on my Securly ticket yet.

[mwnci]

All working correctly for us with Securly so not affecting all customers.

[midweek]

No issues here using the Edge browser extension.

[CJF]

We do occasionally see these errors, but it's intermittent and hard to troubleshoot. For sites that you're ok with anyone accessing you can add it to your Global Allow list to bypass MITM as a temporary workaround. If you're able to recreate it when using a hotspot to rule out double-filtering, then sharing a HTTP Archive (HAR file) with the support team might help us track down the root cause.

If you're able to, I'd consider using the extensions for filtering as there is no MITM required and traffic doesn't come through our servers so you're generally going to have a better browsing experience.

[m_m]

We do occasionally see these errors, but it's intermittent and hard to troubleshoot. For sites that you're ok with anyone accessing you can add it to your Global Allow list to bypass MITM as a temporary workaround. If you're able to recreate it when using a hotspot to rule out double-filtering, then sharing a HTTP Archive (HAR file) with the support team might help us track down the root cause.

If you're able to, I'd consider using the extensions for filtering as there is no MITM required and traffic doesn't come through our servers so you're generally going to have a better browsing experience.

 

Hi Craig,

 

Unfortunately we can't globally unblock Amazon as we have it blocked for students. Plus there are lots of websites that currently don't work and globally unblocking each one isn't viable. Can you get someone to pick up ticket #808294 so we can continue discussing there?

[StephenPink]

We had this for a period at one site - support sorted eventually, but it was a combination of a strange issue with the DNS filtering (that we have enforced as a failsafe) and our IP address being "lost" from registration

[m_m]

We had this for a period at one site - support sorted eventually, but it was a combination of a strange issue with the DNS filtering (that we have enforced as a failsafe) and our IP address being "lost" from registration

 

That's interesting as we have DNS as a failsafe too. I have just changed the DNS on my machine and Amazon now works with the extension still enabled. Switch back to Securly DNS and it stops working so definitely an issue with Securly DNS.

[mdrabble]

It is to do with ZSTD data compression which can cause problems with both Edge and Chrome - as I discovered with our Fortigate.

 

I had to download the latest admx files in order to disable the protocol.

 

[CJF]

I have added some notes and observations to the ticket for the Support team, and raised it as an internal escalation.

Sometimes the Support Team adds domains to the DNS bypass to just rely on Extension for differentiated filtering but that's treating the symptoms, not the cause.

 

If you are going to combine DNS filtering with extension filtering, then it's better to use the simpler GuestDNS filtering as that isn't trying to do MITM or Authentication and rules out a lot of complications with double-filtering (not always an option for everyone as your network/setup may not accommodate this config)

 

I'll look into this ZSTD compression setting - thank you for bringing it up!

Edited October 10, 2024 by CJF

[m_m]

I have added some notes and observations to the ticket for the Support team, and raised it as an internal escalation.

Sometimes the Support Team adds domains to the DNS bypass to just rely on Extension for differentiated filtering but that's treating the symptoms, not the cause.

 

If you are going to combine DNS filtering with extension filtering, then it's better to use the simpler GuestDNS filtering as that isn't trying to do MITM or Authentication and rules out a lot of complications with double-filtering (not always an option for everyone as your network/setup may not accommodate this config)

 

I'll look into this ZSTD compression setting - thank you for bringing it up!

Thanks Craig, interesting point about using GuestDNS as fall back, this has never been suggested to us. Something to talk over with support.

 

On a side note, I just disabled ZSTD in edge://flags/ and it didn't make a difference to this issue.

[CJF]

I just disabled ZSTD in edge://flags/ and it didn't make a difference to this issue.

 

Bah, I thought we might have a nice root cause there :/

[stottio]

We have just moved to this for our PC stock.  Securly on our Chromebooks has been excellent and so thought it would be the same for our PCs, but no, exactly the same errors as are reported here.  Support keep bouncing back and two while issues seems to be getting worse.  All SSL and all seem related to shopping sites.  Did anyone ever solve?

[m_m]

For us it was an issue on Securly's side and not our implementation. I can't remember what they changed though.

[stottio]

Thanks for reply, its so annoying, works well on our chromebook fleet.  Seems to only be afffecting e-commerce sites bizarly, morrisons, tesco, 1001fonts.com (which is an e-commerce site according to their lists).  Othe sites that use SSL are unaffected and work as expect, so annoying when there is nothing i can do to diagnose or fix really.

[StephenPink]

Are users hitting the correct filtering policy? We've had an issue today (still waiting to hear the cause) were all our Policy Maps had disappeared - so staff were getting the Base/Default Policy instead of the Staff Policy - so e-commerce etc was blocked.

[stottio]

I think I have figured out the issue, I don’t know why as it doesn’t make sense.

 

I think it was the default policy.  I had blocked most categories, my thinking being that if anyone falls into the category by mistake id want them to be blocked.  However I don’t think this is how Securly works, having enabled all the categories now apart from obviously porn, gambling etc, the SSL errors are now gone.

 

Now all the policies are blocking as they should and the SSL error pages are no more.

 

I need to look into how Securly applies the policies and why the default policy plays a pivotal role when it isn’t applied to a group

 

[speakercon]

If it can't match the user to a policy the default policy applies (unless you have 'all users need to sign in' ticked). If you tick that, if it doesn't know who the user is it will ask them to sign in with O365/Google and then it will apply the correct policy, instead of them getting the default, asume the users are all synced.

 

Are you using PAC or browser extension?

 

[stottio]

Yeah that's what I thought. I have enforce users to sign in, users were signed in correctly and their logs were coming through in securly, listed as filter in the correct policy but on their machines they were suffering SSL errors.  It seems this was related to the default policy even though they were in another policy.  We use DNS but I'd also tried with the PAC, happened with both.  Seems fixed now just can't understand why.