Honestly, don't do this. Neither option.You can still have some control over SSL access with ordinary domain based filtering getting proxied, via CONNECT method or sorta. You don't need filtering capabilities over full POST/DELETE/UPDATE HTTP methods, and if you believe you need it, you just have a bigger problem that MITMing won't solve at all. It's just like believing a data leak prevention system will really prevent data leaking. Or believing a Palo Alto NGFW policy that allows gmail but won't allow gmail attachments of mime-type XYZ will be effective. If someone is really interested, there are clever ways to bypass it, more clever than your options to filter it. Forcing http fallback for https communication is not only wrong, it's a general regression regarding security policy and best practices. You are risking privacy, or "confidentiality" and "integrity" if you prefer 27002 buzzwords. Not to mention the "availability" breakage since many applications won't just work (aka, you will break 'em). On the other hand, adding a MITM strategy, be using Squid, Fortinet, pfSense, Palo Alto, Sonicwall, EndianFW, is just worse. You are adding you own an attack vector on your company. You are doing the difficult part of the attack for the attacker, installing a custom root cert in your client stations. So you will have much more to worry about, from "who has access", "how vulnerable" and "how to deploy" until "what is deployed", "what is revogated", "how's renegotiation, CRIME, etc like". You will have more problem root and vectors to care about. Not only how safe is the remote destination SSL server, but how save is the client to local proxy doing MITM and local proxy doing MITM to remote SSL server. You are attacking, cracking and breaking your own network. If someone raise your squid log levels, you will have to respond for that, and respond for what was copied before you noticed it. Same goes for Fortinet, Websense, Sonicwall, or whatever open source or proprietary solution you pick. You are still breaking "confidentiality" and "integrity" but now without allowing for ordinary users or applications to notice it. Back to the beginning: you can still do some level of HTTPS filtering and per domain controlling without having to fully MITM and inspect the payload. Don't add OWASP Top 10 / SANS Top 25 facilitation vectors to your company. Do the usual limited but still "safe" (oh no, not counting that unknown openssl zero-day NSA and people on IRC know about but industry stills ignore, or any other conspirator theory/fact), filtering... do just whatever can be filtered without MITMing https and HTTP redirection. And don't be seduced by the possibility of filtering more than that. It's a trap, for both your users and your responsibilities as organization regarding users' privacy not to mention possible ACTs and other laws on your state/contry.
> Date: Sun, 18 Jan 2015 04:29:56 -0800 > Subject: HTTPS redirects to HTTP for monitoring > From: shortdudey...@gmail.com > To: nanog@nanog.org > > Hi Everyone, > > I wanted to see what opinions and thoughts were out there. What software, > appliances, or services are being used to monitor web traffic for > "inappropriate" content on the SSL side of things? personal use? > enterprise enterprise? > > It looks like Websense might do decryption ( > http://community.websense.com/forums/t/3146.aspx) while Covenant Eyes does > some sort of session hijack to redirect to non-ssl (atleast for Google) ( > https://twitter.com/CovenantEyes/status/451382865914105856). > > Thoughts on having a product that decrypts SSL traffic internally vs one > that doesn't allow SSL to start with? > > -Grant
