minte9

LearnRemember

SSL Handshake

SSL (Secure Sockets Layer) is a cryptographic protocol for secure comunications. TLS (Transport Layer Security) is the successor to SSL. TLS handshake is a complex process that establishes a secure encrypted connection between a client and a server. A certificate contains server name, certificate authority, public key. Here's an overview of the SSL handshake process:

 
1. Client initiate a connection
2. Server sends back un encrypted certificate

3. Client decrypt the certificate using the public key
4. Client checks CA against his browser CA trusted list
5. Client encrypts a secret number, using public key

6. Server decrypts secret number
7. Now, both parties have the secret number (handshake)

Here's a more detailed overview of the TLS handshake process. 1. Client Hello: The TLS handshake begins with the client sending a hello message to the server. 2. Server Hello: The server responds with a hello message. 3. Server Certificate (if required): If the server requires authentication, it sends its digital certificate. This certificate contains the server public key (signed by a trusted CA). 4. Key Exchange: The client and server agree on a key exchange method based on the selected cipher suite. This is used to securely exchange session keys. 5. Server Hello Done: The server sends a "ServerHelloDone" message. This indicates that its part of the handshake is complete. 6. Client Key Exchange: If required by the key exchange method, the client sends a "ClientKeyExchange" message, which contains the client public key or the necessary data for key exchange. 7. Change Cipher Spec: Both the client and server send a "ChangeCipherSpec" message to inform each other that subsequent communication will be encrypted using the negotiated keys and parameters. 8. Finished: Both the client and server send a "Finished" message to confirm that the handshake is complete. 9. Data Exchange: Once the handshake is complete, the client and server can begin to securely exchange data. All communication is now encrypted and protected from eavesdropping and tampering.

MITM Atack

Here's how the steps would look without certificate validation and with a MITM attack: 1. Client initiates a connection to the server. 2. The MITM attacker intercepts the connection and responds instead of the actual server. 3. The attacker sends back an unencrypted or self-signed certificate claiming to be the server. The client, without certificate validation, proceeds to accept this certificate as legitimate. 4. The client attempts to decrypt the certificate using the public key provided in the fake certificate. This will succeed, as the public key is known to the attacker, but this public key doesn't belong to the legitimate server. 5. The client, without proper certificate validation, doesn't perform any checks against a list of trusted CAs. It accepts the fake certificate as valid. 6. The client encrypts a secret number with the public key from the fake certificate and sends it to the attacker, believing it's the server. 7. The attacker successfully decrypts the secret number using the corresponding private key (since the attacker created the fake certificate) and has now established a shared secret with the client. The client also believes it has completed a handshake with the legitimate server. From this point, the attacker can intercept and manipulate all data between the client and server, as they possess the shared secret key and can effectively impersonate both sides of the communication.