Great detective work! I think this explains the all the issues that you have been experiencing.
It seems that ZScaler implements a man-in-the-middle attack on all external network communications. According this blog post ZScaler does not generate generally trustable certificates, just some temporary throwaway ones. The ZScaler agent running on the user’s computer receives these temporary certificates and regularly replaces them on the system.
I’m very surprised that hospitals go this far and doubt that this would be effective (if someone wants to hide something it is always possible to add yet another layer of encryption), while it surely introduces additional complexity and therefore extra cost and more vulnerabilities.
The issue may be due to the Slicer application not trusting the unknown ZScaler certificate but the man-in-the-middle attack might also interfere with the communication between the frontend and backend servers. Adding new certificates in Slicer application should not be hard, so if that is sufficient then we shoul definitely look into it. Adding exceptions or special certificates to the servers is not an option.
Based on these, comments on potential next steps:
explore turning off ssl verification from the Slicer side of the connection so that Slicer does not cancel the download because it doesn’t recognize the zscaler certificate
Turning off SSL verification would be quite risky, as man-in-the-middle attacks could allow malicious actors to get manipulated packages installed on user’s computers.
explore adding the zscaler certificate to Slicer’s set of trusted certificates
It would be interesting to try and see if adding the current ZScaler certificate to Slicer’s .crt file fixes extension installation using the “Manage” tag using bookmarks (in this case Slicer directly communnicates with the extension server backend) and/or installation by using the “Install” tab (in this case the extensions server frontend is involved as well).
explore having Slicer get the set of trusted certificates from the OS (or something like that) so that it will trust the zscaler certificate the same way the browser does
If the previous experiment is successful then we should explore this. Accessing the certificate store is depending on the operating system, but Qt or Python may provide some cross-platform API.
@jcfr Do you know why Slicer brings its own .crt file (instead of trying to get the certificates from the operating system)?
explore pushing to have the zscaler certificate added to the outside trusted repository that Slicer builds its list of trusted certificates from (looks like maybe mozilla?).
Since these are temporary certificates, these cannot be added to any repository (by the time they were added they could be already replaced).
I’ve found many links that complains about ZScaler breaking TLS in various applications and many solutions. A few useful links:
- Adding Custom Certificate to an Application Specific Trust Store | Zscaler
- https://community.zscaler.com/zenith/s/question/0D54u00009jZpG7CAK/installing-tls-ssl-root-certificates-to-nonstandard-environments
- Using non-standard certificates — conda 23.11.1.dev66 documentation
- ssl - Installing Zscaler Certificate to Anaconda3 - Stack Overflow