What Is TLS/SSL?

TLS is the protocol protecting data in transit across essentially the whole internet. SSL is its deprecated predecessor — the name persists in common usage long after every version of SSL became unsafe to use.

It is the most successfully deployed security control in history, and the reason is that it became the default rather than a decision anyone had to make. Where it still fails, the causes are configuration and validation rather than the protocol.

What the handshake establishes

Before any data moves, the two parties agree which version and cipher to use, the server proves its identity with a certificate, and they derive a shared symmetric key for the session. Three properties follow: the data is encrypted, it cannot be altered undetected, and the client has some assurance about who it is talking to.

That third property is the one that carries the weight and the one most often undermined, because it depends entirely on the client actually validating the certificate.

Certificate validation is where it breaks

Disabling certificate validation is the single most common TLS failure in application code. It is usually introduced during development to work around a self-signed certificate in a test environment, and it ships to production because nothing visibly breaks.

An application that does not validate certificates has encryption without authentication, which means anyone positioned in the path can present their own certificate, terminate the connection and read everything. The traffic is still encrypted — to the attacker.

This is worth actively looking for in mobile applications and internal service-to-service calls, which are the two places it most commonly survives.

Version and cipher hygiene

TLS 1.2 remains acceptable when well configured; 1.3 is preferable and removes many legacy options entirely by design. Everything earlier should be disabled, along with cipher suites supporting outdated algorithms.

Two adjacent properties are worth understanding. Forward secrecy means a compromise of the server's long-term private key does not retrospectively decrypt recorded past sessions — which directly addresses the capture-now-decrypt-later pattern. And certificate transparency logs issuance publicly, which lets you detect certificates issued for your domains that you did not request.

Internal traffic deserves the same treatment

External TLS is generally well configured because it is visible and scanned. Internal service-to-service traffic frequently is not, on the reasoning that the internal network is trusted — an assumption that fails the moment anything inside is compromised.

The usual objections are certificate management overhead and the awkwardness of internal certificate authorities. Both are solvable, and service mesh or platform-managed certificates have made automated internal TLS considerably more practical than it was.

The question worth asking is what an attacker with a foothold would see on your internal network. Where the answer includes database credentials, session tokens or personal data in plaintext, lateral movement becomes substantially more valuable than it needs to be.

Where to start

Scan your external endpoints for protocol versions and cipher suites, then look at your own application code for disabled certificate validation. The first is a configuration exercise; the second is the one that silently removes the protection entirely.

See encryption in practice. GuardsArm runs security risk assessments.