Re: Inspecting encrypted traffic

[Michael Anderson <michaelanderson () VT EDU>]

Just one point I'd like to note about the technical issues surrounding
inspecting encrypted traffic.  In a BYOD environment, the issuing CA for a
certificate used in connecting the user to inspection point will not be
installed on all end-user devices.  This is effectively conditioning users
to ignore or click-through security warning messages.  If users already
expect man-in-the-middle while on campus, then malicious attacks employing
this technique off campus will more likely succeed.

Thanks,

Mike Anderson
Manager, Secure Information Exchange Services
Virginia Tech Information Technology
(540) 231-9733

On Thu, Jan 21, 2016 at 12:29 PM, John LaPrad <jrl () svsu edu> wrote:

> Thank you everyone for the great comments it gives me a lot to think
> about. The sense I am getting from replies to the list and to me is an
> acknowledgement that encrypted traffic is on the rise and that this is a
> problem for those doing / relying on deep packet inspection.  My initial
> question about decrypting the traffic flows raises concerns about privacy,
> trust, compliance, and technical viability. My take is that if done, it
> would need to be done with clear communication and education. One vendor
> even suggests a popup message informing the user that the https session
> will be inspected for malware and getting their consent to proceed.
>
>    - Personally, I think that the privacy, trust and compliance issues
>       could be solved.  In particular, trust, I think can be solved with
>       education.  Everyone's experience is unique, but for us we had to educate
>       users about virus scanning their computers, then scanning their email, then
>       scanning their Internet activity. Our users have mostly accepted these
>       intrusions as prudent and necessary today- I see this as a logical
>       extension / next step.
>       - Compliance issues will require very clear and open statements
>       from the device manufactures detailing the decryption / inspection process
>       and how the cleartext data is handled. Does it only exist in memory? Is it
>       logged? Written to disk? DLP may actually require inspection of all flows
>       including encrypted ones.
>       - The technical issues are complex and merit a whole other
>       discussion. Different vendors have different approaches for dealing with
>       the certs. And, maybe as applications try to protect their connections even
>       an 'official' company sponsored MITM will be detected, blocked or warned
>       about.
>
> Another thought is that this inspection approach is not a good long term
> strategy. We should concentrate on endpoint device protection. I agree that
> device protection is very important, but, in our environment, byod is a
> huge factor. Over half the devices on our network are not our devices.
> However, the people using them are our constituents, faculty staff,
> students, guests all accessing our systems. In the past, when there were
> only laptops, our NAC could force some standards (but that was not always
> successful on other people's computers; the student who didn't want to
> install stuff on his computer, the corporate user who's computer was locked
> down and couldn't install our stuff). But, now we see phones, tablets, PCs
> and Mac devices; Microsoft, Apple, Linux, Android Operating systems on the
> network. We cannot force endpoint software standards on them all.
>
>    - Other network strategies besides inspection help:
>       - micro-segmentation (private vlans) so each device basically has
>       it's own network.
>       - DNS filtering (Open DNS or others)
>       - URL  filtering
>       - netflow analysis ( I need to look more at this. We did it years
>       ago, but stopped when we got IPS)
>
> It's certainly an interesting and evolving topic. Security is best when
> it's multi-layered and these strategies are all complimentary. I don't like
> decrypting, but honestly, I don't see how these other strategies on their
> own can be as effective, as sure, and safeguard our users and systems as
> well without inspection. It seems to me that is why deep packet inspections
> and IPS systems became so popular-because it does help.
>
> Thanks again everyone for your comments and I apologize for the rant.
> Still not sure what we'll do.....
>
> John
>
> ------------------------------
>
> *From: *"Brian Epstein" <bepstein () ias edu>
> *To: *"John LaPrad" <jrl () svsu edu>
> *Cc: *"The EDUCAUSE Security Constituent Group Listserv" <
> SECURITY () LISTSERV EDUCAUSE EDU>, "Angelo Rodriguez" <
> Angelo.Rodriguez () SOFTWARE DELL COM>
> *Sent: *Wednesday, January 20, 2016 4:15:41 PM
> *Subject: *Re: [SECURITY] Inspecting encrypted traffic
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> John, Angelo,
>
> I've been to a few talks in the past years that have been talking about
> alternatives to deep packet inspection, in part, due to the widespread
> use of TLS.  HTTP/2 is practically requiring TLS, especially if you want
> to use the SPDY protocol that Google developed.
>
> Personally, I see this as a time to change the way we think about
> signature based deep packet inspection.  Using SSL bump to implement a
> MitM might work for now, but I don't see it as viable in the long term.
>
> For us, we are focusing on DNS queries of known malicious hosts, netflow
> and heavily segmenting different user and data roles.  For malware, we
> are working more on endpoint protection and quarantine and the
> realization that bad actors are already inside the network.
>
> I understand your point of view, though, traffic analysis shows that
> malware is now starting to fly in under the radar due to encryption.
> The goal of encryption is to prevent inspection of the data, though.
> So, what comes next to prevent SSL MitM deep packet inspection?
>
> Or perhaps, users will be upset for a little while, and then become
> complacent to the fact that someone is looking at their data.  I
> seriously doubt this statement and think that security professionals
> like ourselves need to find a new methodology than signature based
> packet inspection.
>
> To Angelo's point from a vendor perspective, I agree that current
> products aren't going to be as effective without providing decryption.
> I think that those vendors need to realize that this is happening and
> refocus their efforts on finding new methodologies that are both
> effective and will fly with customer expectations of privacy.  This
> isn't an easy problem to solve, but I think it is something that will
> separate the field in the years to come.
>
> Again, every school and business is different in culture and what is
> acceptable.  There are schools out there right now that are running very
> effective security programs without using NAT and not owning a single
> firewall.  I applaud them for being able to do that.  We run a central
> NG firewall with built in IPS that I fully envision won't be relevant in
> 5 years due to this issue.  We'll see what happens.
>
> Stimulating conversation, would love to hear more perspectives on it.
>
> Also, I have to plug the Educause Security Professionals conference
> coming up April 18-20 in Seattle, WA.
>
> http://www.educause.edu/events/security-professionals-conference
>
> This would be a great conversation to have at one of the birds of a
> feather sessions or informally over dinner with some of our colleagues.
>  Let me know if you are going to be there.
>
> Thanks,
> ep
>
> On 01/20/2016 10:21 AM, John LaPrad wrote:
> > 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> *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
> >
> > 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
>
> iQIcBAEBCAAGBQJWn/j9AAoJEMDlJEpVyit4EtgQAJq/l51Ht9vMbwrl5SS/biO9
> 3PpghUpFsBXWcdOHn/lXvKzbBWWEuz/CvMJzXZTUKF1iSGeFa1J3+NOPIatHzWOr
> 0/iPvRBTlx8aiJypSTxy9+llzBSKdyZY+EYb9VLhb2CGNbgJWwaw408w4MANSoyX
> fuDnKbyyw31igUBCXTTgAzbWtoN9qGV34bHT62YIEN5QONmyWiRDtY+DdwdQcQTF
> V9JcjugWnVJ5NY0SQFYR7VDMdJwPfxoi98OCRx6w1JoddMAtkqmG6J1yhjNK+T/X
> 6tWBPIpzCdHhcE9NNyZA+Ca8GydQrUX3RUxopmYhvgR8uPRl4Bytbz+OjvUE+pdw
> 6CJc1eapzcP5vT0iD3GpXViDwpLzVBAmpM8/GTn5tbGGbZBg+HQX435oV8L6D/9q
> iegQfAwSMZWDmw/W7auku8zj7lVgEXeO4t9nsIot5lwpyPXAWZTa22XaqvOXOTVC
> s9Rb6C1jw2ytvdJ+ysyKL8MpIbHvlOcxhsShq3qDqAOifDqUdjNycxSSakFCER4E
> 6R1zH0pQ/Me8ceymxU4Jm2Om/KiKzx3rKUgWM87TIK8qOTOukCzr+3sJEois7eCK
> Lc1YQ9lLW3AEYSWdWaK5ZZhzoGvBv8XOu3zfDvDlThno4wpyKEwFhp1/saEVWscL
> E5uQNz/nC1Ma57NdYt+W
> =VnZ9
> -----END PGP SIGNATURE-----