When in the course of IT events it becomes necessary to inspect all traffic that hits your user’s PCs, there is but one thing you can do in 2015: get a proxy server or service, deploy a certificate to your trusted root store, and direct all traffic through the proxy.
Why would you do what amounts to a Man in the Middle Attack on your users as a responsible & honest IT Pro? Why Superfish your users? ((
IT Shakespeare put it like this:
To proxy SSL or not to proxy, that is the question
whether ’tis nobler in the mind to suffer
the breaches and theft of outrageous malware
or to take Arms against a sea of digital foes
and by opposing, only mitigate the threat.
To protect via decrypt ; Aye there’s the rub
Thus Conscience does make Cowards of us all
and lose the name of Action))
Numbers are hard to pin down, ((I am not a security expert, and though I checked sources I respect like the Norse IP Viking security blog, Malwarebytes Unpacked blog, SearchSecurity.com etc, I found very few sources that a percentage on how much malware is encrypted and thus difficult to detect. This NSS Labs report from summer 2013 comparing Next Gen Firewall SSL Decryption performance, for instance, says that “the average proportion of SSL traffic within a typical enterprise is 25-35%” and that only ~1% of malware is encrypted. A GWU security researcher named Andre DiMino has a series of good blog posts on the topic, showing what SSL-encrypted malware looks like in WireShark. Team CYMURU’s TotalHash database is probably the most comprehensive open DB of malware samples, but I don’t feel qualified to search it frankly)) but it seems an increasing amount of virulent & potent malware is arriving at your edge encrypted. Because those packets are encrypted, you essentially can’t scan the contents. All you get is source/destination IP address, some other IP header information, and that’s about it.
No bueno.
One option, really your only option at that point, is to crack open those packets and inspect them. Here’s how.
1.You need a proxy server or service that does security inspection.
I’ve seen ZScaler used at several firms. ZScaler dubs itself the premiere cloud-based, SaaS proxy service, and it’s quite a nifty service.
For a fee per user, ZScaler will proxy most if not all of your internet traffic from several datacenters around the globe, sort of like how CloudFlare protects your websites.
The service scans all that http and https traffic, filters out the bad and malicious stuff, blocks access to sites you tell it to, and sends inspected http/https content to your users, wherever they are, on-prem or connected to the unsecured Starbucks access point.
2. You need to bundle those proxy settings up into a .pac file
Getting the service is one thing, you still need to direct your users and computers through it. The easiest way is via Group Policy & what’s called a .pac file.
A .pac file is a settings file generated by ZScaler that contains your preferences, settings, and lists of sites you’d prefer bypass the filter. It looks like this:
function FindProxyForURL(url, host)
{
var resolved_host_ip = dnsResolve(host);
if (!isResolvable("gateway.zscaler.net"))
return "DIRECT";
if (url.substring(0, 4) == "ftp:")
return "DIRECT";
// If the requested website is hosted within the internal network, send direct
if (isPlainHostName(host) ||
isInNet(resolved_host_ip, "1.1.1.1", "255.0.0.0") ||
return "DIRECT";
// If the requested website is SSL and associated with Microsoft O365, send direct
return "DIRECT";
3. Deploy the .pac file via Group Policy to Users
Next, you need to pick your favorite deployment tool to push the .pac file out and set Windows via IE to proxy through ZScaler. We’ll use Group Policy because it’s fast and easy.
Under User Configuration > Policies > Windows Settings > Internet Explorer Maintenance > Connection / Automatic Browser Configuration, select Enable.
Then point the Auto-proxy URL to your Zscaler .pac file URL. It looks like this:
Keep Group Policy open, because we’re not done quite yet.
4. Download the ZScaler Root CA certificates
You’ll find the certs in the administration control screen of ZScaler. There are two:
- ZScaler Root Certificate -2048.crt
- ZScalerRoot Certificate -2048-SHA256.crt
The two certificates are scoped similarly, the only difference seems to be SHA1 or SHA256 encoding.
Double-click the certificate you prefer to use, and notice that Windows alerts you to the fact that it’s not trusted. Good on ya Microsoft, you’re right.
To validate this setup, you’ll probably want to test before you deploy. So select Install Certificate, select your Computer (not user) and navigate to the Trusted Root CA Store:
or you can do it via powershell:
PS C:daisettalabs.netImport-Certificate -FilePath C:usersjeffDownloadsZscalerRootCertsZscalerRootCertificate-2048-SHA256.crt -CertStoreLocation Cert:LocalMachineRoot
Directory: Microsoft.PowerShell.SecurityCertificate::LocalMachineRoot
Thumbprint Subject
---------- -------
thumbprint E=support@company.com, CN=Zed, OU=Zed Inc, O=Zed's Head, L=The CPT, S=CaliforniaLove, C=USA 4. Verify that the .pac file is in use
Now that you’ve installed the .pac file and the certificate, ensure that IE (and thus Chrome, but not necessarily Firefox) have been set to proxy through Zscaler:
5. SSL Proxy Achievement Unlocked:
Go to Google or any SSL/TLS encrypted site and check the Certificate in your browser.
You should see something like this:
6. You can now deploy that same certificate via Group Policy to your Computers.
It’s trivial at this point to deploy the ZScaler certificates to end-user PCs via Group Policy. You’ll want to use Computer Preferences.
Once deployed, you’ll get comprehensive scanning, blocking and reporting on your users http/https use. You can of course exempt certain sites from being scanned ((Before you do this, make sure you get your Legal department or corporate controller’s sign-off on this. Your company needs to understand exactly what SSL Proxy means, and the Gordian Knot of encryption.
By making all SSL traffic visible to your proxy service, you may gain some ability to prevent potent malware attacks, but at the cost of your user’s privacy. When a user transacts business with their bank, their session will be secured, but only between the ZScaler cloud and the bank’s webserver. The same is true of Facebook or personal email sites.
By doing this, you’re placing an immense amount of trust in the proxy server/service of your choice. You’re trusting that they know what they’re doing with Certificates, that they didn’t use a weak password. You’re trusting that they have their act together, and you’re doing this on behalf of all your users who trust you. This is not to be taken lightly, so run it up the legal/HR flagpole before you do this. ))
Wilson.tech 