SSL

= HTTPS =
 * SSL Session vs Connection:
 * Session = Server & client has common session identifiers, certificates, compression, cipher suite, master secret.
 * Connection = Both exchange random numbers, create various keys & parameters for authentication & privacy.


 * SSL has 4 protocols:
 * 1. Handshake Protocol: Negotiate Cipher Suite & exchange information for building cryptographic secrets. It has 4 Phases:
 * a)Phase 1: Establishes secret capabilities
 * b)Phase 2: Server authentication and Key exchange
 * c)Phase 3: Client authentication and Key exchange
 * d)Phase 4: Finalizing handshake
 * 2. ChangeCipherSpec Protocol
 * 3. Alert Protocol
 * 4. Record Protocol

6 Cryptographic secrets 4 Keys 2 IVs
 * SSL needs:

= SSL Record Overview =

Type Version - VH,VL Length - LH,LL
 * Record Format - Each record consists of a five-byte record header, followed by data.

Handshake Change Cipher Spec Alert Application Data
 * Record Type - There are four record types in SSL:

SSLv2 0x0002 SSLv3 0x0300. TLSv1 0x0301.
 * Version Details:


 * Record Length - 16-byte value, single record can be up to 65,535 (2^16 -1) bytes in length.


 * Types of Records

Handshake records are not encrypted. Handshake record that contains a finished message is always encrypted. It always occurs after a Change Cipher Spec (CCS) record.
 * Handshake records:

Hello Request (0) Client Hello (1) Server Hello (2) Certificate (11) Server Key Exchange (12) Certificate Request (13) Server Hello Done (14) Certificate Verify (15) Client Key Exchange (16) Finished (20)

Finished Messages are always sent immediately after a Change Cipher Spec message in order to verify that the key exchange and authentication processes were successful. The Finished message is the first protected packet with the most recently negotiated algorithms, keys, and secrets. No acknowledgment of the Finished message is required; parties can begin to send encrypted data immediately after they send the Finished message. Recipients of Finished messages must verify that the contents are correct.

Hello Request

CCS records are used in order to indicate a change in cryptographic ciphers. Immediately after the CCS record, all data is encrypted with the new cipher. Sent by both client and server in order to notify the receiving party that subsequent records are protected under the most recently negotiated Cipher Spec and keys. Might or might not be encrypted; in a simple connection with single handshake, the CCS record is not encrypted.
 * Change Cipher Spec protocol:

Some alerts are warnings, while others are fatal and cause the connection to fail. Alerts might or might not be encrypted, and might occur during a handshake or during data transfer. There are two types of alerts: Closure Alerts: The connection must be properly closed in order to avoid any kind of truncation attacks. A close_notify message indicates to the recipient that the sender will not send anymore messages on that connection. Error Alerts:  When an error is detected, the detecting party sends a message to the other party. Upon transmission or receipt of a fatal alert message, both parties immediately close the connection. Example: unexpected_message (fatal) decompression_failure handshake_failure
 * Alert Records are used in order to indicate to the peer that a condition has occured.

These records contain the actual application data. These messages are carried by the record layer and are fragmented, compressed, and encrypted, based on the current connection state.
 * Application Data Record

= SSL Handshake =

Source: blogs.msdn.com


 * Brief Steps:
 * 1) Client & Server exchange 2 random keys
 * 2) Both exchange 1 PreMaster Secret
 * 3) Master Key is created from PM Secret by running SHA1 & MD5 several times
 * 4) Master Key is used to create variable length key material depending on the cipher used
 * 5) Six different secrets are extracted from key material


 * Details:



SSL Protocol version Session ID List of Cipher Suites supported by the client. List of CLIENT HELLO Extensions
 * First 3-way handshake occurs.
 * The client will now forward the requests to the Destination IP on port 443 (Default TLS/SSL port).
 * The control is now transferred to the SSL Protocol in the application layer.
 * It has the IP & the Port information handy from previous steps.
 * However, it still has no clue whatsoever about the hostname.
 * The client creates a TLS Packet called as CLIENT HELLO.
 * This contains the following details:

Handshake Protocol: Client Hello Version: TLS 1.0 (0x0301) Cipher Suites (12 suites) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Extension: server_name
 * Capture a network trace this is how the CLIENT HELLO would look like:


 * The client sends a CLIENT HELLO to the server on the IP & Port it obtained during TCP handshake
 * Upon receiving the CLIENT HELLO, the server has access to the following information:

IP Address (10.168.3.213) Port Number (443) Protocol Version (TLS 1.0) List of Cipher Suites Session ID List of CLIENT HELLO Extensions etc.


 * The Server will first check if it supports the above protocol version and if any of the cipher suites in the provided list. * If not, the handshake fails there itself.
 * The Server will now try to determine if there is an end point listening on the IP and PORT.
 * It then finds the certificate hash corresponding to the IP+PORT combination.

SSL/TLS Protocol version. One of the cipher suites from the list of cipher suites provided by client. (whichever is the most secure) Certificate of the server (Without the private key of course) List of SERVER HELLO Extensions. (OPTIONAL)If the web app associated with this binding requires a Client Certificate for authentication then it would request the client to send the certificate. Here the IIS Sever would send the client the distinguished names of the list of TRUSTED ROOT CA it supports.
 * The Server responds to the client with SERVER HELLO.
 * The Server typically responds back with the following details:


 * Below is a snippet of the network trace:

Handshake Protocol: Server Hello Version: TLS 1.0 (0x0301) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Handshake Protocol: Certificate Certificate (id-at-commonName=www.kaushalz.com,id-at-organizationalUnitName=Azure,id-at-organizationName=Microsoft,id-at-localityName=Bangalore,id-at-stateOrProvinceName=India,id-at-countryName=IN)


 * The Client uses the SERVER HELLO to perform SERVER AUTHENTICATION.

If you captured a network trace for a SSL Handshake you could see the details until SERVER HELLO, after that the encryption begins and nothing would be available and would make sense as the packets are encrypted.
 * NOTE:


 * The Client uses the data provided from the server to generate a pre-master secret for the session, encrypts it with the server's public key (obtained from the server's certificate), and then sends the encrypted pre-master secret to the server.
 * If the server had requested for CLIENT CERTIFICATE, then client also signs another piece of data that is unique to this handshake and known by both the client and server.
 * In this case, the client sends both the signed data and the client's own certificate to the server along with the encrypted pre-master secret.
 * If the server had requested for client authentication, the server attempts to authenticate the client.
 * If the client cannot be authenticated, the session ends.
 * If the client is successfully authenticated, the server uses its private key to decrypt the pre-master secret, and then performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret.
 * Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity (that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection).
 * The CLIENT & the SERVER send each other a message informing that future messages from them will be encrypted with the session key.
 * It then sends a separate (encrypted) message indicating that its portion of the handshake is finished.
 * The SSL Handshake is done.
 * The Client and the Server send each other messages which are encrypted/decrypted using the session keys generated in the previous step.
 * It is now that the Client sends the actual HTTP Request packet to the Server in the encrypted form.
 * The Server decrypts the request via the symmetric key and generates a response, encrypts it and sends it back to the client.
 * This continues normally for the entire session of secure communication.


 * We can see details in a Packet Capture only until SERVER HELLO.
 * Anything beyond this point is not visible.
 * However, in case of a SSL ALERT we would see some notification which can be viewed in the network traces.
 * If there was a problem during the SSL Handshake then you there would be an exception raised within the SSL Layer using SSL ALERT PROTOCOL.
 * These exceptions may or may not be fatal i.e. not all exceptions would cause the handshake to fail.


 * References: