Let's go in depth: Inspecting TLS/SSL

SSL (Secure Sockets Layer)

SSL was developed by NetScape in 1994.
SSL (Secure Sockets Layer) is a standard security protocol which is used for establishing encrypted links between a web server and a web client in a client server communication to ensure data security & integrity.
SSL ensures that all data transmitted between the Web Client and Web Server remains encrypted. It works on top of Transport Layer in the network.
The purpose of SSL is to enhance the capability of TCP with confidentiality, data integrity, server authentication and client authentication features to protect from the security threats.
For ensuring security of the data being transferred between a client and server, SSL can be implemented either one-way or two-way.
It was design to provide security and compression services to data generated from the application layer , Data received from the application is compressed(optional), signed, and encrypted before it passed next layer.

TLS (Transport Layer Security)

TLS (Transport Layer Security) is just an updated, more secure, version of SSL. TLS is a cryptographic protocol that provides end-to-end communications security over networks and is widely used for internet communications and online transactions. It is an IETF standard intended to prevent eavesdropping, tampering and message forgery.
TLS is more efficient and secure than SSL as it has stronger message authentication, key-material generation and other encryption algorithms. For example, TLS supports pre-shared keys, secure remote passwords, elliptical-curve keys and Kerberos whereas SSL does not. TLS and SSL are not interoperable, but TLS does offer backward compatibility for older devices still using SSL.
The primary goal of the Transport Layer Security protocol as defined in RFC 2246 (TLS version 1.0) is “to provide privacy and data integrity between two communicating applications.” The TLS protocol ensures this by encrypting data so that any third party is unable to intercept the communication; it also authenticates the peers to verify their identity. By providing a secure channel of communication between two peers, TLS protocol protects the integrity of the message and ensures it is not being tampered.
TLS can be used on top of a transport-layer security protocol like TCP. There are three main components to TLS: Authenticity, Integrity and Confidentiality.

Authenticity, Integrity and Confidentiality.

Authenticity (Not clear who you are talking with): Authenticity is used to make sure that you really communicate with the partner you want to. To achieve these different kinds of techniques can be used, e.g. Pre-shared keys that are configured on both sites, Elliptic Curves or RSA as public/private key algorithms. It ensures that the parties exchanging information are who they claim to be. The server side of the channel is always authenticated; the client side is optionally authenticated.
Integrity (Someone might alter content): Integrity is used to make sure that nobody in between site A and B (for example) changed some parts of the shared information i.e. Data sent over the channel after establishment cannot be modified by attackers without detection. Therefore a hash is calculated and added to a packet. This can be achieved by using hashing algorithms like MD5, SHA (1,2) and so on. To really make sure that no one is even able to modify the hash HMACs are used.
Confidentiality (Anyone can see content): Confidentiality is used to make sure that nobody in between site A and B is able to read what data or information is sent between the two sites. TLS uses a combination of symmetric and asymmetric encryption to ensure message privacy. During the TLS handshake, the TLS client and server agree an encryption algorithm and a shared secret key to be used for one session only. All messages transmitted between the TLS client and server are encrypted using that algorithm and key, ensuring that the message remains private even if it is intercepted. Because TLS uses asymmetric encryption when transporting the shared secret key, there is no key distribution problem.

Location of TLS or SSL

SSL and TLS belong to transport layer which provides end-to-end security for applications that use a reliable transport layer protocol such as TCP.
It provides security services for transactions on the Internet.
SSL fits in between the Transport and Application layers of the OSI model, where any number of protocols (including TCP/IP, Bluetooth, etc.) may act as the transport medium.It is designed to work on top of a reliable transport protocol such as TCP (but has been adapted to UDP, as well) .
Transport Layer Security (TLS) and Secure Sockets Layer (SSL) are both network protocols that allow data to be transferred privately and securely between a web server and web clients.

SSL/TLS is not a single layer protocol, SSL/TLS is two layered protocol, on the top application layer and on bottom Transport layer.There are four protocols on top of SSL Record protocol. SSL Record protocol provides services to these four protocols. Application layers interact with record protocol and in turns provide four protocol for different aspects.

SSL/TLS two layered protocols

1. Handshake Layer manages which cipher (the type of encryption algorithm) will be used, the authentication (using a certificate specific to your domain name and organization), and the key exchange (based on the public-private key pair from the certificate). The handshakeprocess is performed only once to establish a secure network connection for both parties.

Handshake: To communicate over a secure channel, two peers must agree on the cryptographic keys and encryption algorithms for that session. TLS protocol describes the steps to authenticate the peers and set up a secure connection with defined parameters. The entire sequence which involves setting up the session identifier, TLS protocol version, negotiating the cipher suite, certificate authentication of the peers and cryptographic key exchange between peers is called a TLS Handshake.
Alert: This sub-protocol defines the alert levels and provides a description of the alerts. It is used to notify the peer of any error condition that has occurred.
Change Cipher Spec: It defines changes in ciphering strategies. The change cipher spec message, transmitted by both the client and the server, defines the re-negotiated cipher spec and keys that will be used for all the messages exchanged henceforth.
Application Data: This protocol ensures that messages are fragmented, compressed, encrypted and transmitted in a secure manner.

2. Record Layer gets data from the user applications, encrypts it, fragments it to an appropriate size (as determined by the cipher), and sends it to the network transport layer.This is the lower layer which lies on top of the TCP layer and is responsible for:

Fragmenting the message to be transmitted into manageable blocks . It divides the data into blocks of 2*14 bytes.
Encrypting/Decrypting the hashed data. To provide confidentiality, the original data and MAC are encrypted using symmetric-key cryptography.
Compressing/decompressing the outgoing/incoming data . Fragmented data is compressed using one of the lossless compression methods. This service is optional.
Applying the Message Authentication Code (MAC), a hash to maintain the data integrity, SSL use keyed-hash function to create MAC.
Framing : A header is added to encrypted payload. The payload is then passed to a reliable transport layer protocol.
Transmitting the data from the upper application layer to the lower transport layer and vice versa.

History

SSL has evolved with time and several versions have been introduced to deal with any potential vulnerabilities. SSL V2 released in 1995 was the first public version of SSL followed by SSL V3 in 1996 followed by TLS V1.0 in 1999, TLS V1.1 in 2006 and TLS V1.2 in 2008.
TLS and SSL are used interchangeably. TLS’s predecessor, secure socket layer (SSL) was developed by Netscape in 1995. SSL version 1.0 and 2.0 contained many security flaws that prompted a complete redesign of the protocol. In 1996, Netscape released SSL version 3.0 which was the basis for TLS1.0.
In 1999, the PCI Council suggested the eventual deprecation of SSL as TLS 1.0 was a significant upgrade to SSL Protocol (SSL 3.0) that is no longer considered secure; vulnerabilities such as POODLE attack has demonstrated this.
TLS has gone through four iterations, RFC 2246 (TLS 1.0) ,RFC 4346 (TLS 1.1) , RFC 5246 (TLS 1.2) and RFC 8446 (TLS 1.3) Transport Layer Security (TLS) is an IETF (Internet Engineering Task Force) standardization commencement, which aimed to come out with an Internet standard version of SSL.
Netscape passed the protocol over the IETF because it wanted to standardize SSL.The first version of the protocol was published in 1999. The most recent version is TLS 1.3, which was published in 2018.

Difference between TLS and HTTPS

HTTPS is an implementation of TLS encryption on top of the HTTP protocol, which is used by all websites as well as some other web services. Any website that uses HTTPS is therefore employing TLS encryption. I.e. HTTP + TLS/SSL + TCP = HTTPS

Note:
SSL/TSL makes use of both asymmetric and symmetric key cryptography. This is because, of performance reasons. Only the initial "client key exchange message" is encrypted with asymmetric encryption. Symmetric encryption is good compared to asymmetric encryption when compared in terms of performance/speed.

Trust is achieved through the use of certificate trust. Trusted certificates can be used to create secure connections to a server via the Internet. Certificate trust can be thought of as a chain that starts with the Certificate Authority (or CA).Certificate authorities are nothing but a trusted third party. They may and may not be the same firm/organization that the server belongs to.

Certificate Authority (CA) :

A CA is a company or entity that issues SSL Certificates.
A CA certificate is a digital certificate issued by a certificate authority (CA).
The CA verifies trusted certificates for trusted roots.
Trusted roots are the foundation upon which chains of trust are built in certificates.
Trusting a CA root means that you trust all certificates issued by that CA.

Example : Comodo,Symantec,GoDaddy,GlobalSign,Verizon,DigiCert,Buypass,StartCom,Entrust,Trustwave,Secom,Unizeto,QuoVadis,SwissSign

Difference between Self Signed and CA

Self-Signed	CA
Signed/issued by self	Certs signed by a trusted certifying authority
Free to use	Paid to trust authority
Unrecognized by browsers	Trusted by browsers and recognized
Used when there is no sensitive information	Used in case of PII and sensitive data
Used for Pre-Prod environments which reduces cost for local infrastructures(Intranet, Testing)	Can be used everywhere with additional cost

In Self-signed, the certificate is signed by itself . Both "issued to" and "issued by" are same and CA Root certificate is not trusted.
In CA, the Google's certification path is signed by CA-GlobalSign and an intermediate CA-G3 in the chain of trust.
If you would like to build your own Public Key Infrastructure (PKI) and issue other certificates, you need to be a CA as well.

One Way SSL - Only the client authenticates the server

In one way SSL, only client validates the server to ensure that it receives data from the intended server.
For implementing one-way SSL, server shares its public certificate with the clients.
This means that the public certificate of the server needs to configured in the trust store of the client.

Two Way SSL - The client authenticates the server & the server also authenticates the client.

In case of two-way SSL, both client and server authenticate each other to ensure that both parties involved in the communication are trusted.
Both parties share their public certificates to each other and then verification/validation is performed based on that.
This means that the public certificate of the server needs to configured in the trust store of the client. Also the public cert of the client needs to be configured on the server's trust store.

Session vs Connection

Session

This is an association between a client and a server that defines a set of parameters such as algorithms used, session number etc.

Session state parameters

Session identifier: this is an identifier generated by the server to identify a session with a chosen client,
Peer certificate: X.509 certificate of the peer,
compression method: a method used to compress data prior to encryption,
Algorithm specification termed CipherSpec: specifies the bulk data encryption algorithm (for example DES) and the hash algorithm (for example MD5) used during the session,
Master secret: 48-byte data being a secret shared between the client and server,
“is resumable”: this is a flag indicating whether the session can be used to initiate new connections

Connection

This is a logical client/server link, associated with the provision of a suitable type of service. In SSL terms, it must be a peer-to-peer connection with two network nodes.

Connection state parameters

Server and client random: random data generated by both the client and server for each connection,
Server write MAC secret: the secret key used for data written by the server,
Client write MAC secret: the secret used for data written by the client,
Server write key: the bulk cipher key for data encrypted by the server and decrypted by the client,
Client write key: the bulk cipher key for data encrypted by the client and decrypted by the server,
Sequence number: sequence numbers maintained separately by the server for messages transmitted and received during the data session.

Four Protocols (Handshake,ChangeCipherSpec ,Alert & Application Data)

Client Hello - The client sends a Client Hello message proposing SSL/TLS options (specifying the TLS version and a list of suggested cipher suites it supports).
Server Hello - The server responds with a Server Hello message selecting the SSL/TLS options (with the TLS version and a chosen cipher suite).
Certificate from Server - The server presents an X.509 certificate or certificate chain to the client for verification as part of the initial TLS handshake.
Server Certificate Request - The server then requests a certificate from the client so the connection can be mutually authenticated. (optional)
Server Key Exchange - The server sends the client a Server Key Exchange message with the Public Key information sent in step 3.
Server Hello Done - The server sends a Server Hello Done message to tell client it is finished with initial negotiations.
Certificate from client - If the server requests a certificate, the client must send the certificate or certificate chain.
Client Key Exchange - The client sends a Client Key Exchange message which may contain a PreMasterSecret, Public Key, or nothing depending on the cipher suite chosen.
Certificate Verify - This message is sent when the client presents a certificate as above. Its purpose is to allow the server to complete the process of authenticating the client.
Change cipher spec - The client sends a message telling the server to change to encrypted mode.
Finished - The server tells the client that it is ready for secure data communication to begin. This is the end of the SSL handshake.
Change Cipher Spec. - The server sends a message telling the client to change to encrypted mode.
Finished - The server tells the client that it is ready for secure data communication to begin. This is the end of the SSL handshake.
Encrypted data - The client and the server communicate using the symmetric encryption algorithm and the cryptographic hash function negotiated in Messages 1 and 2, and using the secret key that the client sent to the server in Message 8.
Close Messages - At the end of the connection, each side will send a close_notify message to inform the peer that the connection is closed.

Optional messages:

Certificate (server): needed with all key exchange algorithms, except for anonymous ones.
ServerKeyExchange :needed in some cases, like Diffie-Hellman key exchange algorithm.
CertificateRequest : needed if Client authentication is required.
Certificate (client) : needed in response to CertificateRequest by the server.
CertificateVerify :needed if client Certificate message was sent.

Viewing SSL packets using wireshark

Viewing SSL packets using ssldump

Viewing SSL packets using tshark

1. Handshake Protocol

It allows the peers to authenticate each other and to negotiate a cipher suite and other parameters of the connection. The SSL handshake protocol involves four sets of messages (sometimes called flights) that are exchanged between the client and server. Each set is typically transmitted in a separate TCP segment. The following diagram shows a summary of the process, which has several steps and offers optional ones.

Phase-1: Establishing Securing Capabilities
Phase-2: Server Authentication and Key Exchange
Phase-3: Client Authentication and Key Exchange
Phase-4: Finalizing Handshake Protocol

There are 10 handshake message types in the TLS specification (not counting extensions), so the specific format of each one will be described below.

Handshake Type Values	Decimal Value	Hex Value
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_DONE	14	0x0e
CERTIFICATE_VERIFY	15	0x0f
CLIENT_KEY_EXCHANGE	16	0x10
FINISHED	20	0x14

Phase-1: Establishing Securing Capabilities

Here client and server announce their security capability and choose those that are convenient for both.The SSL messages determine the parameters of the encrypted communication channel that the two parties will use. It is important that the client and server agree on the message details, such as the protocol version, cipher suites, secure renegotiation, or client certificate requests. Otherwise the handshake will fail. The parties agree upon particular compression method.The SSL handshake has the following messaging components:

In the first phase of establishing security capabilities is used to exchange security capabilities and started by client_hello message sent by the client to the server. It contains various parameters:

ClientHello

"client" is a symbolic role; it means "the party which speaks first".When a client first attempts to connect to an SSL server, it initiates the session by sending a ClientHello message to the server. The ClientHello message starts the SSL communication between the two systems. The ClientHello message contains some of the following components:

SSL version: The version field contains the highest protocol version that the client wishes to support.
Client random: A random number generated by the client. Its made up of 32 bytes. 4 byte number made up from client's date & time plus 28 byte randomly generated number(this will be used with server's random value made of date & time for generating the "master secret key", from which encryption key will be derived).
session Id: An arbitrary sequence of bytes chosen by the server; it identifies a particular SSL session. The client may attempt to resume a previously established session by sending a non-zero session ID. 0 mean new session, else client want to update existing session in order to enable client's resuming capabilities this session ID is included.
cipher Suite : Identifies the list of ciphers suites that the client supports. ordered by client preference;
compression Method: Identifies the list of compression methods that the client supports. ordered by client preference;

After the client has sent, its client-hello message, its the job of the server to send back a server-hello message.

ServerHello

If the server is able to find an acceptable set of algorithms, it responds to the ClientHello message with a ServerHello message. The server may use the ServerHello message to allow a resumed session. The ServerHello message contains some of the following components:

SSL version: Server selects an ssl version thats supported by both the server and the client, and is the highest version supported by both of them
server random: the server also generates a random value using the server's date and time plus a random number of 28bytes. Client will use this random value and its own random value to generate the "master secret key"
session Id: Identifies a particular SSL session. If the client requires to resume a previously created session then the client sends a non-zero session ID and the server locates a match in its cache, the server will attempt to respond with the same value as was supplied by the client and resume the session using the same cipher suite, then both the client and server will use the same session ID. But, if the client is initiating a new session, the server will send a new session ID. Sometimes a null session ID is also used, where server will never support resuming the session, so no session id's are used at all.
selected Cipher Suite: Identifies the cipher suite chosen by the server from the list of ciphers that the client supports. The client and the server must support at least one common cipher suite, or else the handshake fails. The server generally chooses the strongest common cipher suite.
selected compression method: selected compression algorithm used in during transfer.
Compression: Identifies the compression method chosen by the server from the list that the client supports.

Note :

ChangeCipherSpec messages don’t belong to this protocol, as they are a protocol by themselves.
Keep in mind that, during the SSL initial handshake, nothing is encrypted. So anybody can sniff, and see whats going on. Encryption, starts only after the master secret (which will be used to encrypt and decrypt data as well as MAC calculation) is send by the client.

Phase-2: Server Authentication and Key Exchange

ServerCertificate

The server sends its Certificate message containing the server's certificate or list of (chain) certificates to authenticate itself, depending on the selected cipher suite.
This message is almost always sent, except if the Cipher Suite mandates a handshake without a certificate.
Server certificate is signed and verified by a Certificate Authority, along with the public key(Content encrypted with public key can only be opened with a corresponding private key. In this case, only the server can unlock it because, the server has the private key for its public key).
A certificate signed by a certificate authority(a trusted third party), consists the complete information about the company using that certificate. The certificate identity of many well known certificate authority is made avialable to the web client. Whenever a certificate is recieved by the web client, it is verified with the one it has from the certificate authority. So this proves that, that the server which claims, that it is "example.com" is infact correct.
If the server requires a digital certificate for client authentication, the server sends a digital certificate request message. In the "digital certificate request" message, the server sends a list of the types of digital certificates supported and the distinguished names of acceptable certificate authorities.

Server Key Exchange

This step is taken by the server, only when there is no public key shared along with the certificate. If this key is used, this will be used to encrypt the "Client Key Exchange Method"
The server sends ServerKeyExchange message is sent after the server certificate message if the server certificate does not contains enough information to allow the client to exchange a premaster secret or after the server hello if anonymous Key-Exchange is in use. This is true of some ciphers such as DHE-DSS.
More specifically it is used for anonymous Diffie-Hellman, Diffie-Hellman Ephemeral and Ephemeral RSA key-exchange methods.
For DHE and ECDHE cipher suites : It contains the server’s half of the key agreement and must be signed with server’s private key. For PSK, just contains the server key name.

Client Certificate Request

The server may require the client to authenticate itself, This is only used, when the client also needs to get authenticated, by a client certificate.
Server request certificate from the client , it has two things: certificates types which contains list of certificate types that client may offer and list of certificate authorities , as list of distinguish name of acceptable certificate authorities.
The server sends a message requesting that the client also identifies itself with a Certificate_list of its own. This message contains the list of names of Trust Anchors (aka Root Certificates) that the server will use to validate the client certificate.
It will be used for two way authentication like internet banking and remote login access over the VPN

Server Hello Done

This message from the server will tell the client, that the server has finished sending its hello message i,e it is done with handshake negotiation, and is waiting for a response from the client.
The server sends a marker message (of length zero) which says that the server is finished, and the client should now talk.

Phase-3: Client Authentication and Key Exchange

Client Certificate:

The client sends a client certificate back to the server. This step is an OPTIONAL and only used when a client certificate is requested by the server(through the server hello message).
Must be compatible with selected key exchange algorithm , not sent when using PSK cipher suites or not requested and on receiving this message, server validates the certificate chain.

Client Key Exchange:

The ClientKeyExchange is sent by the Client immediately after the client certificate if it is sent, otherwise immediately after the server hello done message.
It has two variants, one for when RSA key-exchange is used as the Key-Exchange algorithm, and one for when Diffie-Hellman key-exchange is used.
This message is only sent, after the client calculates, the PreMasterSecret with the help of the random values of both the server and the client(Which was shared by both the server and the client through the hello message).
"Client Key exchange" message, is sent by encrypting it with the server's public key, which was shared through the hello message. This message can only be decrypted with the server's private key. If successful, the server is authenticated.
The client will also send the ssl protocol version once again along with the "client key exchange" method, so that the server can verify, this version with the previous one send, so as to prevent a man in the middle from changing the protocol version.
For RSA cipher suites, contains the pre-master secret encrypted with the server’s public key and for DHE or ECDHE cipher suites, contains the client’s half of the key agreement.
On receipt of this message, both sides now have enough information to generate the master secret and the session keys using the PRF, Pseudo Random Function.

Client Certificate Verify

It must immediately follows client_key_exchange.
This message is used by the client to prove the server that it possesses the private key corresponding to its public key certificate. The message holds hashed information digitally signed by the client. It is required if the server issued a CertificateRequest to the client, so that it had to send a Certificate that needs to be verified. Once again, the exact size and structure of the information depends on the agreed algorithm. In all cases, the information that serves as input to the hash functions is the same.

Phase-4: Finalizing Handshake Protocol

The ChangeCipherSpec message activates the negotiated SSL options for the session. From this point forward, all messages are authenticated and encrypted. This stage is significant as it indicates that subsequent records will be protected under the newly negotiated CipherSpec and keys.
This message is used to tell the other party(Server & Client), that the negotiated secret key and cipher suite will be used for the current communication now onwards.
This message, is sent by both the server and the client, to notify each other, that "Lets start using what we just negotiated".
This message is only of a single byte.
Just after the key exchange & certificate verification, the client sends the server this change cipher spec message. And on receiving the key exchange message, the server also sends back a change cipher spec message.

Note :

If the server supports resuming older SSL session(which is indicated through "session id" in server hello message.), and the client wishes to resume an older session, then the client sends this change cipher spec message, just after the "hello messages".
An important fact to note about change cipher spec message is that, "SSL alert messages are produced, when this ssl cipher spec message is used, other than the normal fashion"

Client Change cipher spec :

The client sends a ChangeCipherSpec message, which is not a handshake message: it has its own record type, so it will be sent in a record of its own.
The client sends a message telling the server to change to encrypted mode.
Its contents are purely symbolic (a single byte of value 1). This message marks the point at which the client switches to the newly negotiated cipher suite and keys. The subsequent records from the client will then be Encrypted.

Client Finish :

First message encrypted with the negotiated cipher suite and session keys. Contains hash of all handshake messages exchanged to this point , Verifies that the authentication and key generation was successful
A TLS-Finished message is always sent immediately after a Change_cipher_spec message to verify that the key exchange and Certificate-based Authentication processes were successful. It is essential that a change cipher spec message be received between the other handshake messages and the TLS-Finished message.
The TLS-Finished message is the first protected with the just negotiated algorithms, keys, and secrets.
Recipients of finished messages must verify that the contents are correct. Once a side has sent its Finished message and received and validated the Finished message from its peer, it may begin to send and receive application data over the connection.

Server Change cipher spec :

The server finally responds with its own change_cipher_spec then Finished. At that point, the handshake is finished, and the client and server may exchange application_data (in encrypted records tagged as such).This message marks the point at which the client switches to the newly negotiated Cipher Suite and Master Secret Key.

Server Finish :

The server tells the client that it is ready for secure data communication to begin. This is the end of the SSL handshake.

2. ChangeCipherSpec Protocol:

It makes the previously negotiated parameters effective, so communication becomes encrypted. The change cipher spec protocol is used to change the encryption being used by the client and server.
It is normally used as part of thehandshake processto switch to symmetric key encryption.
The CCS protocol is a single message that tells the peer that the sender wants to change to a new set of keys, which are then created from information exchanged by the handshake protocol.
This protocol consists of a single message which consists of a single byte .

Message Format :

This additional one byte field in the message is called ccs protocol.
This done at the handshake protocol because for exchanging the key.
The default value is 1.

Note : The client suggests the Cipher Suite but the server chooses. The Cipher Suite decision is in the hands of the server.

3. Application Data Protocol:

It takes arbitrary data (application-layer data generally), and feeds it through the secure channel.
The mission of this protocol is to properly encapsulate the data coming from the Application Layer of the network stack, so it can seamlessly be handled by the underlying protocol (TCP) without forcing changes in any of those layers. The format of the messages in this protocols follows the same structure as the previous ones.

4. Alert Protocol:

The primary use of this protocol is to report the cause of failure. Status changes include such things as error condition like invalid message received or message cannot be decrypted, as well as things like the connection has closed. Used for communicating exceptions and indicate potential problems that may compromise security.

This mechanism, used in SSL to inform the other end, of any irregulartity or failure in authentication, is called as Alert Protocol in SSL.
The primary job of the Alert Protocol in SSL is to inform the other end about the issues(if any), in the current session.
This message consists of two fields as shown below.

1. Alert Message
2. Criticality of the alert
3. Description of the alert

Fatal alert messages will result in a sudden end of the SSL session.
Similar to other protocols in SSL, this alert message is also encrypted, and also sometimes compressed if applicable.

The Alert Protocol is also rather simple. It defines two fields: severity level and alert description. The first field indicates the severity of the alert (1 for warning, 2 for fatal), while the second field encodes the exact condition. The supported alert descriptions depend on the SSL/TLS version.

Message Format :

Level : 1 byte field defines error level. 2 levels of error – warning and fatal.
Description : 1 byte description defines type of error.

Alert severity	dec	hex
WARNING	1	0x01
FATAL	2	0x02

Alert descriptions	dec	hex
CLOSE_NOTIFY	0	0x00
UNEXPECTED_MESSAGE	10	0x0A
BAD_RECORD_MAC	20	0x14
DECRYPTION_FAILED	21	0x15
RECORD_OVERFLOW	22	0x16
DECOMPRESSION_FAILURE	30	0x1E
HANDSHAKE_FAILURE	40	0x28
NO_CERTIFICATE	41	0x29
BAD_CERTIFICATE	42	0x2A
UNSUPPORTED_CERTIFICATE	43	0x2B
CERTIFICATE_REVOKED	44	0x2C
CERTIFICATE_EXPIRED	45	0x2D
CERTIFICATE_UNKNOWN	46	0x2E
ILLEGAL_PARAMETER	47	0x2F
UNKNOWN_CA	48	0x30
ACCESS_DENIED	49	0x31
DECODE_ERROR	50	0x32
DECRYPT_ERROR	51	0x33
EXPORT_RESTRICTION	60	0x3C
PROTOCOL_VERSION	70	0x46
INSUFFICIENT_SECURITY	71	0x47
INTERNAL_ERROR	80	0x50
USER_CANCELLED	90	0x5A
NO_RENEGOTIATION	100	0x64
UNSUPPORTED_EXTENSION	110	0x6E
CERTIFICATE_UNOBTAINABLE	111	0x6F
UNRECOGNIZED_NAME	112	0x70
BAD_CERTIFICATE_STATUS_RESPONSE	113	0x71
BAD_CERTIFICATE_HASH_VALUE	114	0x72

Record Layer Protocol

The Record Protocol first fragments the higher-layer protocol data into blocks of 214 bytes or less; then optionally compresses the data, adds a Message Authentication Code and finally encrypts the data according to the cipher spec (when negotiated), adding an SSL Record header.

SSL-TLS is layered and the bottom layer is the Record Protocol. Whatever data is sent in a SSL-TLS tunnel is split into records. Over the wire (the underlying TCP socket or TCP-like medium), a record looks like this:

Fragmentation of Data: first of all each application layer data is fragmented into different fragment depending on size of data, let say entire data is fragmented into 2 raise to power 14 bytes
Compression: then lossless compression is applied on data this is optional.
MAC: in this step MAC (message authentication code) is calculated with the help of Integrity Key and added with data to maintain message integrity.
Encryption: in this step resulting packet will be encrypted which broked down with fixed length by using symmetric key encryption with was provided parameters.
Addition of SSL record protocol: in this last step, SSL record protocol header will be added to the packet with data packet fixed length which consists the following headers, which combinely form a 5 byte header.

a). 1 Byte Protocol Definition
b). 2 Byte Protocol version
c). 2 Byte Length

And finally, packet is sent to the below Transport Layer.

Message Integrity

MAC information is very much necessary in this layer, as it checks the integrity of the record. This is nothing but, a hash value calculated with the help of the following things.

MAC value is the Hash value calculated from [sequence number, padding, primary data, secret key].

Secret Key used in Hash function

SSL connections are always initiated by the client to the server. So most of the times, server has to select one cryptographic algorithm from the client supported list(Which is given by the client).
Most of the negotiation part in SSL is carried out by the client.
After the initial verification of the server(With the help of a certificate, provided by a Certificate Authority ), by the client, the client sends a "Client Key Exchange Message". This message (Client Key Exchange Message) is encrypted with the public key, provided by the server(So that only server can unlock it).
Client Key Exchange Message is a message sent by the client to the server, containing the "Premaster Secret", which is a random number of 46 bytes.
"Premaster Secret", is used to create symmetric encryption keys(which are used to encrypt data), and secret key for MAC hash function(For message integrity check on both the server and client side).
SSL makes use of both Symmetric and Asymmetric Encryption. Asymmetric Encryption is only used for sending "Client Key Exchange Message" Because, client key Exchange message, is the Supper Secret in SSL(Because the symmetric key for data encryption and secret key for MAC,both are derived from "Client Key Exchange Message").
Although a MAC value for integrity check is now placed on our record, our data is still unencrypted. So now the whole data along with the MAC is encrypted with a symmetric Key(which was also shared to the server using "Client Key Exchange Message")
Now this whole encrypted data along with the following header's form a complete record, ready for transmission over TCP.

a). 1 Byte Protocol Definition
b). 2 Byte Protocol version
c). 2 Byte Length

On receiving a record, which is completely(the fragmented data package, at record layer with all its headers), the the other node can calculate the MAC hash value(because, the secret key for MAC was shared, by the client with "Client Key Exchange Method" ), and then compare it with the MAC attached on the header. Also the server can decrypt the data with the symmetric key ( which was also shared with "Client Key Exchange Method" ).

Note :

The object created by the record layer, by fragmenting the data from application layer, and adding appropriate headers, is called as a record.
Record Layer in SSL is the layer, which provides the facilities like confidentiality through encryption and integrity check using MAC.

Record Protocol Format :

The TLS Record header comprises three fields, necessary to allow the higher layer to be built upon it:

Byte 0: TLS record type , this 1 byte field the source or destination of the encapsulated message.Itis used for multiplexing and demultiplexing.The value are 20 for ccs protocol,21 for alert protocol,22for handshake protocol,23 for data from application layer
Bytes 1-2: TLS version (major/minor), this 2 byte field defines the version of SSL ,one byte for major version and another other is for minor
Bytes 3-4: Length of data in the record (excluding the header itself). The maximum supported is 16384 (16K).

Record Type Values	dec	hex
CHANGE_CIPHER_SPEC	20	0x14
ALERT	21	0x15
HANDSHAKE	22	0x16
APPLICATION_DATA	23	0x17

Version Values	dec	hex
SSL 3.0	3,0	0x0300
TLS 1.0	3,1	0x0301
TLS 1.1	3,2	0x0302
TLS 1.2	3,3	0x0303

Cryptographic Parameter Generation :

To achieve message integrity and confidentiality, SSL needs 6 cryptographic secrets, 4 keys and 2 IVs.
Client and Server each needs one key for message authentication, one key for encryption and one IV for block encryption.
SSL requires both direction side keys to be different so if there is an attack in one direction, the other direction is not affected.
The client and server exchange two random numbers; one is created by the client and other by the server.
The client and server exchange one pre-master secret using one of the key-exchange algorithms.
A 48-byte master secret is created from the pre-master secret by applying two hash functions(SHA-I and MD5).
The master secret is used to create variable-length key material by applying the same set of hash functions and prepending with different constants.
6 different keys are extracted from the key material. Client-Server Authkey, Client-Server EncKey, Client-Server IV.

Master Secret Key Generation:

TLS Resumed Sessions

The handshake is a protocol which is played within the record protocol. Its goal is to establish the algorithms and keys which are to be used for the records. There two types of TLS Handshakes:

TLS Full Handshake
TLS Abbreviated Handshake / Resumed Sessions

TLS Full Handshake

Initially, client and server "agree upon" the Cipher Suite "TLS_NULL_WITH_NULL_NULL (0x000) Encryption with no MAC and null compression. This means that the record they will first send will be sent as cleartext and unprotected.

TLS Abbreviated Handshake / Resumed Sessions

TLS Session Resumption is one of the most important mechanism to improve TLS Handshake performance: by submitting an appropriate blob to the server, a client is able to trigger an abbreviated handshake, improving latency and computation time.
A resumed SSL session implements session identifier (session ID) to re-establish a previously negotiated session. When an SSL handshake is resumed, the client presents the session ID from the previously negotiated session. If the server finds the session ID in its cache and accepts the resumed session, it sends back the same session ID and the parties skip the public key operation. If the server does not accept the resumed session, it issues a new session ID and implements the full SSL handshake. The resumed SSL handshake between a client and server consists of the following steps.

Cipher suite

A cipher suite is a set of algorithms that help secure a network connection that uses Transport Layer Security (TLS) or its now-deprecated predecessor Secure Socket Layer (SSL).
The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm.

Protocol_keyexchange_keyauthentication_WITH_bulkencryption_effectivebits_ciphermode_messageauth

Why cipher suites are important

The security level of your HTTPS traffic (the safety of your data and the data of your users) depends on which cipher suites your web server uses.
The compatibility of your HTTPS traffic (who will see errors, warnings or experience other issues) depends on the cipher suites your web server uses.
The performance of your HTTPS traffic (how fast users see your pages – page speed) depends on the cipher suites your web server uses.

Basic elements of a cipher suite

A cipher suite is basically a complete set of methods (technically known as algorithms) needed to secure a network connection through SSL (Secure Sockets Layer) / TLS (Transport Layer Security).
The name of each set is representative of the specific algorithms comprising it.
One cipher suite typically consists of one (1) key exchange, 1 authentication, 1 bulk encryption, and 1 MAC algorithm.

The algorithms that make up a typical cipher suite are the following:

Key exchange algorithm

The key exchange algorithm is used to exchange a key (symmetric) between two devices.
This key (symmetric) is used to encrypt and decrypt the messages being sent between two machines.
These algorithms are asymmetric (public key algorithms) and perform well for relatively small amounts of data.
This key exchange protocol ensure for the secure exchange of symmetric keys over insecure networks.
Example : RSA, DH, ECDH and ECDHE

Authentication algorithm

To ensure the correct and secure transfer of data, a web server needs to verify the identity of the user who is receiving the data.
Usually, this process involves the user inputting a set of credentials including a username and password.
Example : RSA, DSA, ECDSA

Bulk encryption algorithm

This algorithm encrypts messages exchanged between clients and servers.
These algorithms are symmetric and perform well for large amounts of data.
Example : AES, 3DES, CAMELLIA

Message Authentication Code (MAC) algorithm

This algorithms generate message hashes and signatures that ensure the integrity of a message.
Example : SHA, MD5

Example 1 : DHE_RSA_AES256_SHA256.

DHE for its key exchange algorithm
RSA as its authentication algorithm
AES256 for its bulk data encryption algorithm
SHA256 for its Message Authentication Code (MAC) algorithm.

Example 2 : TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS: transport layer security
ECDHE: The key exchange algoritm is ECDHE (Elliptic curve Diffie–Hellman, ephemeral).
ECDSA: The authentication algorithm is ECDSA (Elliptic Curve Digital Signature Algorithm). The certificate authority uses an ECDH key to sign the public key. This is what for example Bitcoin uses.
WITH_AES_256_CBC: This is used to encrypt the message stream. (AES=Advanced Encryption Standard, CBC=Cipher Block Chaining). The number 256 indicates the block size.
SHA_384: This is the so-called message authentication code (MAC) algorithm. SHA = Secure Hash Algorithm. It is used to create a message digest or hash of a block of the message stream. This can be used to validate if message contents have been altered. The number indicates the size of the hash. Larger is more secure.

Example 3: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS: simply indicates the protocol;
ECDHE: signifies the key exchange algorithm;
ECDSA: signifies the authentication algorithm;
AES_256_CBC: indicates the bulk encryption algorithm; and
SHA384: indicates the MAC algorithm.

* If the key exchange algorithm or the authentication algorithm is not explicitly specified, RSA is assumed.

Popular SSL Libraries :

openssl
LibreSSL
BoringSSL
schannel(microsoft)secure transport (apple)
GnuTLS
s2n (amazon)

Let's go in depth

Wednesday, April 3, 2019

Inspecting TLS/SSL