How HTTPS works:

How HTTPS works:

Phase 1: TLS Handshake (Secure Channel Setup)

Phase 2: HTTPS Communication (Encrypted Data Transfer)

Phase 1: TLS Handshake (Secure Channel Setup)

Step 1: Client Hello

 The browser (client) sends an HTTPS request to the server.

 It includes:

•    A random number (`client_random`)
•    A list of supported cipher suites (e.g., ECDHE-RSA, ECDHE-ECDSA)
•    TLS version info

 Step 2: Server Hello

 The server responds with:

•    Another random number (`server_random`)
•    A selected cipher suite (e.g., ECDHE-RSA, ECDHE-ECDSA)
•    Its digital certificate (contains public key and domain info)

 Step 3: Certificate Validation (Browser Side)

 The browser verifies the server certificate:

•    Is it issued by a trusted Certificate Authority (CA)?
•    Is it not expired?
•    Is the domain name correct?
•    If valid → continue.
•    If not → browser shows a "connection not secure" warning.

 Most browsers already include trusted CA certificates, so we don’t usually have to import anything manually unless it’s a self-signed certificate.

(Optional) Self-Signed Certificate Scenario

If you're using a self-signed certificate:

 You create it yourself (with keytool/OpenSSL) → this includes:

•    A public certificate (includes public key)
•    A private key (for decryption)

 You must:

  1. Export the certificate from your keystore

  2. Manually import it into:

•       The browser trust store (for testing)
•       Or the Java truststore (if client is Java-based)

      Only the certificate (public part) is shared. The private key stays in server only (Server's keystore).

 Step 4: Key Exchange

Depending on the cipher method (e.g., ECDHE-RSA, ECDHE-ECDSA):

 In RSA-based TLS (old):

•    Client generates a pre-master secret (random value)
•    Encrypts it using the server's public key
•    Sends it to the server
•    Server decrypts it with its private key

 In ECDHE (modern, TLS 1.2/1.3):

•    Both server and client exchange public keys and use Diffie-Hellman to derive a shared session key.

 Step 5: Session Key Derivation

 Both client and server now have:

•    client_random
•    server_random
•    pre-master secret (or shared key via ECDHE)

 They use a key derivation function to generate a session key.

 Step 6: Handshake Complete

 A secure channel is now established.

 All future data (requests/responses) are encrypted using the session key (symmetric encryption).

Phase 2: HTTPS Communication (Encrypted Data Transfer)

 The client and server send and receive data using the session key.

 No public/private key usage here — it's all symmetric (faster).

 Browser shows "🔒 Secure".

Then handshake is completed and transaction is open:

• Normally mutiple request can send through same transaction (through session id).
• By default without any reqeuest session is alive 30 min in http 1.1 and http2 may Minutes, then it will automatically terminated.
• But that time is configurable (In Tomcat or other web servers).

Final Clean and Correct Version

1. Browser sends Client Hello with a random number and supported encryption methods.
2. Server responds with Server Hello, random number, and its certificate (contains public key).
3. Browser validates certificate using built-in trusted CAs (or manually if self-signed).
4. Browser generates a pre-master secret, encrypts it using the server’s public key, and sends it.
5. Server decrypts the secret using its private key.
6. Both sides generate the session key from the shared secret + randoms.
7. From now, all data is encrypted using the session key (symmetric encryption).
8. The connection may stay open for multiple requests (keep-alive), and times out after a configured period (e.g., 30–120 seconds).
9. (Optional) Self-signed certs must be manually trusted by the client (browser or Java).