Yeah, zscaler is terrible MDM corporate crapware that mitms your SSL connections for compliance reasons. It does so by setting up a tun interface and mutilating your routing table.
I think it is safe to assume that your IT department rolled that out to you (because why else would you ever touch this with a 10-foot pole?). Theoretically they should have rolled out everything such that this works out of the box.
Practically speaking, zscaler breaks a lot of stuff. As a fellow sufferer:
If you can get root on your machine, kill the process. Take no prisoners, do e.g. on macos launchctl unload /Library/LaunchAgents/com.zscaler.tray.plist && sudo launchctl unload /Library/LaunchDaemons/com.zscaler.service.plist && sudo launchctl unload Library/LaunchDaemons/com.zscaler.tunnel.plist. Don’t forget to write a good reason for that into the audit log.
zscaler is necessarily not intercepting traffic in your local network (look at the routing table). Set up a SOCKS / ssh proxy on a machine in the same local network. This is the protip if zscaler decides to block the zscaler login and therefore all internet access. (lol, right?)
in most configs, zscaler doesn’t intercept ssh traffic. Use socks via ssh proxies.
Complain to your IT department. Continue complaining, telling them that this blocks your work. You NEED ipv6 unblocked, yadda yadda. You might get an exemption, or create enough workload that they end this policy.
IT policy might have escape hatches like “oh, while you’re on the corporate VPN you don’t need zscaler active”. These are a godsent – just make sure you’re on the VPN.
Look for a new job. I’m only half joking, a quarter crying, and a quarter looking for a place that respects my dignity enough not to MITM my SSL connections.
That being said, no idea about juliaup / zscaler specific interactions.
@foobar_lv2 Thankyou.
Setting up a SOCKS proxy is a good tip.
Looks like another fix is to download the Zscaler certificate and set WSL to trust it. This did not work for me, though I did not try too hard. I will give that method another try.
Theoretically your it department should have done that with the rollout / some kind of group policy thing.
Practically speaking, all kinds of software use all kinds configs with respect to root certificate store; some even have hardcoded certificate pinning.
And I emphasize with the impulse: If you’re juliaup, there is no reason to give honest achmed the power to pown all your users (implicitly: The jurisdiction where Honest Achmed resides also gets full access to MITM the software install. Access to a trusted root certificate can also come out of the barrel of a gun). Google used to be pretty hot on certificate pinning – super annoying if you want to MITM your own connections for security research.
So in practice zscaler is a support horror show. Do give a little push-back for the sake of all of us (if you’re in academia, you can give a lot more push-back than as a corporate drone; if you’re in natsec then you’re probably even more limited).
A quick search in the juliaup repo could not find any certificate pinning; but I’m not sure how the trust root set in juliaup is ultimately derived.
I think your (our ) situation is similar as the linked issue (making juliaup work in iran); what we need is a command-line argument (or environment variable) that specifies a socks proxy and overrides system settings. Alas, there is no documentation regarding socks in the linked issue + pr.
Maybe you should open an issue. cc @davidanthoff because you added socks support to juliaup.