Mutual authentication aims to solve the problem of ensuring that both parties in a communication are who they claim to be. Here’s a detailed scenario illustrating the problem and how mutual authentication could prevent it:
Scenario
A young lady, Alice, is working on her laptop in a coffee shop. She intends to access a common website, such as her online banking portal, which typically uses SSL/TLS to secure the connection. However, an attacker, Bob, is also in the coffee shop with his laptop and has set up a rogue Wi-Fi access point named similarly to the coffee shop’s legitimate Wi-Fi.
Attack Process
Spoofing the Wi-Fi Network: Bob’s rogue Wi-Fi network mimics the name of the coffee shop’s legitimate network, and Alice unknowingly connects to it.
Spoofing the Website: Bob has configured his network to intercept and redirect requests to common websites. When Alice tries to access her banking website, Bob’s network redirects her to a fake version of the site he controls.
SSL Stripping: Bob’s fake site does not use SSL/TLS, so when Alice connects, her browser does not establish a secure connection. Bob strips away the SSL, effectively downgrading the security.
Man-in-the-Middle Attack: Bob can now intercept and monitor all traffic between Alice and the fake website. He can capture sensitive information such as login credentials, personal data, and session cookies.
Problem Statement
Without proper authentication mechanisms, Alice has no way of knowing that she is connected to an impostor website, and Bob can easily impersonate the legitimate site. This scenario exposes Alice to severe security risks, including identity theft and financial loss.
Mutual Authentication Solution
Mutual authentication involves both parties (Alice and the legitimate banking website) verifying each other’s identity before establishing a connection. Here’s how it can mitigate the attack:
Client-Side Certificate: Alice’s laptop is configured with a client-side certificate issued by a trusted Certificate Authority (CA). This certificate uniquely identifies Alice’s device.
Server-Side Certificate: The legitimate banking website also uses a server-side certificate issued by a trusted CA. This certificate uniquely identifies the website.
TLS Handshake with Mutual Authentication:
When Alice attempts to connect to the banking website, her browser initiates a TLS handshake.
As part of the handshake, the banking website presents its server-side certificate. Alice’s browser verifies this certificate against the trusted CA’s list.
Simultaneously, the banking website requests Alice’s client-side certificate. Alice’s browser sends her certificate, which the banking website verifies against its own trusted CA’s list.
Result
Verification of Authenticity: Both Alice and the banking website can independently verify each other’s identity through the certificates.
Secure Connection Establishment: Once mutual authentication is successful, a secure TLS connection is established, ensuring that all data transmitted is encrypted and protected from interception.
Failure of MITM Attack: Bob, the attacker, cannot present a valid server-side certificate that matches the banking website’s certificate. Similarly, he cannot spoof Alice’s client-side certificate. Any attempt to bypass or interfere with this mutual authentication process will result in the connection being terminated, alerting Alice to the presence of a potential security threat.
In summary, mutual authentication prevents attackers like Bob from successfully executing man-in-the-middle attacks by requiring both parties to authenticate each other using trusted certificates. This ensures that Alice’s connection to the banking website is both secure and legitimate.
But what about when there is no certificate signing verification on both side such as non banking websites — as the simple web admin among of us might have?
Join me and wait for part III.
