There are changes afoot in the way web traffic flows. It seems likely that we are heading towards a change of protocol, probably to HTTP/2, with the intention of increasing security.
For those who are unaware, HTTP/2 is a protocol that has been designed with encryption at its heart. In fact, so central is encryption to HTTP/2 that early drafts of the Internet Engineering Task Force’s Request for Comments (RFC) on the topic suggested that Transport Layer Security (TLS) cryptography - the successor to Secure Sockets Layer (SSL) - would be mandatory within HTTP/2.
This proved unworkable and the situation has now been softened so that TLS is now considered optional, although the Chrome and Firefox browsers have both committed to employing TLS by default. The end result looks likely to be a increased lack of visibility when it comes to inspecting traffic.
Cryptography is not the only challenge current inspection technologies will face. HTTP/2 uses binary encoding, which will mean an end to the paradigm of scrutinising the ASCII payload contained within http frames.
As most network engineers are aware, the much beloved Wireshark has already addressed this particular issue, but it’s doubtful some of the current hardware can programmatically decode the stream without some financial expenditure.
The lack of traffic visibility is not entirely new. After all, https blinds a lot of deep packet inspection (DPI) methods (unless the private key is supplied). But browser traffic using HTTP/2 will be able to flow unhindered by current DPI methods.
For example, a typical use of DPI would be to look for sql injection with ASCII strings such as “=%27” or some sql statement such as “1' or '1' = '1 “. However, as we’ve already established, with HTTP/2 the ASCII is binary encoded and encrypted and such inspection methods would be rendered useless.
This will leave CIOs, IT managers and administrators with a very tricky question: if I want to make sure this traffic is not a threat, am I really going to break the encryption to inspect the contents to make sure?
Aside from the ethical questions this poses for some sectors and businesses, it is opening up a can of worms from a security standpoint.
In effect, HTTP/2 adds extra layers of security due to the recent increase in practice and media coverage of cyberattacks. This undoubtedly represents a significant improvement for the end user in terms of securing their information. Yet the use of end-to-end encryption also blinds the mechanisms that administrators and engineers have put in place to maintain security.
So, in order to make sure that nothing is slipping through under the radar with the help of HTTP/2’s encryption, network administrators are faced with a stark choice: reap the benefits of HTTP/2 at the cost of 'going dark' or decide to not support this new protocol to maintain a paradigm in which they have much invested.
No prizes for guessing where malevolent actors will focus their attacks.
