TLS

TLS secures a connection in three ways at once: it encrypts the data so an observer cannot read it, it authenticates the server (and optionally the client) through certificates issued under a public key infrastructure, and it protects integrity so tampering is detected. A handshake negotiates the version and cipher suite, establishes keys, and validates the certificate chain before any application data flows. TLS 1.3 simplified this: it removed the older, weaker options, made a faster handshake, and provides forward secrecy by default, so recording today’s traffic does not let an attacker decrypt it later if a long-term key is compromised. It is the mechanism behind encryption in transit for the web and much else.

The finding is almost always the version and configuration, not the protocol. Estates keep TLS 1.0 and 1.1 enabled for a legacy client nobody wants to break, leave weak cipher suites negotiable, or serve certificates that are expired, self-signed where they should not be, or validated loosely by the client. From the attacker’s side, a downgrade to an obsolete version or a weak suite reopens attacks that the current protocol closed, and a client that does not validate the certificate properly can be intercepted regardless of how modern the server is. The protocol being strong does not help if the deployment offers a weak path.

We review TLS by what the endpoint actually negotiates: which versions and suites it accepts, whether obsolete versions are still offered, the certificate chain and its validity, and whether forward secrecy is available. On the client side we check that certificates are validated, which for high-value connections extends to mutual TLS and certificate pinning. We name the version in every finding, because the version is the actionable detail. This is part of how we review your TLS configuration.