So been playing with HTTPS Inspection on Squid and CP for URL filtering lately and am starting to understand why people avoid it. This is not a CP problem, but an industry problem. Sort of like when IPSEC came out, your IPSEC never talked to my IPSEC. Only HTTPS Inspection has been around since I had hair and I’m not sure we are any closer to nirvana then we were before.
So basically – HTTPS Inspection is where the proxy is a Man-In-The-Middle between a client and a server. The proxy can then decrypt and inspect all data in the tunnel. Google will give tons of details so I won’t bore you. The key here is the certificates. How does the client get WELLSFARGO.COM server certificate if the proxy is in the middle and acting as the client? Well, the proxy generates a fake WELLSFARGO.COM certificate and sends it to the client. Here is a good diagram and slide show of how the fake cert is created and sent to the client. You might also want to research HTTPS CONNECT where the client connects to the proxy server for the HTTPS tunnel.
All sounds easy-peasy huh??? Not so quick…Before embarking on this journey I tried to google what are all the problems of forcing clients to install a new cert and proxy through a HTTPS Inspecting gateway. Only got bits and pieces. So here is my list of the fun times I am having doing HTTPS Inspection:
- How do you work with humans that don’t even know what a cert is? Much less a proxy? How many times do you get the same phone call “What is a cert? Proxy what?”. Yeah deployment was automated via AD and magic just happened….right. Problem is there are too many pieces and unique components..proxies, certs, AD, Linux, OpenSSL, JavaCertStores, pinned certs, that automation will only get 80% and the others are YOUR phone call.
- Client desktops are locked down. Have fun installing those certs or fixing problems for the client in Zambia speaking Bemba on a locked down desktop.
- Not all servers use Windows so installing certs via command line on TinyLinux version .00000003 will be a great time.
- Some applications use Java cert store or OpenSSL cert store or Bob and Jimbo’s cert store version 0.45. So make sure you install the right cert into the right cert stores.
- Some clients apps just will not use fake signed certs signed by the proxy server. They are pinned and will only use the original cert and not one generated by the proxy server.
- BS you say. My ORG has AD or other friggin magic and we already distributed an ORG public cert to all our clients. That’s all you have to do is setup the proxy to sign certs as the ORG CA and wham-bam thank you mam its done. OK, so that means giving the ORG private key to the proxy server. Let me say that again….the ORG PRIVATE key. How do you control use of that private key? How do you know the proxy admin is not deep into hookers and blow and accidentally sends the private key to all his Russian friends? And malware these days are looking for private keys like crazy…is the proxy server secured???
- No problem you say, I’ll just buy some fancy FIPS 140-2 certified $1billion Hardware Security Module HSM with 126 pretty blinking lights and hook it up and push the GAZUNGA easy button to store all the private keys. HAHAHAHAH. Oh you make me laugh geek boy. Yet more technology on technology on technology. Have fun with that when it breaks. Interoperability, supportability, debugging, etc.
- Speed. Generating fake certs and decrypting SSL kills CPUs. No problem you say, my vendor has XL5Billion hardware accelerator developed by some Nigerian guy for the KGB. HAHAHAHAHAH. You so funny. See above.
- After your vendor wines and dines you with hookers and blow and single malt, in your drunken stupor ask them to allow you to log into their support site and type in HTTPS inspection or SSL decryption.
So my cost/benefit analysis is pretty negative right now as I work through all these HTTPS issues. I’ll keep you updated.
DreezSecurityBlog 