If someone tells me their service uses TLS 1.2 or higher, how much 'guaranteed' security does this provide?

Is it possible to correctly claim to be using TLS 1.2 or 1.3 and still be insecure? For example, using a correctly implemented TLS handshake but with a weak cipher?

If it is possible to 'correctly' implement TLS insecurely, using the above example, what would be examples of ciphers that are acceptable in the TLS standards but are actually insecure?

  • Secure against what? Insecure in what relevant ways? I could perform TLS inspection on the most up-to-date and most robust ciphers, and see all traffic in clear text and read everything. – schroeder Apr 29 at 11:41
  • The list of weak ciphers is known and established. Is your entire concern about cipher suites? – schroeder Apr 29 at 11:43
  • No in general. Are any correct TLS implimentations vulnerable to any known attacks? i.e. if i want to buy a product that says... data is protected using TLS 1.2, is this enough to deem it to be secure or should i ask more questions? An could you please provide me a link to the weak ciphers? – WireInTheGhost Apr 29 at 11:46
  • !!!CROSS-POSTED !!! – kelalaka Apr 29 at 15:00

Differentiate between Implementation and Protocol

The protocol is the "theoretical" was two machines are supposed to communicate with each other. The Implementation is the actual code running on the machine, which implements a protocol. There is a difference between saying a protocol is insecure, and an implementation is insecure.

For example, Heartbleed was an issue with the implementation, not the protocol. It could easily be fixed by just adding a boundary check into the relevant code section. Wired Equivalent Privacy, better known as WEP, was a flawed protocol to begin with. No implementation could fix the inherent weaknesses in the design, and the only mitigation was to switch to a newer, more secure protocol.

Is TLS 1.2 a secure protocol?

Well...yes and no. It fixed some of the issues, from TLS 1.0 and TLS 1.1, but it still followed the design principle similar to Burger King, namely "Have It Your Way". TLS 1.2 supported a myriad of different cipher suites, which in terms of security range from "Best Practice" to "Oh my God what are you doing?!"

As such, if someone says "I am using TLS 1.2", you really can't know if they are secure or not. There are a lot of ciphers, which are supported by TLS 1.2, which experts now agree are insecure.

Is TLS 1.3 a secure protocol?

Generally, yes. Or more specifically, we have not found any weaknesses yet. The design philosophy shifted away from allowing all sorts of protocols, to only allowing a very tiny, known-to-be-secure set of ciphers. That means if you and your client support and use TLS 1.3, you are going to use a secure protocol - at least, given the knowledge we have 2021.

What does this all mean in practice?

It means that in order to have a reasonable amount of confidence in the security TLS provides, you need to look at the following things:

  • Which versions of TLS do you support?
    TLS 1.3 is the most secure one, but also has limited support for clients. TLS 1.2 is considered secure, if and only if you use a secure set of ciphers. Which ciphers those are exactly depends on how many clients you wish to support. Mozilla's SSL Config Generator (which should really be called TLS Config Generator) offers an "Intermediate" profile, which is a good starting point.

  • Is your implementation up-to-date?
    TLS implementations can have bugs, which lead to vulnerabilities. For example, the CCS Injection Vulnerability or Heartbleed vulnerability are all implementation vulnerabilities, which can only be fixed by staying with an up-to-date version of your TLS implementation.

  • Is your implementation configured correctly?
    Certain attacks are possible when certain configuration options are set. For example, when Secure Renegotiation is enabled, this can lead to Denial-of-Service attacks. Luckily, this feature was removed in TLS 1.3. So please make sure that your configuration doesn't lead to vulnerabilities.

  • Do you use compromised keys?
    If the keys to your certificate are compromised, malicious third parties are able to impersonate you perfectly and intercept traffic to your server. No amount of TLS security can prevent that.

Examples of weak ciphers

Since you specifically asked for examples of ciphers, which are supported by TLS 1.2, but are considered insecure, here are a few:

  • 1
    In addition to avoiding bad ciphersuites, which is easy to set and see in configuration, you must not use bad DHE parameters or ECDHE curve, as explained if you read wiki.mozilla.org/Security/Server_Side_TLS instead of using the 'no-thinking-or-understanding-just-cut-and-paste' generator. Against active attacks you must also use a strong and valid certificate and the client(s) must validate it robustly, which the server cannot enforce. The server could detect non-client-authorized interception by requiring client cert (which MitM can't fake) but that reduces userbase often to zero. – dave_thompson_085 Apr 30 at 1:20
  • Client certificates only make sense if you know your userbase beforehand (e.g. internal applications). And yes, I absolutely agree that understanding how TLS works is much preferable than simply copy/pasting a pre-made config - but I'll be realistic here and say that a lot of people will not put in the required time and effort to try and understand it. So giving them a "good enough" config out-of-the-box will most likely work fine enough for 99% of all users. – MechMK1 Apr 30 at 10:35

The most secure bank safe in the world is useless if someone forgets to lock it at night. Any security configuration is the same. There are ways to weaken the security:

  • using weak ciphers, even though they are allowed by the standard
  • Mishandling of the certificate
  • Mishandling of the keys
  • Using compromised root certificates
  • etc.

Luckily, there are well-known online inspectors that can analyse a TLS server to rate the security and check for known-poor configurations.

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.