Subscribe Now

* You will receive the latest news and updates on the Canadian IT marketplace.

Trending News

Blog Post

Universal TLS
SECURITY SHELF

Universal TLS 

TLS’s predecessor, Secure Sockets Layer (SSL), was developed by Netscape. Version 1 was never publicly released because of serious security flaws. Version 2 was released in February 1995 and was found to contain a number of security issues, leading to the design and release of version 3 in 1996. TLS version 1.0 was published in January 1999, followed by version 1.1 in 2006. Version 1.2 was published in 2008 and remains the current version.

Over the years, it has been necessary for clients and servers to support multiple versions of SSL and TLS to maximize compatibility. In practice, all versions of SSL and TLS version 1.0 are deprecated, while TLS version 1.1 and 1.2 have no known security flaws (assuming that appropriate controls are in place with respect to certificates and the choice of cipher suites). TLS provides strong privacy protection when properly configured.

Dozens of network protocols are in widespread use today. Some, such as HTTPS, SSH, SFTP, OpenVPN, and IPSec are relatively secure. Others, such as SMTP, POP3, and IMAP include TLS-encapsulation options.

SMTP is perhaps the most interesting because it allows for opportunistic encryption. Once the initial TCP session is established, the SMTP server may signify that it is TLS-capable. The client can then start a TLS session within the existing SMTP connection. But in most cases, an attacker who obtains privileged network-level access anywhere between the client and server can avoid the opportunistic TLS session being established. It is possible to configure mandatory TLS on a per-destination basis, but that requires prior knowledge of where mail will be sent.

At the insecure end of the spectrum, DNS, SIP, RTP, and many instant messenger protocols include no confidentiality functionality. As a result, some data in transit is always encrypted, some is sometimes encrypted, and some is never encrypted. In addition, the use of various TCP and UDP ports allows attackers to profile encrypted communications. TCP/443 is probably HTTPS, TCP/993 is likely someone retrieving email via IMAP over TLS, and TCP/25 is virtually always SMTP.

As some developers work on securing their protocols, one question begs an answer: What would happen if everything on the Internet used TLS?

At the risk of stating the obvious, TLS, like any other encrypted protocol, involves more overhead than a plain-text TCP session. This is one of the major challenges facing web server owners who wish to move exclusively to HTTPS. It is also presents an issue for applications that currently leverage UDP datagrams to achieve scalability. A basic desktop PC can easily handle hundreds or even thousands of SIP messages per minute. TLS can be implemented over UDP (OpenVPN does it now), but a significant throughput decrease will result. It will increase costs and session initiations will take longer.

Some developers may believe they can achieve better performance with their own implementation. While possible, very few people have the skills required to implement a secure encryption protocol; even experts make mistakes. The chances of getting session security right are much higher with TLS.

There are always arguments to be made against change, and moving protocols such as DNS to TLS will require a lot of work. But universal TLS adoption has the potential to dramatically improve Internet security. Imagine if every Internet communication was encapsulated within a TLS session addressed to a single TCP or UDP port. All an attacker would observe is a sea of encrypted connections.

Instead of simply looking at the TCP or UDP port to determine the protocol, even the most sophisticated adversaries would have to resort to much more expensive and less accurate traffic analysis techniques to differentiate between web, email, IM, and VoIP traffic. Universal TLS might be the answer.

Have questions you’d like answered in a future column?  Email eric.jacksch@iticonline.ca

Related posts