In my previous two posts in this series, I’ve discussed the basic functionality and emergence of HTTPS as a dominant protocol. In this my final post, I will share with you its limitations.
It is difficult to find something that is completely perfect, and HTTPS is no exception. Technological limitations exist and can be analysed from two perspectives – limitations of HTTPS as a protocol and the limitations it can impose upon Internet Service Providers (ISPs).
Technological limitations as a protocol
The basic purpose of HTTPS is to provide a security umbrella, consisting of authenticity, confidentiality and integrity. However, HTTPS can also be vulnerable, due to continuous attempts of certain entities who need to break its secured structure for their own purposes.
The most highlighted example in this regard is the role of the NSA (National Security Agency), an intelligence organization of the United States government who are responsible for monitoring, collection, and processing of required information along with protection of U.S. government communications and information systems. While intercepting phone calls and Internet communications have been common activities of intelligence organizations, breaking through a secured communication mechanism like HTTPS has often been a challenging task for them. However, during the last few years, there have been several reports that the NSA is decrypting HTTPS as well.
How are they doing this? The simple answer is by using any encryption mechanism based on a certain algorithm using certain keys. An extremely strong algorithm based on a very solid key can also be decrypted through enormous computation, which can be performed by a robust machine. The considerable financial investment and expertise makes it near impossible for a mere hacker or even an established group to build such a machine deploying these techniques; but not for an organization like the NSA.
Such a vulnerability of HTTPS can appear risky for users. However, the bigger challenge HTTPS often creates is for ISPs.
Why are ISPs upset about HTTPS?
To understand the answer to this question we first need to understand that ISPs (both fixed and mobile broadband operators) want to be able to correctly identify traffic in their network, followed by proper classification and functionalization of it.
Operators use various transparent and explicit components (for example, caching, traffic compression and ad-insertion boxes) in their network to make this easier, including: caching content to reduce the amount of IP transit traffic; compressing content before transmission on expensive wireless links; filtering inappropriate/undesired content; applying special service/features on particular traffic; and so on.
These components, however, can become blind when dealing with encrypted (HTTPS) traffic. As per basic mechanisms, they do not apply any of their functionalities on encrypted traffic; they just let that traffic pass through transparently.
Losing these functionalities for a significant amount of traffic (HTTPS is in fact becoming a dominant traffic protocol in most places) can be detrimental for network operators.
Recently a global project for mobile traffic optimization (through web and video compression) completely failed in a telco group due to an unexpected rise of HTTPS traffic, which could not be compressed.
Apple is also adding to the problem for ISPs
During Apple’s Worldwide Developers’ Conference in June 2016, it announced full deployment of its App Transport Security measure at the start of 2017. This means from 1 January 2017, Apple will not approve applications or application updates that make HTTP requests from application to server. Instead, Apple want application developers to use TLS security for all new or updated apps on the App Store.
Several mobile operators use HTTP header enrichment technology in order to pass subscribers’ identities or profile information to their partners or home-grown applications. This HTTP Header Enrichment mechanism allows them to enable Single Sign-On or provide a customized experience to their users.
With Apple’s App Transport Security mandate, the HTTP calls from application to server will need to be replaced with HTTPS calls. As a secured protocol, HTTPS disallows any HTTP header enrichment, and will therefore break the process that operators have relied on for so long.
This means operators will have to say goodbye to any system of identity management, customer experience management, customization or monetization that they rely on.
Technology is adapting to these limitations
Despite this, there has been no foreseen impact on HTTPS adoption and usage with numerous endeavors being carried out to overcome these factors.
Promoters of HTTPS, including the Electronic Frontier Foundation (who run “HTTPS Everywhere” program), have been mounting strong legal battles against illegal mass surveillance schemes like the activities of the NSA.
ISPs (particularly mobile broadband operators) are trying to apply all available mechanisms, for example, intelligent traffic management and generic traffic policies, to optimize the limitations that increased HTTPS traffic is creating for them.
What also needs to be remembered is that as a technological tool, HTTPS is continually advancing. For example, from 1 January 2016, the CA Council (the common forum of Certificate Authorities) started deploying TLS certificates signed with the SHA-2 (Secure Hash Algorithm) cryptographic hash, which is the successor to SHA-1 ( the previous version that was widely deployed in the last decade and is now seen as cryptographically insecure).
Add to this Google’s search algorithm’s disposition to prioritize HTTPS sites, we can expect to see HTTPS to continue its dominance.
Azfar Adib works for Bangladesh ISP and Telco, Grameenphone Ltd. He is focused on review and analysis of data-service related trends and their impact.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.