{"id":3514,"date":"2017-02-13T09:14:56","date_gmt":"2017-02-13T14:14:56","guid":{"rendered":"https:\/\/www.thesslstore.com\/blog\/?p=3514"},"modified":"2020-12-15T11:08:15","modified_gmt":"2020-12-15T16:08:15","slug":"https-interception-harming-security","status":"publish","type":"post","link":"https:\/\/www.thesslstore.com\/blog\/https-interception-harming-security\/","title":{"rendered":"Study: HTTPS Interception is Harming Security"},"content":{"rendered":"\n

New Study Finds HTTPS Interception is Weakening HTTPS.<\/h2>\n\n\n\n

A new study<\/a> has found that HTTPS Interception \u2013 the practice of decrypting and scanning HTTPS connections in order to scan traffic for malware and monitoring – is much more prevalent than previously believed. It was also found that devices and software that perform interception significantly reduce the protections of HTTPS and weaken the overall safety of user\u2019s data.<\/p>\n\n\n\n

The study was conducted by a large team of academics and professionals including Zakir Durumeric, Zane Ma, Drew Springall, Elie Bursztein, Nick Sullivan (Head of Cryptography at Cloudflare), and Richard Barnes (Firefox\u2019s Security Lead).<\/p>\n\n\n\n

Traditionally, an HTTPS connection is made directly between a client (your browser) and a web server. That connection is encrypted and authenticated so that the data sent between the two computers can only be read by those same computers, defeating a wide range of network attacks and monitoring.<\/p>\n\n\n\n

“[HTTPS] interception significantly reduces the protections of HTTPS and weakens the overall safety of user\u2019s data.”<\/p><\/blockquote>\n\n\n<\/span>\n\n\n\n

But when HTTPS interception is taking place, there is no longer a direct connection between your browser and the server. Instead, a third party, the interception device, stands in the middle. First, an HTTPS connection is made between the web server and the interceptor. This allows the interceptor to decrypt and scan the data once it has received it. The interceptor can then perform traffic inspection and anti-virus scanning. Then another HTTPS connection is made between the interceptor and your browser, and the data is encrypted again.<\/p>\n\n\n\n

Two separate and distinct HTTPS connection are needed \u2013 the first \u2018securely\u2019 delivers the data to the interceptor, and the second \u2018securely\u2019 delivers the data to the browser. However, many products that perform interception were found to have poor SSL\/TLS capabilities, which compromised the security of the HTTPS connections and left the user with reduced protections.<\/p>\n\n\n\n

Due to a combination of outdated software, bad documentation, and the lack of incentive to configure them properly, manufactures and networks who deploy these products are actually weakening their user\u2019s and data\u2019s safety for the benefit of network monitoring and anti-virus scanning.<\/p>\n\n\n\n

The Surprising Scale of HTTPS Interception<\/h2>\n\n\n\n

The study looked at two distinct classes of products. The first are commercial hardware devices known as middleboxes which perform traffic inspection. These are deployed on corporate networks so that administrators can see what is going on while still protecting data as it travels across the public internet. The second is anti-virus software, which is usually run on consumer computers.<\/p>\n\n\n\n

The team analyzed nearly 8 billion SSL\/TLS handshakes<\/a>, comparing data of the observed connections to determine when an interceptor was bridging the connection between the server and the client. They found that up to 10.9% of observed connections were intercepted.<\/p>\n\n\n\n

This has large implications on the true privacy provided by those HTTPS connections. But the bigger problem is that the interception products are severely weakening HTTPS by using outdated cryptography and failure to implement basic features.<\/p>\n\n\n<\/span>\n\n\n\n

To figure out the scale of the problem, the researchers needed to quantify how much interception was taking place. For observed connections the HTTP User-Agent header (which tells the server what browser and operating system it is talking to) and the parameters of the SSL\/TLS handshake were recorded. Comparing that data allowed the researchers to look for inconsistencies that would reveal the connection was being intercepted.<\/p>\n\n\n\n

For example, if the User-Agent header said they were talking to a Chrome browser, but the TLS handshake included ciphers that Chrome has never supported, it told them that an interceptor was passing along the browser\u2019s header and making the connection.<\/p>\n\n\n\n

Connections were monitored on Firefox\u2019s update servers, on a \u201cset of popular e-commerce sites,\u201d and on Cloudflare\u2019s network, in order to get an accurate sample of internet data.<\/p>\n\n\n\n

Cloudflare had the highest rate, with 10.9% of traffic being intercepted. The ecommerce sites had 6.2% of interception, and Firefox update servers had 4%. All of these numbers \u201care more than an order of magnitude higher than previous estimates,\u201d which estimated the rate was closer to a half percent or less.<\/p>\n\n\n\n

The Negative Effects Of Interception<\/h2>\n\n\n\n

Once they knew how much traffic was being intercepted, the next thing to know was how this was effecting the security benefits of HTTPS. The researchers knew that the interceptor products were using outdated SSL\/TLS libraries and often lacked support for modern cryptography and other security features.<\/p>\n\n\n\n

To quantify the impact of HTTPS interception, the authors came up with a grading rubric, giving A, B, C, and F grades to the tested products depending on how their SSL\/TLS capabilities compared to a modern browser.<\/p>\n\n\n\n

Their criteria was very forgiving.<\/p>\n\n\n\n

An \u201cA\u201d grade simply meant that the interceptor\u2019s TLS connection was \u201cequivalent to a modern web browser\u201d when it came to encryption and authentication. None of the products they tested had support for advanced HTTPS mechanisms such as HSTS (HTTP Strict Transport Security) and HPKP (HTTP Public Key Pinning), and those factors were left out of the grading. This means that even an \u201cA\u201d grade is still a decrease in overall security because browsers do implement these advanced mechanisms.<\/p>\n\n\n\n

A \u201cB\u201d grade was for \u201csuboptimal\u201d connections that were flawed but still cryptographically secure. A \u201cC\u201d grade meant the connection was vulnerable to known attacks; and an \u201cF\u201d was for \u201cseverely broken\u201d connections which left out basic functionality like certificate validation altogether, or supported extremely weak encryption ciphers.<\/p>\n\n\n\n

Note that the \u201cC\u201d criteria is very forgiving. Most people would consider vulnerability to known attacks to be reason enough to give a failing grade.<\/p>\n\n\n\n

Given the low bar, you would think the products performed well. After all, scoring an \u201cA\u201d just means the product needed support for modern cryptography. Browsers do it for free, so commercial products should be able to do just as well, right?<\/p>\n\n\n\n

\"HTTPS<\/figure>\n\n\n\n

Of the 12 middleboxes only one received an \u201cA.\u201d That was a device from Blue Coat (owned by Symantec). Blue Coat\u2019s ProxySG 6642 properly validated certificates, supported TLS 1.2 and modern ciphers, and mirrored the client\u2019s capabilities. This effectively preserved the security of the client, meaning you were no worse off by using it.<\/p>\n\n\n\n

The rest of the middleboxes worsened user security. Six of the middleboxes received a \u201cC\u201d grade and four received an \u201cF.\u201d<\/p>\n\n\n\n

\u201cFive of the twelve products introduce severe vulnerabilities that would enable future interception by a man-in-the-middle attacker.\u201d Overall, 62% of observed traffic was made less secure by the middlebox\u2019s poor TLS capabilities, in comparison to the connection being made directly between the browser and server.  The authors said the majority of these connections were \u201cseverely broken\u201d and questioned the protection they provided.<\/p>\n\n\n\n

\"HTTPS<\/figure><\/div>\n\n\n\n

The upside was relatively small \u2013 less than 15% of connections experienced increased security. This would happen when the user\u2019s browser had inferior capabilities compared to the interceptor. Less than a quarter of connections maintained equal security when the middlebox was present.<\/p>\n\n\n\n

Anti-virus software performed even worse. The study tested 26 products from 13 vendors including major anti-virus software makers Avast, AVG, and Kaspersky. A whopping 15 products scored an \u201cF\u201d and 9 a \u201cC\u201d (that\u2019s 24 of the 26 products). Only 2 products \u2013 both from Avast \u2013 scored an \u201cA.\u201d<\/p>\n\n\n\n

This means that both consumer and corporate traffic is being severely harmed by their own HTTPS interception products. These products are meant to provide more security \u2013 by allowing for network monitoring and anti-virus and malware scanning. While they may very well do that, it comes at the cost of crippling the encryption that protects that data.<\/p>\n\n\n\n

In the context of corporate networks, this means that using an interceptor not only makes it easier for you to monitor your traffic, but it\u2019s likely making it easier for other people to monitor your traffic. Poorly encrypted data can be captured and stored by anyone who can monitor the network (such as the government, or your ISP operating under court order from the government) and then decrypted. Some of these connections are weakened so severely that they can be easily decrypted today \u2013 while others could be broken in a few years when computing power increases.<\/p>\n\n\n\n

The authors pointed out that the problem here is multi-faceted. First, while the internet community has always known HTTPS interception was happening, the scale of it was likely not realized. This means that interception has largely been ignored and there is little consensus if an alternative solution should be sought out.<\/p>\n\n\n\n

Then there is of course lots of blame to spread around to middlebox manufacturers and anti-virus vendors. There is no excuse for their horrible SSL\/TLS configurations. The problem is bigger than out-of-date libraries and improper implementation; the authors noted that Cisco devices had no documentation on how to configure cipher suites.<\/p>\n\n\n\n

But our own industry also deserves some blame. It is only very recently (in the last few years) that the security community has put the \u201csecure by default\u201d philosophy into practice. Previously, software offered confusing and insecure configurations which made HTTPS weak or easily broken. For years OpenSSL, the most widely-used SSL\/TLS library, was shipped with default settings that were vulnerable, \u201crendering the middlebox[es] [which used OpenSSL] vulnerable.\u201d<\/p>\n\n\n\n

Hopefully this research has made it apparent that HTTPS interception is a major issue which must be addressed by the security community and the IETF, the organization which designs the TLS protocol.<\/p>\n\n\n<\/span>\n","protected":false},"excerpt":{"rendered":"

New Study Finds HTTPS Interception is Weakening HTTPS. A new study has found that HTTPS Interception \u2013 the practice of decrypting and scanning HTTPS connections in order to scan traffic…<\/p>\n","protected":false},"author":2,"featured_media":3515,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":"","tve_updated_post":"","tve_custom_css":"","tve_user_custom_css":"","tve_globals":{},"tcb2_ready":0,"tcb_editor_enabled":0,"tve_landing_page":"","_tve_header":"","_tve_footer":""},"categories":[130],"tags":[507,170,506,508,136,161],"class_list":["post-3514","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-everything-encryption","tag-cryptography","tag-https","tag-https-interception","tag-ietf","tag-ssl","tag-tls","post-with-tags"],"views":20820,"jetpack_featured_media_url":"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/02\/iStock-628125726.jpg","_links":{"self":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/3514","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/comments?post=3514"}],"version-history":[{"count":0,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/3514\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media\/3515"}],"wp:attachment":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media?parent=3514"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/categories?post=3514"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/tags?post=3514"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}