I have seen that most companies use the TLS1.2 protocol, why not use the TLS1.3?
My question here is, what are these pros and cons of both, and currently what is a better option?
3
-
1One word: support. Not all servers and not all browsers support 1.3– schroeder ♦Commented Jan 11, 2020 at 22:06
-
security.stackexchange.com/questions/166855/… and support.cloudflare.com/hc/en-us/articles/… and en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers– schroeder ♦Commented Jan 11, 2020 at 22:07
-
And here's a monthly survey of sites using TLS versions: ssllabs.com/ssl-pulse– schroeder ♦Commented Jan 11, 2020 at 22:15
Add a comment
|
3 Answers
... what are these pros and cons of both and currently what is a better option?
If TLS 1.3 is possible you should use it since it has a faster TLS handshake and encrypts not only the application payload but also parts of the TLS handshake like the certificate. TLS 1.2 is not insecure though, i.e. you can continue to use it.
The best is currently to support both on the client and server side: if a client supporting only TLS 1.2 connects to a server supporting both the server will automatically pick TLS 1.2. Similar if a client supporting both connects to a server supporting only TLS 1.2 then TLS 1.2 will be used by both too.
answered Jan 11, 2020 at 22:16
The pros of using TLS 1.3 are that it is more secure. It mandates things like perfect forward security, removes support for insecure crypto-primitives like MD5, adds new more secure ciphers, etc.
The cons of using TLS 1.3 is that it's so new (August 2018) that it's not often supported by underlying tools, and if it is it's often only supported under the latest and greatest versions.
Deploying new versions of anything is expensive. Software must constantly be maintained. Upgrading to new versions requires testing, may break existing infrastructure, etc.
Which is better is a matter of priorities and requirements for the specific case. The reason you're not seeing a lot of TLS 1.3 servers in January 2020 is because there's not a compelling reason to upgrade, and organizations have other priorities.
We've been through this before. As I write this in January 2020, TLS 1.0 is still supported by major browsers, but this will change in March of 2020, and TLS 1.0 and 1.1 will be deprecated. TLS 1.2 came out in August of 2008, but yet it's taken 11+ years for it to replace older versions of SSL/TLS. So often times protocol support moves slowly. For example, according to project dataspere TLS 1.2 was only turned on by default in Firefox 27, released on Feb 14, 2014. This is almost 6 years after the specification was released.
answered Jan 11, 2020 at 23:05
-
While it may disable support for things like MD5 that any security concious person should disable, it also mandates allowing 128 bit AES connections, which are considered by at least one high-profie body (SSLLabs) to be insecure enough to grade it at a lower cipher strength. While I can understand the benefit of having it in there as an option, servers being forced to alllow it makes TLS 1.3 potentially less secure in at least one way compared with TLS 1.2, according to standards all but hard-coded now. Commented Apr 26, 2020 at 10:08
-
@What'sinaGoogleSearch I'm not sure what you mean that 128 bit AES is considered insecure. Certain modes of AES (largely ECB) aren't as secure,but I don't think this is used in SSL. Until we get extremely good quantum computers (which may take 50+ years), 128 bit keys are highly secure, and not any less weak in any meaningful way than 256 bit keys. Commented Apr 27, 2020 at 13:38
-
SSLLabs, which is referenced by user @schroeder as a useful source, downgrade any websites using 128 bit AES as regards cipher strength. This has been discussed in the community and SSLLabs are without doubt aware, yet after a couple of years since they last become aware of this debate, they have not changed their decision to derank 128 bit AES. Make of that what you will. Commented Apr 27, 2020 at 17:11
-
In addition, regarding 128 bit itself, your figures only hold true of a brute force attempt with no prior knowledge, not for an attacker beginning from a position of partial knowledge via, for example, side-channels. As such the belief that a particular key strength is the most that offers protection based purely on the math surrounding a zero knowledge attack is not giving a full picture. Commented Apr 28, 2020 at 7:36
-
@What'sinaGoogleSearch Can you please provide a reference that any cipher combo using 128 bit AES is downgraded in score by SSL labs? I don't know that what you're saying is true. There's many combinations of AES and hash algorithms, so I'm really not sure what you're referring to. Commented Apr 28, 2020 at 18:44
If your computer has tls1.3 is because it was compiled with openssl newers versions for linux and similar libraries/support/security updates when referring on windows and so on (That means the "If possible" in Steffen answer)
You may take in account also even if you have tls1.3 support on your OS (I mean those shared compiled libraries) your software to use this security functionality, maybe Mozilla, or others development like Python can have tls1.3 support statically compiled or linked in some ways that finally can make use of this one without needing OS support but precompiled "inside". This same history is valid for the computer/cloud on the server side for them to have tls support
Long story short, many users (not only computers of client/servers but you might want think on phone apps, embedded electronic field systems) still doesn't have support for tls1.3 these days so the "migration" could be a pain in the ass for them because is work for achieving "nothing" new apparently I'm terms of functionality, however you may look some blogs and dates to check tls1.2 already has its flaws and it is an older guy that companies still believe is full secure but I think this has to change (Even phones and all electronic stuff these days are powerful/automated enough to maybe start consider obsolete to our closed friend tls1.2 in a near future)
About client/server "picking versions" automatically ... Yes and No ... Please look this examples
- Suppose a server that has tls1.3 but also likes tls1.2, when handshake occurs and client request have support for 1.2 then everything is fine
- The same as previous but client says it has 1.1 the the server rejection will blow up the entire socket connection, and actually 1.1 and backwards are considered totally insecure so the only real valid is 1.2 and 1.3
- Can happens that a bad developer on the server side simple doesn't know about this rejection is possible and let's the defaults, then the server uses tls1.1 or lower and do downgrades to totally insecure connection and server just accept this (not common on serious enterprises but can happens)
Hope this can clarify the monster of tls similar to "just a better way to encrypt socket connection" (tcp normally) using a "better handshake" when the version is higher and this happens on the first talk of each other so the entire socket talk is hard to understand for hackers (for example an entire http message and whatever application layer you can think of like mqtt and so on)
