This weakness occurs when software exchanges cryptographic keys with another party without verifying that party's identity. An attacker positioned between the…
This weakness occurs when software exchanges cryptographic keys with another party without verifying that party's identity. An attacker positioned between the two parties can intercept the key exchange, substitute their own keys, and decrypt or manipulate all subsequent encrypted communication. This is a foundational vulnerability in cryptographic systems and is the root cause of man-in-the-middle (MITM) attacks.
Key exchange protocols (like Diffie-Hellman or ECDH) allow two parties to agree on a shared secret over an untrusted channel. However, these protocols alone do not prove *who* you are talking to—only that both parties can compute the same value. Without authentication, an attacker can perform the key exchange with both the client and server separately, becoming an invisible intermediary. The client believes it is talking to the server, and the server believes it is talking to the client, but both are actually communicating with the attacker. Authentication mechanisms—such as digital certificates, pre-shared keys, or public-key signatures—must be layered on top of the key exchange to bind the agreed key to the identity of each party.
An unauthenticated key exchange allows an attacker to read, modify, or inject messages in encrypted sessions. In practice, this can lead to credential theft (capturing login credentials sent over the "encrypted" channel), session hijacking, malware injection, or data exfiltration. The attacker's presence remains invisible because encryption is still in place—the victim sees a locked padlock but is actually communicating with an attacker. This is particularly dangerous in scenarios like VPN connections, API authentication, or IoT device pairing, where users assume encryption means security.
import socket
from cryptography.hazmat.primitives.asymmetric import dh
from cryptography.hazmat.backends import default_backend
# Perform Diffie-Hellman key exchange without verifying peer identity
parameters = dh.generate_parameters(generator=2, key_size=1024, backend=default_backend())
private_key = parameters.generate_private_key()
public_key = private_key.public_key()
# Send public key to peer (no authentication of peer's identity)
peer_public_key_bytes = receive_from_peer() # Attacker can intercept and substitute
peer_public_key = dh.DHPublicKey.from_bytes(peer_public_key_bytes, parameters)
# Derive shared secret
shared_secret = private_key.exchange(peer_public_key)Why it's vulnerable:
The code exchanges keys but never verifies that peer_public_key actually belongs to the intended peer. An attacker can substitute their own public key, and the shared secret will be known to the attacker instead of being private.
import socket
from cryptography.hazmat.primitives.asymmetric import dh, rsa, padding
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.backends import default_backend
# Perform key exchange AND authenticate peer using a pre-shared certificate or public key
parameters = dh.generate_parameters(generator=2, key_size=2048, backend=default_backend())
private_key = parameters.generate_private_key()
public_key = private_key.public_key()
# Receive peer's public key and a signature proving ownership
peer_public_key_bytes = receive_from_peer()
peer_signature = receive_from_peer()
# Verify signature using peer's trusted certificate (obtained out-of-band)
trusted_peer_cert = load_trusted_certificate("peer_cert.pem")
trusted_peer_cert.public_key().verify(
peer_signature,
peer_public_key_bytes,
padding.PSS(mgf=padding.MGF1(hashes.SHA256()), salt_length=padding.PSS.MAX_LENGTH),
hashes.SHA256()
)
# Only after verification, derive shared secret
peer_public_key = dh.DHPublicKey.from_bytes(peer_public_key_bytes, parameters)
shared_secret = private_key.exchange(peer_public_key)<?php
// Simulate unauthenticated key exchange
$peer_public_key = $_POST['peer_public_key']; // Attacker can inject their own key
// Perform DH exchange without verifying peer identity
$local_private = openssl_pkey_new(['private_key_bits' => 2048]);
$local_public = openssl_pkey_get_details($local_private)['key'];
// Derive shared secret using unverified peer key
$shared_secret = openssl_pkey_get_private($peer_public_key);
// ... use $shared_secret for encryption
?>Why it's vulnerable:
The peer's public key is accepted directly from user input without any verification of its origin or authenticity. An attacker can submit their own key and intercept all encrypted communication.
<?php
// Authenticate peer using a pre-shared certificate before key exchange
$peer_public_key_pem = $_POST['peer_public_key'];
$peer_signature = base64_decode($_POST['peer_signature']);
// Load trusted peer certificate (obtained and stored securely beforehand)
$trusted_cert = file_get_contents('/secure/path/peer_cert.pem');
$cert_details = openssl_x509_parse($trusted_cert);
// Verify the signature to prove the peer owns the public key
$peer_cert_resource = openssl_x509_read($trusted_cert);
$verification = openssl_verify(
$peer_public_key_pem,
$peer_signature,
openssl_pkey_get_public($peer_cert_resource),
OPENSSL_ALGO_SHA256
);
if ($verification === 1) {
// Only after successful verification, proceed with key exchange
$local_private = openssl_pkey_new(['private_key_bits' => 2048]);
$shared_secret = openssl_pkey_get_private($peer_public_key_pem);
// ... use $shared_secret for encryption
} else {
die('Peer authentication failed');
}
?>Look for unexpected changes in peer certificates or public keys in your logs, or reports of encrypted sessions being readable by unauthorized parties. If users report that they can decrypt traffic they should not have access to, or if security tools detect the same encrypted session being decrypted by multiple parties, a MITM attack exploiting unauthenticated key exchange may be in progress.
