Electronic mail (E-MAIL)

E-mail Architecture:

Figure 16.1 shows the most common scenario in a one-way e-mail exchange.

 An organization runs an e-mail server and every employee is connected to the e-mail server
through a LAN. Or alternatively.
 The administrator of the e-mail server at the sender site has created a queuing system that
sends e-mail to the Internet one by one.
 The administrator of the e-mail server at receiver site has created a mailbox for every user
connected to the server; the mailbox holds the received messages until they are retrieved by
the recipient.
 When sender needs to send a message to receiver, he invokes a user agent (UA) program to
prepare the message.
 He then uses another program, a message transfer agent (MTA), to send the message to the
mail server at his site.
 Note that the MTA is a client/server program with the client installed at sender’s computer
and the server installed at the mail server.
 The message received at the mail server at sender’s site is queued with all other messages.
 A client/server MTA is responsible for the e-mail transfer between the two servers.
 When the message arrives at the destination mail server, it is stored in receiver’s mailbox, a
special file that holds the message until it is retrieved by receiver.

There are several important points about the architecture of the e-mail system.

 The sending of an e-mail from Alice to Bob is a store-retrieve activity.

  The main communication between Alice and Bob is through two application programs: the
MTA client at Alice’s computer and the MAA client at Bob’s computer.
 The MTA client program is a push program; the client pushes the message
 The MAA client program is a pull program; the client pulls the messages

E-mail Security:

 Sending an e-mail is a one-time activity.

 In e-mail, there is no session

The security of a unidirectional message:

Cryptographic Algorithms:

If e-mail is a one-time activity,

 Select one algorithm for each cryptographic operation and to force Alice to use only those
algorithms.
 Define a set of algorithms for each operation that the user used in his/her system

Cryptographic Secrets:

In e-mail security, the encryption/decryption is done using a symmetric-key algorithm, but the secret
key to decrypt the message is encrypted with the public key of the receiver and is sent with the
message

Certificates:

Each e-mail security protocol has a different method of certifying keys.

Pretty Good Privacy (PGP)

 PGP was invented by Phil Zimmermann.
 PGP is a first protocolto provide e-mail with privacy, integrity, and authentication.

Operational description:

1. Plaintext
2. Message integrity
3. Compression
4. Confidentiality with One-Time Session Key:
5. Code Conversion:
6. Segmentation:

Plaintext:

The simplest scenario is to send the e-mail message (or store the file) in plaintext as shown in Figure
16.2. There is no message integrity or confidentiality in this scenario. Alice, the sender, composes a
message and sends it to Bob, the receiver. The message is stored in Bob’s mailbox until it is retrieved
by him.
Message Integrity:
Alice sign the message.

Alice creates a digest of the message and signs it with her private key. When Bob receives the
message, he verifies the message by using Alice’s public key.

Compression:

Compress the message to make the packet more compact.

Confidentiality with One-Time Session Key:

Confidentiality in an e-mail system can be achieved using conventional encryption with a one-time
session key.

Alice can create a session key, use the session key to encrypt the message and the digest, and send
the key itself with the message.
However, to protect the session key, Alice encrypts it with Bob’s public key. Figure 16.5 shows the
situation.

When Bob receives the packet, he first decrypts the key, using his private key to remove the key.

He then uses the session key to decrypt the rest of the message.

After decompressing the rest of the message, Bob creates a digest of the message and checks to see
if it is equal to the digest sent by Alice. If it is, then the message is authentic.

Code Conversion:

Another service provided by PGP is code conversion.

PGP uses Radix-64 conversion. Each character to be sent (after encryption) is converted to Radix-64
code,

Segmentation:

PGP allows segmentation of the message after it has been converted to Radix-64 to make each
transmitted unit the uniform size as allowed by the underlying e-mail protocol.

Key Rings:

The PGP designers specified a ring of private/public keys.

One reason is that Alice may wish to change her pair of keys from time to time.

Another reason is that Alice may need to correspond with different groups of people (friends,
colleagues, and so on).

Alice may wish to use a different key pair for each group.
Therefore, each user needs to have two sets of rings: a ring of private/public keys and a ring of
public keys of other people.

1. Alice needs to send a message to another person in the community.

 She uses her private key to sign the digest.

 She uses the receiver’s public key to encrypt a newly created session key.
 She encrypts the message and signed digest with the session key created.

2. Alice receives a message from another person in the community.

 She uses her private key to decrypt the session key.

 She uses the session key to decrypt the message and digest.
 She uses her public key to verify the digest.

PGP Algorithms:

The following algorithms are used in PGP.

Public-Key Algorithms The public-key algorithms that are used for signing the digests or encrypting
the messages are listed in Table 16.1.
Symmetric-Key Algorithms The symmetric-key algorithms that are used for conventional encrypting
are shown in Table 16.2.

Hash Algorithms:

The hash algorithms that are used for creating hashes in PGP are shown in Table 16.3.
Compression Algorithms:

The compression algorithms that are used for compressing text are shown in Table 16.4.

S/MIME
Secure/Multipurpose Internet Mail Extension (S/MIME) is a security service designed for electronic
mail is. The protocol is an enhancement of the Multipurpose Internet Mail Extension (MIME)
protocol.

MIME:
Electronic mailcan send messages only in NVT 7-bit ASCII format.

Multipurpose Internet Mail Extensions (MIME) is a supplementary protocol that allows non-ASCII
data to be sent through e-mail.

MIME transforms non-ASCII data at the sender site to NVT ASCII data and delivers it to the client
MTA to be sent through the Internet. The message at the receiving side is transformed back to the
original data.
MIME defines five headers that can be added to the original e-mail header section.

1. MIME-Version
2. Content-Type
3. Content-Transfer-Encoding
4. Content-Id
5. Content-Description

MIME-Version

This header defines the version of MIME used. The current version is 1.1.

Content-Type

This header defines the type of data used in the body of the message. The content type and the
content subtype are separated by a slash.

MIME allows seven different types of data.

 Text
 Multipart
  Message.
 Image
 Video
 Audio
 Application.

Content-Transfer-Encoding

This header defines the method used to encode the messages into 0s and 1s for transport

The five types of encoding methods

Content-Id:

This header uniquely identifies the whole message in a multiple message environment.

Content-Description

This header defines whether the body is image, audio, or video

S/MIME
S/MIME adds some new content types to include security services to the MIME.

. All of these new types include the parameter “application/pkcs7-mime,” in which “pkcs” defines
“Public Key Cryptography Specification.”

Cryptographic Message Syntax (CMS):

Security services, such as confidentiality or integrity, can be added to MIME content types, S/MIME
has defined Cryptographic Message Syntax (CMS).

The following describe the type of message and different subtypes that are created from these
messages.

Data Content Type:

This is an arbitrary string. The object created is called Data.

Signed-Data Content Type:

This type provides only integrity of data.

It contains any type and zero or more signature values. The encoded result is an object called
signedData.

The following are the steps in the process:

 For each signer, a message digest is created from the content using the specific hash
algorithm chosen by that signer.
 Each message digest is signed with the private key of the signer.
 The content, signature values, certificates, and algorithms are then collected to create the
signedData object.

Enveloped-Data Content Type:

This type is used to provide privacy for the message.

It contains any type and zero or more encrypted keys and certificates.

The encoded result is an object called envelopedData

The following show the process of creating an object of this type.

 A pseudorandom session key is created for the symmetric-key algorithms to be used.

  For each recipient, a copy of the session key is encrypted with the public key of each
recipient.
 The content is encrypted using the defined algorithm and created session key.
 The encrypted contents, encrypted session keys, algorithm used, and certificates are
encoded using Radix-64.

Digested-Data Content Type:

This type is used to provide integrity for the message.

The result is normally used as the content for the enveloped-data content type. The encoded result
is an object called digestedData.
1. A message digest is calculated from the content.

2. The message digest, the algorithm, and the content are added together to create the
digestedData object

Encrypted-Data Content Type:

This type is used to create an encrypted version of any content type.

It can be used to store the encrypted data

The process is very simple, the user employs any key (normally driven from the password) and any
algorithm to encrypt the content. The encrypted content is stored without including the key or the
algorithm. The object created is called encryptedData.

Authenticated-Data Content Type

This type is used to provide authentication of the data. The object is called authenticatedData

 Using a pseudorandom generator, a MAC key is generated for each recipient.

 The MAC key is encrypted with the public key of the recipient.
 A MAC is created for the content.
 The content, MAC, algorithms, and other informations are collected together to form the
authenticatedData object.
Key Management

 The key management in S/MIME is a combination of key management used by X.509 and
PGP.
 S/MIME uses public-key certificates signed by the certificate authorities defined by X.509.
 The user is responsible to maintain the web of trust to verify signatures as defined by PGP.

Cryptographic Algorithms

S/MIME defines several cryptographic algorithms as shown in Table 16.17

IP Security (IPSec):

IP Security (IPSec) is a collection of protocols designed by the Internet Engineering Task Force (IETF)
to provide security for a packet at the network level.

IPSec helps create authenticated and confidential packets for the IP layer.
TWO MODES:

IPSec operates in one of two different modes:

 Transport mode
 Tunnel mode.
Transport Mode:

In transport mode, IPSec protects what is delivered from the transport layer to the network layer.

Transport mode protects the network layer payload.

IPSec in transport mode does not protect the IP header; it only protects the information coming
from the transport layer.

Transport mode is normally used when we need host-to-host (end-to-end) protection of data. The
sending host uses IPSec to authenticate and/or encrypt the payload delivered from the transport
layer. The receiving host uses IPSec to check the authentication and/or decrypt the IP packet and
deliver it to the transport layer.

Tunnel Mode:

In tunnel mode, IPSec protects the entire IP packet. It takes an IP packet, including the header,
applies IPSec security methods to the entire packet, and then adds a new IP header,
IPSec in tunnel mode protects the original IP header.

Tunnel mode is normally used between two routers, between a host and a router, or between a
router and a host

Comparison:

In transport mode, the IPSec layer comes between the transport layer and the network layer. In
tunnel mode, the flow is from the network layer to the IPSec layer and then back to the network
layer again.
TWO SECURITY PROTOCOLS:

IPSec defines two protocols: To provide authentication and/or encryption for packets at the IP level.

 Authentication Header (AH) Protocol

 Encapsulating Security Payload (ESP) Protocol

Authentication Header (AH):

The Authentication Header (AH) Protocol is designed to authenticate the source host and to ensure
the integrity of the payload carried in the IP packet.

The protocol uses a hash function and a symmetric key to create a message digest; the digest is
inserted in the authentication header.

Figure 18.7 shows the fields and the position of the authentication header in transport mode.

A brief description of each field follows:

Next header:

The 8-bit next header field defines the type of payload carried by the IP datagram (such as TCP, UDP,
ICMP, or OSPF).

Payload length:

It defines the length of the authentication header in 4-byte multiples.

Security parameter index:

The 32-bit security parameter index (SPI) field plays the role of a virtual circuit identifier.
Sequence number:

A 32-bit sequence number provides ordering information for a sequence of datagram’s.

Authentication data:

The authentication data field is the result of applying a hash function to the entire IP datagram
except for the fields that are changed during transit.

Encapsulating Security Payload (ESP):

 Encapsulating Security Payload (ESP), that provides source authentication, integrity, and
privacy.
 ESP adds a header and trailer.

The ESP procedure follows these steps:

1. An ESP trailer is added to the payload.

2. The payload and the trailer are encrypted.
3. The ESP header is added.
4. The ESP header, payload, and ESP trailer are used to create the authentication data.
5. The authentication data are added to the end of the ESP trailer.
6. The IP header is added after changing the protocol value to 50

The fields for the header and trailer are as follows:

Security parameter index:

The 32-bit security parameter index field is similar to that defined for the AH protocol.

Sequence number:

The 32-bit sequence number field is similar to that defined for the AH protocol.

Padding:

This variable-length field (0 to 255 bytes) of 0s serves as padding.

Pad length:

The 8-bit pad-length field defines the number of padding bytes. The value is between 0 and 255;

Next header:

The 8-bit next-header field is similar to that defined in the AH protocol.

Authentication data:

The authentication data field is the result of applying an authentication scheme to parts of the
datagram.

Services Provided by IPSec:

The two protocols, AH and ESP, can provide several security services for packets at the network
layer.

Access Control:

IPSec provides access control indirectly using a Security Association Database (SAD).

Message Integrity:

Message integrity is preserved in both AH and ESP. A digest of data is created and sent by the sender
to be checked by the receiver.

Entity Authentication:

The Security Association and the keyed-hash digest of the data sent by the sender authenticate the
sender of the data in both AH and ESP.

Confidentiality:

The encryption of the message in ESP provides confidentiality. AH, however, does not provide
confidentiality

Replay Attack Protection:

 The replay attack is prevented by using sequence numbers and a sliding receiver window.
  Each IPSec header contains a unique sequence number when the Security Association is
established. The number starts from 0 and increases until the value reaches 2 32 – 1.
 When the sequence number reaches the maximum, it is reset to 0 and, at the same time,
the old Security Association (see the next section) is deleted and a new one is established.
 To prevent processing duplicate packets, IPSec mandates the use of a fixed-size window at
the receiver.

SECURITY ASSOCIATION

 Security Association is a very important aspect of IPSec.

 IPSec requires a logical relationship, called a Security Association (SA), between two hosts

Idea of Security Association:

 A Security Association is a contract between two parties; it creates a secure channel

between them.
 Let us assume that Alice needs to unidirectionally communicate with Bob.
 If Alice and Bob are interested only in the confidentiality aspect of security, they can get a
shared secret key between themselves.
 We can say that there are two Security Associations (SAs) between Alice and Bob;
o One outbound SA
o One inbound SA.
 Each of them stores the value of the key in a variable and the name of the encryption/
decryption algorithm in another.
 Alice uses the algorithm and the key to encrypt a message to Bob; Bob uses the algorithm
and the key when he needs to decrypt the message received from Alice
Security Association Database (SAD):

A set of SAs can be collected into a database. This database is called the Security Association
Database (SAD).

The database can be thought of as a two-dimensional table with each row defining a single SA.

There are two SADs,

 One inbound
 One outbound

Each entry in an inbound SAD is selected using a triple index:

1. Security parameter index,

2. Destination address,
3. Protocol.

Security Parameter Index:

The security parameter index (SPI) is a 32-bit number that defines the SA at the destination.

Destination Address:

The second index is the destination address of the host.

Protocol:

IPSec has two different security protocols: AH and ESP. To separate the parameters and information
used for each protocol.

The entries for each row are called the SA parameters. Typical parameters are shown in Table 18.2.

SECURITY POLICY:

The Security Policy (SP) defines the type of security applied to a packet when it is to be sent or when
it has arrived.

Security Policy Database:

Each host needs a Security Policy Database (SPD).

They need an inbound SPD and an outbound SPD.

Each entry in the SPD can be accessed using a sextuple index:

  Source address,
 Destination address,
 Name,
 Protocol,
 Source port,
 Destination port,

Outbound SPD:

When a packet is to be sent out, the outbound SPD is consulted

The input to the outbound SPD is the sextuple index; the output is one of the three following cases:

Drop:

This means that the packet defined by the index cannot be sent; it is dropped.

Bypass:

This means that there is no policy for the packet with this policy index; the packet is sent, bypassing
the security header application.

Apply:

The security header is applied. Two situations may occur:

 If an outbound SA is already established, the triple SA index is returned that selects the
corresponding SA from the outbound SAD
 If an outbound SA is not established yet, the Internet Key Exchange (IKE) protocol (see the
next section) is called to create an outbound and inbound SA for this traffic

Inbound SPD:
  When a packet arrives, the inbound SPD is consulted.
 Each entry in the inbound SPD is also accessed using the same sextuple index.

The input to the inbound SPD is the sextuple index; the output is one of the three following cases:

Discard:

This means that the packet defined by that policy must be dropped

Bypass:

This means that there is no policy for a packet with this policy index; the packet is processed,
ignoring the information from AH or ESP header. The packet is delivered to the transport layer.

Apply:

The security header must be processed. Two situations may occur:

 If an inbound SA is already established, the triple SA index is returned that selects the
corresponding inbound SA from the inbound SAD.
 If an SA is not yet established, the packet must be discarded
 INTERNET KEY EXCHANGE (IKE)

 The Internet Key Exchange (IKE) is a protocol designed to create both inbound and outbound
Security Associations.
 IKE creates SAs for IPSec.

IKE is a complex protocol based on three other protocols:

1. Oakley,
2. SKEME,
3. ISAKMP

Oakley:

 The Oakley protocol was developed by Hilarie Orman. It is a key creation protocol based on
the Diffie-Hellman key-exchange method.
 Oakley is a free-formatted protocol in the sense that it does not define the format of the
message to be exchanged

SKEME

 SKEME, designed by Hugo Krawcyzk, is another protocol for key exchange.

 It uses public-key encryption for entity authentication in a key-exchange protocol

ISAKMP

 The Internet Security Association and Key Management Protocol (ISAKMP) is a protocol
designed by the National Security Agency (NSA) that actually implements the exchanges
defined in IKE.
 It defines several packets, protocols, and parameters that allow the IKE exchanges to take
place in standardized, formatted messages to create SAs.

ISAKMP

The ISAKMP protocol is designed to carry messages for the IKE exchange.

General Header:
Initiator cookie:

This 32-bit field defines the cookie of the entity that initiates the SA establishment, SA notification,
or SA deletion.

Responder cookie:

This 32-bit field defines the cookie of the responding entity. The value of this field is 0 when the
initiator sends the first message.

Next payload:

This 8-bit field defines the type of payload that immediately follows the header.

Major version:

 This 4-bit version defines the major version of the protocol. Currently, the value of this field
is 1.

Minor version

 This 4-bit version defines the minor version of the protocol. Currently, the value of this field
is 0.

Exchange type:

 This 8-bit field defines the type of exchange that is being carried by the ISAKMP packets.

Flags:

 This is an 8-bit field in which each bit defines an option for the exchange.
 Only the three least significant bits are defined.
1. The encryption bit, when set to 1, specifies that the rest of the payload will be encrypted
using the encryption key and the algorithm defined by SA.
2. The commitment bit, when set to 1, specifies that encryption material is not received
before the establishment of the SA.
 3. The authentication bit, when set to 1, specifies that the rest of the payload, though not
encrypted, is authenticated for integrity.

Message ID:

This 32-bit field is the unique message identity that defines the protocol state.

Message length:

This 32-bit field defines the length of the total message, including the header and all payloads.
Confidentiality of information:

Cardholder account and payment information is secured as it travels across the network. An
interesting and important feature of SET is that it prevents the merchant from learning the
cardholder's credit card number; this is only provided to the issuing bank. Conventional encryption
by DES is used to provide confidentiality.

Integrity of data:

Payment information sent from cardholders to merchants includes order information, personal data,
and payment instructions. SET guarantees that these message contents are not altered in transit.
RSA digital signatures, using SHA-1 hash codes, provide message integrity. Certain messages are also
protected by HMAC using SHA-1.

Cardholder account authentication:

SET enables merchants to verify that a cardholder is a legitimate user of a valid card account
number. SET uses X.509v3 digital certificates with RSA signatures for this purpose.

Merchant authentication:

SET enables cardholders to verify that a merchant has a relationship with a financial institution
allowing it to accept payment cards. SET uses X.509v3 digital certificates with RSA signatures for this
purpose.
Steps involved in SET

The customer opens an account.

The customer obtains a credit card account, such as MasterCard or Visa, with a bank that supports
electronic payment and SET.

The customer receives a certificate.

After suitable verification of identity, the customer receives an X.509v3 digital certificate, which is
signed by the bank. The certificate verifies the customer's RSA public key and its expiration date. It
also establishes a relationship, guaranteed by the bank, between the customer's key pair and his or
her credit card.

Merchants have their own certificates.

A merchant who accepts a certain brand of card must be in possession of two certificates for two
public keys owned by the merchant: one for signing messages, and one for key exchange. The
merchant also needs a copy of the payment gateway's public-key certificate.

The customer places an order.

This is a process that may involve the customer first browsing through the merchant's Web site to
select items and determine the price. The customer then sends a list of the items to be purchased to
the merchant, who returns an order form containing the list of items, their price, a total price, and
an order number.

The merchant is verified.

In addition to the order form, the merchant sends a copy of its certificate, so that the customer can
verify that he or she is dealing with a valid store.

The order and payment are sent.

The customer sends both order and payment information to the merchant, along with the
customer's certificate. The order confirms the purchase of the items in the order form. The payment
contains credit card details. The payment information is encrypted in such a way that it cannot be
read by the merchant. The customer's certificate enables the merchant to verify the customer.

The merchant requests payment authorization.

The merchant sends the payment information to the payment gateway, requesting authorization
that the customer's available credit is sufficient for this purchase.

The merchant confirms the order.

The merchant sends confirmation of the order to the customer.

The merchant provides the goods or service.

The merchant ships the goods or provides the service to the customer.

The merchant requests payment.

This request is sent to the payment gateway, which handles all of the payment processing.
The Secure Sockets Layer (SSL) Protocol and the Transport Layer
Security (TLS) Protocol.

the goals of these protocols is to provide

 Server and client authentication,

 Data confidentiality,
 Data integrity.

SSL ARCHITECTURE
 SSL is provides security and compression services to data generated from the application
layer.
 SSL can receive data from any application layer protocol,(HTTP) is compressed (optional),
signed, and encrypted.
 The data is then passed to a reliable transport layer protocol such as TCP.
Services:

SSL provides several services

Fragmentation:

SSL divides the data into blocks of 214 bytes or less.

Compression:

Each fragment of data is compressed using one of the lossless compression methods.

Message Integrity:

To preserve the integrity of data, SSL uses a keyed-hash function to create a MAC.

Confidentiality:

To provide confidentiality, the original data and the MAC are encrypted using symmetrickey
cryptography.

Framing:

A header is added to the encrypted payload. The payload is then passed to a reliable transport layer
protocol.

Key Exchange Algorithms

To exchange an authenticated and confidential message, the client and the server each need six
cryptographic secrets (four keys and two initialization vectors).

To create these secrets, one pre-master secret must be established between the two parties.

SSL defines six key-exchange methods to establish this pre - master secret:

 NULL,
 RSA,
 anonymous Diffie-Hellman,
 ephemeral Diffie-Hellman,
  fixed Diffie-Hellman,
 Fortezza,

NULL:

There is no key exchange in this method. No pre-master secret is established between the client and
the server.

RSA:

 The pre-master secret is a 48-byte random number created by the client, encrypted with the
server’s RSA public key, and sent to the server.
 The server needs to send its RSA encryption/decryption certificate.

Anonymous Diffie-Hellman:

 This is the simplest and most insecure method.

 The pre-master secret is established between the client and server using the Diffie-Hellman
(DH) protocol.
 The DiffieHellman half-keys are sent in plaintext.
Ephemeral Diffie-Hellman:

 The ephemeral Diffie-Hellman key exchange can be used.

 Each party sends a Diffie-Hellman key signed by its private key.
 The receiving party needs to verify the signature using the public key of the sender.
 The public keys for verification are exchanged using either RSA or DSS digital signature
certificates.

Fixed Diffie-Hellman:

 All entities in a group can prepare fixed Diffie-Hellman parameters (g and p).
 Then each entity can create a fixed Diffie-Hellman half-key (gx ).
 Two parties do not directly exchange the half-keys; the CA sends the half-keys in an RSA or
DSS special certificate.

Fortezza:

It is a family of security protocols developed for the Defense Department.

Encryption/Decryption Algorithms
 There are several choices for the encryption/decryption algorithm.
  We can divide the algorithms into 6 groups.

NULL:

The NULL category simply defines the lack of an encryption/decryption algorithm.

Stream RC:

Two RC algorithms are defined in stream mode: RC4-40 (40-bit key) and RC4-128 (128-bit key).

Block RC:

One RC algorithm is defined in block mode: RC2_CBC_40 (40-bit key).

DES:

All DES algorithms are defined in block mode. DES40_CBC uses a 40-bit key. Standard DES is defined
as DES_CBC. 3DES_EDE_CBC uses a 168-bit key

IDEA:

The one IDEA algorithm defined in block mode is IDEA_CBC, with a 128-bit key

Fortezza:

The one Fortezza algorithm defined in block mode is FORTEZZA_CBC, with a 96-bit key

Hash Algorithms
SSL uses hash algorithms to provide message integrity.

Three hash functions are defined,

Null:

The two parties may decline to use an algorithm. In this case, there is no hash function and the
message is not authenticated.

MD5:

The two parties may choose MD5 as the hash algorithm. In this case, a 128-key MD5 hash algorithm
is used.

SHA-1:

The two parties may choose SHA as the hash algorithm. In this case, a 160-bit SHA-1 hash algorithm
is used.

FOUR PROTOCOLS
 SSL defines four protocols in two layers.
 The Record Protocol is the carrier.
 It carries messages from three other protocols as well as the data coming from the
application layer.
 Messages from the Record Protocol are payloads to the transport layer, normally TCP.
Handshake Protocol:

 The Handshake Protocol provides security parameters for the Record Protocol.
 It establishes a cipher set and provides keys and security parameters.
 It also authenticates the server to the client and the client to the server if needed and to
exchange information for building the cryptographic secrets.
 The handshaking is done in four phases.

Phase I: Establishing Security Capability

Phase II: Server Key Exchange and Authentication:

Phase III: Client Key Exchange and Authentication:

Phase IV: Finalizing and Finishing

ChangeCipherSpec Protocol:

 The ChangeCipherSpec Protocol is used for signalling the readiness of cryptographic secrets.
 The ChangeCipherSpec message, which is exchanged during the Handshake protocol and
defined in the ChangeCipherSpec Protocol.
 The sender and the receiver need two states,
  One state, the pending state, keeps track of the parameters and secrets. The other state, the
active state, holds parameters and secrets used by the Record Protocol to sign/verify or
encrypt/decrypt messages.
 Each state holds two sets of values: read (inbound) and write (outbound).

Alert Protocol:

SSL uses the Alert Protocol for reporting errors and abnormal conditions.
Record Protocol:

 The Record Protocol carries messages from the upper layer (Handshake Protocol,
ChangeCipherSpec Protocol, Alert Protocol, or application layer).
 The message is fragmented and optionally compressed; a MAC is added to the compressed
message using the negotiated hash algorithm.
 The compressed fragment and the MAC are encrypted using the negotiated encryption
algorithm. Finally, the SSL header is added to the encrypted message.


 SSL MESSAGE FORMATS
The Record Protocol:

The Record Protocol has a general header that is added to each message coming from the sources,

Protocol:

This 1-byte field defines the source or destination of the encapsulated message.

Version:

This 2-byte field defines the version of the SSL

Length:

This 2-byte field defines the size of the message (without the header) in bytes.

ChangeCipherSpec Protocol:

 The ChangeCipherSpec Protocol has one message, the ChangeCipherSpec message.

 The message is only one byte, encapsulated in the Record Protocol message with protocol
value 20.
 The one-byte field in the message is called the CCS and its value is currently 1

Alert Protocol:

 The Alert Protocol has one message that reports errors in the process.
 The encapsulation of this single message in the Record Protocol with protocol value 21.
The two fields of the Alert message are listed below

Level:

This one-byte field defines the level of the error. Two levels have been defined so far: warning and
fatal.

Description:

The one-byte description defines the type of error.

Handshake Protocol:

 Several messages have been defined for the Handshake Protocol.

All of these messages have the four-byte generic header.

Type:

 This one-byte field defines the type of message

 Ten types have been defined
Length (Len):

This three-byte field defines the length of the message.

 TRANSPORT LAYER SECURITY

 The Transport Layer Security (TLS) protocol is the IETF standard version of the SSL protocol.
 The two are very similar, with slight differences

Highlight the differences between TLS and SSL protocols

Version:

The first difference is the version number (major and minor). The current version of SSL is 3.0; the
current version of TLS is 1.0. In other words, SSLv3.0 is compatible with TLSv1.0.

Cipher Suite:

Another minor difference between SSL and TLS is the lack of support for the Fortezza method. TLS
does not support Fortezza for key exchange or for encryption/decryption.

Generation of Cryptographic Secrets:

The generation of cryptographic secrets is more complex in TLS than in SSL

TLS first defines two functions:

 The data-expansion function

 The pseudorandom function

Data-Expansion Function:

The data-expansion function uses a predefined HMAC (either MD5 or SHA-1) to expand a secret into
a longer one.
Pseudorandom Function (PRF):

TLS defines a pseudorandom function (PRF) to be the combination of two data-expansion functions,
one using MD5 and the other SHA-1. PRF takes three inputs, a secret, a label, and a seed

Pre-master Secret:

The generation of the pre-master secret in TLS is exactly the same as in SSL.

Master Secret:
TLS uses the PRF function to create the master secret from the pre-master secret.

Key Material:

TLS uses the PRF function to create the key material from the master secret.

Alert Protocol:

TLS supports all of the alerts defined in SSL except for NoCertificate.
Handshake Protocol:

TLS has made some changes in the Handshake Protocol.

CertificateVerify message and the Finished message have been changed.

CertificateVerify Message:
In SSL, the hash used in the CertificateVerify message is the two-step hash of the handshake
messages plus a pad and the master secret. TLS has simplified the process. The hash in the TLS is
only over the handshake messages,

Finished Message:

The calculation of the hash for the Finished message has also been changed. TLS uses the PRF to
calculate two hashes used for the Finished message.

Record Protocol:

The only change in the Record Protocol is the use of HMAC for signing the message. TLS uses the
MAC to create the HMAC.