SSL/TLS

SSL/TLS (Secure Sockets Layer / Transport Layer Security) is the cryptographic protocol that encrypts data in transit between a client and a server. SSL is the deprecated predecessor; TLS is its modern replacement, with TLS 1.2 and TLS 1.3 being the versions in active use today. When you see https:// in a browser, TLS is the layer doing the work: it encrypts the connection, verifies the server's identity through a certificate, and protects the data from tampering.

Why it matters

TLS provides three guarantees: confidentiality (eavesdroppers can't read the traffic), integrity (data can't be silently altered), and authentication (you're talking to the real server, not an impostor). Weak or misconfigured TLS undermines all three. A site running an obsolete protocol like SSLv3 or TLS 1.0, presenting an expired certificate, or accepting broken ciphers can expose login credentials, session tokens, and customer data to interception or man-in-the-middle attacks. Certificate expiry is also a frequent, avoidable source of outages.

How it works

A TLS connection begins with a handshake:

1. The client and server agree on a protocol version and cipher suite.
2. The server presents its certificate, signed by a trusted Certificate Authority (CA), proving ownership of the domain.
3. The two sides establish a shared session key using asymmetric cryptography (or, in TLS 1.3, a faster key-exchange mechanism with forward secrecy).
4. All subsequent traffic is encrypted symmetrically with that session key.

The certificate ties the encryption to a verified identity, which is why both the cipher configuration and the certificate's validity period, issuer, and key strength all matter.

A concrete example

Imagine an API endpoint at api.example.com that still accepts TLS 1.0 and the RC4 cipher, with a certificate that expired last week. A browser will warn users and may refuse the connection, breaking the service. Worse, an attacker on a shared network could exploit the weak cipher to decrypt or downgrade the session and capture API keys passing through it. Renewing the certificate and disabling protocols below TLS 1.2 closes both gaps.

How it appears on your external attack surface

Every public endpoint that speaks HTTPS — web servers, APIs, mail servers, admin panels — has a TLS configuration that is visible to anyone, including attackers. Common externally observable issues include expired or soon-to-expire certificates, deprecated protocol versions, weak cipher suites, hostname mismatches, self-signed certificates on production hosts, and missing HTTP security headers like HSTS that enforce TLS use.

How FortWatch helps

FortWatch's SSL/TLS monitoring scanner continuously inspects the certificates and TLS configuration of your discovered assets, flagging upcoming expiries, weak protocols, and insecure ciphers, then assigns each finding a severity with AI-generated remediation steps. Because it runs as part of broader external attack surface management, TLS findings sit alongside open ports, DNS hygiene, and exposed files so you see the whole picture, not one slice. For a deeper walkthrough of what to watch, see our SSL/TLS monitoring guide.