It’s surprising the forum posts do not appear to mention a developer’s point of view. Scripted downloads in “testing” or “continuous integration” of “software” fail due to 2 levels of interference by the enterprise-wide routing through Zscaler:
- Zscaler rewriting HTTPS. This may be worked around by adding the Zscaler Certificate Authority but causes loss of many hours to modify and maintain the scripts.
- Zscaler offering a 307 redirect to the “banned” message or to the “are you sure” dialog as a response to contentious decrypted requests. This requires a lot more effort to avoid or work around at a level of scripting often unavailable to mere mortal developers.
Zscaler as a product appears aiming at organizations full of personal machines or VPN users whose work involves browsing. The product appears extremely hostile to organizations of modern day turning their eye at quick prototyping and development. Zscaler’s meddling with automated downloads and other HTTP requests can be avoided by Zscaler’s product development who may consider the following useability fixes.
- Avoid HTTPS decryption and MitM rewrites for destination IP addresses and Server Name Indications found in an enterprise-wide white list. The white list can, by default, include a number of modern package repositories such as Microsoft Gallery, Maven Central and other Maven repositories, NodeJS Package Manager Registry, Docker Hub, Linux distributions etc. (The scenario of unintended downloads of malicious packages needs to be handled at a higher level involving setting up trusted build environments and human code reviews at each of the package repositories).
- The most developer-friendly approach would enable traffic inspection only through enterprise-enforced opt-in of the desktop browsers. For example, each enterprise-approved desktop browser could receive a policy update installing an open-source plugin (authored by Zscaler, I hope) that would accompany HTTPS requests with an unencrypted tag or a GUID indicating a request for Zscaler decryption and inspection. The plugin should tag only those HTTP requests that are initiated by the browser as document (frame) loads.
- The following option is the least effort for Zscaler product development but it is not so good for the developers at whom the product is thrown by their upper management. Decrypt HTTPS (requiring consumer developers carry the Zscaler CA) but inspect the decrypted contents and bring up the “are you sure” redirects or bans only when decrypted requests have User-Agent headers resembling known browsers.