michelangelus - Fotolia
There a number of attacks targeting the SSL/TLS protocol that have put secure Internet communications at risk. These attacks include BEAST, CRIME, BREACH, RC4 Attack, Renegotiation Attack, Lucky Thirteen, BERserk, Truncation Attack and Triple Handshake Attack.
The growing number of these attacks is so great a concern that the Transport Layer Security (TLS) Working Group of the Internet Engineering Task Force (IETF) is working on a new version of the protocol, TLS 1.3, to address the vulnerabilities that have been exposed over the past few years, reduce the chance of implementation errors, and remove features that are no longer needed.
In this tip, I will discuss some of the updates that will help address vulnerabilities and improve secure Internet communications.
TLS 1.3 updates and improvements
TLS 1.3 will be based on the earlier TLS 1.1 and 1.2 specifications, but without unnecessary options and functions, such as support for compression and non-AEAD (Authenticated Encryption with Associated Data) ciphers. Removing the code that implements features no longer needed will reduce the chances of potentially dangerous coding errors and immediately reduce the attack surface.
The IETF has also decided to move away from RSA-based key transport in favor of protocols that support perfect forward secrecy (PFS) and are easier to analyze. TLS has had cipher suites based on RSA key transport since SSL 2.0, but confidence in RSA has been shaken over the past few years. Fact of the matter is, cryptanalysts are constantly improving at factoring large numbers. RSA derives its security from the difficulty of factoring large numbers, which means RSA key lengths are having to be increased to maintain security, which in turn slows down the encryption process.
Cipher suites that use RSA for authentication and key exchange are protected solely by the server's RSA private key. If the key is compromised now or sometime in the future, all handshakes using these cipher suites will be compromised. RSA certificates will still be allowed in TLS 1.3, but a key establishment will be via Diffie-Hellman (DH) or Elliptic curve Diffie-Hellman (ECDH). Using DH or ECDH algorithms for key exchange ensures PFS as a new key is negotiated for each handshake. Support for HMAC-SHA256 cipher suites has been added while the IDEA and DES cipher suites have been deprecated.
Reducing implementation flaws with TLS 1.3
Implementation flaws have always been a big problem with any encryption technology, and TLS is no exception. The infamous Heartbleed bug was a result of a surprisingly small bug in a piece of logic that relates to the OpenSSL implementation of the TLS heartbeat mechanism, which is designed to keep connections alive even when no data is being transmitted.
Another example is a variant of the POODLE attack that exploits certain implementations of the TLS protocol, which don't correctly validate encryption padding. This makes some servers vulnerable to POODLE even if they disable SSL -- one of the recommended techniques for countering a POODLE attack.
Making TLS easier to implement will reduce the chances of implementation errors putting the Internet community at risk. The IETF's Using TLS in Applications (UTA) working group will offer common guidelines and best practices for using TLS in applications, such as the use of the latest crypto algorithms and eliminating the use of older TLS/SSL versions, as well as guidance on how certain applications should use the encryption protocol. To promote interoperability among encrypted systems, the UTA is also working on guidance for using TLS with the instant messaging protocol XMPP and with email client protocols POP, IMAP and SMTP Submission -- a variant of the SMTP protocol.
The '1 round trip time' handshake
TLS 1.3 is being designed to allow for a "1 round trip time" or "1-RTT" handshake by changing the order of messages sent when establishing a secure connection between a server and client.
When using TLS 1.3, the client will send a Client Key Exchange message containing its cryptographic parameters for key establishment before a cipher suite has been negotiated. This will allow a server to calculate the keys for encryption and authentication before sending its first response. Reducing the number of packets sent during this handshake phase will not only speed up the whole process, but also reduce the attack surface.
The TLS 1.3 protocol will have a backwards compatibility mode; if the client's cryptographic parameters don't match the cipher suites supported by the server, it will send a Server Hello message with a valid cipher suite and restart the handshake.
Note that TLS 1.3 is still a draft and has not been finalized. However, having an updated protocol that's faster, more secure and easier to implement is essential to ensure the privacy and security of information exchange and to maintain trust in the Internet as a whole.
About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with over 20 years of experience in the IT industry. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. He was also formerly a Microsoft Certified Database Manager and a registered consultant with the CESG Listed Advisor Scheme (CLAS). Mike has a passion for making IT security best practices easier to understand and achievable. His website www.hairyitdog.com offers free security posters to raise employee awareness of the importance of safeguarding company and client data and of following good practices.
Check out SearchSecurity's latest SSL and TLS security news and advice
Learn how education and technology can improve SSL/TLS security