TLS 1.3 has a Trust Problem

The final version (draft) for TLS 1.3 is ready, the problem is that several organization, especially from the USA and several banking pages & Anti-Virus developers, constantly fighting the upcoming (and most secure) protocol. Who will be in control?!

tls-1.3-handshake-performance
TLS 1.3 handshake performance. Picture Source: GitHub

TLS 1.3 vs TLS 1.2

The Internet Engineering Task Force (IETF) is the group that has been in charge of defining the TLS protocol, which has gone through many various iterations. The previous version of TLS, TLS 1.2, as defined in RFC 5246 and has been in use for the past eight years by the majority of all web browsers. As of March 21st, 2018, TLS 1.3 has now been finalized, after going through 28 drafts.

Companies such as Cloudflare are already making TLS 1.3 available to their customers. Filippo Valsorda had a great talk (see presentation below) on the differences between TLS 1.2 and TLS 1.3. In short, the major benefits of TLS 1.3 vs that of TLS 1.2 is faster speeds and improved security.

Improved Security With TLS 1.3

A big problem with TLS 1.2 is that it’s often not configured properly it leaves websites vulnerable to attacks. TLS 1.3 now removes obsolete and insecure features from TLS 1.2, including the following:

  • SHA-1
  • RC4
  • DES
  • 3DES
  • AES-CBC
  • MD5
  • Renegotiation
  • CBC MtE modes (POODLE, Lucky 13 or Vaudenay)
  • Arbitrary Diffie-Hellman groups — CVE-2016-0701
  • EXPORT-strength ciphers – Responsible for FREAK and LogJam

Browser Support

With Chrome 63, TLS 1.3 is enabled for outgoing connections. Support for TLS 1.3 was added back in Chrome 56 and is also supported by Chrome for Android. TLS 1.3 is enabled by default in Firefox 52 and above (including Quantum). They are retaining an insecure fallback to TLS 1.2 until they know more about server tolerance and the 1.3 handshake. Some SSL test services on the Internet don’t support TLS 1.3 yet and neither do other browsers such as IE, Microsoft Edge, Opera, or Safari. It will be a couple more months while the protocol is being finalized and for browsers to catch up. Most of the remaining ones are in development at the moment.

TLS 1.3 wrongly advertised as more secure without mention that it gets pre-keyed

The bitch-fight about the protocol was real, I’m not joking. IETF not want to give away the keys while mostly all other organizations want the keys. There huge doubts from me and others that the IEFT changes his mind under so many pressure to change the draft in order to allow pre-keyed connection (Wiretapping). This would mean if your bank wants to see what’s going on they could look in your traffic without that you ever notice.

The future is dark, more spying, more re-CAPTCHA’s and more ways to get your data

Because of secure protocols and other mechanisms to avoid being fingerprinted we are getting more and more mechanism which tries to get you even behind a VPN, CAPTCHA’s are not only existent to prevent DOS attacks, there can also identify you (not entirely but partially). You can bet that more mechanism are coming – and there will be no solution.

Closing Words (no conclusion!)

TLS 1.3 is a step forward but none of it matters when the encryption can be bypassed with the keys which are (maybe?) hand over to several organizations. IEFT can promise us much when you can’t inspect the traffic in order to verify their words or not – that’s the thing here. There both sides of one medal here, security and speed Vs encryption.

I have several doubts that several organizations not going to bypass this, the draft took over 4 years to be completed which gave them enough time to find and build strategies to get the data. I also don’t like that every AV product wants to inspect the traffic, I get the part that this is necessary in order to find malware but on the other side you can’t trust them because they might use this knowledge to sell such data to get even more money or if the government secretly forces them – you only hear about it when it’s already too late.

On paper, everything looks good but what I don’t like is that no one talks about possible weaknesses and that’s, in my opinion, a problem because it looks like they want to hide something.

IS TLS 1.3 enough? No, there is no reason to relax and it anyway takes several more years until 1.3 gets the default which is in my opinion way to slow. blink

Resource

  • TLS 1.3: better for individuals – harder for enterprises (ncsc.gov.uk)
  • Google Search Console Notifying Webmasters Of TLS Upgrade Requirements (seroundtable.com)
  • TLS 1.3 and Proxies (10 Mar 2018) (imperialviolet.org)
  • Why TLS 1.3 isn’t in browsers yet (blog.cloudflare.com)
  • The Transport Layer Security (TLS) Protocol Version 1.3 draft-ietf-tls-tls13-28 (tools.ietf.org)
  • A Cryptographic Analysis of the TLS 1.3 Handshake Protocol Candidates [PDF](eprint.iacr.org)
  • Implementing and Proving the TLS 1.3 Record Layer [PDF] (microsoft.com)
  • IETF Live (ietf.org)
  • TLS 1.3 Option for Negotiation of Visibility in the Datacenter draft-rhrd-tls-tls13-visibility-00 (tools.ietf.org)
  • IETF Policy on Wiretapping (tools.ietf.org)
  • tinfoil: TLS Is Not For Obligatory (Or Ostensibly Optional) Interception, Luckily (github.com)
  • On Consensus and Humming in the IETF (tools.ietf.org)
  • [TLS] Update on TLS 1.3 Middlebox Issues (ietf.org)

Comments are closed.

Blog at WordPress.com.

Up ↑

%d bloggers like this: