SSL Handshake: Public Key Manipulation

TL;DR

Attackers generally cannot directly change a certificate’s public key during an SSL/TLS handshake. However, they can attempt to present a fraudulent certificate (with their own public key) if the server isn’t properly validating certificates. Strong server-side validation is crucial for preventing man-in-the-middle attacks.

Understanding the SSL Handshake

The SSL/TLS handshake establishes a secure connection between a client (e.g., your web browser) and a server. A key part of this process involves verifying the server’s identity using its certificate, which contains the server’s public key.

Why Attackers Can’t Directly Change the Public Key

1. Digital Signatures: Certificates are digitally signed by a Certificate Authority (CA). Any modification to the certificate, including the public key, invalidates this signature. The client verifies the signature before trusting the certificate.
2. Hash Verification: During the handshake, the server presents its certificate chain. The client calculates hashes of the certificates and compares them against trusted CA root certificates. A changed public key would result in a different hash value, failing verification.

How Attackers Try to Bypass Validation

Attackers don’t change the existing certificate; they attempt to substitute it with a malicious one.

1. Man-in-the-Middle (MitM) Attacks

An attacker intercepts communication between the client and server, presenting their own fake certificate instead of the legitimate one.

1. Interception: The attacker positions themselves in the network path.
2. Fake Certificate: They generate a certificate for the target domain (or use a wildcard certificate) signed by a CA they control or a rogue CA.
3. Presentation: When the client connects, the attacker presents their fake certificate.

If the client trusts the attacker’s CA (e.g., because it’s self-signed or from an untrusted source), the handshake proceeds with the malicious certificate.

2. Weak Server Configuration

Servers can be misconfigured to accept invalid certificates, making them vulnerable.

1. Missing Validation: The server doesn’t properly check the certificate chain against a trusted CA list.
2. Accepting Expired Certificates: The server allows expired certificates.
3. Ignoring Hostname Mismatch: The server doesn’t verify that the certificate’s hostname matches the requested domain.

Preventing Public Key Manipulation Attacks

1. Strong Server-Side Validation: This is the most important step.
   • Trusted CA List: Ensure your server uses an up-to-date list of trusted Certificate Authorities.
   • Hostname Verification: Always verify that the certificate’s Common Name (CN) or Subject Alternative Names (SANs) match the requested domain name.
   • Certificate Revocation Lists (CRLs) & Online Certificate Status Protocol (OCSP): Check if the certificate has been revoked. OCSP stapling is preferred for performance.
   • Chain Validation: Verify the entire certificate chain up to a trusted root CA.
2. HSTS (HTTP Strict Transport Security): Enforces HTTPS connections, preventing downgrades to insecure HTTP.

   # Example HSTS header in your web server configuration

3. Certificate Pinning: Clients explicitly trust specific certificates or public keys. This is more complex but adds an extra layer of security.
4. Mutual TLS (mTLS): Requires both the client and server to present valid certificates, significantly increasing security.
5. Regular Security Audits: Regularly audit your SSL/TLS configuration for vulnerabilities.

   # Example using OpenSSL to check certificate details