Loading...

Tech Talk Live Blog

The Blind Shall See – Part 2

Roy Hoover


In my last post about visibility I talked about looking at information from your network gear in order to see what is happening or to better manage your network. In this post, we will look at the implications of breaking encryption on user data passing through your network in order to manage it. Sometimes you may need to decrypt traffic on your network to inspect it in order to protect your network or the users on your network. Just make sure that the cure isn’t worse than the disease.

Who owns the data on your network? There are varied and strong opinions to that question. They may vary from “Not me. I am just the transport.” to “I own every bit that touches my network.” There are a variety of factors that affect where one might land on that continuum. In K-12 schools CIPA (Children’s Internet Protection Act) requires that schools protect children from harmful content on the Internet. How can you protect them from content that they are encrypting?

There are legitimate reasons to decrypt content that K-1 2 students are accessing. How can you be sure you are not harming them when you decrypt their traffic? A typical scenario is that a web filter solution used by a school has a decryption feature that can be enabled. The filter box implements a man-in-the-middle attack on the SSL session, applies the school district policy to the clear text content, re-encrypts the content and sends it to the user. The user in none the wiser about what happened to their encrypted data while passing through your network.

There are a number of places where that process can introduce vulnerabilities that could affect users. Some web filters allow the system administrator to turn off server certificate verification. A recent InfoWorld article describes how some filtering solutions handled server validation incorrectly, which would have allowed servers with invalid SSL certificates to appear in the user’s browser as valid. Browsers check the validity of the certificate that encrypted the traffic, which in this scenario is your district web filter that will be valid as long as you previously installed the proper root certificate in each browser on the client machines on your network. A deep dive on the topic can be found in this article, The Security Impact of HTTPS Interception.

By using this design, school district staff must take over the server certificate checking responsibility on behalf of the users on their network. Are you prepared to take on that responsibility? What if a user’s machine gets compromised because a flawed server certificate was presented as valid by your web filter? Does the district assume the responsibility for that compromised machine?

How about troubleshooting a network issue that involves encrypted data? Wireshark is a great tool for analyzing what is happening “on the wire” in a network. When the data stream you are investigating is encrypted it can be difficult to get useful troubleshooting data from the captured packets.

Much like the web filter man-in-the-middle attack, Wireshark can use a certificate to decrypt the data and present it to you in clear text. Just load the server certificate into the SSL decoder in Wireshark, and the encrypted data is decrypted. See the article, Decrypting TLS Browser Traffic with Wireshark – The Easy Way! for details.

What about other entities that would like to see your data? Should they have the right to decrypt it too? After it leaves your network, should your ISP be able to decrypt it? If so, for what purposes? National Security? Protecting you from malware? So they can target advertising to you? Should you even be able to encrypt your users’ data in the first place?

Who gets to decide what information should be intercepted, and by whom? It is a very slippery slope as we have seen recently.

Deciding to inspect traffic on your network comes with great responsibility. Deciding to decrypt traffic passing through your network comes with an even greater responsibility. You have a responsibility to protect your students, staff, network, and other assets. Please do that responsibly and ensure that you are not inadvertently placing them at risk while trying to protect them.

Tech Talk Live Blog Comment Guidelines:

One of our main goals at Tech Talk Live is to build a community. It is our hope that this blog can be a forum for discussion around our content. We see commenting as an integral part of this community. It allows everyone to participate, contribute, connect, and share relevant personal experience that adds value to the conversation. Respect counts. We believe you can disagree without being disagreeable. Please refrain from personal attacks, name calling, libel/defamation, hate speech, discriminatory or obscene/profane language, etc. Comments should keep to the topic at hand, and not be promotional or commercial in nature. Please do not link to personal blog posts, websites, or social media accounts that are irrelevant to the conversation. This is considered self-promotion. We welcome links that help further the conversation and reserve the right to delete those we deem unnecessary. The appearance of external links on this site does not constitute official endorsement on behalf of Tech Talk Live or Lancaster-Lebanon Intermediate Unit 13. You are solely responsible for the content that you post – please use your best judgment. We reserve the right to remove posts that do not follow these guidelines.

Leave a Reply

Your email address will not be published. Required fields are marked *

CONTACT

Tech Talk Live is the only conference of its kind in the region specifically designed for IT pros in education.


techtalklive@iu13.org
1020 New Holland Avenue, Lancaster, PA 17601

(717) 606-1770