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.

  • 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 '14 at 16:48
  • 2
    @SteffenUllrich what about Lucky 13 attack ? Wasn't it solved thanks to AEAD ? – melostap May 14 '14 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 '14 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 '14 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 '14 at 8:54

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.

  • 13
    Is this answer still accurate? Any updates to this for 2017? – Craig London May 16 '17 at 21:01
  • The sense of this answer is wrong. Look at acunetix.com/blog/articles/…. There are serious issues in sslv3, tls1 and implementations of tls1.1. This answer will leave most people thinking it is ok to stick with older versions of the secure layer protocol, and that is wrong. The reasons for the drive for TLS 1.2 adoption are not only pavlovian. Keeping your servers patched and up to date is a basic security practice. Saying there is no flaw that "would make a switch to TLS 1.2 mandatory or even recommended" is at best misleading. – AgapwIesu May 24 at 9:45
  • @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 at 19:59
  • @TomLeek feel free to roll back or modify my edit. – Mike Ounsworth May 31 at 20:05
  • 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 at 21:20

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.