[177418] in North American Network Operators' Group
RE: HTTPS redirects to HTTP for monitoring
daemon@ATHENA.MIT.EDU (Teleric Team)
Sun Jan 18 13:41:30 2015
X-Original-To: nanog@nanog.org
From: Teleric Team <teleric-lists@outlook.com>
To: Grant Ridder <shortdudey123@gmail.com>, "nanog@nanog.org" <nanog@nanog.org>
Date: Sun, 18 Jan 2015 13:41:22 -0500
In-Reply-To: <CAPiURgX9jGFQMvVcW2ON1gnUkG1yEF2=n6AqfS9U6HjJu_vWdA@mail.gmail.com>
Errors-To: nanog-bounces@nanog.org
Honestly=2C don't do this. Neither option.You can still have some control o=
ver SSL access with ordinary domain based filtering getting proxied=2C via =
CONNECT method or sorta. You don't need filtering capabilities over full PO=
ST/DELETE/UPDATE HTTP methods=2C and if you believe you need it=2C you just=
have a bigger problem that MITMing won't solve at all. It's just like beli=
eving a data leak prevention system will really prevent data leaking.
Or believing a Palo Alto NGFW policy that allows gmail but won't allow gmai=
l attachments of mime-type XYZ will be effective. If someone is really inte=
rested=2C there are clever ways to bypass it=2C more clever than your optio=
ns to filter it.
Forcing http fallback for https communication is not only wrong=2C it's a g=
eneral regression regarding security policy and best practices. You are ris=
king privacy=2C or "confidentiality" and "integrity" if you prefer 27002 bu=
zzwords. Not to mention the "availability" breakage since many applications=
won't just work (aka=2C you will break 'em).
On the other hand=2C adding a MITM strategy=2C be using Squid=2C Fortinet=
=2C pfSense=2C Palo Alto=2C Sonicwall=2C EndianFW=2C is just worse. You are=
adding you own an attack vector on your company. You are doing the difficu=
lt part of the attack for the attacker=2C installing a custom root cert in =
your client stations. So you will have much more to worry about=2C from "wh=
o has access"=2C "how vulnerable" and "how to deploy" until "what is deploy=
ed"=2C "what is revogated"=2C "how's renegotiation=2C CRIME=2C etc like". Y=
ou will have more problem root and vectors to care about. Not only how safe=
is the remote destination SSL server=2C but how save is the client to loca=
l proxy doing MITM and local proxy doing MITM to remote SSL server.=20
You are attacking=2C cracking and breaking your own network. If someone rai=
se your squid log levels=2C you will have to respond for that=2C and respon=
d for what was copied before you noticed it. Same goes for Fortinet=2C Webs=
ense=2C Sonicwall=2C or whatever open source or proprietary solution you pi=
ck. You are still breaking "confidentiality" and "integrity" but now withou=
t allowing for ordinary users or applications to notice it.
Back to the beginning: you can still do some level of HTTPS filtering and p=
er 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=2C not counting that unknown =
openssl zero-day NSA and people on IRC know about but industry stills ignor=
e=2C or any other conspirator theory/fact)=2C filtering... do just whatever=
can be filtered without MITMing https and HTTP redirection. And don't be s=
educed by the possibility of filtering more than that. It's a trap=2C for b=
oth your users and your responsibilities as organization regarding users' p=
rivacy not to mention possible ACTs and other laws on your state/contry.
> Date: Sun=2C 18 Jan 2015 04:29:56 -0800
> Subject: HTTPS redirects to HTTP for monitoring
> From: shortdudey123@gmail.com
> To: nanog@nanog.org
>=20
> Hi Everyone=2C
>=20
> I wanted to see what opinions and thoughts were out there. What software=
=2C
> appliances=2C or services are being used to monitor web traffic for
> "inappropriate" content on the SSL side of things? personal use?
> enterprise enterprise?
>=20
> It looks like Websense might do decryption (
> http://community.websense.com/forums/t/3146.aspx) while Covenant Eyes doe=
s
> some sort of session hijack to redirect to non-ssl (atleast for Google) (
> https://twitter.com/CovenantEyes/status/451382865914105856).
>=20
> Thoughts on having a product that decrypts SSL traffic internally vs one
> that doesn't allow SSL to start with?
>=20
> -Grant
=
