Re: Inspecting encrypted traffic

[Angelo Rodriguez <Angelo.Rodriguez () SOFTWARE DELL COM>]

I would like to offer a vendor perspective.

Without SSL inspection, limited URL filtering can be done (using cert common name) but you cannot block keywords, 
perform complex filtering or inject block/splash pages. Likewise applications might show up as “https” or “SSL” so app 
visibility and control may be limited. Threats via IPS, malware and other vectors will also be hidden from the DPI 
engine and go right through (the way they do now on many legacy FW’s or those that are not inspecting SSL). Our own 
analysis from +1m active sensors (NGFW’s) shows encrypted traffic levels at nearly 60% and growing faster than http. In 
some places it will be lower/higher of course.

Think of all the common use sites/apps (anything Google or MS, most social media sites, CRM  and ERP, financials, 
medical, etc) that introduce threat vectors if they are not being inspected (via MitM or similar). Inspection is 
required to peform full URL, App control, IPS and malware prevention else, in effect you are only protecting ~50% of 
your traffic/users.

I can only speak for specific roducts, but you have to specifically capture and export or mirror unencrypted traffic to 
see PII data. It does not appear in logs nor do the products I’m familiar with have onboard storage of captures, data 
is only kept in volatile memory during inspection. I fully understand the concerns and it’s brought up regularly in my 
interaction with Hied customers across NOAM, but there are many deployments and growing very quickly (for SSL 
inspection) across both Hied and K-12 (and commercial, FED, G500 acounts).


Cheers,

Angelo J. Rodriguez, CISSP
Director, Sales Engineering
Dell | Network Security
mobile +1 512 297 1758; office +1 512 309 7006



From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of John 
LaPrad
Sent: Wednesday, January 20, 2016 9:22 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Inspecting encrypted traffic

Thanks Brian for your thoughtful comments. I agree, there are serious issues with decrypting 'secure' connections. This 
topic came up at our institution and I want to give it a thorough examination.  Encrypted traffic is increasing 
constantly. I did a URL analysis of our encrypted traffic to see where folks were going. It was somewhat similar to the 
non-encrypted traffic.

In order of connection count:

  *   browsing; educational, business, economy, news,
  *   streaming media
  *   phishing (blocked by url bad list)
  *   advertisments
  *   social media
  *   training
  *   games
  *   shopping
The traffic patterns are quite similar between encrypted and non-encrypted sessions (Netflix being one of the main 
differences). If the traffic is similar, the risks are also going to be similar. People have made a case for inspecting 
regular traffic (layer 7 firewalls are everywhere), couldn't the same case be made for encrypted traffic? For me, I see 
the same need to inspect it as regular traffic. Just because it's encrypted doesn't mean it's more secure from malware 
or bad intentions then un-encrypted traffic. There was a time when encryption was only used for financials, but that is 
no longer the case.

However, the reasons you mention; enduser trust, privacy, compliance are important. I'm not sure yet what we'll do, but 
I do see it coming though.

John

________________________________
From: "Brian Epstein" <bepstein () ias edu<mailto:bepstein () ias edu>>
To: "John LaPrad" <jrl () svsu edu<mailto:jrl () svsu edu>>, "The EDUCAUSE Security Constituent Group Listserv" 
<SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () LISTSERV EDUCAUSE EDU>>
Sent: Tuesday, January 19, 2016 5:30:15 PM
Subject: Re: [SECURITY] Inspecting encrypted traffic

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi John,

I believe you are speaking about a feature called SSL Bump or an
authorized man in the middle (MitM) proxy.

The only way I know to implement this is to install a trusted CA or
certificate on every client machine you have so that they "trust" your
man in the middle box.  Then, your box decrypts and re-encrypts all
traffic.  The client is tricked into thinking they are connecting to a
real server, while your MitM box is actually doing that leg of the
communication.

We don't do this for two reasons.  First, is your concern about
privacy issues.  As a user, I would be quite perturbed about having
someone sniffing what I thought was private traffic.  You will
probably have a few savvy users that will figure out what is going on
by looking at the certs and make a big stink about it.  It might not
be worth the negative press.

Secondly is the liability and compliance aspect that you mention.  If
you do this MitM service, you will now have clear text of credit card
information, banking passwords, and other PII.  Depending on how you
are collecting this data, you may have to worry about things like PCI
compliance, HIPAA, FERPA or other regulations that you didn't have to
worry about before.  You don't really get to choose to decrypt only
the viruses.

I would recommend steering clear of this avenue.  I believe Squid was
one of the first places that started offering this, and even their
documentation states:

"WARNING: HTTPS was designed to give users an expectation of privacy
and security. Decrypting HTTPS tunnels without user consent or
knowledge may violate ethical norms and may be illegal in your
jurisdiction. Squid decryption features described here and elsewhere
are designed for deployment with user consent or, at the very least,
in environments where decryption without consent is legal. These
features also illustrate why users should be careful with trusting
HTTPS connections and why the weakest link in the chain of HTTPS
protections is rather fragile. Decrypting HTTPS tunnels constitutes a
man-in-the-middle attack from the overall network security point of
view. Attack tools are an equivalent of an atomic bomb in real world:
Make sure you understand what you are doing and that your decision
makers have enough information to make wise choices."
- - http://wiki.squid-cache.org/Features/SslBump

Instead, we have focused on installing good anti-malware on the
machines we control, and put them into network segments separated from
the machines we don't control.  We are looking into network access
control (NAC) solutions and authenticated network devices using
802.1x.  True, we won't catch as much stuff as if we did the MitM
decrypt and scan method, but for us, our users' confidence and
satisfaction is more important.  Different rules for different
schools.  If I was a bank, my attitude may differ as well.

Good luck in your endeavors, look forward to hearing what you decide.

Thanks,
ep

On 01/19/2016 01:53 PM, John LaPrad wrote:
> Hello all,
>
> I'm looking into the possibility of decrypting and inspecting
> encrypted traffic to and from the Internet for viruses, malware
> etc.... Is anyone doing this? We have Palo Alto firewalls and they
> support decryption, inspection, re-encryption. I'm concerned about
> privacy issues, could it impact compliance in any way, user
> acceptance. I appreciate any feed back.
>
> Thanks in advance for your time;
>
> John LaPrad Manager of Technical Services Saginaw Valley State
> University Phone: 989-964-7134 jrl () svsu edu<mailto:jrl () svsu edu>

- --
Brian Epstein <bepstein () ias edu<mailto:bepstein () ias edu>>                     +1 609-734-8179
Manager, Network and Security           Institute for Advanced Study
Key fingerprint = A6F3 9F5A 26C5 5847 79ED  C34C C0E5 244A 55CA 2B78
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWnrj3AAoJEMDlJEpVyit4VpwP/i5+IMDyI3QpimR8WVVAEqAq
YL92vK4JpFn0Htf9upLF0a10G+Jzz5QHTCe51cMocIN+B5EzUYzkYzlpxXc84nor
YD45LEGk9lGt88oz/AgZgrXKsm514nNt1CeiNpeqE8tQ5Oun9w01iuZgb3pU6dIc
45Jtf0dXHTd8FNMmCx2kBrgkk8OA5p6rypKiYX3l0KxVrM8145/Uh129yUSfllTC
QSXvYQulNb+hymDWZBC1l5kGZJFF9pGhhAeM5jFo1/nBHL5iqD2NuJnxJcuCjsMb
juTWLk3w0Wth9wBefswxxLaOJ9uZSePs5E/5GywvXylC63bxQ27RYxViUwHo1GWW
fMwmnyoAd3YGXs0xNFuJIXgDbd5tW3SBxO3mYjykuXJuN415LKvhwhykC5pG9URA
OhY5J1c/pcpiiNqsU2ewCnycAprRnZULebdc3ywCjijcCJI55DGPZeXRU9GDjrBp
vGD6AZMi3t7FiIOD/lkkFZFGqmxf0CZHn1fM3EJbv0FbVbe7pt8YvNmGKo/7fLmx
k0Q4mN+Z185s5At06hpotuHmMiB92bYbjPBkyrkpx6UpMWFmAWIaumYom+egkgl1
nF3UAUc7XNAEBLQyVegLEMTi1hvi/hEbIU07lDBlkdwVqzp/ZXfEmxM/xj602WaY
FpUlJJwEClX/VZSk6NWE
=8r17
-----END PGP SIGNATURE-----