RE: HTTPS redirects to HTTP for monitoring

[Teleric Team <teleric-lists () outlook com>]

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: shortdudey123 () 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