Categories
Deploy360 Improving Technical Security Transport Layer Security (TLS)

Deploying TLS 1.3

Last week saw the formal publication of the TLS 1.3 specification as RFC 8446. It’s been a long time coming – in fact it’s exactly 10 years since TLS 1.2 was published back in 2008 – but represents a substantial step forward in making the Internet a more secure and trusted place.

What is TLS and why is it needed?

Transport Layer Security (TLS) is widely used to encrypt data transmitted between Internet hosts, with the most popular use being for secure web browser connections (adding the ‘S’ to HTTP). It is also commonly (although less visibly) used to encrypt data sent to and from mail servers (using STARTTLS with SMTP and IMAP/POP etc..), but can be used in conjunction with many other Internet protocols (e.g. DNS-over-TLS, FTPS) where secure connections are required. For more information about how TLS works and why you should use it, please see our TLS Basics guide.

TLS is often used interchangeably with SSL (Secure Socket Layers) which was developed by Netscape and predates it as an IETF Standard, but many Certification Authorities (CAs) still market the X.509 certificates used by TLS as ‘SSL certificates’ due to their familiarity with users. It should be noted though, that all versions of the SSL protocol are now obsolete whilst TLS 1.0 is deprecated and should not be used.

How is TLS 1.3 improving things?

TLS 1.3 offers a number of technical advantages such as a simplified handshake to establish secure connections, and allow clients to more quickly resume sessions with servers. This should reduce setup latency and the number of failed connections on poor links that is often used as a justification for maintaining HTTP-only connections.

Just as importantly, it also removes support for several outdated and insecure encryption and hashing algorithms that are currently permitted (although no longer recommended) to be used with earlier versions of TLS, including SHA-1, MD5, DES, 3DES and AES-CBC, whilst adding support for newer cipher suites. Other enhancements include more encrypted elements of the handshake (e.g. the exchange of certificate information is now encrypted) to reduce hints to potential eavesdroppers, as well as improvements to forward secrecy when using particular key exchange modes so that communications at a given moment in time should remain secure even if the algorithms used to encrypt them are compromised in the future.

How can I use TLS 1.3?

So we’ve established that TLS 1.3 is a good thing for the Internet. but how can people actually take advantage of it? Of course, both the client and server need to have the ability to support TLS 1.3 to take advantage of the improvements, but the good news is that developers, vendors and service providers have been actively working to implement it for some time now, and it’s already supported by a number of applications.

Starting with web browsers, Google Chrome (including the Android version) from version 67 onwards, and Mozilla Firefox from version 61 onwards, already have support for TLS 1.3 by default. The latest version (54) of Opera also supports it, although it needs to be specifically enabled.

Apple has already implemented draft support for TLS 1.3 in both MacOS 10.13 and iOS 11, although this also needs to be specifically enabled.

With respect to server-side applications, many of these utilise TLS libraries and several of the more popular implementations including OpenSSL 1.1.1, GnuTLS 3.5.x, Google’s Boring SSL and Facebook’s Fizz are already supporting TLS 1.3. This should allow the protocol to quickly and easily be added to many widely used server applications, and indeed a number of Internet services including Google, Facebook, Akamai and Cloudflare are already supporting TLS 1.3 from compatible clients.

Microsoft does not yet support TLS 1.3 on any of its operating systems or in the Edge and Internet Explorer browsers, preferring to wait until the specification was finalised. It should be noted that early implementations of TLS 1.3 have been based on various versions of the specification (of which there were 28 in all), so a shakeout period will be required to bring implementations up to full standard, but this is likely to be short given the significance and importance of this protocol.

So what can possibly go wrong?

Well it’s not really a problem with TLS 1.3 per se, but whilst it has a mechanism to negotiate TLS 1.2 connections to those devices that can only support that protocol, there are a significant number of older applications that can only support earlier versions of TLS. As use of TLS 1.3 becomes more widespread and secure connections become expected, many devices and applications that cannot be upgraded may no longer be usable. However, the question that must be asked whether it’s advantageous or reasonable to keep supporting older protocols (e.g. TLS 1.0 and 1.1) when they become obsolete and potentially insecure?

The 0-RTT feature that allows data to be sent earlier when resuming secure connections to enable performance comparable with unencrypted handshaking, has been identified as having a potential weakness with respect to replay attacks (see Section 8 of RFC 8446). Nevertheless, replay attacks can happen with earlier versions of the TLS as well, and applications already need to implement specific restrictions on the scope of requests. 0-RTT can also be optionally turned off, or similarly limited in scope if this is a concern for particular types of application, and some guidelines for this can be found in RFC 8446.

Last but not least, many organisations implement middle box solutions to inspect and monitor traffic that is traversing their networks, particularly organisation have have strong regulatory and compliance requirements, This may be used identifying unauthorised or malicious communications, malware, or for monitoring self-signed or fake certificates for example, but as TLS 1.3 changes the handshake behaviour and encrypts certain parts of this (e.g. the certificate information exchange), this may affect middlebox functionality, downgrade TLS connections, or even prevent connections being made entirely.

The issue was identified during testing of early implementations of TLS 1.3, and changes made to allow certain features of the TLS 1.2 handshake to be replicated even though these are not actually necessary for the functioning of the new protocol. In addition, it’s still possible to implement other workarounds such as terminating all connections at the middlebox or distributing custom root certificates that allow decryption of the traffic, with the caveat there are resource and administrative practicalities to consider.

It should be appreciated though, that TLS 1.3 has been introduced to address some of the potential and actual vulnerabilities of earlier versions of the protocol such as the Triple Handshake, BEAST, FREAK and Logjam attacks. Whilst TLS 1.2 is not inherently a poor or even insecure protocol, it does require careful configuration to ensure obsolete cipher suites with identified vulnerabilities are not used in conjunction with it. TLS 1.3 removes the need to make these decisions, and brings significant performance improvements which should ensure there are no longer any reasons to be using unencrypted connections in future.

What You can do!

TLS 1.3 is being deployed now in browsers and many other applications, and in many cases you can already use it by selecting a browser that supports it. We also encourage you ask your IT teams, server administrators and developers to ensure that your sites and services support it, so we can collectively build a more secure Internet!

The Internet Society supports making encryption the new norm on the Internet, and our Deploy360 programme is developing resources on how to implement TLS in different applications.

Further Information

Categories
Improving Technical Security Technology Transport Layer Security (TLS)

TLS 1.3 – Internet Security Gets a Boost

Today marks the formal publication of an overhaul of the Transport Layer Security (TLS) protocol. TLS is an Internet standard used to prevent eavesdropping, tampering, and message forgery for various Internet applications. It is probably the most widely deployed network security standard in the world. Often indicated by the small green padlock in a web browser’s address bar1, TLS  is used in financial transactions, by medical institutions, and to ensure secure connections in a wide variety of other applications.

We believe the new version of this protocol, TLS 1.3, published as RFC 8446, is a significant step forward towards an Internet that is safer and more trusted.

Under development for the past four years and approved by the Internet Engineering Task Force (IETF) in March 2018, TLS 1.3 addresses known issues with the previous versions and improves security and performance, in particular it is able to establish a session more quickly than its predecessors. Because it is more efficient, TLS 1.3 promises better performance for the billions of users and organizations that use TLS every day. As with every IETF standard, TLS 1.3 was developed through open processes and participation, and included contributions from scores of individuals.

Many companies have indicated that they plan to implement and deploy TLS 1.3 in the near future and several have already done so. Part of their readiness can be traced back to the fact that the standard’s development was informed along the way by “running code” – test implementations that helped identify issues in and provide additional clarity to the specification, ensuring TLS 1.3 would not only look good on paper but that it would work well in the real world too. TLS 1.3 was also reviewed extensively by academic security and cryptography experts to help identify and address possible weaknesses before it was widely deployed.

A popular saying in the IETF community is that “there are no protocol police.” This reflects the reality that adoption of IETF protocols is voluntary and each network, enterprise, and Internet user is free to decide whether or not to use them. Given how widely TLS is deployed, it is inevitable that some challenges will be encountered as TLS 1.3 adoption gathers pace. Additional work may be required to address these challenges. However, on balance, TLS 1.3 represents a significant security win for the Internet and its users. We look forward to using it and tracking its adoption on the Internet.

See also:


1 – Editor’s Note: The TLS protocol is often mistakenly called “SSL” or “Secure Socket Layer”. SSL was the name of the original protocol developed by Netscape back in the mid-1990s. It was replaced by TLS 1.0 in 1999. (Yes, almost 20 years ago!) TLS 1.0 was in turn replaced by 1.1, 1.2, and now 1.3.

Categories
Deploy360 Transport Layer Security (TLS)

MPTCP and TLS 1.3 – Big Announcements from Apple

Apple recently announced some major changes to their operating systems across all platforms during their flagship developer conference WWDC. The Worldwide Developers Conference is where developers can attend sessions and meet with over 1,000 Apple engineers, and this event included a keynote introducing new software (iOS 11, macOS High Seirra and watchOS 4) and hardware (iPad Pro and HomePod) . The 2017 conference was held 5-9 June in San Jose, California, and apart from the other announcements, there are two major developments in the networking area.

  • Support of MPTCP (Multi Path TCP)
  • Support of TLS 1.3

MPTCP (Multi Path TCP) is defined by RFC6824, and has the ambition of enabling the simultaneous use of several IP-addresses/interfaces by modifying TCP to present a regular TCP interface to applications, whilst in fact sending data over several subflows. The benefits include better resource utilization, better throughput and redundancy. Apple has been using MPTCP for their Siri application since the release of iOS 7 in 2013, and according to the statistics presented during the WWDC – Advances Networking event, they have seen 20% (95th Percentile) faster user feedback and a 5 times reduction in network failure.

Apple considers this a great success and in iOS 11 they are opening up the API for MPTCP which they have specifically been using for Siri until now. This requires server support as well, but the good news is that many load balancers already support it, and whilst the main linux kernel doesn’t currently support it, a new kernel with MPTCP support is available from INL (IP Networking Lab, UCL – Belgium). AWS and GCE images are also available, whilst Android images are available for 4.4.x only. Geoff Huston (APNIC) has written a detailed blog on MPTCP.

TLS 1.3 (Transport Layer Security) – The underlying technology that enables secure communication on the Internet is a protocol called Transport Layer Security (TLS), which is an evolution of Secure Sockets Layer (SSL) developed by Netscape in the 1990s. TLS 1.0 was first defined in RFC 2246 in January 1999 as an upgrade of SSL Version 3.0, and was updated with TLS 1.1 that was defined in RFC 4346 in April 2006. The most recent  version, TLS 1.2, was standardized in RFC 5246 in 2008, and is currently supported by the majority of browsers and HTTPS-enabled web services. All TLS versions were further updated in RFC 6176 in March 2011, removing their backward compatibility with SSL so that TLS sessions will not negotiate the use of Secure Sockets Layer (SSL) version 2.0.

TLS 1.3 currently in its draft stage, and was first announced in April 2014. Since then it has undergone many changes, but is expected to become an Internet standard by the end of this year. TLS 1.3 has two main advantages over previous versions:

  • Enhanced security
    • Legacy options, ciphers, and key exchange algorithms removed
    • TLS 1.2 features that have been removed were associated with high profile attacks in the past
  • Improved network efficiency
    • TLS 1.2 requires two round-trips to complete the handshake
    • TLS 1.3 cut the initial handshake into half and require only one round trip.

TLS 1.3 is not enabled by default in iOS 11, but is a huge step forward for web security and performance. Apple also announced support for ECN (Explicit Congestion Notification) during their Advances in Networking session. If you want to check out other announcements, then you can find all the other sessions online.

Deploy360 also aims to help this process, so please take a look at our TLS section to understand why the use of TLS is important.