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
- 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.
- 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.
- Interception: The attacker positions themselves in the network path.
- 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.
- 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.
- Missing Validation: The server doesn’t properly check the certificate chain against a trusted CA list.
- Accepting Expired Certificates: The server allows expired certificates.
- Ignoring Hostname Mismatch: The server doesn’t verify that the certificate’s hostname matches the requested domain.
Preventing Public Key Manipulation Attacks
- 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.
- HSTS (HTTP Strict Transport Security): Enforces HTTPS connections, preventing downgrades to insecure HTTP.
# Example HSTS header in your web server configuration - Certificate Pinning: Clients explicitly trust specific certificates or public keys. This is more complex but adds an extra layer of security.
- Mutual TLS (mTLS): Requires both the client and server to present valid certificates, significantly increasing security.
- Regular Security Audits: Regularly audit your SSL/TLS configuration for vulnerabilities.
# Example using OpenSSL to check certificate details