Not logged in » Login

Recent Discussion:

NunoCosta | 02.06.2020, 17:25
Hi mlegrafleitas.Thank you for your question.We are working on providing you the best answer, I'll g...
mlegrafleitas | 01.06.2020, 17:28
Hi everyone,Need your help to compare this 2 Storage from FUJITSU and DELL because I have a customer...
HarryD | 24.03.2020, 08:46
Thank you all for helping out.The problem has been solved.
Jun 26 2018

IETF Plans to ‘Kill’ TLS 1.0 and 1.1

The Internet Engineering Task Force (IETF) has announced plans to retire old editions of the Transport Layer Security Protocol (TLS) as soon as possible.

Since their inception in the 1990s, TSL and its immediate predecessor Secure Sockets Layer/SSL have provided core functionalities that are necessary to carry out secure, trustworthy business transactions via the Internet, namely in areas like online banking and general order/payment services. But while they're among the most popular protocols – pretty much every netizen knows and appreciates the https traffic sign in their browsers' search bars – both standards have always been subjected to rigorous security tests whose results then led to the deprecation and replacement of traditional with more modern and secure protocol versions. In other words, such swaps are a pretty common procedure, but may nonetheless take years to be completed: as of this summer, many online retailers still appear to be using TSL 1.0 or even SSL 3.0 to set up 'secure' connections to their web shops, even though the payment card industry had already recommended an upgrade to TLS 1.1 or higher some three years ago. Against this backdrop, a new Internet Draft that was released by the IETF early last week and has been colorfully entitled "tls-oldversions-diediedie" may well be regarded as a means to enforce the implementation of TLS 1.2 (the current safe standard, first released in 2008) or its successor TLS 1.3, which is due for release in a couple of weeks.

The plan to 'kill' TLS 1.0/1.1 is a result of technical limitations that basically rendered these standards useless:

  • They require implementation of weak cipher suites that are no longer desirable because of security considerations, since they either have already been broken or are easy to break, e.g. TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, which is mandatory under TLS 1.0
  • Lack of support for current recommended cipher suites, especially using AEAD ciphers which are not supported prior to TLS 1.2
  • Support for four protocol versions increases the likelihood of misconfiguration
  • Developers plan to drop support for TLS 1.0 and 1.1. in upcoming releases of a at least one widely popular library; but products using such a library would still need to include some kind of backdoor to enable backwards compatibility, which is both technically and commercially undesirable

As expected, the draft calls for the deprecation or upgrade of several RFCs – namely, numbers 2246, 4346, 5246, and 7525 – with the aim of establishing TLS 1.2 as a baseline standard and eliminating backwards compatibility with earlier versions by July 1, 2018. However, that deadline is already impossible to meet: Not only was the draft released way too late on June 18, but we all know from previous experiences that it takes about a year for these suggestions to be implemented and/or laid down in one or more new RFCs. Moreover, the idea of a "hard reset" clearly clashes with the aforementioned requirements put forth by the payment card industry that would demand backwards compatibility with TLS 1.1. Consequently, we'll be looking at some interesting discussions over the next 12 months.

 
SHARE

Comments on this article

No comments yet.

Please Login to leave a comment.

X

Please login

Please log in with your Fujitsu Partner Account.

Login


» Forgot password

Register now

If you do not have a Fujitsu Partner Account, please register for a new account.

» Register now