RFC
TLS 1.3 (RFC 8446)
The basic standard for modern TLS handshake and key schedule.
When we talk about channel security and trust between services, there are almost always three layers working behind the scenes: cryptographic primitives, a key infrastructure, and a transport protocol. In practice it looks like a bunch asymmetry + PKI + TLS, and not as one “magic” algorithm.
What is important to understand about encryption
Asymmetric Encryption
- Key pair: public key can be distributed, private key must remain secret.
- Encryption is usually done hybridly: the data is encrypted with a symmetric key, and the key is encrypted using a public key.
- Main practical role: secure key exchange and bootstrap trust.
Digital Signatures
- The signature confirms the integrity and source of the data (authenticity + integrity).
- Sign: private key, Verify: public key.
- In TLS, signatures are used to prove ownership of the server key.
Key Management
- Real security depends on the lifecycle of keys: generation, storage, rotation, revocation.
- KMS/HSM, key versioning, access policies and audit trail - basic production minimum.
- Compromising a private key is often more dangerous than a bug in the protocol itself.
PKI
X.509 / RFC 5280
Standard for certificates and basic rules certificate chain validation.
Public/Private Key Infrastructure (PKI)
Root CA
An anchor of trust. Usually offline, with strict access control.
Intermediate CA
Signs server certificates, isolating the risk from the root key.
Leaf Certificate
A certificate for a specific domain/service with a public key and expiration date.
Revocation / Rotation
CRL/OCSP, short TTL certificates and regular key rotation.
Production approach: private keys should be stored in KMS/HSM with minimal access rights, regular rotation and mandatory auditing of key operations.
How TLS 1.3 works (simplified)
Before the handshake is completed, the parties agree on parameters and keys, after Finished The application works through a secure channel.
Click Start visualizationto walk through the TLS 1.3 handshake step by step.
TLS 1.3 removed outdated mechanisms and accelerated handshake while maintaining security guarantees.
Even perfect TLS doesn't solve business authorization: AuthZ should be a separate layer.
Common mistakes
- Assuming 'HTTPS is enabled' automatically covers all risks: TLS closes the channel, but does not replace AuthN/AuthZ.
- Long-lived certificates and keys without rotation.
- Ignoring certificate chain and hostname checks.
- Storing private keys in plain text on hosts without KMS/HSM and access control.
- Same keys for different environments (dev/stage/prod).
- Lack of expiry monitoring and emergency key revoke procedures.