SSL Messages Exchange DeepDive (for advanced users)

SSL packets are called records and can be classified into four types:

• Handshake (22, 0x16)
• Change Cipher Spec (20, 0x14)

• Alert (21, 0x15)

• Application Data (23, 0x17)

Each record consists of:

• Type: uint8

• Version: uint16

• Length: uint16
• Data

Types of Records

Handshake Records

Handshake records contain a set of messages that are used in order to handshake. These are the messages and their values:

• Hello Request (0, 0x00)
• Client Hello (1, 0x01)
• Server Hello (2, 0x02)
• Certificate (11, 0x0B)
• Server Key Exchange (12, 0x0C)
• Certificate Request (13, 0x0D)
• Server Hello Done (14, 0x0E)
• Certificate Verify (15, 0x0F)
• Client Key Exchange (16, 0x10)
• Finished (20, 0x14)

In the simple case, handshake records are not encrypted. However, a handshake record that contains a Finished message is always encrypted, as it always occurs after a Change Cipher Spec (CCS) record.

Change Cipher Spec Records

CCS records are used in order to indicate a change in crpytographic ciphers. Immediately after the CCS record, all data is encrypted with the new cipher. CCS records might or might not be encrypted.

Alert Records

Alert records are used in order to indicate to the peer that a condition has occured. 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 between the client and the server must be properly closed in order to avoid any kind of truncation attacks. A close_notify message is sent that 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. Some examples of error alerts are:
• unexpected_message (fatal)
• decompression_failure
• handshake_failure

Application Data Record

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.

A typical SSL client-server authentication as follow.

Hello Message Phase

When an SSL client and server begin to communicate, they agree on a protocol version, select cryptographic algorithms, optionally authenticate each other, and use public key encryption techniques in order to generate shared secrets.

Client Hello

The Client Hello sends these attributes to the server: 

• Protocol Version: The version of the SSL protocol by which the client wishes to communicate during this session.

• Session ID: The ID of a session the client wishes to use for this connection. In the first Client Hello of the exchange, the session ID is empty (refer to the packet capture screen shot after the note below).
• Cipher Suite: This is passed from the client to the server in the Client Hello message. It contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (first choice first). Each cipher suite defines both a key exchange algorithm and a cipher spec. The server selects a cipher suite or, if no acceptable choices are presented, returns a handshake failure alert and closes the connection.

• Compression Method: Includes a list of compression algorithms supported by the client. If the server does not support any method sent by the client, the connection fails. The compression method can also be null. 

Note: The server IP address in the captures is 10.0.0.2 and the client IP address is 10.0.0.1.

Server Hello

The server sends back these attributes to the client: 

• Protocol Version: The chosen version of the SSL protocol that the client supports.
• Session ID: This is the identity of the session that corresponds to this connection. If the session ID sent by the client in the Client Hello is not empty, the server looks in the session cache for a match. If a match is found and the server is willing to establish the new connection using the specified session state, the server responds with the same value that was supplied by the client. This indicates a resumed session and dictates that the parties must proceed directly to the finished messages. Otherwise, this field contains a different value that identifies the new session. The server might return an empty session_id in order to indicate that the session will not be cached, and therefore cannot be resumed.
• Cipher Suite: As selected by the server from the list that was sent from the client. 
• Compression Method: As selected by the server from the list that was sent from the client. 
• Certificate Request: The server sends the client a list of all the certificates that are configured on it, and allows the client to select which certificate it wants to use for authentication.

For SSL session resumption requests:

• The server can send a Hello request to the client as well. This is only to remind the client that it should start the renegotiation with a Client Hello request when convenient. The client ignores the Hello request from the server if the handshake process is already underway.
• The handshake messages have more precedence over the transmission of application data. The renegotiation must begin in no more than one or two times the transmission time of a maximum-length application data message.

Server Hello Done

The Server Hello Done message is sent by the server in order to indicate the end of the server hello and associated messages. After it sends this message, the server waits for a client response. Upon receipt of the Server Hello Done message, the client verifies that the server provided a valid certificate, if required, and checks that the Server Hello parameters are acceptable.

Server Certificate, Server Key Exchange, and Certificate Request (Optional)

• Server Certificate: If the server must be authenticated (which is generally the case), the server sends its certificate immediately after the Server Hello message. The certificate type must be appropriate for the selected cipher suite key exchange algorithm, and is generally an X.509.v3 certificate.
• Server Key Exchange: The Server Key Exchange message is sent by the server if it has no certificate. If the Diffie?Hellman (DH) parameters are included with the server certificate, this message is not used.

Client Exchange

Client Certificate (Optional)

This is the first message that the client sends after he/she receives a Server Hello Done message. This message is only sent if the server requests a certificate. If no suitable certificate is available, the client sends a no_certificate alert instead. This alert is only a warning; however, the server might respond with a fatal handshake failure alert if client authentication is required. Client DH certificates must match the server specified DH parameters.

Client Key Exchange

The content of this message depends on the public key algorithm selected between the Client Hello and the Server Hello messages. The client uses either a premaster key encrypted by the Rivest-Shamir-Addleman (RSA) algorithm or DH for key agreement and authentication. When RSA is used for server authentication and key exchange, a 48-byte pre_master_secret is generated by the client, encrypted under the server public key, and sent to the server. The server uses the private key in order to decrypt the pre_master_secret. Both parties then convert the pre_master_secret into the master_secret.

Certificate Verify (Optional)

If the client sends a certificate with signing ability, a digitally-signed Certificate Verify message is sent in order to explicitly verify the certificate. 

Cipher Change

Change Cipher Spec Messages

The Change Cipher Spec message is sent by the client, and the client copies the pending Cipher Spec (the new one) into the current Cipher Spec (the one that was previously used). Change Cipher Spec protocol exists in order to signal transitions in ciphering strategies. The protocol consists of a single message, which is encrypted and compressed under the current (not the pending) Cipher Spec. The message is sent by both the client and server in order to notify the receiving party that subsequent records are protected under the most recently negotiated Cipher Spec and keys. Reception of this message causes the receiver to copy the "read pending" state into the "read current" state. The client sends a Change Cipher Spec message following handshake key exchange and Certificate Verify messages (if any), and the server sends one after it successfully processes the key exchange message it received from the client. When a previous session is resumed, the Change Cipher Spec message is sent after the Hello messages. In the captures, the Client Exchange, Change Cipher, and Finished messages are sent as a single message from the client.

Finished Messages

A Finished message is 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.

What is SSL Cryptography?

Recently, I have been working on a project to deploy Cisco Jabber. Cisco Jabber needs integration with Cisco AnyConnect VPN for remote teleworkers. AnyConnect VPN is a sub-division of Cisco SSL VPN.

As I usually prefer, I will post in the following order:

1. What SSL Cryptograph?
2. SSL Messages Exchange DeepDive (for advanced users)
3. ASA SCEP Proxy Enrollment
4. Deploying Jabber for Remote Teleworkers (Step-by-Step Guide)

I prefer this order to avoid any gaps in knowledge transfer. Some of the posts won't be relevant to some people who already have the knowledge or not interested in VPN technologies.

SSL is a security protocol used to establish encrypted link between clients and servers to carry data securely. Clients can be outlook, web browsers, any connect client, etc.

Asymmetric Encryption

Asymmetric encryption (or public-key cryptography) uses a separate key for encryption and decryption. Anyone can use the encryption key (public key) to encrypt a message. However, decryption keys (private keys) are secret. This way only the intended receiver can decrypt the message. The most common asymmetric encryption algorithm is RSA.

 

Asymmetric keys are typically 1024 or 2048 bits. Though larger keys can be created, the increased computational burden is so significant that keys larger than 2048 bits are rarely used.

Symmetric Encryption

Symmetric encryption (or pre-shared key encryption) uses a single key to both encrypt and decrypt data. Both the sender and the receiver need the same key to communicate.

Symmetric key sizes are typically 128 or 256 bits.

Which is better?

There are three parameters to use in the comparison:
1. Security
Due to the fact that asymmetric encryption uses two keys, make it more secure and very complex to crack.

2. Compute Complexity

Symmetric keys are smaller than asymmetric, so they require less computational burden.

3. Ease of Distribution

Since symmetric keys should be similar at both ends of communication, distribution can be more complex in large environments. With asymmetric keys, this won't be an issue since the public key is used for encryption only. This means that you can distribute the public key globally. Private key is kept as secret and will be used by intended destination only for decryption.

SSL Encryption

SSL Encryption combines the advantages of both symmetric and Asymmetric encryption. Its usually called Public Key Infrastructure.

In SSL communications, the server’s SSL Certificate contains an asymmetric public and private key pair. The session key that the server and the browser create during the SSL Handshake is symmetric. This is explained further in the diagram below.

1. Server sends a copy of its asymmetric public key.

2. Browser creates a symmetric session key and encrypts it with the server’s asymmetric public key.

3. Server decrypts the asymmetric public key with its asymmetric private key to get the symmetric session key.

4. Server and Browser now encrypt and decrypt all transmitted data with the symmetric session key. This allows for a secure channel because only the browser and the server know the symmetric session key, and the session key is only used for that session. If the browser was to connect to the same server the next day, a new session key would be created.

Asymmetric Encryption Algorithms: These can use RSA and Elliptic Curve Cryptography (ECC) to create the public and private keys. With asymmetric encryption it is computationally easy to generate public and private keys, encrypt messages with the public key, and decrypt messages with the private key. However, it is extremely difficult (or impossible) for anyone to derive the private key based only on the public key

Symmetric Encryption Algorithms: These use algorithms like Twofish, AES, or Blowfish, to create keys. All of these encryption algorithms fall into two types: stream ciphers and block ciphers. Stream ciphers apply a cryptographic key and algorithm to each binary digit in a data stream, one bit at a time. Block ciphers apply a cryptographic key and algorithm to a block of data (for example, 64 sequential bits) as a group. Block ciphers are currently the most common symmetric encryption algorithm.

SSL Certificates

To get a certificate, you must create a Certificate Signing Request (CSR)on your server for your organization domain name/web site. This CSR creates the private key and a CSR data file that you send to the SSL Certificate issuer (called a Certificate Authority or CA). The CA uses the CSR data file to create a public key to match your private key without compromising the key itself. The CA never sees the private key.

Once you receive the SSL Certificate, you install it on your server. Now the server hosts private key, public key, and SSL certificate. Also, the server is ready to accept and encrypt connections.

Now if you got the private and public keys, why do you need the SSL certificate?

Certificates are mainly used for authentication and verifying identity of the organization (you don't want to submit your credit card information to untrusted organization using fake domain name). Anyone having a CA server (MS, Cisco IOS, OpenSSL) can issue a certificate and generate public key for a CSR, but browsers only trust server certificates issued by trusted CAs. Browsers come with a pre-installed list of trusted CAs, known as the Trusted Root CA store.

Trusted CAs usually verify the identity of the organization before signing the CSR and generating the certificate (establishment card of the organization, verifying the authorized representative of the organization, etc). When the client trying to connect to server and receives the certificate, it looks at the certificate path to check the CA who signed the certificate. If the client has the CA certificate (Root certificates) in its Trusted Root CA Store, it knows that the certificate was signed by a trusted CA which means that the organizations identity was verified, i.e. authentication is successful

Certification Chain

For some CAs, you also install a pair of intermediate certificates that establish the credibility of your SSL Certificate by tying it to your CA’s root certificate.

In the image below, you can see what is called the certificate chain. It connects your server certificate to your CA’s (in this case DigiCert’s) root certificate through a series of intermediate certificates.