“Encryption makes it more difficult for governments and other third parties to monitor your traffic. It also makes it harder for Internet Service Providers (ISPs) to censor access to specific Wikipedia articles and other information”. - Wikimedia blog, June 12, 2015


“and that by the end of 2016 65-70% of traffic will be encrypted in most markets”. - Sandvine Global Internet Phenomena Spotlight



I recently met a bright young man who works for Google in Europe.

Me: It’s nice to meet you!

Him: It’s nice to meet you, too!

Me: I have to say to you that Google’s “HTTPS everywhere” makes my life harder as a network security professional”.

Him: Well… This is the way to make things more secure.

Me: I agree, especially in the user perspectives. But my job is still harder…




Pierre Far and Ilya Grigorik gave an awesome Google I/O session to developers, titled HTTPS everywhere, in June 2014. They evangelized that ALL web communications should be secure always and by default, in order to protect users’ privacy. To prevent Man-In-The-Middle (MITM) attacks, all web communications should be secured by HTTPS, which is HTTP over TLS. Pierre and Ilya stated that HTTPS not only would provide encryption of the client-server communications, but also authentication and data integrity. They later demonstrated the best practices of setting up a secure web site and its indexing signals for Googlebot.




Google’s increasing use of HTTPS inspired Electronic Frontier Foundation (EFF) to introduced HTTPS Everywhere (with uppercase E in Everywhere) with version 1.0 released in 2011. HTTPS Everywhere is an open source web browser extension for Firefox, Chrome, and Opera. If the target websites support HTTPS, the browser extension automatically makes the web browsing connections to HTTPS. As far as I understand, IE users can install the non-EFF Zscaler Tools HTTPS Everywhere; Safari users need to type https:// manually.




Canadian network policy control products company Sandvine conducted a study with a North American fixed access network service provider in April 2015 to understand the encryption adoption of the internet traffic. The study found that 29% of the downstream traffic of that service provider was encrypted. The majority of the encrypted source traffic was YouTube and BitTorrent’s traffic followed.


For the unencrypted traffic, Netflix contributed 35% share (surprise, surprise, surprise not). This was an interesting finding because in April 2015, Netflix announced in the quarterly earnings letter that it would move to HTTPS to stream movies in the next year, in addition to the existing encrypted log-in and other sensitive data pages. With the Netflix transition to secure content delivery, Sandvine predicted that almost two-third on that North American ISP traffic would be encrypted.


More and more web sites are moving to HTTPS. For example, Wikimedia Foundation announced in a blog on June 2015 that it were in the process to encrypt all Wikimedia’s content with HTTPS and that it would use HTTP Strict Transport Security (HSTS) to protect against MITM attacks.




My team has recently been working on a project to migrate our perimeter firewalls to the Next Generation Firewalls (NGFW). Before we would put them inline, we set them up as monitor mode. What did we observe? Over 95% of our DMZ inbound traffic was encrypted. It’s not a surprise because our company’s website enforces HTTPS connections. About 60% of our outbound web traffic was encrypted. Of course with only monitor mode, our NGFW found ZERO threat from the encrypted traffic.


How do you monitor the activities in the encrypted traffic? You may say you can implement SSL Interception. SSL Interception is a beautiful term that we information security use for what we do, but in the end, it’s basically MITM attack (OK, in a white hat).


Even though we have the blessing from the executives to implement SSL interception for DLP, IPS, IDS, etc, we certainly cannot provide 100% customer satisfaction to our employees. NGFW and web proxy vendors provide a list of affected applications when SSL interception is implemented. The list includes, Microsoft Update, iTunes Store, GoToMeeting, and Dropbox. Beside high cost (money and man power) of implementing SSL interception for visibility and control, I wonder how many companies are blind to the encrypted traffic on their network.


Lastly, I would like to point out that Jacob Thompson of Independent Security Evaluators proposed a method against SSL interception. He demo’ed it at DerbyCon 4 in 2014. My point is that the half a million to a million dollars NGFW/IPS may not be able to give you 100% visibility that you expect.


Do you encounter any challenge to detect threats with the increasing encrypted traffic on the infrastructure? Do you have any successful and failure story to share? I would like to hear from you.