Re: Inspecting encrypted traffic

[John LaPrad <jrl () SVSU EDU>]

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 

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

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