Re: HTTPS redirects to HTTP for monitoring

[Larry Sheldon <larrysheldon () cox net>]

On 1/18/2015 12:41, Teleric Team wrote:
> 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

I have been "off-line" for several days and I have to say that this is 
one of the most depressing thread I have seen _anywhere_ in a while and 
reading it on NANOG multiplies the depression.

But I am heartened to see this response (and one or two others so 
far)--there is still hope.

For what it is worth (and this reflects at most two people's thinking 
here), I go to some considerable effort to identify handlers-of-my-data 
that betray my trust and on the merest hint I take considerable effort 
the avoid the betrayer and anybody who relies on the betrayer.

Yes, I know that there is no way that I can stop everybody, but I try 
very hard.



--
The unique Characteristics of System Administrators:

The fact that they are infallible; and,

The fact that they learn from their mistakes.


Quis custodiet ipsos custodes