TLS and Certificates

What TLS Is and How It Encrypts Network Traffic

TLS (Transport Layer Security) is the cryptographic protocol that encrypts communication between two endpoints — typically a client (browser, application) and a server (web server, API, C2 infrastructure).
TLS replaced SSL (Secure Sockets Layer), which was deprecated after the POODLE attack in 2014.
TLS 1.2 (RFC 5246, 2008) remains the most widely deployed version.
TLS 1.3 (RFC 8446, 2018) is the current standard and significantly improves security and speed.

The TLS Handshake Step by Step

The TLS handshake is the negotiation that establishes encrypted communication. Understanding it is critical for analysts because the handshake reveals information about both the client and server — even without decrypting the payload.

TLS 1.2 Handshake (4 round trips — slower but still dominant)

Client                     Server
  │                          │
  │  ClientHello              │
  │  ├─ Supported TLS version │
  │  ├─ Cipher suites list    │
  │  ├─ Random bytes          │
  │  └─ Session ID (optional) │
  │─────────────────────────>│
  │                          │
  │  ServerHello              │
  │  ├─ Selected TLS version  │
  │  ├─ Selected cipher suite │
  │  └─ Random bytes          │
  │  ServerCertificate       │
  │  ├─ Server's public key   │
  │  └─ CA signature chain    │
  │  ServerHelloDone          │
  │<─────────────────────────│
  │                          │
  │  ClientKeyExchange       │
  │  └─ Pre-master secret     │
  │     (encrypted with       │
  │      server's public key) │
  │  ChangeCipherSpec         │
  │  Finished                 │
  │─────────────────────────>│
  │                          │
  │  ChangeCipherSpec         │
  │  Finished                 │
  │<─────────────────────────│
  │                          │
  │  ── Encrypted data ────> │

The pre-master secret is the key insight: the client generates a random value, encrypts it with the server’s public key, and sends it. Only the server can decrypt it with its private key. Both sides then derive the session keys from this shared secret.

TLS 1.3 Handshake (1 round trip — much faster)

Client                     Server
  │                          │
  │  ClientHello              │
  │  ├─ Supported versions    │
  │  ├─ Key share (Client     │
  │  │  sends its public key  │
  │  │  guess in advance)     │
  │  ├─ PSK (if resuming)     │
  │  └─ Supported signature   │
  │     algorithms            │
  │─────────────────────────>│
  │                          │
  │  ServerHello              │
  │  ├─ Selected version      │
  │  ├─ Key share (Server's   │
  │  │  public key)           │
  │  ├─ Certificate + verify  │
  │  └─ Finished              │
  │<─────────────────────────│
  │                          │
  │  ── Encrypted data ────> │

TLS 1.3 removed:

Cipher suites with static RSA key exchange (all must use forward secrecy)
CBC mode ciphers (only AEAD ciphers: AES-GCM, ChaCha20-Poly1305)
Compression
Renegotiation

Cipher Suite Selection — What Each Part Means

A cipher suite defines the cryptographic algorithms used in a TLS session. It has four parts:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Component	Meaning	Options
TLS	Protocol prefix	TLS
ECDHE	Key exchange algorithm	RSA, DH, DHE, ECDHE, PSK
RSA	Authentication / signature algorithm	RSA, ECDSA, DSA
AES_256_GCM	Symmetric encryption + mode	AES_128_GCM, AES_256_GCM, CHACHA20_POLY1305
SHA384	HMAC hash for message integrity	SHA256, SHA384

Detection implications:

C2 malware often requests unusual cipher suites — a tool that hardcodes the cipher suite list (rather than using the OS TLS library) will have a unique JA3 fingerprint
TLS 1.3 only allows 5 cipher suites — if you see TLS 1.3 sessions with non-standard cipher suites, the traffic is likely custom/abnormal
RSA key exchange (no PFS) is increasingly rare — most modern clients prefer ECDHE. Seeing RSA key exchange is a strong signal of legacy software or attacker tooling

Detection — Indicators in TLS Traffic

Without Decryption

You can spot suspicious TLS traffic by inspecting the handshake metadata — no certificate inspection, no decryption required.

Indicator	What It Suggests	What to Check
Unusual JA3 fingerprint	Non-standard TLS stack — could be malware	Compare JA3 against known malware fingerprints. See if it appears on only one host.
TLS version mismatch	Client offers only TLS 1.0 or 1.1	Outdated software or intentional downgrade. TLS 1.0 should not appear anywhere.
Cipher suite inconsistency	Client requests TLS 1.3 ciphers then negotiates TLS 1.2	Abnormal — may indicate a custom TLS stack with inconsistent capabilities
No ALPN negotiation	Client sends HTTP/1.1, does not negotiate HTTP/2	Normal for some apps (curl, custom clients). But seeing no ALPN across all connections from a host is suspicious.
Constant handshake time	Beaconing — malware connects to C2 at precisely regular intervals	Time between handshake completions is within ±100ms for all events
No SNI	Client does not send the server name	C2 servers often do not check SNI. Legitimate browsers always send SNI. Missing SNI to a known domain is suspicious.

With Certificate Inspection

Indicator	What It Suggests
Self-signed certificate	C2 infrastructure, dev/test, internal-only service exposed to internet
Expired certificate	Abandoned infrastructure or C2 that does not rotate
Mismatched CN	Certificate CN does not match the domain the client is connecting to
Subject = “localhost” or IP	Not a legitimate public-facing service
Organizational unit = company name	Does the certificate’s organization match who you expect runs the server?
Certificate issued by Let’s Encrypt	Legitimate and common — but also used by C2 infrastructure (free, automated, 90-day certs). Not suspicious by itself but worth noting.
Certificate chain too short	Leaf cert → Root CA with no intermediary. Unusual for legitimate services (normally chain through 2-3 intermediates).
Certificate freshly issued, domain old	Domain existed for years, suddenly gets new certificate after no changes for a long time — possible domain takeover

C2 Detection via TLS Fingerprinting

Attackers building C2 infrastructure often use default TLS configurations. These stand out against the background of legitimate traffic.

Common C2 TLS patterns:

Pattern	Why It Happens	Detection
No OCSP stapling	Most C2 frameworks do not configure OCSP must-staple	Check TLS handshake for OCSP response absence — not definitive alone, but with other indicators it adds weight
Self-signed or Let’s Encrypt cert	Free, easy to set up, no vetting	Cross-reference with JA3 and domain age
TLS 1.2 only (no 1.3)	C2 frameworks based on older libraries (e.g., Go net/http default, older OpenSSL)	TLS 1.2-only connections from a host that normally uses 1.3 is a signal
HTTP/1.1 only (no HTTP/2)	C2 tools do not implement HTTP/2	Compare with host’s typical HTTP versions
Single cipher suite (no negotiation)	Hardcoded cipher in the malware, no fallback logic	Most TLS libraries offer 10+ cipher suites. A single cipher is extremely unusual.
Session resumption disabled	Malware does not care about performance	Check if session tickets are issued — most servers issue them automatically

SPL query — detect C2 by JA3 + self-signed cert + domain age:

index=network sourcetype=tls_metadata
| search self_signed=true AND ja3_hash NOT IN (known_good_ja3_hashes) OR tls_version="TLSv1.2" only
| lookup domain_whois_lookup domain_name OUTPUT registration_date
| eval domain_age_days = (now() - registration_date) / 86400
| where domain_age_days < 90
| stats values(domain_name) as Domains, values(ja3_hash) as JA3, values(issuer) as Issuer by src_ip, dest_ip
| eval alert = "HIGH — possible C2: self-signed cert + unusual JA3 + young domain"

TLS Hardening for Defenders

Control	What It Prevents
Disable TLS 1.0 and 1.1	Protocol downgrade attacks, POODLE, BEAST
Enable TLS 1.3	Faster, more secure handshake, removes weak ciphers
Disable static RSA key exchange	Ensures forward secrecy
Enable HSTS preloading	Prevents SSL stripping by forcing browsers to always use HTTPS
Use OCSP must-staple	Ensures clients get OCSP status during handshake
Monitor JA3 fingerprints	Detects non-standard TLS clients
Deploy certificate transparency monitoring	Detects rogue certificates issued for your domains
Short certificate lifetimes (90 days)	Minimizes impact of key compromise

Active Directory Basics — covers the active directory basics concepts
AWS Misconfigurations — detection and response for T1525, T1613 techniques
Cloud Security Fundamentals — detection and response for T1525 techniques