41

What are the main vulnerabilities of TLS v1.1? Actually, no RFC describes v1.1 vulnerabilities, neither what pushed them to change to the new protocol 1.2 except the description given in section 1.2 of RFC 5246.

Please note that I do not mean implementation vulnerabilities, I am only looking for issues with the protocol itself.

Improve this question
6
  • 1
    Section 1.2 clearly describes why they made a new version (more flexibility, cleanups...) and the reason was not the fixing of vulnerabilities of TLS 1.1 so nothing was done in this area.
    – Steffen Ullrich
    May 13, 2014 at 16:48
  • 2
    @SteffenUllrich what about Lucky 13 attack ? Wasn't it solved thanks to AEAD ?
    – melostap
    May 14, 2014 at 7:36
  • 1
    @melostap: yes, but this was not the reason for TLS1.2. TLS1.2 was done 2008, while Lucky 13 was first reported 2013. So in a way TLS1.2 can fix problems with lower TLS versions, but only if you use the appropriate GCM ciphers.
    – Steffen Ullrich
    May 14, 2014 at 7:55
  • 1
    @SteffenUllrich I see what you mean. And what about CRIME, TIME, and BREACH attacks ? Was that the same context ?
    – melostap
    May 14, 2014 at 8:10
  • 2
    @SteffenUllrich I wish I could close this topic with your comment and answer, but I sadly can't. Anyway, thanks for our help.
    – melostap
    May 15, 2014 at 8:54

2 Answers 2

Reset to default
35

There is no "real" security issue in TLS 1.1 that TLS 1.2 fixes. However, there are changes and improvements, which can be argued to qualify as "fixing". Mainly:

  • The PRF in TLS 1.1 is based on a combination of MD5 and SHA-1. Both MD5 and SHA-1 are, as cryptographic hash functions, broken. However, the way in which they are broken does not break the PRF of TLS 1.1. There is no known weakness in the PRF of TLS 1.1 (nor, for that matter, in the PRF of SSL 3.0 and TLS 1.0). Nevertheless, MD5 and SHA-1 are "bad press". TLS 1.2 replaces both with SHA-256 (well, actually it could be any other hash function, but in practice it is SHA-256).

  • TLS 1.2 allows the use of authenticated encryption modes like GCM. This can replace the more traditional CBC encryption mode, which has historically been a source of many flaws. Properly implemented CBC encryption is still fine; however, it appears that properly implementing CBC encryption is easier said than done. Getting GCM right seems a more readily achievable goal.

  • TLS 1.2 mandates support for TLS_RSA_WITH_AES_128_CBC_SHA whereas TLS 1.1 required only TLS_RSA_WITH_3DES_EDE_CBC_SHA. Thus, if you use TLS 1.2 then you have a "guarantee" that AES encryption will be available. (This is not in fact completely true: the guarantee holds only as long as no "application specific profile" mandates otherwise. Also, you will get AES only if both client and server support it, and if they both support it, then it is available, regardless of whether TLS 1.1 or 1.2 is used.)

To summarize, it's not a bad idea to patch your servers to support TLS 1.2 and configure them to prefer it over TLS 1.1, but there is no real flaw in TLS 1.1 that needed fixing and would make a switch to TLS 1.2 mandatory or even recommended. The main drive for TLS 1.2 adoption is the usual pavlovian craving for anything new and shiny.

Improve this answer
13
  • 21
    Is this answer still accurate? Any updates to this for 2017?
    – Craig London
    May 16, 2017 at 21:01
  • 3
    @AgapwIesu This is not a question of "Keeping your servers patched and up to date is a basic security practice". It's a question of whether you should support backwards compatibility for older clients. I agree fully with Tom that you should configure your servers to prefer TLS 1.2, but there's no need (yet) to reject a connection if the client only supports up to TLS 1.1.
    – Mike Ounsworth
    May 31, 2018 at 19:59
  • 2
    @MikeOunsworth If it's a matter of backwards compatibility, I agree. But Tom's response of adopting TLS 1.2 as "pavlovian" sounds a bit silly in 2018, when TLS 1.2 is quite common and provides a bit more safety. In May 2014 IIRC not many browsers supported TLS 1.2, and server implementations were sparse, so I could see the point then. It's a much different story in May 2018 where the implementations have caught up with the standard.
    – Steve Sether
    May 31, 2018 at 21:20
  • 2
    There's a distinction between staying up to date and supporting all secure protocols, allowing clients to negotiate the highest protocol they support, versus actively blocking older protocols which have no known vulnerabilities. Staying up to date means adding support for newer versions, maintaining support for all non-vulnerable versions, and blocking negotiation for vulnerable versions. This is the happy balance of security and compatibility. The question of whether TLS 1.1 is secure is a different question of whether one should support it. The former informs the latter.
    – AaronLS
    Feb 6, 2019 at 15:22
  • 2
    @EakanGopalakrishnan PRF => pseudo-random function
    – Rowan Thorpe
    Jun 24, 2020 at 6:52
10

Sticking with TLS 1.0 is a very bad idea and pretty unsafe. Can be POODLEd, BEASTed and otherwise padding-Oracled as well. Lots of other CVE weaknesses still apply which cannot be fixed unless by switching TLS 1.0 off.

Sticking with TLS 1.1 is only a bad compromise though it is halfway free from TLS 1.0 Problems (but since both protocols do not provide any modern cipermodes which are essential today, the modern encryption methods do not work here)

TLS 1.2 with CBC Ciphers ON and also RSA on is kind of a lotteryplay wether your connections are entirely safe or not. Which depends on how the ciphers are implemented on either side of the Connection (Server <-> Clientbrowser).

Recommended opmode as of now: TLS 1.2 without any CBC Ciphers (that means also plain RSA handshakes off) is safe enough only TLS 1.3 is safer because of its handling improvement and the exclusion of everything that went obsolete since TLS 1.2 came up.

(assuming all other unsafe 64bit including 3DES and RC4 ciphers are already disabled)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .