Re: Inspecting encrypted traffic

[John LaPrad <jrl () SVSU EDU>]

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 

----- Original Message -----

| From: "Brian Epstein" <bepstein () ias edu>
| To: "John LaPrad" <jrl () svsu edu>, "The EDUCAUSE Security Constituent Group
| Listserv" <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
| >

| - --
| Brian Epstein <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-----