TLS secures my data, right?

You have to understand that TLS by-design is intended to have all data read by anyone without any authorisation checks.

Don't just take my word for it. In the words of ‌‌Nate Lawson;
(cryptographer and software engineer who has contributed to the protocols since SSL3.0)

Data within the session should not be recoverable by anyone except the endpoints

It is that simple.
‌‌Whether you have good or bad intentions, all you need is to be either the requester or the 'receiver'. TLS is designed to let you see the 'protected' data. With zero authentication at the protocol level there are no real way to control the identity of a requester or a receiver, effectively this means in plain speak that if you have the encrypted data you can read it if you are able to perform the procedure a requester or a receiver would.

A quick acknowledgement: identity and access controls do exist outside the TLS protocol; HMAC is the leading implementation in modern APIs. Moving on.

The TLS protocol allows client and server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. All are characteristic of integrity, confidentiality can never be effectively achieved, it is a myth of TLS.

Confidentiality is a TLS myth

Let's explore some TLS basic concepts - demystifying TLS (buzzword!).

Point-to-point

TLS goal is to protect data from eaves-droppers reading the data between point A and point B. This characteristic of TLS is commonly called point-to-point encryption.

Typical scenarios;

• Low traffic websites
• Client initiated data; i.e. a Dropbox, file upload or download
• Media streaming (not live); podcast, music, video

e2ee

If we are using TLS from A to B, TLS from B to C, and controlling all A, B and C points - this is called end-to-end encryption (e2ee). This is common where load-balancing or proxy servers are used in the most secure environments that require e2ee.‌‌However modern privacy enthusiasts argue that traditional e2ee is insecure because the origin and destination do not utilise the same certificate to achieve encryption in TLS. Therefore TLS had to introduce Forward secrecy (a.k.a PFS for Perfect Forward secrecy).

Typical scenarios;

• High traffic websites (load balancing)
• The load balancing software vendors
• Enterprise networks (proxy)
• The proxy software vendors
• Many security software vendors
• Cloud (SaaS / PaaS / IaaS) providers management plane

Forward secrecy

Using Perfect Forward Secrecy (PFS) reduces the impact of the compromise of a TLS session.
Forward secrecy provides cryptographic verifiable assurances of e2ee, or a more simplistic version of that is PFS is an agreement between sender and receiver, regardless of any servers in the middle.

However many privacy advocates argue that the middle server is still a privacy violation.‌‌ This privacy purist view is ignorance as it disregards facts about the ownership of the technology. Specifically both the middle server and endpoint are the same owner, and in many use cases it is the very the same hardware - so this argument is useless until it is focused solely on a peer-to-peer messaging platform where the peers expect all data (including metadata) is e2ee without anything in the middle. These purists are totally crazy, this opinion is ignorant of the basic concept that it is the internet made up of all sorts of hardware that forwards your data from peer to peer. It is not a cross-over cat5 cable!

Try to remember, peer-to-peer is still the internet made up of hardware devices to transmit your data

We still call Forward Secrecy an e2ee implementation, if information security were to change the meaning of something so fundamental to the way the internet works, would be beyond irrational.

For these privacy purists narrow view of e2ee only being used to describe peer-to-peer, the information security professionals have designated something called Zero Knowledge.

It's worth pointing out that educated information security professionals prefer the term Forward anonymity over the analogous Forward secrecy, because there is no real added secrecy (confidentiality) characteristics over it's TLS-based predecessors. TLS will only ever provide a guarantee of integrity with any cryptographic solution, so Forward anonymity adds the concept to TLS that your identity can now be preserved in TLS.

Typical scenarios;

• Everywhere TLS is used, without it you are vulnerable to compromise via trivial attacks
• Australian ISM Security Control 1453
• Future standards in draft now (NIST SP 800-77, PCI DSS v4, CSA CCM v4)

Zero Knowledge

A form of e2ee mostly desired for peer-to-peer communications.

Zero Knowledge e2ee can provide both confidentiality and integrity cryptographic verifiable assurances.

TLS does not provide zero knowledge e2ee

There is no specific ciphers used to distinctly achieve Zero Knowledge.
Equally there is no part of TLS or any other standardised protocol specification that currently defines what zero knowledge e2ee should technically implement.

To achieve Zero Knowledge today, one must convince the privacy purists that their bespoke implementation is a Zero Knowledge scenario, in a beautiful example of irony the privacy purists must trust the offer is Zero Knowledge through the scrutiny of white papers and external observations. Sometimes a claimed Zero Knowledge implementation provides full source code, but more often (e.g. Signal) the actual source code users are running is never provided, but a protocol that implements the design goals of a white paper is made available - and we must trust that the real source code that users run is the same - no one but the vendors themselves really know.

Typical scenarios;

• Use instead of TLS where peer-to-peer e2ee is desired

Datagram Transport Layer Security (DTLS)

DTLS is a protocol based on TLS concepts that is capable of securing the datagram transport.

Basically DTLS is to construct TLS over datagram (UDP, DCCP) and solves two problems TLS does not. DTLS adds packet lost tolerance and reordering packets, through assigning sequence number within the handshake packet re-transmission and replay detection is possible which were not available characteristics of TLS.

In terms of the cipher suites that are available only RC4 is not permitted, so DTLS can generally be considered the same as TLS in discussions related to cryptographic assurances.

Typical scenarios;

• Delay-sensitive (and hence use datagram transport) applications; media stream buffering, VPN, Interactive SSH
• Applications that tend to run out of file descriptors or socket buffers; data clusters, container clusters

Mutual TLS

TLS guarantees the identity of the server to the client and provides a two-way encrypted channel between the server and client. Mutual TLS (mTLS) allows an application on the server to confirm the identity of the client.

We've established that TLS assumes anyone who sends and receives are authorised to read, therefore MTLS being based on TLS fundamentally it also assumes this characteristic, so using MTLS we can learn both sides of the communication identity - But MTLS will not assure or promise either side any authentication assurances so the identity remains unauthenticated (no matter what the internet tells you).

MTLS remains unauthenticated during communication, only the identity is offered and an out-of-band authentication is assumed

If you take a casual look at any MTLS you will find it relies on either Basic Authentication (considered deprecated for over a decade) or something more modern like HMAC. So MTLS alone is unauthenticated but almost always ass a layer of authentication over the top of MTLS.

Typical scenarios;

• In co-called Zero Trust networks, where an identity of all servers in the network is expected so a least privileged approach can be applied to network communications

TLS Dependencies

There are a number of assumptions in TLS that lead to many myths.

Primarily TCP is intentionally based on TCP which introduces too many optional implementation interpretations like ciphers suite choice, which are problematic due to both the signature hashes used and ways cipher negotiation can compromise security.
There are several other things either left open to interpretation in TLS, or have made too many assumptions such as version negotiation for backwards compatibility, data compression, and root-CA trust. There are so many possible security issues with TLS that are only possible because TCP does not define compression well, or it doesn't account for side-channel attacks, ignores that we can deriving private keys from public keys due to hash collisions or data leaks in poor signature algorithm implementations.

These are just a few security topics of conversation that make easy compromise or security implications, and TLS protocol offers no answers to assure security professionals.

Conclusion

Basically TLS is not a security-first protocol, downgrade attacks alone tell us that TLS compromises security in favour of adoption by-design. Heartbleed also showed us that TCP itself can cause TLS issues that are impossible if TLS were based on UDP or something uniquely defined for TLS on top of IP (like ICMP) which is actually security first.

So for security reasons TLS alone is never sufficient in any of it's variant forms, you should chose additional security standards like authentication to implement on top of your TLS.