2.6Certificates and security

Throughout the prior sections we repeatedly saw that "encryption reduces monitoring visibility." Precisely for that reason, a SOC analyst must read the health of the encrypted communication itself—is it the right peer, is the strength sufficient, is there room for tampering—from certificates and the handshake. This section organizes PKI that assures public-key authenticity, symmetric/asymmetric cryptography dividing the roles of speed and key distribution, and the elements negotiated in the TLS handshake—the cipher suite, X.509, key exchange, protocol version, and PKCS—from the monitoring perspective of judging "can this encryption be trusted?"

2.6.1Symmetric, asymmetric, and PKI

• Symmetric-key cryptography uses the same key to encrypt and decrypt (AES, etc.). It is fast and suits bulk data but has the problem of delivering the key securely (key distribution) to the peer. Asymmetric-key cryptography uses a public/private key pair (RSA, ECC). What the public key encrypts, only the private key can decrypt, which solves key distribution but is computationally expensive.
• Real TLS combines both: use asymmetric to safely deliver a key (key exchange), then encrypt the bulk data with a fast symmetric key (hybrid). The essence is neither "asymmetric is slow, so skip it" nor "handle key distribution with symmetric alone," but taking both advantages through a division of roles.
• PKI (public key infrastructure) guarantees that a public key truly belongs to that peer via a third party's (a Certificate Authority, CA) signature. Validating a CA-signed X.509 certificate prevents impersonation (MITM). Being able to follow the certificate's chain of trust (root CA -> intermediate CA -> server certificate) is the basis of authenticity.

2.6.2Certificate and handshake elements

• A cipher suite is the combination of cryptographic algorithms used in TLS (key exchange, authentication, symmetric cipher, hash), negotiated during the handshake from what both sides support. In monitoring, negotiating a weak/deprecated cipher suite (e.g., RC4, DES, export-grade) is a red flag and can indicate a downgrade attack.
• X.509 is the standard certificate format, containing the issuer (CA), subject (peer), public key, validity period, serial, signature, and SAN (covered domains). Typical monitoring red flags: an expired, self-signed, subject (CN/SAN)-mismatched, or revoked (CRL/OCSP) certificate, which can indicate MITM or a fake site.
• A key exchange is the procedure to securely share the symmetric key (RSA key transport or DH/ECDHE). Methods like ECDHE provide Perfect Forward Secrecy, so past traffic stays undecryptable even if the private key later leaks. For protocol version, TLS 1.2/1.3 are current while SSL 3.0 and TLS 1.0/1.1 are weak and deprecated; negotiating an old version is a red flag. PKCS is a family of public-key standards (e.g., PKCS#7 signatures, PKCS#10 certificate requests, PKCS#12 key/certificate bundles) defining key/certificate formats and containers.

In the SOC you are investigating an alert about an HTTPS connection from inside to an external site. The proxy's TLS-inspection log records that, in the handshake with a server, the protocol version was negotiated to TLS 1.0, the cipher suite chose RC4, and the presented X.509 certificate is self-signed with a CN/SAN that does not match the destination domain. Judge the elements one by one. First, TLS 1.0 and RC4 are a deprecated, weak combination, itself a red flag for a downgrade attack or an obsolete server. Next, a self-signed certificate not chaining to a trusted CA lacks PKI's authenticity guarantee and is a textbook sign of MITM (an attacker in the middle presenting their own certificate). Further, the CN/SAN mismatch with the destination domain indicates a connection to "something else posing as the legitimate site." Judging "it is encrypted, therefore safe" here is a serious error—being encrypted and being encrypted with the right peer at sufficient strength are entirely different, and the latter is exactly what validating PKI, the certificate, the cipher suite, and the version guarantees. The correct response is to block the connection, record the certificate's fingerprint/issuer, and pivot to search for other flows presenting the same rogue certificate. By contrast, another connection shows TLS 1.3, an ECDHE key exchange, a valid CA-signed X.509, and a matching domain, and with Perfect Forward Secrecy it can be judged healthy as encrypted communication. Reading certificates in monitoring is a key skill for the era of reduced visibility: instead of giving up on the "invisible content," confirm from the elements whether the cryptographic vessel itself can be trusted.

2.6.3Section summary

• Symmetric is fast with one key but has the key-distribution problem, asymmetric uses a public/private pair to solve key distribution but is slow; TLS is a hybrid of both
• PKI assures public-key authenticity via CA signatures; X.509 red flags—expired, self-signed, name mismatch, revoked—signal MITM or a fake site
• Validate the cipher suite, protocol version, key exchange, and PKCS to judge "whether the cryptographic vessel is trustworthy"; weak suites and old versions (SSL3, TLS1.0-1.1) are red flags