39

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.

Anders
  • 64,406
  • 24
  • 178
  • 215
melostap
  • 565
  • 1
  • 4
  • 8
  • 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 07: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 07: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 08:10
  • @melostap: these three rely on compression, either by TLS or of the application itself. Nothing changed with TLS1.2 – Steffen Ullrich May 14 '14 at 09:15
  • 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 08:54

2 Answers2

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.

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • 20
    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 https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/. 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 '18 at 09:45
  • 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 '18 at 19:59
  • @TomLeek feel free to roll back or modify my edit. – Mike Ounsworth May 31 '18 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 '18 at 21:20
  • 1
    @MikeOunsworth - When you say, like Tom did, that "the main drive for TLS 1.2 adoption is the usual pavlovian craving for anything new and shiny," you are not just calling for backward compatibility. You are putting down a basic security practice (keeping your servers updated) as a mindless instinct. – AgapwIesu Jun 01 '18 at 15:54
  • @SteveSether - I agree with you, and Mike, that providing for backwards compatibility is a given necessity. I would say that even now, preferring 1.2, but allowing 1.1 should be the default. But I would argue that thinking of 1.2 adoption as pavlovian should have sounded silly even in 2014. Sure, we did not know of any existing vulnerabilities in 1.1 at the time, but the history of encryption and secure protocols should teach us that it's just a matter of time, and that it is unwise to wait until a vulnerability has been proven, with an exploit, before we update a server. – AgapwIesu Jun 01 '18 at 16:06
  • @AgapwIesu I recall a number of years ago looking into upgrading to 1.2. IIRC in 2014 it was't very easy to do for lack of tool and browser support, so you couldn't really expect any sort of real tangible benefit. My point is more that it's not about waiting for exploits, it's about waiting for implementations and tools to catch up. I can't really perfectly recall this of course, but I definitely have a distinct memory of being frustrated by lack of library support for 1.2 somewhere around the mid 2010s. – Steve Sether Jun 01 '18 at 16:23
  • @AgapwIesu Some quick googling reveals my memory isn't too off. TLS 1.2 support was only added to Chrome at of Chrome 30, released in Oct 2013. And enabled by default in FF 27, released in Feb 2014. It sounds pretty reasonable in 2014 to not just push for automatic upgrades only a few months after the most progressive browsers added support for it. – Steve Sether Jun 01 '18 at 17:29
  • Also, in further defense of holding off on non-needed upgrades, I'd say it's far better to let others be the guinea-pigs of new technology. A new implementation of TLS means new risk of vulnerabilities in the new code, and new protocol. TLS 1.3 is about to come out, and it adds newer, better, and more secure protections like mandating PFS. Is it better? Yes. Should you upgrade? Depends on tool support, your tolerance for implementation bugs, and the amount of time and resources you have. I might give you a different answer in 10 years however. (For comparison, TLS 1.2 came out in 2008) – Steve Sether Jun 01 '18 at 17:45
  • 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 06 '19 at 15:22
  • What on Earth is PRF in this context? – Eakan Gopalakrishnan Jan 07 '20 at 15:51
  • 2
    @EakanGopalakrishnan PRF => pseudo-random function – Rowan Thorpe Jun 24 '20 at 06: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)

Bernd P
  • 101
  • 1
  • 3