Explain secure socket

layer (SSL) protocol

stack with a neat
diagram and define
the
different parameters
used in session and
connection state
SSL: Secure Socket Layer and TLS (Transport Layer Security)

Q: Explain secure socket layer (SSL) protocol stack with a neat diagram and
define the different parameters used in session and connection state

Secure Socket Layer is designed to make use of TCP to provide a reliable end-to-end
secure service. Moreover, Secure Socket Layer is not a single protocol but rather two layers
of protocols, as illustrated in above figure. The SSL Record Protocol provides basic
security services to various higher layer protocols. In particular, the Hypertext Transfer
Protocol (HTTP), which provides the transfer service for Web client/server interaction,
can operate on top of SSL. Three higher-layer protocols are defined as part of SSL:
the Handshake Protocol, The Change Cipher Spec Protocol, and the Alert Protocol. These
SSL specific protocols are used in management of SSL exchanges. SSL Concepts: Two
important SSL concepts are the SSL session and the SSL connection, which are defined in the
specification as follows. ➢ Connection: A connection is a transport that provides a suitable
type of service. For SSL, such connections are peer-to-peer relationships. The connections
are transient. Every connection associated with one session. ➢ Session: An SSL session is
an association between a client and a server. Sessions are created by the Handshake Protocol.
Sessions define a set of cryptographic security parameters which can be shared among
multiple connections. Sessions are used to avoid the expensive negotiation of new security
parameters for each connection.

Parameters used in session state: ➢ Session identifier: An arbitrary byte sequence

chosen by the server to identify an active or resumable session state. ➢ Peer certificate:
An X509.v3 certificate of the peer. This element of the state may be null. ➢ Compression
method: The algorithm used to compress data prior to encryption. ➢ Cipher spec: Specifies
the bulk data encryption algorithm (such as null, AES, etc.) and a hash algorithm (such as
MD5 or SHA-1) used for MAC calculation. It also defines cryptographic attributes
such as the hash size. ➢ Master secret: 48-byte secret shared between the client and the
[Link] resumable: A flag indicating whether the session can be used to initiate new
connections.

Parameters used in connection states: ➢ Server and client random: Byte sequences that
are chosen by the server and client for each connection. ➢ Server write MAC secret: The
secret key used in MAC operations on data sent by the server. ➢ Client write MAC secret:
The secret key used in MAC operations on data sent by the client. ➢ Server write key: The
secret encryption key for data encrypted by the server and decrypted by the client. ➢ Client
write key: The symmetric encryption key for data encrypted by the client and decrypted by
the server. ➢ Initialization vectors: When a block cipher in CBC mode is used, an
initialization vector (IV) is maintained for each key. This field is first initialized by the SSL
Handshake Protocol. ➢ Sequence numbers: Each party maintains separate sequence
numbers for transmitted and received messages for each connection. When a party
sends or receives a change cipher spec message, the appropriate sequence number is set
to zero. Sequence numbers may not exceed (264 – 1).

4. Discuss security socket layer (SSL) record protocol in terms of fragmentation,

compression and encryption.

The SSL record protocol provides two services for SSL connections Confidentiality and
Message Integrity. Figure 1.3 indicates the overall operation of SSL Record Protocol. The
Record Protocol takes an application message to be transmitted, fragments the data into
manageable blocks, optionally compresses the data, applies a MAC, encrypts, adds a header,
and transmits the resulting unit in a TCP segment. The first step is Fragmentation. Each
upper-layer message fragmented into blocks of 214 bytes (16384 bytes) or less. Next
Compression is optionally applied. Compression must be lossless and may not increase the
content length by more than 1024 bytes. The next step in processing is to compute a
message authentication code over the compressed data. For this purpose, a shared secret key
is used. The calculation is defined as

hash (MAC_write_secret || pad_2 || hash (MAC_write_secret || pad_1 || seq _ num || SSL

Compressed. type || SSL Compressed. length || SSL Compressed. fragment))

Next the compressed message plus the MAC are encrypted using symmetric
encryption. Encryption may not increase the content length by more than 1024 bytes, so that
the total length may not increase 214+2048. The following encryption algorithms are
permitted
 For stream encryption, the compressed message plus the MAC are encrypted. Note that
MAC is computed before encryption takes place and that the MAC is encrypted along with
the plaintext or compressed plaintext.

For block encryption, padding may be added after the MAC prior to encryption. The padding
is in the form of a number of padding bytes followed by a one-byte indication of length of
padding. The total amount of padding is the smallest amount such that the total size of data to
be encrypted is a multiple of the cipher’s block length.

The final step of SSL Record Protocol processing is to prepare a header consisting of the
following fields: ➢ Content Type (8 bits): The higher-layer protocol used to process the
enclosed fragment.

➢ Major Version (8 bits): Indicates major version of SSL in use. For SSLv3, the value is 3.
➢ Minor Version (8 bits): Indicates minor version in use. For SSLv3, the value is 0. ➢
Compressed Length (16 bits): The length in bytes of the plaintext fragment (or
compressed fragment if compression is used).The maximum value is 214+2048 .

5. Explain Change Cipher Spec, Alert Protocol and Handshake Protocols

The Change Cipher Spec Protocol is one of the three SSL-specific protocols that use
the SSL Record Protocol, and it is the simplest. This protocol consists of a single
message (Figure 1.4a), which consists of a single byte with the value [Link] sole purpose
of this message is to cause the pending state to be copied into the current state, which
updates the cipher suite to be used on this connection.
 The Alert Protocol is used to convey SSL-related alerts to the peer entity. As with
other applications that use SSL, alert messages are compressed and encrypted, as specified by
the current state. Each message in this protocol consists of two bytes (Figure 1.4b).
The first byte takes the value warning (1) or fatal (2) to convey the severity of the
message. If the level is fatal, SSL immediately terminates the connection. Other
connections on the same session may continue, but no new connections on this session
may be established. The second byte contains a code that indicates the specific alert.

The most complex part of SSL is the Handshake Protocol. This protocol allows the
server and client to authenticate each other and to negotiate an encryption and MAC
algorithm and cryptographic keys to be used to protect data sent in an SSL record. The
Handshake Protocol is used before any application data is transmitted. The Handshake
Protocol consists of a series of messages exchanged by client and server. All of these have
the format shown in Figure 1.5. Each message has three fields:

➢ Type (1 byte): Indicates one of 10 messages. ➢ Length (3 bytes): The length of the
message in bytes. ➢ Content ( bytes): The parameters associated with this message

Q. Explain the alert signals used in alert protocols

➢ unexpected_message: An inappropriate message was received. ➢ bad_record_mac: An

incorrect MAC was received. ➢ decompression_failure: The decompression function
received improper input (e.g., unable to decompress or decompress to greater than maximum
allowable length). ➢ handshake_failure: Sender was unable to negotiate an acceptable set of
security parameters given the options available. ➢ illegal_parameter: A field in a handshake
message was out of range or inconsistent with other fields. ➢ close_notify: Notifies the
recipient that the sender will not send any more messages on this connection. Each party is
required to send a close_notify alert before closing the write side of a connection. ➢
no_certificate: May be sent in response to a certificate request if no appropriate certificate is
available. ➢ bad_certificate: A received certificate was corrupt (e.g., contained a signature
that did not verify). ➢ unsupported_certificate: The type of the received certificate is not
supported. ➢ certificate_revoked: A certificate has been revoked by its signer. ➢
certificate_expired: A certificate has expired. ➢ certificate_unknown: Some other unspecified
issue arose in processing the certificate, rendering it unacceptable.

Q. Explain the various phases of SSL handshake protocol OR

With a diagram, explain handshake protocol action.

Figure 1.6 below shows the initial exchange needed to establish a logical connection
between client and server. There are four phases of SSL handshake protocol. Phase 1:
Establish Security Capabilities ,Phase 2: Server Authentication and Key Exchange, Phase 3:
Client Authentication and Key Exchange, Phase 4: Finish

Phase 1: Establish Security Capabilities: This phase is used to initiate a logical connection
and to establish the security capabilities that will be associated with it. The exchange is
initiated by the client, which sends a client_hello message with the following parameters:
➢ Version: The highest SSL version understood by the client. ➢ Random: A client-generated
random number which serves as the nonce. ➢ Session ID: A variable-length session
identifier. A nonzero value indicates that the client wishes to update the parameters of an
existing session. A zero value indicates that the client wishes to establish a new connection
on a new session. ➢ Cipher Suite: This is a list that contains the cryptographic
algorithms (key exchange, encryption, and MAC) supported by the client, in decreasing
order of preference. ➢ Compression Method: This is a list of the compression methods the
client supports.

After sending the client_hello message, the client waits for the server _ hello message,
which contains the same parameters as the client _ hello message. The parameters contain the
values which client had sent to the server and the server has chosen to use
 Phase 2: Server Authentication and Key Exchange: This phase provides authentication of
the server to the client. The server sends its certificate (one or more) if it needs to be
authenticated. ➢ The server sends a server_key_exchange message which contains the list of
secret keys to be used for the subsequent data. The certificate _ request message is
sent next which includes two parameters: certificate _ type and certificate _ authorities. ➢
Moreover, the final message in phase 2, and one that always required is the server_done
message, which sent by the server to indicate the end of the server hello and
associated messages. ➢ After sending this message, the server will wait for a client response.
This message has no parameters.

Phase 3: Client Authentication and Key Exchange: This phase provides client authentication
to the server. ➢ The client verifies the server certificates and checks whether the server _
hello parameters are acceptable. ➢ Moreover, if all is satisfactory, the client sends a
certificate message if the server has requested a certificate. If no suitable certificate is
available, the client sends a no _ certificate alert. ➢ Next is the client _ key _ exchange
message which has the same parameters as the server-key-exchange message. ➢ Similarly,
the client may send a certificate _ verify message to provide explicit verification of a client
certificate. The client encrypts all the previous messages and master secret with its private
key.
Phase 4: Finish: This phase completes the setting up of a secure connection. ➢ The client
sends a change _ Cipher _ spec message and copies the pending Cipher Spec into the current
Cipher Spec. ➢ Moreover, The client then immediately sends the finished ➢ The server
sends its own change _ cipher _ spec message, transfers the pending to the current Cipher
Spec, and sends it finished ➢ At this point, the handshake is complete and the client
and server may begin to exchange application-layer data.

Q. Briefly explain, TLS alert codes

TLS supports all of the alert codes defined in SSLv3 with the exception of
no_certificate. Number of additional codes are defined in TLS; of these, the following are
always fatal. ➢ record_overflow: A TLS record was received with a payload
(ciphertext) whose length exceeds 2 14 +2048 bytes, or the ciphertext decrypted to a length
of greater than 2 14 +2048 bytes. ➢ unknown_ca: A valid certificate chain or partial chain was
received, but the certificate was not accepted because the CA certificate could not be located
or could not be matched with a known, trusted CA. ➢ access_denied: A valid certificate was
received, but when access control was applied, the sender decided not to proceed with the
negotiation. ➢ decode_error: A message could not be decoded, because either a field
was out of its specified range or the length of the message was incorrect. ➢
protocol_version: The protocol version the client attempted to negotiate is recognized but not
supported. ➢ insufficient_security: Returned instead of handshake_failure when a negotiation
has failed specifically because the server requires ciphers more secure than those
supported by the client. ➢ unsupported_extension: Sent by clients that receive an
extended server hello containing an extension not in the corresponding client hello. ➢
internal_error: An internal error unrelated to the peer or the correctness of the
protocol makes it impossible to continue. ➢ decrypt_error: A handshake cryptographic
operation failed, including being unable to verify a signature, decrypt a key exchange, or
validate a finished message. ➢ user_canceled: This handshake is being cancelled for some
reason unrelated to a protocol failure. ➢ no_renegotiation: Sent by a client in response to
a hello request or by the server in response to a client hello after initial handshaking.
Either of these messages would normally result in renegotiation, but this alert indicates that
the sender is not able to renegotiate. This message is always a warning.

Q. Briefly explain HTTPS, connection initiation and connection closure in HTTPS.

HTTPS (HTTP over SSL) refers to the combination of HTTP and SSL to implement
secure communication between a Web browser and a Web server. The HTTPS capability is
built into all modern Web browsers. Its use depends on the Web server supporting HTTPS
communication. For example, search engines do not support HTTPS.

The principal difference seen by a user of a Web browser is that URL (uniform resource
locator) addresses begin with https:// rather than [Link] A normal HTTP connection
uses port 80. If HTTPS is specified, port 443 is used, which invokes SSL. When HTTPS is
used, the following elements of the communication are encrypted: ➢ URL of the requested
document ➢ Contents of the document ➢ Contents of browser forms (filled in by browser
user) ➢ Cookies sent from browser to server and from server to browser ➢ Contents of
HTTP header

Connection Initiation: For HTTPS, the agent acting as the HTTP client also acts as the TLS
client. The client initiates a connection to the server on the appropriate port and then sends
the TLS Client Hello to begin the TLS handshake. When the TLS handshake has finished, the
client may then initiate the first HTTP request. All HTTP data is to be sent as TLS
application data. there are three levels of awareness of a connection in HTTPS. At the
HTTP level, an HTTP client requests a connection to an HTTP server by sending a
connection request to the next lowest layer. Typically, the next lowest layer is TCP, but it
also may be TLS/SSL. At the level of TLS, a session is established between a TLS
client and a TLS server. This session can support one or more connections at any time

Connection Closure: An HTTP client or server can indicate the closing of a

connection by including the following line in an HTTP record: Connection: close. This
indicates that the connection will be closed after this record is delivered. The closure
of an HTTPS connection requires that TLS close the connection with the peer TLS entity
on the remote side, which will involve closing the underlying TCP connection. At the
TLS level, the proper way to close a connection is for each side to use the TLS alert
protocol to send a close_notify alert. TLS implementations must initiate an exchange of
closure alerts before closing a connection. A TLS implementation may, after sending a
closure alert, close the connection without waiting for the peer to send its closure alert,
generating an “incomplete close”. HTTP clients also must be able to cope with a situation in
which the underlying TCP connection is terminated without a prior close_notify alert and
without a Connection: close indicator. Such a situation could be due to a programming error
on the server or a communication error that causes the TCP connection to drop.
3. TRANSPORT
LAYER SECURITY
(TLS)
 TLS is an IETF
standardization
initiative whose goal is
to produce an Internet
standard version of SSL.
 Moreover, TLS is
defined as a Proposed
Internet Standard in
RFC 5246. Is very
similar to SSLv3.
 We highlight the
differences.
Version Number
 The one difference is
in version values. For
the current version of
TLS, the major version
is 3 and the minor
version is 3.
TRANSPORT LAYER SECURITY (TLS)

TLS is an IETF standardization initiative whose goal is to produce an Internet standard version
of SSL.  Moreover, TLS is defined as a Proposed Internet Standard in RFC 5246. Is very similar
to SSLv3.  We highlight the differences.

Version Number  The one difference is in version values. For the current version of TLS, the major
version is 3 and the minor version is 3.

Message Authentication
Code: Transport Layer
Security
 There are two
differences between the
SSLv3 and TLS MAC
schemes:
 The actual algorithm
and the scope of the
MAC calculation.
 TLS makes use of the
HMAC algorithm defined
in RFC 2104.
 HMAC is defined as
Message Authentication Code: Transport Layer Security  There are two differences between the
SSLv3 and TLS MAC schemes:  The actual algorithm and the scope of the MAC calculation.  TLS
makes use of the HMAC algorithm defined in RFC 2104.  HMAC is defined as

H = embedded hash function (for TLS, either MD5 or SHA-1) M = message input to HMAC K+ = secret
key padded with zeros on the left so that the result is equal to the block length of the hash code (for
MD5 and SHA-1, block length = 512 bits) Ipad = 00110110 (36 in hexadecimal) repeated 64 times
(512 bits) opad = 01011100 (5C in hexadecimal) repeated

 SSLv3 uses the same

algorithm, except that
the padding bytes are
concatenated with the
secret key rather than
being XORed with the
secret key padded to
the block length.
 Moreover, The level
of security should be
about the same in both
cases.
 For TLS, the MAC
calculation
encompasses the fields
indicated in the
following
expression:
 SSLv3 uses the same algorithm, except that the padding bytes are concatenated with the secret
key rather than being XORed with the secret key padded to the block length.  Moreover, The level
of security should be about the same in both cases.  For TLS, the MAC calculation encompasses
the fields indicated in the following expression:

MAC(MAC_write_secret,seq_num || [Link] || [Link] ||

[Link] || [Link]
 The MAC calculation
covers all of the fields
covered by the SSLv3
calculation, plus the
field version, which is
the version of the
protocol being employed
 The MAC calculation covers all of the fields covered by the SSLv3 calculation, plus the field version,
which is the version of the protocol being employed

.1 PSEUDORANDOM
FUNCTION:
 TLS makes use of a
pseudorandom function
referred to as PRF to
expand secrets into
blocks of data for
purposes of key
generation or validation.
PSEUDORANDOM FUNCTION:  TLS makes use of a pseudorandom function referred to as PRF
to expand secrets into blocks of data for purposes of key generation or validation.

 Moreover, the
objective is to make
use of a relatively
small shared secret
value but to
generate longer blocks
of data in a way that is
secure from the kinds of
attacks made on
hash functions and MAC
 Moreover, the objective is to make use of a relatively small shared secret value but to
generate longer blocks of data in a way that is secure from the kinds of attacks made on hash
functions and MACs
 Figure 7: TLS Function P_Hash(Secret, Seed)

 The PRF is based on the data expansion function (Figure 7) given as

P _ hash (secret, seed) = HMAC _ hash (secret, A(1) || seed) ||

HMAC _hash (secret, A (2) || seed) ||

HMAC _ hash (secret, A (3) || seed) ||…

Where A () is defined as A (0) = seed

A (i) = HMAC _ hash (secret, A (i – 1) )

 PRF defined as PRF (secret, label, seed) = P _ hash (S1, label || seed

PRF takes as input a secret value, an identifying label, and a seed value and produces an
output of arbitrary length.
Alert Codes: Transport Layer Security

 TLS supports all of

the alert codes
defined in SSLv3 with
the exception of no _
certificate.
 A number of
additional codes defined
in TLS; of these, the
following are always
fatal.
 Record _ overflow: A
TLS record was received
with a payload (cipher
text) whose
length exceeds 214 +
2048 bytes, or the
cipher text decrypted to
a length of greater
than 214 + 1024 bytes.
 Unknown _ ca: A
valid certificate chain
or partial chain was
received, but the
certificate was not
accepted because the
CA certificate could not
be located or could
not be matched with a
known, trusted CA.
 Access _ denied: A
valid certificate was
received, but when
access control was
applied, the sender
decided not to proceed
with the negotiation.
 Decode _ error: A
message could not be
decoded, because either
a field was out of
its specified range or the
length of the message
was incorrect.
 Protocol _version:
The protocol version
the client attempted
to negotiate is
recognized but not
supported.
 Insufficient _
security: Returned
instead of handshake _
failure when a
negotiation
has failed specifically
because the server
requires ciphers more
secure than those
supported by the client.
 Unsupported _
extension: Sent by
clients that receives
an extended server
hello
containing an extension
not in the corresponding
client hello.
 Internal _ error:
An internal error
unrelated to the peer
or the correctness of
the
protocol makes it
impossible to continue.
 Decrypt _ error: A
handshake
cryptographic operation
failed, including being
unable
to verify a signature,
decrypt a key exchange,
or validate a finished
message.
 TLS supports all of the alert codes defined in SSLv3 with the exception of no _
certificate.  A number of additional codes defined in TLS; of these, the following are always
fatal.  Record _ overflow: A TLS record was received with a payload (cipher text) whose
length exceeds 214 + 2048 bytes, or the cipher text decrypted to a length of greater than 2 14
+ 1024 bytes.  Unknown _ ca: A valid certificate chain or partial chain was received,
but the certificate was not accepted because the CA certificate could not be located or
could not be matched with a known, trusted CA.  Access _ denied: A valid certificate
was received, but when access control was applied, the sender decided not to proceed
with the negotiation.  Decode _ error: A message could not be decoded, because either a
field was out of its specified range or the length of the message was incorrect.  Protocol
_version: The protocol version the client attempted to negotiate is recognized but not
supported.  Insufficient _ security: Returned instead of handshake _ failure when a
negotiation has failed specifically because the server requires ciphers more secure
than those supported by the client.  Unsupported _ extension: Sent by clients that
receives an extended server hello containing an extension not in the corresponding client
hello.  Internal _ error: An internal error unrelated to the peer or the correctness of
the protocol makes it impossible to continue.  Decrypt _ error: A handshake cryptographic
operation failed, including being unable to verify a signature, decrypt a key exchange, or
validate a finished message.

 The remaining alerts

include the following.
 User _ cancelled:
This handshake is being
cancelled for some
reason unrelated to a
protocol failure.
 No _ renegotiation:
Sent by a client in
response to a hello
request or by the server
in
response to a client
hello after initial
handshaking. Either of
these messages would
normally result in
renegotiation, but this
alert indicates that the
sender is not able to
renegotiate. This
message is always a
warning.
 The remaining alerts include the following.  User _ cancelled: This handshake is being
cancelled for some reason unrelated to a protocol failure.  No _ renegotiation: Sent by a
client in response to a hello request or by the server in response to a client hello after
initial handshaking. Either of these messages would normally result in renegotiation, but
this alert indicates that the sender is not able to renegotiate. This message is always a
warning.

Cipher Suites: Moreover, there are several small differences between the cipher suites
available under SSLv3 and under TLS:  Key Exchange: TLS supports all of the key
exchange techniques of SSLv3 with the exception of Fortezza.  Symmetric Encryption
Algorithms: TLS includes all of the symmetric encryption algorithms found in SSLv3, with
the exception of Fortezza

Client Certificate Types  TLS defines the following certificate types to be requested in
a certificate_ request message: rsa _sign, dss _sign, rsa _fixed _dh, and dss _fixed _dh. 
These are all defined in SSLv3. In addition, SSLv3 includes rsa _ ephemeral _dh, dss _
ephemeral _dh, and fortezza _kea.  Ephemeral Diffie-Hellman involves signing the
Diffie-Hellman parameters with either RSA or DSS. For TLS, the rsa _ sign and dss _sign
types are used for that function; a separate signing type is not needed to sign Diffie-Hellman
parameters.  TLS does not include the Fortezza scheme.

Certificate _verify and Finished Messages  In the TLS certificate _verify message, the MD5
and SHA-1 hashes are calculated only over handshake _messages.  Recall that for SSLv3,
the hash calculation also included the master secret and pads. These extra fields were
felt to add no additional security.  As with the finished message in SSLv3, the finished
message in TLS is a hash based on the shared master _secret, the previous handshake
messages, and a label that identifies client or server. The calculation is somewhat
different. For TLS, we have PRF (master_secret, finished_label, MD5 (handshake _
messages) ‖ SHA-1 (handshake _messages)) Where finished label is the string ―client
finished‖ for the client and ―server finished‖ for the server.
Cryptographic Computations The pre _ master _secret for TLS is calculated in the
same way as in SSLv3. As in SSLv3, the master _secret in TLS is calculated as a hash
function of the pre_ master _secret and the two hello random numbers. The form of the TLS
calculation is different from that of SSLv3 and is defined as Master _secret = PRF (pre
_master _secret, "master secret", Client Hello .random ‖ Server Hello .random) The
algorithm is performed until 48 bytes of pseudorandom output are produced. The
calculation of the key block material (MAC secret keys, session encryption keys, and IVs) is
defined as

Key _block = PRF

(master _secret, "key
expansion", Security
Parameters. Server _
random‖ Security
Parameters. Client
_random)
Until enough output has
been generated. As with
SSLv3, the key _block is
a function of the
master _secret and the
client and server
random numbers, but
for TLS, the actual
algorithm is
different.
Key _block = PRF (master _secret, "key expansion", Security Parameters. Server _
random‖ Security Parameters. Client _random) Until enough output has been generated. As
with SSLv3, the key _block is a function of the master _secret and the client and server
random numbers, but for TLS, the actual algorithm is different.

For example,  if the plaintext (or compressed text if compression is used) plus MAC
plus padding.  Length byte is 79 bytes long, then the padding length (in bytes) can be 1, 9,
17, and so on, up to 249.  A variable padding length may be used to frustrate attacks based
on an analysis of the lengths of exchanged messages.

3. TRANSPORT
LAYER SECURITY
(TLS)
 TLS is an IETF
standardization
initiative whose goal is
to produce an Internet
standard version of SSL.
 Moreover, TLS is
defined as a Proposed
Internet Standard in
RFC 5246. Is very
similar to SSLv3.
 We highlight the
differences.
Version Number
 The one difference is
in version values. For
the current version of
TLS, the major version
is 3 and the minor
version is 3.