Does using HTTPS, TLS, S/MIME, SSL e.t.c. protect you from Deep Packet Inspection and 'Big Data' analytics?

Question

The title basically covers it. I want to know if using HTTPS, TLS, S/MIME, SSL will protect you from Deep Packet Inspection and Big Data Analytics? (I know that if someone fakes a cert or gets you to install a fake CA or using MITM software they can fool the average user, I want to know if a semi-diligent semi-intelligent IT security person is safe using those technologies to encrypt the data and connections)

Answer 1

Deep packet inspection (DPI) is a term that commonly refers to standard network middle-men, such as the routers at an ISP, examining content at a protocol layer higher than the layer they need to in order to process the packet (thus inspecting "deeper" into the packet than necessary). For example, an IP router may need to only look at the IP layer (layer 3 in the OSI model) of the packet, but if it also inspects the application layer data (layer 5/7) then it is performing deep packet inspection.

HTTPS (referring to the wide suite you mentioned) is an application layer protocol. It will defend against deep packet inspection that reads the content of the application layer, but not against DPI at lower levels of the protocol wrapping. For example, HTTPS will not prevent DPI from looking at the TCP packet and examining the destination port to guess what protocol it is for. But it will prevent the DPI from learning the actual application data payload of the protocol.

Big Data Analysis refers to analysis performed on very large databases of collected data, but how that data is collected has little to do with HTTPS. HTTPS is only designed to protect data in network transit, when the destination server in the HTTPS protocol reads data, the data is decrypted and HTTPS protection no longer exists. What happens at that point is up to whatever the client and server are using on top of HTTPS. Likely, the server can do pretty much whatever it wants at that point. (In other words, Big Data generally refers to Data At Rest, whereas HTTPS protects Data In Motion. Since they address different stages of the data, it makes sense that protection in one stage won't apply to data when it is moved to a different stage.)

Answer 2

Will transport layer encryption (SSL/TLS/https) prevent you from Big Data Analytics?

Depends. Does the server at the other end use your data for big data analytics? If they don't, you are safe from big data analytics. If you use google/facebook/amazon, etc they are analyzing your data (and potentially sharing with other entities (like the US gov't/NSA)), they are using doing big data analytics on the information you gave them.

TLS (and SSL is just an old version of that; and HTTPS is just HTTP + SSL/TLS) just limits network eavesdroppers to only know when, whom (IP address), and how much data you are sending and receiving. (This assumes they have not compromised a CA or your browsers' trusted certificates for a sophisticated attack). This limited information is sometimes quite useful in a side-channel attacks to deduce what private information you are sending (especially if there are ajax auto-complete features like google suggest).

However, in general the transport encryption only lets your computer and the https servers at the end other end of the connection see your data; though each computer is then free to share that data with adversaries to analyze.

To be specifically clear, yes transport layer encryption prevent your ISP/other network eavesdroppers from Deep Packet Inspection; with the exception of seeing when, whom, and how much encrypted data you are sending/receiving. If you are paranoid about even this limited information, you can proxy all your traffic through an encrypted tunnel/VPN/tor to hide what web sites/machines you are visiting, so the ISP can only discover how much data you are sending to your proxy at any given time. (Granted the ISP of the proxy server could eavesdrop on which sites are visited by its proxy servers as well as what computers are connected to the proxy server.)

Answer 3

There is actually a surprising amount of data that can leak through a typical HTTPS connection.

If the TLS server and client are up to date, then the data's encrypted, and safe, but the sizes, times, and number of packets and TLS messages within the packets do contain interesting information. Consider the Bicycle Attack; the order and approximate length of headers returned by the webserver may be visible in the encrypted stream.

Observant attackers including DPI inspecting firewalls including the Great Firewall, may create their own connections to the target webserver to obtain the encrypted content which is not unique to a user.

Eg anyone can see the site's login page, even if you have TLS, because you have to show it to unauthenticated users.

Pages which respond to user events by sending data to a server, like google's search-as-you-type feature, may expose the typing rate or patterns of the user, which can serve to identify them.

And of course... DNS and Proxy information is typically outside the HTTPS layer, and can expose the sites and clients used.

Answer 4

SonicWALL DPI-SSL is mainly for use in a managed network where Administrators can control a Root Certificate Authority and therefor force clients to trust the certificate signed by the SonicWALL in the middle.

An example of this would be a School filtering out / forcing safe search on Goolge (as this now uses https as default) - without this "man in the middle" packet breakdown the user could look at anything they wanted to and it would only be reported back as https://google.com.

In simple terms, client makes request to https://google.com in their browser - the SonicWALL (as Edge device) then makes this request to Google on their behalf (therefore creating the secure connection between Google -> SonicWALL) - the SonicWALL then Re-signs the traffic and routes it to the correct internal device.

This can only be done if the Network Administrator has access to the public key infrastructure or the workstations have been told to trust the self-signed sonicwallCA certificate.

In real-terms you can check this by clicking the padlock on your browser and seeing if it is a trusted third party or your local company. This attack would be VERY difficult if you are not in charge of the infrastructure of a network.