HTTPS

https.md

HTTPS

Two main purposes:

1. Authentication: verifying that you are talking directly to the server that you think you are talking to  
	
2. Encryption: ensuring that only the server can read what you send it and only you can read what it sends back

SSL = SSL ^3.0
TLS = SSL >= 3.1
HTTPS = HTTP inside TLS / SSL bi-direction tunnel connection

---

Process

(1) A client makes a request for HTTPS URI--this initiates a handshake between the client and server

The goals of the handshake are:

1. Satisfy the client that it is talking to the right server (and optionally visa versa)  
2. Parties to have agreed on a “cipher suite”, including which encryption algorithm to exchange data  
3. Parties to have agreed on any necessary keys for this algorithm  

(2) Handshake starts

Hello [Client sends]

• SSL / TLS versions available Key algorithms available (RSA, DSA, Diffie-Hellman)
• Cipher algorithms available (RC4, AES, DES3)
• Hash algorithms available (MD5, SHA1, SHA256)

Hello [Server sends]

• SSL / TLS version selection
• Key algorithm selection
• Cipher algorithm selection
• Hash algorithm selection
• Random data to be used as key exchange for client

Certificate [Server sends]

• Issuer (CA: certificate authority) often via a chain that goes up to the root CA. Each subsequent CA is certified by the one before it all the way up to the root.
• Serial number Expiration (dates valid)
• Public key
• Entity information (domain, name, address, etc)

Key exchange [Client sends]

• Encrypts random data with server's public key

Key exchange [Server sends]

• Decrypts random data with its private key

Ciper Spec [Client sends]

• All further information from client will be encrypted

Digest [Client sends]

• Encrypted summary of all previous information exchanged between client and server ensure no tampering has taken place

Cipher Spec [Server sends]

• All further information from server will be encrypted

Digest [Server sends]

• Encrypted summary of all previous information exchanged between client and server ensure no tampering has taken place

(3) Handshake complete.

Now that the authentication check has taken place, a symmetric key is used for encryption for the remainder of the session. This is computationally less intensive than asymmetric encryption and therefore incurs less overhead.

  Client                                               Server

  ClientHello                  -------->
                                                  ServerHello
                                                 Certificate*
                                           ServerKeyExchange*
                                          CertificateRequest*
                               <--------      ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                           [ChangeCipherSpec]
                               <--------             Finished
  Application Data             <------->     Application Data

Figure 1. Message flow for a full handshake