Thread 'Download, upload, and Notices don't work on wired LAN; work on wireless guest LAN'

Message boards : Questions and problems : Download, upload, and Notices don't work on wired LAN; work on wireless guest LAN
Message board moderation

To post messages, you must log in.

AuthorMessage
flarbnatz

Send message
Joined: 25 Mar 22
Posts: 6
Message 107571 - Posted: 25 Mar 2022, 2:59:51 UTC

BOINC 7.16.20 (x64) [20211014; latest]. Windows 7.

Downloading, Uploading, and Notices stopped working via the wired LAN, but they all work via the wireless guest LAN. (The work-around is to plug in the wireless USB adapter and disable the wired LAN or disconnect the cable.)

I think it started right after we added SonicWALL Firewall DPI-SSL. (BOINC took a few days to run out of work units and then tell me.) DPI-SSL firewall decrypts TLS connections, inspects traffic both ways, and re-encrypts. (I have end-to-end privacy, EXCEPT that the beneficent "man in the middle" can see and filter everything.) At first it blocked all of my HTTPS browsing, with a security warning, until I registered a special certificate that lets the firewall pretend to be every domain, "dpi-ssl-2048-sha2.cer". If I add the cert to Firefox, only Firefox can browse HTTPS sites. If I add it only to Windows, that lets Firefox, Filezilla, and more visit secure servers. But BOINC didn't like it - it said "Info: SSL certificate problem: self signed certificate in certificate chain" and/or "HTTP error: Peer certificate cannot be authenticated with given CA certificates". I fixed that by opening "dpi-ssl-2048-sha2.cer" and re-saving it as base64, and then copying and pasting that text (in matching format) into "C:\Program Files\BOINC\ca-bundle.crt", just before the other certs in that "bundle". Now it has to work? Nope.

I think the firewall tries to upgrade the connection security, but apparently the app or the project servers don't like it.

Following are two logs, with each line stripped of the date+time. (That makes WinDiff show only the differences.) And differences in color.

The first difference is tiny: "DHE-RSA-AES256-GCM-SHA384" versus "ECDHE-RSA-AES256-GCM-SHA384".

This wakeup text is common to both:
Starting BOINC client version 7.16.20 for windows_x86_64
log flags: file_xfer, sched_ops, task, file_xfer_debug, http_debug, work_fetch_debug
Libraries: libcurl/7.47.1 OpenSSL/1.0.2s zlib/1.2.8
Data directory: C:\ProgramData\BOINC
Running under account me2
CUDA: NVIDIA GPU 0: NVIDIA GeForce GTX 1050 Ti (driver version 471.68, CUDA version 11.4, compute capability 6.1, 4096MB, 3038MB available, 2138 GFLOPS peak)
OpenCL: NVIDIA GPU 0: NVIDIA GeForce GTX 1050 Ti (driver version 471.68, device version OpenCL 3.0 CUDA, 4096MB, 3038MB available, 2138 GFLOPS peak)
Windows processor group 0: 8 processors
Host name: BoatAnchor
Processor: 8 GenuineIntel Intel(R) Xeon(R) CPU X5450 @ 3.00GHz [Family 6 Model 23 Stepping 6]
Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 cx16 sse4_1 syscall nx lm vmx tm2 dca pbe
OS: Microsoft Windows 7: Professional x64 Edition, Service Pack 1, (06.01.7601.00)
Memory: 32.00 GB physical, 48.60 GB virtual
Disk: 122.32 GB total, 30.68 GB free
Local time is UTC -4 hours
No WSL found.
VirtualBox version: 6.0.14
etta@home | General prefs: from Rosetta@home (last modified 13-Jul-2017 13:03:05)
etta@home | Host location: none
etta@home | General prefs: using your defaults
Reading preferences override file
Preferences:
max memory usage when active: 26212.52 MB
max memory usage when idle: 29489.09 MB
max disk usage: 38.10 GB
don't compute while active
don't use GPU while active
suspend work if non-BOINC CPU load exceeds 75%
max download rate: 524288 bytes/sec
max upload rate: 262144 bytes/sec
(to change preferences, visit a project web site or select Preferences in the Manager)
[work_fetch] Request work fetch: Prefs update
[work_fetch] Request work fetch: Startup
Setting up project and slot directories
Checking active tasks
stein@Home | URL https://einstein.phys.uwm.edu/; Computer ID 900000; resource share 100
etta@home | URL https://boinc.bakerlab.org/rosetta/; Computer ID 2000000; resource share 100
Setting up GUI RPC socket
Checking presence of 616 project files
Suspending computation - computer is in use

Success, via the wireless guest LAN (apparently bypasses firewall):
[http] HTTP_OP::init_get(): https://einsteinathome.org/rss_main.php
[http] HTTP_OP::libcurl_exec(): ca-bundle 'C:\Program Files\BOINC\ca-bundle.crt'
[http] HTTP_OP::libcurl_exec(): ca-bundle set
[http] [ID#0] Info: Trying 130.75.116.40...
[http] [ID#0] Info: Connected to einsteinathome.org (130.75.116.40) port 443 (#0)
[http] [ID#0] Info: ALPN, offering http/1.1
[http] [ID#0] Info: Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
[http] [ID#0] Info: successfully set certificate verify locations:
[http] [ID#0] Info: CAfile: C:\Program Files\BOINC\ca-bundle.crt
[http] [ID#0] Info: CApath: none
[http] [ID#0] Info: TLSv1.2 (OUT), TLS header, Certificate Status (22):
[http] [ID#0] Info: TLSv1.2 (OUT), TLS handshake, Client hello (1):
[http] [ID#0] Info: TLSv1.2 (IN), TLS handshake, Server hello (2):
[http] [ID#0] Info: TLSv1.2 (IN), TLS handshake, Certificate (11):
[http] [ID#0] Info: TLSv1.2 (IN), TLS handshake, Server key exchange (12):
[http] [ID#0] Info: TLSv1.2 (IN), TLS handshake, Server finished (14):
[http] [ID#0] Info: TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
[http] [ID#0] Info: TLSv1.2 (OUT), TLS change cipher, Client hello (1):
[http] [ID#0] Info: TLSv1.2 (OUT), TLS handshake, Finished (20):
[http] [ID#0] Info: TLSv1.2 (IN), TLS change cipher, Client hello (1):
[http] [ID#0] Info: TLSv1.2 (IN), TLS handshake, Finished (20):
[http] [ID#0] Info: SSL connection using TLSv1.2 / DHE-RSA-AES256-GCM-SHA384
[http] [ID#0] Info: ALPN, server accepted to use http/1.1

[http] [ID#0] Info: Server certificate:
((blank line))
[http] [ID#0] Info: start date: Jan 24 00:00:00 2022 GMT
[http] [ID#0] Info: expire date: Jan 24 23:59:59 2023 GMT
[http] [ID#0] Info: subjectAltName: einsteinathome.org matched
[http] [ID#0] Info: issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Organization Validation Secure Server CA
[http] [ID#0] Info: SSL certificate verify ok.
[http] [ID#0] Sent header to server: GET /rss_main.php HTTP/1.1
[http] [ID#0] Sent header to server: Host: einsteinathome.org
[http] [ID#0] Sent header to server: User-Agent: BOINC client (windows_x86_64 7.16.20)
[http] [ID#0] Sent header to server: Accept: */*
[http] [ID#0] Sent header to server: Accept-Encoding: deflate, gzip
[http] [ID#0] Sent header to server: Accept-Language: en_US
[http] [ID#0] Sent header to server:
[http] [ID#0] Received header from server: HTTP/1.1 200 OK
[http] [ID#0] Received header from server: Date: Fri, 25 Mar 2022 01:02:43 GMT
[http] [ID#0] Received header from server: Server: Apache
[http] [ID#0] Received header from server: Last-Modified: Fri, 25 Mar 2022 01:02:07 GMT
[http] [ID#0] Received header from server: ETag: "a6a767327ed7b0f614c2e9cf927a9b06-gunzip-gzip"
[http] [ID#0] Received header from server: Expires: Sun, 19 Nov 1978 05:00:00 GMT
[http] [ID#0] Received header from server: Cache-Control: must-revalidate
[http] [ID#0] Received header from server: X-Content-Type-Options: nosniff
[http] [ID#0] Received header from server: X-Frame-Options: sameorigin
[http] [ID#0] Received header from server: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
[http] [ID#0] Received header from server: Content-Type: application/rss+xml; charset=utf-8
[http] [ID#0] Received header from server: Set-Cookie: SESS3e8888888888888888f7f6d21b=8888btfadsdehhsshh8888c5s2z; expires=Sun, 17-Apr-2022 04:36:03 GMT; Max-Age=2000000; path=/; domain=einsteinathome.org; secure
[http] [ID#0] Received header from server: Vary: Accept-Encoding
[http] [ID#0] Received header from server: Content-Encoding: gzip
[http] [ID#0] Received header from server: Content-Length: 226
[http] [ID#0] Received header from server:
((blank line))
[http] [ID#0] Info: Connection #1 to host boinc.bakerlab.org left intact


Failure, through the wired LAN (via DPI-SSL firewall):
((The wake-up text is identical, so no need to repeat it.)
[http] HTTP_OP::init_get(): https://einsteinathome.org/rss_main.php
[http] HTTP_OP::libcurl_exec(): ca-bundle 'C:\Program Files\BOINC\ca-bundle.crt'
[http] HTTP_OP::libcurl_exec(): ca-bundle set
[http] [ID#0] Info: Trying 130.75.116.40...
[http] [ID#0] Info: Connected to einsteinathome.org (130.75.116.40) port 443 (#0)
[http] [ID#0] Info: ALPN, offering http/1.1
[http] [ID#0] Info: Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
[http] [ID#0] Info: successfully set certificate verify locations:
[http] [ID#0] Info: CAfile: C:\Program Files\BOINC\ca-bundle.crt
[http] [ID#0] Info: CApath: none
[http] [ID#0] Info: TLSv1.2 (OUT), TLS header, Certificate Status (22):
[http] [ID#0] Info: TLSv1.2 (OUT), TLS handshake, Client hello (1):
[http] [ID#0] Info: TLSv1.2 (IN), TLS handshake, Server hello (2):
[http] [ID#0] Info: TLSv1.2 (IN), TLS handshake, Certificate (11):
[http] [ID#0] Info: TLSv1.2 (IN), TLS handshake, Server key exchange (12):
[http] [ID#0] Info: TLSv1.2 (IN), TLS handshake, Server finished (14):
[http] [ID#0] Info: TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
[http] [ID#0] Info: TLSv1.2 (OUT), TLS change cipher, Client hello (1):
[http] [ID#0] Info: TLSv1.2 (OUT), TLS handshake, Finished (20):
[http] [ID#0] Info: TLSv1.2 (IN), TLS change cipher, Client hello (1):
[http] [ID#0] Info: TLSv1.2 (IN), TLS handshake, Finished (20):
[http] [ID#0] Info: SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
[http] [ID#0] Info: ALPN, server did not agree to a protocol

[http] [ID#0] Info: Server certificate:
((blank line))
[http] [ID#0] Info: start date: Jan 24 00:00:00 2022 GMT
[http] [ID#0] Info: expire date: Jan 24 23:59:59 2023 GMT
[http] [ID#0] Info: subjectAltName: einsteinathome.org matched
[http] [ID#0] Info: issuer: C=US; ST=CA; L=San Jose; O=SonicWALL Inc.; CN=SonicWALL Firewall DPI-SSL
[http] [ID#0] Info: SSL certificate verify ok.
[http] [ID#0] Sent header to server: GET /rss_main.php HTTP/1.1
[http] [ID#0] Sent header to server: Host: einsteinathome.org
[http] [ID#0] Sent header to server: User-Agent: BOINC client (windows_x86_64 7.16.20)
[http] [ID#0] Sent header to server: Accept: */*
[http] [ID#0] Sent header to server: Accept-Encoding: deflate, gzip
[http] [ID#0] Sent header to server: Accept-Language: en_US
[http] [ID#0] Sent header to server:
[http] [ID#0] Info: SSL read: error:00000000:lib(0):func(0):reason(0), errno 10054
[http] [ID#0] Info: Closing connection 0
[http] HTTP error: Failure when receiving data from the peer
ID: 107571 · Report as offensive
ProfileJord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15549
Netherlands
Message 107575 - Posted: 25 Mar 2022, 6:43:07 UTC

I'm not sure if your problem doesn't stem from your Windows 7 and it not receiving required security updates anymore.

You can still update it to Windows 10 without charge (as long as it is a non-pirated version to be begin with), ever thought of that?
ID: 107575 · Report as offensive
Harri Liljeroos
Avatar

Send message
Joined: 25 Jul 18
Posts: 66
Finland
Message 107576 - Posted: 25 Mar 2022, 9:13:22 UTC - in response to Message 107575.  
Last modified: 25 Mar 2022, 9:14:41 UTC

Windows 7 works well here (with older Boinc version though), so that shouldn't be a problem by it self.
ID: 107576 · Report as offensive
robsmith
Volunteer tester
Help desk expert

Send message
Joined: 25 May 09
Posts: 1296
United Kingdom
Message 107577 - Posted: 25 Mar 2022, 9:16:30 UTC

Failure, through the wired LAN (via DPI-SSL firewall):

This line might be a clue - firewalls can block certain types of message, including encrypted messages.
ID: 107577 · Report as offensive
Dr Who Fan
Avatar

Send message
Joined: 10 May 07
Posts: 1432
United States
Message 107578 - Posted: 25 Mar 2022, 17:08:19 UTC

As robsmith pointed out in the last post it's a wired -vs- wireless difference in connectivity problem in your firewall settings.

I would suggest you contact your firewall provider for help in setting it up and getting it working properly as this does not appear to be a BOINC issue.
ID: 107578 · Report as offensive
SteveTheCynic

Send message
Joined: 30 Dec 21
Posts: 8
Message 107585 - Posted: 27 Mar 2022, 10:14:54 UTC - in response to Message 107578.  

As robsmith pointed out in the last post it's a wired -vs- wireless difference in connectivity problem in your firewall settings.

I would suggest you contact your firewall provider for help in setting it up and getting it working properly as this does not appear to be a BOINC issue.

Pretty much this. I work as a developer for a *different* firewall company (which one it is isn't relevant here), and it's possible to:
* Deactivate the TLS proxy altogether. (By default, it's not active anyway.)
* Add exceptions based on the server certificate's alt-names to not decrypt traffic (which then lets the "true" server certificate through).

OP (and anyone else with this problem) should investigate either or both of these possibilities.
ID: 107585 · Report as offensive
computezrmle

Send message
Joined: 2 Feb 22
Posts: 81
Germany
Message 107628 - Posted: 29 Mar 2022, 12:23:22 UTC

Based on the OP I suspect flarbnatz has a hardware firewall plugged between LAN and internet that intercepts encrypted traffic.
To make this work that firewall needs a CA certificate and all LAN clients must trust that CA certificate.
That requirements have more or less already been discussed in this thread.

BOINC ships a ca-bundle.crt and in principle it is possible to add a self created CA certificate to that file.
This would enable BOINC to connect transparently via the firewall...


BUT!
VM based tasks making encrypted connections will not be able to do so as inside the VM images the self created CA certificate is not available.
Example: LHC VMs running CMS
Those connections must pass the firewall untouched.
ID: 107628 · Report as offensive
flarbnatz

Send message
Joined: 25 Mar 22
Posts: 6
Message 107631 - Posted: 29 Mar 2022, 17:56:26 UTC

My wired LAN blocks some websites by content "category". All traffic is inspected by SonicWALL Firewall DPI-SSL. BOINC connections fail.

My wireless "guest" LAN blocks some websites (last time I looked). Its traffic is NOT inspected by DPI-SSL. BOINC connections work.
It is not public. (It has a weak password.) Many devices connect to it. (Phones, laptops, thermostats.)
It might be unwise to leave the wireless "guest" LAN without traffic inspection. BUT: Putting it through DPI-SSL would cause many tech-support requests. Also, devices can access the Internet via their cellular provider, so the devices are often on "unprotected" data connections anyway.

I assume that many users run BOINC behind SonicWALL Firewall DPI-SSL.
I suspect that they all must have this same problem.
And not all have the handy work-around that I have (a less-protected LAN).
They might only get BOINC to upload and download by connecting through a VPN (if possible), or by hosting a hotspot from their cellphone and connecting to it from their BOINC computer.

I still think this problem happens because the DPI-SSL firewall tries to change or upgrade the connection security from "DHE-RSA-AES256-GCM-SHA384" to "ECDHE-RSA-AES256-GCM-SHA384", but either the BOINC app or the BOINC project servers (I can't guess which) don't like it.

If this problem blocks enough users, something has to be changed.
Maybe the firewall shouldn't change the selected encryption. (If enough people object, they MIGHT adjust it.)
Maybe the BOINC app and/or BOINC server should tolerate it when a DPI-SSL changes or upgrades the selected encryption. Maybe a configuration option could fix it. Maybe adding a DLL or a Windows patch could fix it. Maybe it has to be hard-coded.

I don't know whether BOINC under Windows 8/10/11 has this same problem. BOINC could detect the OS and make different requests, or it could make the same request that happens to act differently under different OS.
ID: 107631 · Report as offensive
Ian&Steve C.

Send message
Joined: 24 Dec 19
Posts: 229
United States
Message 107632 - Posted: 29 Mar 2022, 18:35:27 UTC - in response to Message 107631.  


I assume that many users run BOINC behind SonicWALL Firewall DPI-SSL.


I think you're making too much of an assumption. most people likely don't even know what this is.

most people just use the standard Windows firewall with an off-the-shelf consumer router, or whatever is provided by their ISP.
and you're definitely in a minority running something with DPI.
ID: 107632 · Report as offensive
computezrmle

Send message
Joined: 2 Feb 22
Posts: 81
Germany
Message 107633 - Posted: 29 Mar 2022, 18:49:04 UTC - in response to Message 107631.  

You described the key problem in your OP:
"DPI-SSL firewall decrypts TLS connections".

Since BOINC (like any other client) tries to establish an end-to-end encryption between the client and the server the firewall is treated as unfriendly "man-in-the-middle".
Hence BOINC must drop the connection.


The only possible solution has already been described.
You need 2 independent encrypted connections
1. between the client and the firewall
2. between the firewall and the server

To make (1.) work the firewall must generate a temporary cert with the name of the target server and sign it with your self generated CA cert.
And the client must accept your firewall's CA cert to verify that "faked" server cert.
Regarding the BOINC client: the CA cert must be added to ca-bundle.crt.
Reading the comments at the beginning of ca-bundle.crt should explain how to do this.

If you can't configure your client to accept the CA cert you have to configure the firewall to forward the connection without decryption like any other router/proxy would do it.
ID: 107633 · Report as offensive
Les Bayliss
Help desk expert

Send message
Joined: 25 Nov 05
Posts: 1654
Australia
Message 107636 - Posted: 29 Mar 2022, 21:22:49 UTC - in response to Message 107632.  

SonicWALL Firewall DPI-SSL
Yes, I've never heard of that fire wall before.
ID: 107636 · Report as offensive
flarbnatz

Send message
Joined: 25 Mar 22
Posts: 6
Message 107660 - Posted: 30 Mar 2022, 20:36:52 UTC
Last modified: 30 Mar 2022, 21:12:58 UTC

"the CA cert must be added to ca-bundle.crt"
I did that. That makes BOINC believe that the "man in the middle" is the endpoint and allow the connection. (That's how I got this far.)
The problem is that after connection, the firewall tries to use a different security protocol. The BOINC client (or server) sees this and rejects the connection. (This firewall behavior MIGHT break some websites too. Coincidentally, some websites don't work for me when they go through the firewall - "secure connection failed".)

I forgot to mention, besides the logged errors, BOINC puts up this Notice:
"Notice from BOINC
BOINC can't access Internet - check network connection or proxy configuration.
2022-03-29 21:40:10"

The firewall is an appliance, SonicWall NSa 2700. "Firmware updated last week."

I found another work-around, still good for me only:
Instead of forcing ALL traffic into the unfiltered wireless LAN connection (by temporarily disabling the filtered wired LAN connection), I can divert [only] BOINC traffic into the unfiltered wireless connection by typing this at an administrative command prompt:
route add 130.75.116.42 mask 255.255.255.255 10.1.55.1 metric 2 if 23

That should work until reboot.

I copied the parameters from various places:
130.75.116.42 mask 255.255.255.255 : only divert 130.75.116.40 (einsteinathome.org). (copied from BOINC Manager's Event Log.)
10.1.55.1 : the gateway address for the wireless router. (copied from ipconfig output)
metric 2 : (any number lower than the metrics displayed by route print before)
if 23 : number of the wireless adapter (copied from route print output)
(I think I've seen the interface number change sometimes. Run route print each time to be sure.)
ID: 107660 · Report as offensive
flarbnatz

Send message
Joined: 25 Mar 22
Posts: 6
Message 107662 - Posted: 30 Mar 2022, 21:54:09 UTC

If it fails to connect, it tries other addresses. (Close and restart BOINC might rest the list.)
These commands divert more main and alternate addresses used by Einstein@Home to the UNfiltered router:
route add 130.75.116.0 mask 255.255.255.0 10.1.55.1 metric 4
route add 129.89.61.0 mask 255.255.255.0 10.1.55.1 metric 4
route add 138.230.171.0 mask 255.255.255.0 10.1.55.1 metric 4


BOINC client displays the message "BOINC can't access Internet" after doing a "general connectivity" check.
After the client discards the connection to Einstein (with "ALPN, server did not agree to a protocol"), it tries to access https://www.google.com/ :
2022-03-30 17:30:26 | | [http] [ID#0] Info: Connected to www.google.com (172.253.122.99) port 443 (#4)
When connected through the firewall, it rejects that connection with the same error:
2022-03-30 17:30:26 | | [http] [ID#0] Info: SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384
2022-03-30 17:30:26 | | [http] [ID#0] Info: ALPN, server did not agree to a protocol
...
2022-03-30 17:30:26 | | [http] HTTP error: Failure when receiving data from the peer
2022-03-30 17:30:26 | | BOINC can't access Internet - check network connection or proxy configuration.
I can browse https://www.google.com/ through the firewall, but BOINC discards this connection just like it does the connection to Einstein server.

It still looks like a patch is needed for BOINC client, BOINC server, and/or SonicWall's firewall appliance.
ID: 107662 · Report as offensive
robsmith
Volunteer tester
Help desk expert

Send message
Joined: 25 May 09
Posts: 1296
United Kingdom
Message 107666 - Posted: 31 Mar 2022, 8:10:13 UTC - in response to Message 107662.  

Or one might consider setting up the firewall "white list" to allow all BOINC's traffic through unimpeded.

(Of course if this is a corporate situation have you obtained the appropriate permission from that organisation)
ID: 107666 · Report as offensive
computezrmle

Send message
Joined: 2 Feb 22
Posts: 81
Germany
Message 107667 - Posted: 31 Mar 2022, 8:16:40 UTC - in response to Message 107662.  

It still looks like a patch is needed for BOINC client, BOINC server ...

I don't have a SonicWall but I have a Squid proxy that can also be configured to intercept/inspect TLS connections using a self generated CA certificate.

After I added that CA cert to Squid and a browser's CA store my browser accepts encrypted connections signed by Squid.
Squid's logfiles show that it decrypts packets from the browser/server(s), checks if the content is already cached and sends the replies encrypted to the browser.
This is exactly the expected behaviour.


To test the BOINC client I added the same CA cert to ca-bundle.crt as explained in an earlier post.
I then tested encrypted connections against Rosetta and LHC-dev forcing the connections through Squid.
This also worked as expected.


Conclusion:
Neither BOINC server nor BOINC cliend need a patch.
ID: 107667 · Report as offensive
flarbnatz

Send message
Joined: 25 Mar 22
Posts: 6
Message 108222 - Posted: 24 May 2022, 20:16:04 UTC - in response to Message 107667.  

"Conclusion:"? Really??
Wrong in multiple ways. Profoundly unhelpful.

•Squid proxy is not SonicWall. It might do something different.
•Rosetta and LHC-dev are not Einstein@home. They might not be as strict.
(You have tested nothing relevant.)

•The only way to know that your Squid proxy actually intercepts your outbound TLS connections is to verify that your browsers and BOINC cannot connect via TLS until you show them the needed certificate (the certificate that tells them your Squid proxy is authoritative for every domain).
(You might not have actually tested Squid's transparent TLS proxying.)

To this day:
When I go through SonicWall:
2022-05-24 15:03:03 | Einstein@Home | [http] [ID#1] Info: SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
2022-05-24 15:03:03 | Einstein@Home | [http] [ID#1] Info: ALPN, server did not agree to a protocol

When I route some IP addresses through the wireless LAN, bypassing SonicWall (by disabling the wired connection or by using route add):
2022-05-24 15:08:46 | Einstein@Home | [http] [ID#1] Info: SSL connection using TLSv1.2 / DHE-RSA-AES256-GCM-SHA384
2022-05-24 15:08:46 | Einstein@Home | [http] [ID#1] Info: ALPN, server accepted to use http/1.1

It looks like SonicWall is not a perfectly transparent TLS proxy. SonicWall changes a security protocol on the way through, and Einstein@Home's BOINC server (and a few rare other servers) doesn't like it.

•This problem goes away if someone configures or patches SonicWall to pass the right security protocol through. (IF it is possible for SonicWall to determine.) (IF it is acceptable for SonicWall to not change the security protocol.)

•This problem goes away if someone configures or patches Einstein@Home's BOINC server to accept the other security protocol, the one that comes in when the connection comes through SonicWall's TLS proxy.

•(Patching BOINC client seems less likely to fix this problem. BOINC client would have to alter its request such that the request that passes through SonicWall is accepted by BOINC server.)
ID: 108222 · Report as offensive
flarbnatz

Send message
Joined: 25 Mar 22
Posts: 6
Message 108298 - Posted: 1 Jun 2022, 18:15:46 UTC - in response to Message 108222.  

Einstein@home does not work through the SonicWall "transparent TLS proxy":
2022-06-01 13:30:16 | Einstein@Home | [http] [ID#1] Info: Connected to scheduler.einsteinathome.org (130.75.116.40) port 443 (#4)
...
2022-06-01 13:30:17 | Einstein@Home | [http] [ID#1] Info: SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
2022-06-01 13:30:17 | Einstein@Home | [http] [ID#1] Info: ALPN, server did not agree to a protocol

even as Rosetta@home works through the same "transparent TLS proxy":
2022-06-01 13:30:25 | Rosetta@home | [http] [ID#1] Info: Connected to bwsrv1.bakerlab.org (128.95.160.156) port 443 (#5)
...
2022-06-01 13:30:25 | Rosetta@home | [http] [ID#1] Info: SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
2022-06-01 13:30:25 | Rosetta@home | [http] [ID#1] Info: ALPN, server accepted to use http/1.1

Only after I bypass the TLS proxy (by adding wireless NIC and using "route add" to route BOINC requests through it), Einstein@home works:
2022-06-01 13:35:53 | Einstein@Home | [http] [ID#1] Info: Connected to scheduler.einsteinathome.org (130.75.116.40) port 443 (#7)
...
2022-06-01 13:35:54 | Einstein@Home | [http] [ID#1] Info: SSL connection using TLSv1.2 / DHE-RSA-AES256-GCM-SHA384
2022-06-01 13:35:54 | Einstein@Home | [http] [ID#1] Info: ALPN, server accepted to use http/1.1

So the company's "transparent" TLS proxy is not completely transparent. Either: 1) The proxy modifies a request on its way through (making an alternative request that the server doesn't like), or 2) The proxy modifies a reply (causing the client take make a request that the server does not like).

•Making the TLS proxy more perfectly transparent (if it is possible) would (by definition) eliminate this problem (and surely others). (A patch that fixes "only" this problem might break other software or reduce security.)

•Making Einstein@home's server tolerate the protocol change would eliminate this problem.

•There probably is no patch for the BOINC client that would eliminate this problem.
ID: 108298 · Report as offensive
computezrmle

Send message
Joined: 2 Feb 22
Posts: 81
Germany
Message 108299 - Posted: 1 Jun 2022, 19:18:05 UTC - in response to Message 108298.  

Einstein works fine even with (transparent) TLS connections through a Squid proxy.
So do all BOINC projects my computers are attached to.

Since TLS is the same for all firewalls just do it right and add the CA cert to your firewall (or Squid) and to the ca-bundle.crt file where the BOINC client can find it. There's no need to change BOINC, neither the client side nor the server side.

See:
https://wiki.squid-cache.org/Features/SslPeekAndSplice


Mi 01 Jun 2022 20:37:54 CEST | Einstein@Home | [http] [ID#1] Info:  Establish HTTP proxy tunnel to scheduler.einsteinathome.org:443
Mi 01 Jun 2022 20:37:54 CEST | Einstein@Home | [http] [ID#1] Sent header to server: CONNECT scheduler.einsteinathome.org:443 HTTP/1.1
Mi 01 Jun 2022 20:37:54 CEST | Einstein@Home | [http] [ID#1] Sent header to server: Host: scheduler.einsteinathome.org:443
Mi 01 Jun 2022 20:37:54 CEST | Einstein@Home | [http] [ID#1] Sent header to server: User-Agent: BOINC client (x86_64-suse-linux-gnu 7.19.0)
Mi 01 Jun 2022 20:37:54 CEST | Einstein@Home | [http] [ID#1] Sent header to server: Proxy-Connection: Keep-Alive

Mi 01 Jun 2022 20:37:54 CEST |  | [http] [ID#0] Received header from server: HTTP/1.1 200 Connection established
Mi 01 Jun 2022 20:37:54 CEST |  | [http] [ID#0] Received header from server:
Mi 01 Jun 2022 20:37:54 CEST |  | [http] [ID#0] Info:  Proxy replied 200 to CONNECT request
Mi 01 Jun 2022 20:37:54 CEST |  | [http] [ID#0] Info:  CONNECT phase completed
Mi 01 Jun 2022 20:37:54 CEST |  | [http] [ID#0] Info:  ALPN: offers h2
Mi 01 Jun 2022 20:37:54 CEST |  | [http] [ID#0] Info:  ALPN: offers http/1.1
Mi 01 Jun 2022 20:37:54 CEST |  | [http] [ID#0] Info:   CAfile: ca-bundle.crt
Mi 01 Jun 2022 20:37:54 CEST |  | [http] [ID#0] Info:   CApath: none
Mi 01 Jun 2022 20:37:54 CEST |  | [http] [ID#0] Info:  TLSv1.3 (OUT), TLS handshake, Client hello (1):
Mi 01 Jun 2022 20:37:54 CEST | Einstein@Home | [http] [ID#1] Received header from server: HTTP/1.1 200 Connection established
Mi 01 Jun 2022 20:37:54 CEST | Einstein@Home | [http] [ID#1] Received header from server:
Mi 01 Jun 2022 20:37:54 CEST | Einstein@Home | [http] [ID#1] Info:  Proxy replied 200 to CONNECT request
Mi 01 Jun 2022 20:37:54 CEST | Einstein@Home | [http] [ID#1] Info:  CONNECT phase completed
Mi 01 Jun 2022 20:37:54 CEST | Einstein@Home | [http] [ID#1] Info:  ALPN: offers h2
.
.
.
Mi 01 Jun 2022 20:37:54 CEST | Einstein@Home | [http] [ID#1] Info:   CAfile: ca-bundle.crt
Mi 01 Jun 2022 20:37:54 CEST | Einstein@Home | [http] [ID#1] Info:   CApath: none
Mi 01 Jun 2022 20:37:54 CEST | Einstein@Home | [http] [ID#1] Info:  TLSv1.3 (OUT), TLS handshake, Client hello (1):
Mi 01 Jun 2022 20:37:55 CEST | Einstein@Home | [http] [ID#1] Info:  TLSv1.3 (IN), TLS handshake, Server hello (2):
Mi 01 Jun 2022 20:37:55 CEST | Einstein@Home | [http] [ID#1] Info:  TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
Mi 01 Jun 2022 20:37:55 CEST | Einstein@Home | [http] [ID#1] Info:  TLSv1.3 (IN), TLS handshake, Certificate (11):
Mi 01 Jun 2022 20:37:55 CEST | Einstein@Home | [http] [ID#1] Info:  TLSv1.3 (IN), TLS handshake, CERT verify (15):
Mi 01 Jun 2022 20:37:55 CEST | Einstein@Home | [http] [ID#1] Info:  TLSv1.3 (IN), TLS handshake, Finished (20):
Mi 01 Jun 2022 20:37:55 CEST | Einstein@Home | [http] [ID#1] Info:  TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
Mi 01 Jun 2022 20:37:55 CEST | Einstein@Home | [http] [ID#1] Info:  TLSv1.3 (OUT), TLS handshake, Finished (20):
Mi 01 Jun 2022 20:37:55 CEST | Einstein@Home | [http] [ID#1] Info:  SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
Mi 01 Jun 2022 20:37:55 CEST | Einstein@Home | [http] [ID#1] Info:  ALPN: server did not agree on a protocol. Uses default.
Mi 01 Jun 2022 20:37:55 CEST | Einstein@Home | [http] [ID#1] Info:  Server certificate:
.
.
.
Mi 01 Jun 2022 20:37:55 CEST | Einstein@Home | [http] [ID#1] Info:   subjectAltName: host "scheduler.einsteinathome.org" matched cert's "scheduler.einsteinathome.org"
.
.
.
Mi 01 Jun 2022 20:37:55 CEST | Einstein@Home | [http] [ID#1] Info:   SSL certificate verify ok.
ID: 108299 · Report as offensive

Message boards : Questions and problems : Download, upload, and Notices don't work on wired LAN; work on wireless guest LAN

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.