Re: Inspecting encrypted traffic

[Nathaniel Hall <educause-lists () NATHANIELHALL COM>]

Palo Alto is able to do that too. You can also take specific URL
categories and either include or exclude them from decryption. So you
could exclude financial or healthcare sites for privacy reasons, but
specifically include parked domains or sites you are less likely trust.

Getting these URL categories from Palo does require a URL Filtering
license, or you can create your own custom categories without a license.


--
Nathaniel Hall, GSEC GPPA GCIA GCIH GCFA CNSE

On 1/20/2016 10:54 AM, Dexter Caldwell wrote:
> I will say that here is one tool that claims to allow you to exclude
> trusted sites from ssl decryptions, but that might be awful lot of
> excluding.  In either case, just passing along.  I have no experience
> with it personally, although I am familiar with the company.
>
>  
>
> https://www.fireeye.com/products/nx-network-security-products/ssl-intercept.html
>
>  
>
>  
>
> D/C
>
>  
>
> *From:*The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] *On Behalf Of *Dexter Caldwell
> *Sent:* Wednesday, January 20, 2016 11:49 AM
> *To:* SECURITY () LISTSERV EDUCAUSE EDU
> *Subject:* Re: [SECURITY] Inspecting encrypted traffic
>
>  
>
> I tend to agree that it’s a good idea to steer clear of this if you
> don’t absolutely need to it for some key reason like troubleshooting. 
> Besides that, you may find that as your traffic loads increase, you may
> have to throw a considerably greater load of hardware firepower at it.
>
>
> D/C
>
>  
>
> *From:*The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] *On Behalf Of *John LaPrad
> *Sent:* Wednesday, January 20, 2016 10:22 AM
> *To:* SECURITY () LISTSERV EDUCAUSE EDU <mailto: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
>
>      
>
>  
>
> 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>
>
>
>  
>
>
>