“The Fundamental of Secure Socket Layer (SSL)”

By:

-Vishal Kumar

(CEH, CHFI, CISE, MCP)

info@prohackers.in

Part - 2

Topics to be Covered in this Presentation

1. The Record protocol

2. The Alert protocol

3. Closing and Resuming SSL Connections

4. Buffer Overflow Attack on SSL

Part 1 o this presentation can be found at: https://www.slideshare.net/vishalkumar245/fundamental-of-secure-socket-layer-ssl-part-1

2. The Record Protocol

The Record Protocol in the SSL comes into picture after asuccessful handshake is completed between the client and theserver. That is, after the client and the server have optionallyauthenticated each other and have decided what algorithms touse for secure information exchange, we enter into the SSLrecord protocol. This protocol provides two services to an SSLconnection, as follows.

1. Confidentiality – this is achieved by the using the secret key that is define by the handshake protocol.

2. Integrity - The handshake protocol also define hared secret key (MAC) that is used for assuring the message integrity

2. The Record Protocol

The operation of the record protocol is mentioned in belowfigure:

Fig: SSL record protocol

2. The Record Protocol

As the figure shown, the SSL record protocol takes an applicationmessage as input. First, it fragments it into smaller blocks,optionally compress each block, ass MAC, encrypt it, add itsheader and gives it to the transport layer, where the TCP protocolprocesses it like any other TCP block. At the receiver’s end, theheader of each block is removed; the block is then decrypted,verified, decompressed, and reassembled into applicationmessages. Let us discuss these steps in more details:

• (a) Fragmentation The original application messages is brokeninto blocks, so that the size of each block is less than or equalto 214 bytes (16,384 bytes).

2. The Record Protocol

• (b) Compression The fragmented blocks are optionallycompressed. The compression process must not result into theloss of the original data, which means that this must be losslesscompression mechanism.

• (c) Addition of MAC Using the shares secret key establishedpreviously in the handshake protocol, the MessageAuthentication Code (MAC) for each block is calculated. Thisoperation is similar to the HMAC algorithm.

• (d) Encryption Using the symmetric key establish previously inthe handshake protocol, the output of the previous step is nowencrypted. This encryption may not increase the overall size ofthe block by more than 1024 bytes.

2. The Record Protocol

Stream cipher Block cipher

Algorithms Key Size Algorithms Key Size

RC4 40 AES 128,256

RC4 128 IDEA 128

RC2 40

DES 40

DES 56

DES-3 168

Fortezza 80

2. The Record Protocol

(e) Appended Header Finally, a header is added to the encryptedblock. The header contains the following fields:

Content type (8 bits) – Specifies the protocol used for processingthe records in the next higher level (e.g. handshake, alert, change,

cipher)

• Major version (8 bits) – Specifies the Major version of the SSL protocol inuser. For instance, if SSL version 3.1 is in use, this field contains 3.

• Minor version (8 bits) – Specifies the minor version of SSL protocol in use.For instance, if SSL version 3.1 is in use, this field contains 1.

• Compressed length (16 bits) – Specifies the length in bytes of the originalplain-text-book (or the compressed block, if compression is used)

2. The Record Protocol

The final SSL message now looks as shown in below figure:

3. The Alert Protocol

When either the client or the server detects an error, thedetecting party sends an alert message to the other party. If theerror is fatal, both the parties immediately close the SSLconnection (which means that the transmission from both theends is terminated immediately). Both the parties also destroythe session identifiers, secrets and key associated with theconnection before it is terminated. Other errors, which are not sosever, do not result in the termination of the connection. Instead,the parties handle the error and continue.

3. The Alert Protocol

Below is the list of fatal alerts (errors):

Alert Description

Unexpected message An in-appropriate message was received.

Bad record MAC A message is received without a correct MAC.

Decompression failure The decompression function received an improper input.

Handshake failure Sender was unable to negotiate an acceptable set of security parameters from the

available options.

Illegal parameters A field in the handshake message was out of range or was inconsistent with the other

fields,

3. The Alert Protocol

List of non-fatal alerts (errors)

Alerts Description

No certificate Sent in response to certificate request if an appropriate certificate is not

available

Bad certificate A certificate was corrupt (its digital signature verification failed)

Unsupported certificate The type of the received certificate is not supported.

Certificate revoked The signer of the certificate has revoked it.

Certificate expired A received certificate has expired.

Certificate unknown An unspecified error occurred while processing the certificate.

Close notify Notifies that the sender will not send any more messages in this connection. Each

party must send this message before closing its side the connection.

Closing and Resuming SSL Connections

Before ending their communication, the client and the servermust inform each other that their side of the connection isending. As we have noted, each party sends a Close notifyalert to other party. This ensures a graceful closure of theconnection. When a party receives this alert, it mustimmediately stop whatever it is doing, sends its own Closenotify alert and end the connection from its side as well. If anSSL connection ends without a Close notify from either party,it cannot me resumed.

Closing and Resuming SSL Connections

The handshake protocol in SSL is quite complex and timeconsuming, as it uses asymmetric-key cryptography. Therefore,if desired, a client and a server can decide to reuse or resumean earlier SSL connection, rather than creating a fresh onewith a new handshake. However for this to be possible, boththe parties must agree on the reuse. If either party feels thatit is dangerous to reuse the earlier connection, of if the otherparty’s certificate has expired since that last connection it canforced the other party to perform a fresh handshake. As perthe SSL specifications, any SSL connection should not be reusedafter 24 hours in any case.

Buffer Overflow Attack on SSL

A buffer overflow attack occurs when a program or process triesto store more data in a buffer (a temporary data storage area)than what it was designed to hold. Because buffer are created tocontains a fixed amount of data, the extra information – whichhas to go somewhere – can overflow into adjacent buffers,corrupting of overwriting the valid data held in them. Althoughthis may happen accidentally through programming errors, bufferoverflow is an increasingly common type of security attack ondata integrity. In buffer overflow attacks, the extra data maycontain codes design to cause specific action, thus sending newinstructions to the attacked computer. This could damage theuser’s files, change data, or compromise confidentialinformation.

Buffer Overflow Attack on SSL

OpenSSL is an open-source implementation of the Secure SocketLayer (SSL) protocol. OpenSSL is subject to four remotelyexecutable buffer overflows. The buffer overflow vulnerabilitiescan allow an attacker to execute arbitrary code on the target(victim) computer with the privilege level of the OpenSSL process,as well as providing opportunities for launching a denial-of-serviceattack. These four vulnerabilities are listed below:

Three of four buffer-overflow vulnerabilities occur in SSLhandshakes. The last one deals with 64-bit operating system.

Buffer Overflow Attack on SSL

1. The first vulnerability is found in the key exchangeimplemented in SSL version 2. A client can be used to send anoversize master key to an SSL version 2 servers, enabling denial-of-service or malicious code execution on the server.

2. The second buffer overflow exist is contained in the SSLversion 3 handshake. A malicious server can execute code on anOpenSSL client by sending a malformed session ID during the firstphase of the handshake.

Buffer Overflow Attack on SSL

3. The third buffer overflow exists in OpenSSL server running SSLversion 3 with Kerberos authentication enabled. A maliciousclient can send an oversized master key to a Kerberos-enabledSSL server.

4. The fourth set of overflows exists only on 64-bit operatingsystems. Several buffer used to store ASCII representation ofintegers are smaller then required.

Feedback

Thanks for reading this presentation

Please give us your feedback at

info@prohackers.in

Your feedback is most valuable for us for improving the presentation

You can also suggest the topic on which you want the presentation

Website: www.prohackers.in

FB page: www.facebook.com/theprohackers2017

Join FB Group: www.facebook.com/groups/group.prohackers/

Watch us on: www.youtube.com//channel/UCcyYSi1sh1SmyMlGfB-Vq6A