Is Content Filtering doing a slow side to not working for you? Are you sure?
millia
Newbie ✭
Good morning. We have been having an issue that is spreading from machine to machine on our chromebooks that is blocking instruction. (Our students are using office.com online, and now they can't get to it.) It all appears to have started on March 10th. All of our machines have a last contact of that date. The error that starts then are:
Info Sending query to CM: 'clientmanager.global.sonicwall.com'
Error curl failed: error 35 (SSL connect error): 'error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small'
Warning Failed to send request to uri: 'clientmanager.global.sonicwall.com'. error 14
etc. This repeats over and over again.
This is happening on machines that are showing the correct policy, as well as machines that are not and show 'Built-In' instead. We do have lots of errors before that, involving curl timeouts to the various servers, but they don't seem to be wholesale breaking things- just a multitude of machines that need reboots so that things work with EPRS. Has anybody ever had to get SonicWall to prioritize your IP # out of the firewall so that things work well? The perpetual slowness makes me wonder.
If you haven't looked at a TSR recently, it might be a good idea.
In the past, I would say to people who asked that sonicwall is an okay solution. It works. It's not great to use, or exceedingly granular, but it works. This past year, my opinion has changed. I'm not sure if they plan to keep it as an offering, but if they do, I can't come to a conclusion other than the fact that they need to pony up for some more servers in what I hope is a cluster.
Answers
@millia did you got any update around March 10th? It seems that the SSL related components are not happy when connecting to clientmanager.global.sonicwall.com. This might have changed around the date you mentioned.
Qualys SSL labs gives that server a straight F, not very compelling for a security company, but boundless indeed.
--Michael@BWC
Its possible a certificate chain broke or updated around that day... but I couldnt find much in a quick search. But what OS version on the Chromebooks? Do they have any expired root CAs? As BWC pointed out SSL is not happy.
Excellent idea! I had not thought of using a SSL tester. Interesting results.
As for updates, we have several that would happen:
a) Google. Chromebooks generally update at will, but we capped them at 97 when we had the earlier day-of-breakage. Alas, most machines had already gotten to 98. Both sets show the same behavior. It is possible that Google had swapped some background behavior about the 10th whereby they require a higher level of security. I can't find anything to allow me to control that on the CrBooks or in the console, not like you can on a PC. I'm going to look closer at the changes re: that time period. Also, I used to be able to find really detailed git type checkin logs from the Google CrOs updates, and I can't find them anymore. I'll dig for those again. Really wanted to find DH related changes.
b) The sonicwall updates. No clue. The logs are just full of errors on good and bad machines.
c) Firewall. Actually, these DON'T go through our sonicwall firewall. It couldn't handle the traffic last year so we had to split it off onto a mikrotik. That didn't change, and it's really not doing anything. No overhead or issues there, and in any case, it does it off campus or on campus.
d) Other plugins/extensions. Ublock, blocksi (another filtering solution- but the filtering is off and we only use it for class pedagogy needs) and misc. others that don't touch this problem.
Okay, more testing.
When I try getting an xml file from the site, I get interesting results.
Going to:
https://clientmanager.global.sonicwall.com/ecm/getClientLicenseInfo
opens fine in a web browser. No SSL errors.
(BTW, the results are interesting using an SSL tester:
https://www.ssllabs.com/ssltest/analyze.html?d=clientmanager.global.sonicwall.com - they need to see that. I realize that some of those grades can be taken with a grain of salt or three, but I've fooled enough with certs to know something needs tweaking.)
From a linux box I have, using wget:
wget https://clientmanager.global.sonicwall.com/ecm/getClientLicenseInfo
--2022-03-23 11:21:20-- https://clientmanager.global.sonicwall.com/ecm/getClientLicenseInfo
Resolving clientmanager.global.sonicwall.com (clientmanager.global.sonicwall.com)... 204.212.170.204
Connecting to clientmanager.global.sonicwall.com (clientmanager.global.sonicwall.com)|204.212.170.204|:443... connected.
OpenSSL: error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small
Unable to establish SSL connection.
From the linux box, using curl:
curl https://clientmanager.global.sonicwall.com/ecm/getClientLicenseInfo
curl: (60) Peer's Certificate issuer is not recognized.
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
On a hunch, we removed the old DPI cert we had pushed out, and had never used because the box was not near powerful enough to do it, to see if we got different results. Verified cert was gone; results were same in CF logs.
We then pushed an intermediate cert from godaddy out to the machine that's in a test group. Verified cert was added; results were same.
I'm going to dowmload the site cert now and force import on the machine and see if we get different results, next.
@millia it might be not just the broken certificate chain (they don't deliver the intermediate) it's probably more related to the DH key exchange and the ciphers offered. SNWL has to do the work here.
--Michael@BWC
We think you are exactly correct. I'm just throwing spaghetti at the wall to see if anything sticks.
Update: stuffed all the certs I can think of on the machine. No change.