I am looking at all the green and red boxes here, and am wondering what it would look like if one were to "implement TLS" today? What should you implement if you were to implement TLS today?

  • Do you need to implement all of the previous versions? (SSL 1-3, TLS 1.0-1.3)
  • Do you need to implement all the cryptography algorithms, or just the TLS 1.3 ones? (RSA is not used in TLS 1.3 it looks like, but is the standard for HTTPS as far as I know, for example).
  • Do you need to implement all the ciphers, or just the TLS 1.3 ones?

Rather than trying to describe what needs to be implemented in order to support TLS today, the simpler question is do browsers support TLS 1.3? If not, why not? This leads to the above questions, plus...

In order to fetch "older" websites, do you need to support older TLS protocols? Or can you have, let's say, a brand new TLS 1.3 implementation that only implements the following, and be good to go in terms of communicating with "older" sites and services? Basically TLS 1.3 seems to only implement:

  1. DHE-RSA
  4. AES GCM
  5. AES CCM
  6. ChaCha20-Poly1305
  7. AEAD

That's only 7 things, meanwhile there are about 20 key exchange algorithms in the full range of TLS/SSL versions from SSL 1.0 to TLS 1.3, and about 20 ciphers, and 6 data integrity algorithms.

Basically, in order to support browsing the web if TLS was implemented today in a new open source project for example, would it only need to write the code for those 7 things, or all 20 + 20 + 6 ~ 46 algorithms, basically supporting all SSL and TLS versions of the past?

I am basically confused as to what needs to be implemented to support secure web browsing in the 21st century, given that everything before TLS 1.3 has been found to be insecure (it seems like). The answer to this question would help me come up with a project scope on what it would take to implement TLS properly today.

If you can't just implement TLS 1.3 (and need to support the older TLS/SSL versions), what happens if you only had TLS 1.3? What about only TLS 1.3 and 1.2? etc. Basically, what handicaps do you have by only supporting the latest version. Does it mean simply that you can't fetch certain webpages, or what?

It sounds like browsers have stopped supporting SSL 3.0 and before for a while now, but I'm not sure.


Backward Compatibility

I think your question is a more general question around being compatible.

You can see this in several ways, the first of which is that TLS 1.3 is the most secure standard (@apr2020), allowing anything less is essentially a security vulnerability. Therefore not being compatible with the older specification is the intention, and a feature.

On the otherhand not being compatible is a turn off for many users who have to operate in the messy world of independently maintained services. In this world there maybe production critical programs that can only talk ssl 2.0. (I'm currently running into this problem myself with an inhouse app that cannot talk tls of any version). In which case supporting all protocols would be a boon, perhaps with some other checks and balances such as ip/cert verification.

The question is how much backward compatibility should you provide? And it depends.

As at Apr 2020, I would provide TLS 1.2 and 1.3 as a minimum, with TLS 1.2 disabled by default.

Older standards I would provide based on request, or by my own desire to implement them.

Some of the very old standards are fundamentally broken now. It might still pay to implement these, however this draws its own problems. By providing them, you are enabling programs to be insecure by default. It might make sense to place these in a separate legacy variant of your library (still maintained though).

  • By backwards compatibility do you mean that you simply can't fetch a webpage or something, or what exactly does this look like? Apr 30 '20 at 16:52
  • If you cannot talk the same protocol as the other side of the conversation, then yes you cannot fetch a web page. You might be able to discern that the page exists though.
    – Kain0_0
    Apr 30 '20 at 22:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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