Domain name system (DNS) over transport layer security (TLS) adds an extra layer of encryption, but in what way does it impact your IP network traffic? The additional layer of encryption indicates controlling what’s happening over the network is likely to become challenging.
Most noticeably it will prevent ISPs and enterprises from monitoring the user’s site activity and will also have negative implications for both; the wide area network (WAN) optimization and SD-WAN vendors.
During a recent call with Sorell Slaymaker, we rolled back in time and discussed how we got here, to a world that will soon be fully encrypted. We started with SSL1.0, which was the original version of HTTPS as opposed to the non-secure HTTP. As an aftermath of evolution, it had many security vulnerabilities. Consequently, we then evolved from SSL 1.1 to TLS 1.2.
However, even though we were heading in the right direction, there were significant technical disadvantages of using TLS 1.2. One major disadvantage is that you can auto-negotiate backward to use SSL1.0. Evidently, SSL1.0 has numerous known vulnerabilities and the US PCI 3.1 came up with the requirement that you could not use SSL1.0.
Introducing TLS 1.3
The above drawback drove the requirement for TLS 1.3. The implication of TLS1.3 is that it does a few things better. First of all, the setup is faster. Instead of exchanging 5 packets, it exchanges only 2 packets. This certainly improves performance and reduces latency. Also, the certificate name is encrypted, which is another added advantage. Overall, it provides good privacy and performance compared to the previous versions of TLS.
However, encrypting the certificate has a number of implications involved. Often firewalls and network proxies use the certificate name to understand which site you are connecting to. Each connection to various websites has a different certificate. Therefore, if you have the certificate name, you can understand and classify the session.
Today when you do a DNS lookup, you send out a DNS request. The DNS server that responds the fastest gives the IP address which directs your browser to that server. However, when the domain name system security extensions (DNSSEC) is being used, the TLS encrypts the DNS request lookup.
As a result, we end up encrypting the TLS handshake and hiding the certificate name. Essentially, DNSSEC adds cryptographic signatures to existing DNS records.
Network proxies will become useless
The common network architecture is designed for web applications to use Internet relays to either permit or deny, log and understand a user’s intended destination. Ultimately, encrypting DNS queries will make network proxies useless.
However, privacy advocates, such as Google, are all for this and will be shipping TLS 1.3 in Android 8.1 and in the coming versions of Google Chrome. In a world of BYOD, it’s going to be exhausting to stop this transition.
The process of encryption is making us think differently about the network design. Google amplified the use of TLS by casting sites that were encrypted higher up in the search engine rankings than the non-encrypted sites. Hence, for this reason, it is now estimated that over 70% of the pages in the US are delivered with encryption.
Encrypting and corresponding network implications
Ideally, this has implications for big networks. As a network operator whether you work in the enterprise, or ISP, two questions often surface in mind; how do you identify the session and how do you troubleshoot it? TLS encrypts after the TLS header so you can still look at the TCP session information such as TCP retransmits and window sizing. However, is this enough?
You can’t identify and control which sites the users are going to. This way, you lose the ability to control and log. Additionally, network operators can’t troubleshoot as they can’t identify which sessions are going where. They can, however, enter through the backdoor by looking at the IP addresses but that’s quite challenging especially if you are going somewhere in the cloud, like, AWS.
Factually, the introduction of TLS 1.3 will introduce limitations to caching. A lot of ISPs and enterprises use wide area application services or content distribution services to cache information locally. Common large email attachments, screens for common applications, such as Salesforce can all be cached locally but with TLS 1.3 they cannot be.
Squarely, the most controversial part of 1.3 is the part called the server name indications (SNI) and whether that gets encrypted or not. One of the workarounds is not to encrypt the SNI. The second potential workaround is for cloud applications and others to share their encryption keys to the proxies and ISPs. This way, the information to determine the client usage can be decrypted. The 3rd option is to delay the rollout TLS 1.3.
But why would you delay something that brings so many benefits? TLS 1.3 offers a standard and robust security model; both for the setup and encryption. A major drawback of TLS 1.2 is that you could actually use different encryption algorithms, which are not as secure or, have known vulnerabilities. Contrarily, TLS 1.3 only includes support for algorithms with no known vulnerabilities.
As a matter of fact, we have a conflict of interest. The network operators, ISPs and enterprises don’t want to lose visibility, but users and cloud providers like Google are pushing for TLS1.3. Most likely TLS 1.3 will become a reality, which is expected to present many problems to the WAN optimization and SD-WAN vendors.
Effects on WAN optimization and SD-WAN vendors
Today, the WAN optimization market is getting hit hard by the introduction of TLS encrypted traffic. This tough trail is compounded by the fact that there has already been a rapid growth in real-time voice and video traffic over the network. Ultimately, this has led to a decline in the WAN optimization market. As a result, many WAN optimization vendors are entering the SD-WAN market.
However, the SD-WAN market is going to be impacted with the introduction of DNS over TLS. Some SD-WAN vendors need to use DNS to provide automatic application identification schemas.
Authentically, automatic application identification is the process by which SD-WAN vendors examine the TCP/UDP port numbers to identify applications such as web or email traffic. Then DNS is employed to identify the application using the underlying service.
A potent workaround that some SD-WAN vendors can execute is to use the TLS setup process for the application identification and network prioritization parts. Then they can use a session state-aware device to carry out the reverse DNS lookup on the destination IP.
Once a session state-aware device such as a firewall or a proxy is in the traffic path, it tracks and ties all packets in the flow as opposed to simply forwarding them as a layer 3 device would do.
Alternatively, you could use the TLS setup process to extract the DNS name. This too requires the device in the traffic path to be session state-aware. Essentially the ideal workaround is to have a device that is session state-aware.
This article is published as part of the IDG Contributor Network. Want to Join?