SSL

From Network Security Wiki


Basics

  • 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:[1] 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
  • SSL needs:
6 Cryptographic secrets
4 Keys
2 IVs
  • The Diffie-Hellman key exchange provides Forward Secrecy.
Even if the attacker obtains the certificate key and a connection transcript after the connection ended they can't decrypt the data, because they don't have the ephemeral session key.
  • Example of SSL Stream:
https://tls.ulfheim.net/


SSL Record Overview

Source: cisco.com

        This section needs reorganization.
Record Format

Each record consists of a five-byte record header, followed by data. 

Type
Version - VH,VL
Length  - LH,LL
  • Record Type - There are four record types in SSL:
Handshake
Change Cipher Spec
Alert
Application Data
  • Version Details:
SSLv2    0x0002
SSLv3    0x0300
TLSv1    0x0301
TLS 1.0  0x0302
TLS 1.2  0x0303


  • Record Length - 16-byte value, single record can be up to 65,535 (2^16 -1) bytes in length.
Types of Records
  • Handshake 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.

  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.
  • Change Cipher Spec protocol:
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.
  • 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 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
  • 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.


Client Hello
Protocol Version     Version of the SSL protocol by which the client wishes to communicate during this session.
Session ID           ID client wishes to use for this connection. In first Client Hello of exchange, the session ID is empty.
Cipher Suite         Cryptographic Algorithms supported by the client; First choice first; Each contains Key Exchange Algorithm and a Cipher Spec.
Compression Method   List of compression algorithms supported by the client. If server does not support any method, the connection fails. This can also be null.
Server Hello
Protocol Version     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 session ID sent by the Client in the Client Hello is not empty, server looks in the session cache for a match. 
                     If a match is found, the server responds with the same value that was supplied by the client.  
                     This indicates a resumed session and both must directly proceed to Finished messages. 
                     If this field contains a different value that identifies the new session.
                     If server sends empty Session_ID, it indicate that the session will not be cached, and therefore cannot be resumed.
Cipher Suite         Selected by the server from the list.
Compression Method   Selected by the server from the list. 
Certificate Request  The server sends the client a list of all the certificates that are configured on it.
                     Allows the client to select which certificate it wants to use for authentication.
Hello Request
Server sends Hello Request to the client for SSL session resumption requests. 
This tells client to start the renegotiation with a Client Hello request.
Server Hello Done
Sent by the server to indicate the end of the server hello and associated messages. 
Then Server waits for a client response. 
Upon receipt of this, 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:   Server sends its certificate immediately after the Server Hello message. 
                      The certificate type must be appropriate for the selected cipher suite key exchange algorithm, generally X.509.v3 certificate.
Server Key Exchange:  This 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.
Certificate Request:  A server can optionally request a certificate from the client.
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.

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
        This section needs to be concized.
  • 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:
SSL Protocol version
Session ID
List of Cipher Suites supported by the client.
List of CLIENT HELLO Extensions
  • Capture a network trace this is how the CLIENT HELLO would look like:
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
  • 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.


  • The Server responds to the client with SERVER HELLO.
  • The Server typically responds back with the following details:
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.
  • 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.
NOTE
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.
  • 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.



OCSP Stapling

Source: wikipedia.org

OCSP Issues
  • OCSP itself can introduce a significant cost for the CA because it requires them to provide responses to every client of a given certificate in real time.
  • When a certificate is issued to a high traffic website, the servers of CAs are likely to be hit by enormous volumes of OCSP requests querying the validity of the certificate
  • OCSP checking potentially impairs users' privacy and slows down browsing, since it requires the client to contact a third party (the CA) to confirm the validity of each certificate that it encounters.
  • Moreover, if the client fails to connect to the CA for an OCSP response, then it is forced to decide between:
(a) Continuing the connection anyway; defeating the purpose of OCSP
(b) Terminating the connection based on the assumption that there is an attack; but which could result in excessive false warnings and blocks.
OCSP Stapling
  • Online Certificate Status Protocol stapling is a standard for checking the revocation status of X.509 digital certificates.
  • It allows the presenter of a certificate to bear the resource cost involved in providing OCSP responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance.
  • The certificate holder itself queries the OCSP server at regular intervals, obtaining a signed time-stamped OCSP response.
  • When the site's visitors attempt to connect to the site, this response is included ("stapled") with the TLS/SSL handshake via the Certificate Status Request extension response
  • The stapled responses can't be forged as they need to be directly signed by the certificate authority, not the server.
  • If the client does not receive a stapled response, it will just contact the OCSP server by itself.
  • If the client receives an invalid stapled response, it will abort the connection.
  • The only increased risk of OCSP stapling is that the notification of revocation for a certificate may be delayed until the last-signed OCSP response expires.
  • OCSP stapling supports only one OCSP response at a time, which is insufficient for certificate chains with intermediate CA certs.
  • This limitation has been addressed by Multiple Certificate Status Request Extension


Session Tickets

Source blog.filippo.io

  • Supported in TLS 1.2
  • Technique to resume TLS sessions by storing key material encrypted on the clients.
  • They speed up the handshake from two to one round-trips.
  • Server will encrypt the session key with a key only the server has, the Session Ticket Encryption Key (STEK), and send it to the client.
  • The client holds on to that encrypted session key, called a ticket, and to the corresponding session key.
  • The next time the client wants to connect to that server it sends the ticket along with the initial parameters.
  • If the server still has the STEK it will decrypt the ticket, extract the session key, and start using it.
  • This establishes a resumed connection and saves a round-trip by skipping the key negotiation.
  • Otherwise, client and server fallback to a normal handshake.
References
  1. ↑ www.zscaler.com



{{#widget:DISQUS |id=networkm |uniqid=SSL |url=https://aman.awiki.org/wiki/SSL }}

Retrieved from "https://aman.awiki.org/wiki/SSL?oldid=4544"