In this presentation we will learn about the Record Protocol, Alert Protocol, Closing and Resuming SSL Connections and Attacks on SSL. The Part - 1 cab be founded at : https://www.slideshare.net/vishalkumar245/fundamental-of-secure-socket-layer-ssl-part-1

1. “The Fundamental of Secure
Socket Layer (SSL)”
By:
-Vishal Kumar
(CEH, CHFI, CISE, MCP)
info@prohackers.in
Part - 2

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

3. 2. The Record Protocol
The Record Protocol in the SSL comes into picture after a
successful handshake is completed between the client and the
server. That is, after the client and the server have optionally
authenticated each other and have decided what algorithms to
use for secure information exchange, we enter into the SSL
record protocol. This protocol provides two services to an SSL
connection, 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

4. 2. The Record Protocol
The operation of the record protocol is mentioned in below
figure:
Fig: SSL record protocol

5. 2. The Record Protocol
As the figure shown, the SSL record protocol takes an application
message as input. First, it fragments it into smaller blocks,
optionally compress each block, ass MAC, encrypt it, add its
header and gives it to the transport layer, where the TCP protocol
processes it like any other TCP block. At the receiver’s end, the
header of each block is removed; the block is then decrypted,
verified, decompressed, and reassembled into application
messages. Let us discuss these steps in more details:
• (a) Fragmentation The original application messages is broken
into blocks, so that the size of each block is less than or equal
to 214 bytes (16,384 bytes).

6. 2. The Record Protocol
• (b) Compression The fragmented blocks are optionally
compressed. The compression process must not result into the
loss of the original data, which means that this must be lossless
compression mechanism.
• (c) Addition of MAC Using the shares secret key established
previously in the handshake protocol, the Message
Authentication Code (MAC) for each block is calculated. This
operation is similar to the HMAC algorithm.
• (d) Encryption Using the symmetric key establish previously in
the handshake protocol, the output of the previous step is now
encrypted. This encryption may not increase the overall size of
the block by more than 1024 bytes.

7. 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

8. 2. The Record Protocol
(e) Appended Header Finally, a header is added to the encrypted
block. The header contains the following fields:
Content type (8 bits) – Specifies the protocol used for processing
the records in the next higher level (e.g. handshake, alert, change,
cipher)
• Major version (8 bits) – Specifies the Major version of the SSL protocol in
user. 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 original
plain-text-book (or the compressed block, if compression is used)

9. 2. The Record Protocol
The final SSL message now looks as shown in below figure:

10. 3. The Alert Protocol
When either the client or the server detects an error, the
detecting party sends an alert message to the other party. If the
error is fatal, both the parties immediately close the SSL
connection (which means that the transmission from both the
ends is terminated immediately). Both the parties also destroy
the session identifiers, secrets and key associated with the
connection before it is terminated. Other errors, which are not so
sever, do not result in the termination of the connection. Instead,
the parties handle the error and continue.

11. 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,

12. 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.

13. Closing and Resuming SSL Connections
Before ending their communication, the client and the server
must inform each other that their side of the connection is
ending. As we have noted, each party sends a Close notify
alert to other party. This ensures a graceful closure of the
connection. When a party receives this alert, it must
immediately stop whatever it is doing, sends its own Close
notify alert and end the connection from its side as well. If an
SSL connection ends without a Close notify from either party,
it cannot me resumed.

14. Closing and Resuming SSL Connections
The handshake protocol in SSL is quite complex and time
consuming, as it uses asymmetric-key cryptography. Therefore,
if desired, a client and a server can decide to reuse or resume
an earlier SSL connection, rather than creating a fresh one
with a new handshake. However for this to be possible, both
the parties must agree on the reuse. If either party feels that
it is dangerous to reuse the earlier connection, of if the other
party’s certificate has expired since that last connection it can
forced the other party to perform a fresh handshake. As per
the SSL specifications, any SSL connection should not be reused
after 24 hours in any case.

15. Buffer Overflow Attack on SSL
A buffer overflow attack occurs when a program or process tries
to store more data in a buffer (a temporary data storage area)
than what it was designed to hold. Because buffer are created to
contains a fixed amount of data, the extra information – which
has to go somewhere – can overflow into adjacent buffers,
corrupting of overwriting the valid data held in them. Although
this may happen accidentally through programming errors, buffer
overflow is an increasingly common type of security attack on
data integrity. In buffer overflow attacks, the extra data may
contain codes design to cause specific action, thus sending new
instructions to the attacked computer. This could damage the
user’s files, change data, or compromise confidential
information.

16. Buffer Overflow Attack on SSL
OpenSSL is an open-source implementation of the Secure Socket
Layer (SSL) protocol. OpenSSL is subject to four remotely
executable buffer overflows. The buffer overflow vulnerabilities
can 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-service
attack. These four vulnerabilities are listed below:
Three of four buffer-overflow vulnerabilities occur in SSL
handshakes. The last one deals with 64-bit operating system.

17. Buffer Overflow Attack on SSL
1. The first vulnerability is found in the key exchange
implemented in SSL version 2. A client can be used to send an
oversize 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 SSL
version 3 handshake. A malicious server can execute code on an
OpenSSL client by sending a malformed session ID during the first
phase of the handshake.

18. Buffer Overflow Attack on SSL
3. The third buffer overflow exists in OpenSSL server running SSL
version 3 with Kerberos authentication enabled. A malicious
client can send an oversized master key to a Kerberos-enabled
SSL server.
4. The fourth set of overflows exists only on 64-bit operating
systems. Several buffer used to store ASCII representation of
integers are smaller then required.

19. 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