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?
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.
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.
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.
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.
Since you specifically asked for examples of ciphers, which are supported by TLS 1.2, but are considered insecure, here are a few:
TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_*
TLS_RSA_WITH_RC4_128_MD5
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
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:
Luckily, there are well-known online inspectors that can analyse a TLS server to rate the security and check for known-poor configurations.