Question

Suppose Bob initiates a TCP connection to Trudy who is pretending to be Alice. During the handshake, Trudy sends Bob Alice’s certificate. In what step of the SSL handshake algorithm will Bob discover that he is not communicating with Alice?

Short answer

Bob discovers the issue during the certificate validation step.

Step-by-step solution

Understanding SSL Handshake Basics

The SSL handshake is a process that establishes the encryption methods and verifies identities between a client and a server. It typically involves several steps, including exchanging certificates to establish trust.

Certificate Sending Step

During the SSL handshake, the server sends its certificate to the client in order to prove its identity. This usually happens after the client hello and server hello messages.

Certificate Validation

After receiving the server's certificate, the client performs validation checks. These checks include verifying the certificate's signatures and ensuring that the certificate corresponds to the server's claimed identity.

Alice's Certificate Validation Fails

Bob checks if the certificate belongs to Alice by trying to verify some details like the Common Name (CN) on the certificate and cross-verifying it against the expected identity. Since Trudy is pretending to be Alice, the certificate details (CN, issuer, etc.) will likely lead to a mismatch.

Decision Point for Bob

If the certificate validation fails or Bob senses any discrepancies in the expected identity, he discovers that the server does not genuinely belong to Alice. Bob will abandon the communication upon this realization, which occurs during the certificate validation step.

Key concepts

Certificate Validation

The process of certificate validation is a critical step in the Secure Sockets Layer (SSL) handshake. When a client, like Bob, connects to a server, part of the handshake involves the server sending its digital certificate to the client. This certificate acts like an ID card for the server, showing that it's authentic and trustworthy.

Once Bob receives this certificate, he needs to ensure that it is legitimate. This involves several checks:

• **Signature Verification**: Bob checks if the certificate's digital signature is from a trusted Certificate Authority (CA). If the signature doesn't match, it's a red flag.
• **Validity Period**: He checks the start and end dates to ensure the certificate is currently valid.
• **Common Name (CN) and Identity Check**: The CN should match the server's URL Bob intended to connect to. Any mismatch here could indicate foul play.
• **Revocation Status**: Bob ensures that the certificate hasn't been revoked, by checking Certificate Revocation Lists (CRLs) or using the Online Certificate Status Protocol (OCSP).

If any of these checks fail, Bob will understand that something is wrong, which is what happens when Trudy pretends to be Alice. This crucial step ensures that the client isn't tricked into communicating with an imposter.

Encryption Methods

During the SSL handshake, encryption methods are determined to ensure that all data exchanged between the client and server is secure. Encryption converts readable data into ciphertext, which is unreadable without the correct decryption key.

The initial handshake includes a negotiation where both parties agree on which encryption algorithms to use. This often involves a mix of symmetrically and asymmetrically methods:

• **Symmetric Encryption**: This type uses the same key for both encryption and decryption. It's fast and suitable for secure data transmission but requires a secure way to share the key.
• **Asymmetric Encryption**: Utilizes a pair of keys; one public and one private. The public key encrypts the data, and only the corresponding private key can decrypt it, facilitating secure key exchange.
• **Cipher Suite Agreement**: The parties agree on a package of algorithms that comprises the cipher suite - this includes the key exchange algorithm, bulk encryption algorithm, and the message authentication code (MAC).

Agreeing on strong, reliable encryption methods is pivotal in safeguarding sensitive data against eavesdropping or interception during transfer.

Identity Verification

Identity verification is an essential function of the SSL handshake, where the client confirms the server's claimed identity. This operation ensures that Bob knows he's connecting to Alice, rather than an imposter like Trudy.

This is typically achieved through:

• **Digital Certificates**: These provide detailed information about the server, including the public key and the server's identity as vouched by a CA.
• **Public Key Infrastructure (PKI)**: The backbone of secure communications, where trusted third parties assert the identities of entities via certificates.
• **Trust Chains**: If Bob trusts the CA that issued the server's certificate, he can trust the server's identity. This chain of trust is crucial in establishing a secure connection.
• **Cross-Checking Information**: Bob verifies the certificate's properties (like the CN) against the server he intended to interact with, ensuring that the details align.

Without successful identity verification, there's a risk of man-in-the-middle attacks, where an attacker masquerades as a legitimate server. Ensuring the true identity of the communication partner helps to maintain integrity and trust during online interactions.