Module 2

Transport Level Security

 Transport Level Security
• Web security considerations
• Secure sockets layer
• Transport Layer security
• HTTPS
• Secure shell (SSH)
 Why web security is must?

• Electronic publishing systems, voice response –

vulnerable to attack
• Platform for corporate & product info., business
transactions
• Complex software – hide many security flaws
• Casual and untrained users
 Comparison of Threats on the Web
Threats Consequences Countermeasures
Integrity  Modification of user data  Loss of Cryptographic
information checksums
 Trojan horse browser
 Compromise of
 Modification of memory
machine
 Modification of message
 Vulnerabilty to
traffic in transit
all other threats
Confidentiality  Eavesdropping on the Net  Loss of Encryption, web
information proxies
 Theft of info from server
 Loss of privacy
 Theft of data from client
 Info about network
configuration
 Info about which client talks
to server
 Threats Consequences Countermeasures
Denial of Service  Killing of user  Disruptive Difficult to prevent
threads
 Annoying
 Flooding machine
 Prevent user from
with bogus
getting work done
requests
 Filling up disk or
memory
 Isolating machine
by DNS attacks
Authentication  Impersonation of  Misrepresentation Cryptographic
legitimate users of user techniques
 Data forgery  Belief that false
information is
valid
Web traffic security approaches:
Location of security facilities in TCP/IP Protocol Stack
 Secure Socket Layer
SSL Architecture

Session

Connection
 Secure Socket Layer – SSL
• TCP – Reliable end-to-end secure service
• Two SSL concepts are:

Connection:
• Provides type of service
• Peer-to-peer relationships
• Transient
• Every connection associated with one session

Session:
• Association between client & server
• Created by Handshake protocols
• Cryptographic security parameter – multiple connections
 Connection State is defined by
• Server & Client random – byte sequence chosen by server &
client
• Server write MAC secret – Secret key – on data sent by the
server
• Client write MAC secret – on data sent by the client
• Server write key – secret encryption key – for data encrypted
by server and decrypted by client
• Client write key – symmetric encryption key – for data enc
by client & decrypted by server
• Initialization vectors – block cipher in CBC mode is used, IV is
maintained for each key. Field is initialized by SSL Handshake
protocol
• Sequence numbers – When a party sends or receives a
change cipher spec msg, appropriate sequence no. is set to
zero. May not exceed 2 ^(64) -1
 Secure Socket Layer – SSL
• TCP – Reliable end-to-end secure service
• Two SSL concepts are:

Connection:
• Provides type of service
• Peer-to-peer relationships
• Transient
• Every connection associated with one session

Session:
• Association between client & server
• Created by Handshake protocols
• Cryptographic security parameter – multiple connections
 SSL Record Protocol
• Two services – Confidentiality and Message integrity
• Two SSL concepts are:

Connection:
• Provides type of service
• Peer-to-peer relationships
• Transient
• Every connection associated with one session

Session:
• Association between client & server
• Created by Handshake protocols
• Cryptographic security parameter – multiple connections
 A session state is defined by the following parameters
1. Session identifier
2. Peer certificate
3. Compression method
4. Cipher spec
5. Master secret
6. Is resumable

A connection state is defined by the following parameters

7. Server and client random
8. Server write MAC secret
9. Client write MAC secret
10. Server write key
11. Client write key
12. Initialization vectors
13. Sequence numbers
Secure Socket Layer Record Protocol

214 Bytes 16384 bytes

 hash(MAC_write_secret || pad_2 ||
hash(MAC_write_secret || pad_1 || seq_num ||
SSLCompressed.type || SSLCompressed.length ||
SSLCompressed.fragment))
|| concatenation
MAC_write_secret shared secret key
hash cryptographic hash algorithm; either MD5 or SHA-1
pad_1 the byte 0x36 (0011 0110) repeated 48 times (384
bits) for MD5 and 40 times (320 bits) for SHA-1
pad_2 the byte 0x5C (0101 1100) repeated 48 times for
MD5 and 40 times for SHA-1
seq_num the sequence number for this message
SSLCompressed.type the higher-level protocol used to process this
fragment
SSLCompressed.length the length of the compressed fragment
SSLCompressed.fragment the compressed fragment (if compression is not
used, the plaintext fragment)
 Alert Protocol

• Used to convey SSL – related alerts to peer entity

• Two bytes - Level & Alert
• First byte – warning or fatal
• Second byte – a code that indicates the specific alert
• Alerts that are always fatal
 Unexpected message – inappropriate message
 Bad_record_mac – Incorrect MAC
 Decomposition_failure – Unable to decompress to greater than
allowable length
 Handshake_failure – unable to negotiate acceptable set of
security parameters
 Illegal_parameter – a field in a handshake message was out of
range with other fields
 The remaining alerts

 Close_notify - Notifies the recipient that the sender will not

send any more messages on this connection
 No certificate - Sent in response to a certificate request if no
appropriate certificate is available
 Bad_certificate – received certificate was corrupt (signature
that did not verify)
 Unsupported_certificate – Type of certificate received is not
supported
 Certificate_revoked – Revoked by its signer
 Certificate_expired
 Certificate_unknown – Unspecified issue arose in processing -
unacceptable
• Handshake Protocol allows the server and client to
authenticate each other and to negotiate an encryption
and MAC algorithm and cryptographic keys.
• Handshake Protocol is used before any application data is
transmitted.
• Handshake Protocol consists of a series of messages
exchanged by client And server.
• All of these have the format shown in (Figure c)
A handshake message has the following format:
1. Type (1 byte): Indicates one of 10 messages of handshake
protocol.
2. Length (3 bytes): The length of the message in bytes.
3. Content (bytes): The parameters associated with the message.
 Handshake Protocol message types
Message Type Parameter
Hello_request Null
Client_hello version, random, session id, cipher
suite, compression method

Server_hello version, random, session id, cipher

suite, compression method

Certificate Chain of X.509v3 certificates

Server_key_exchange Parameters, signature

Certificate_request Type, authorities
Server_done Null
Certificate_verify Signature
Client_key_exchange Parameters, signature
finished Hash value
• The initial exchange needed to establish a logical connection between client and server
Phase 1. Establish Security Capabilities
• Used to initiate a logical connection and to establish the security capabilities

• Exchange is initiated by the client : client_hello

• 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 - client wishes

to update the parameters of an existing session. A zero value - 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 - 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

• Provides authentication of the server to the client.

• The server sends its certificate (one or more) if it needs to be
authenticated.
• Server_key_exchange message – list of secret keys –
subsequent data
• Certificate_request message – 2 parameters
 Certificate_type
 Certificate_authorities
• Server_done – End of the server hello and associated
messages
• After sending this message, the server will wait for a client
response.
Phase 3. Client Authentication and Key Exchange

• This phase provides client authentication to the server.

• Client verifies the server certificates and checks whether the

server _ hello parameters are acceptable.
• If all is satisfactory - 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.
• Client may send a certificate _ verify message - 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.
• The client - immediately sends the finished message under the
new algorithms, keys, and secrets.
• The content of the finished message is the concatenation of two
hash values: MD5 – Authenticating messages, content
verification, digital signatures. 128 bits length of message digest
• SHA - 160 bits length of message digest
• 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.
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

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
 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 that 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 - 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 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:

• 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.
Cipher Suites:
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 some certificate types to be requested in a

certificate_ request message: rsa _sign

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

#include <openssl/rsa.h>
int RSA_sign(int type, const unsigned char *m, unsigned int
m_len, unsigned char *sigret, unsigned int *siglen, RSA *rsa);
int RSA_verify(int type, const unsigned char *m, unsigned int
m_len, unsigned char *sigbuf, unsigned int siglen, RSA *rsa);

• RSA_sign() signs the message digest m of

size m_len using the private key rsa as specified in
PKCS #1 v2.0.
• It stores the signature in sigret and the signature size
in siglen. sigret must point to RSA_size(rsa) bytes of
memory.
• Certificate _verify and Finished Messages
• In the TLS certificate _verify message, the MD5 and SHA-1 hashes
are calculated only over handshake _messages.

• For SSLv3, the hash calculation also included the master secret and
pads.

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

• For TLS, we have PRF (master_secret, finished_label, MD5

(handshake _ messages) ‖ SHA-1 (handshake_messages))
 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.
 Padding
• In SSL, the padding added prior to encryption of user data is the minimum
amount required so that the total size of the data to be encrypted is a
multiple of the cipher’s block length.

• In TLS, the padding can be any amount that results in a total that is a
multiple of the cipher’s block length, up to a maximum of 255 bytes.

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

• HTTPS (HTTP over SSL) - to implement secure communication between a

Web browser and a Web server.
• 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
addresses begin with https:// rather than http://.
• 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

• The client initiates a connection to the server on the appropriate port and
then sends the TLS Client Hello to begin the TLS handshake.

• The client may then initiate the first HTTP request. All HTTP data is to be sent
as TLS application data. Retained connections should be followed.

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

• 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 - session can support one or more connections at any time.

• A TLS request to establish a connection begins with the establishment of a

TCP connection between the TCP entity on the client side and the TCP entity
on the server side.
 Connection Closure
• Connection: close - 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.
• 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 - 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.
• The unannounced TCP closure could be evidence of some sort of attack -
security warning.
SSH Protocol Stack
SSH Transport Layer Protocol Packet Exchanges
SSH Transport Layer Protocol Packet Formation
 A session state is defined by the following parameters
1. Session identifier
2. Peer certificate
3. Compression method
4. Cipher spec
5. Master secret
6. Is resumable

A connection state is defined by the following parameters

7. Server and client random
8. Server write MAC secret
9. Client write MAC secret
10. Server write key
11. Client write key
12. Initialization vectors
13. Sequence numbers
Tuesday, March 11, 2025 44
SHA 1 MD 5
 Block Cipher Stream Cipher
Algorithm Key Size Algorithm Key Size
AES 128,256 RC4-40 40
IDEA 128 RC4-128 128
RC2-40 40
DES-40 40
DES 56
3DES 168
Fortezza 80
•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.
 Handshake Protocol
Message Type Parameters
hello_request null
client_hello version, random, session id, cipher
suite, compression method
server_hello version, random, session id, cipher
suite, compression method
certificate chain of X.509v3 certificates
server_key_exchange parameters, signature
certificate_request type, authorities
server_done null
certificate_verify signature
client_key_exchange parameters, signature
finished hash value
Each message has three fields:

•Type (1 byte): Indicates one of 10 messages. Table lists the defined message
types.

•Length (3 bytes): The length of the message in bytes.

•Content ( 0 bytes): The parameters associated with this message; these are
listed in Table.

PHASES
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
•Version: The highest SSL version understood by the client.
•Random: A client-generated random structure, consisting of a 32-bit timestamp
and 28 bytes generated by a secure random number generator. These values
serve as nonces and are used during key exchange to prevent replay attacks.
•Session ID: A variable-length session identifier. A nonzero value indicates that
the client wishes to update the parameters of an existing connection or create a
new connection on this session. A zero value indicates that the client wishes to
establish a new connection on a new session.
•CipherSuite: This is a list that contains the combinations of cryptographic
algorithms supported by the client, in decreasing order of preference. Each
element of the list (each cipher suite) defines both a key exchange algorithm and
a CipherSpec; these are discussed subsequently.
•Compression Method: This is a list of the compression methods the client
supports.
 CipherSuite
Key exchange method
•RSA
•Fixed Diffie-Hellman
•Ephemeral Diffie-Hellman
•Anonymous Diffie-Hellman
•Fortezza
Cipher Spec
CipherAlgorithm: Any of the algorithms mentioned earlier: RC4, RC2, DES, 3DES,
DES40, IDEA, Fortezza
MACAlgorithm: MD5 or SHA-1
CipherType: Stream or Block
IsExportable: True or False
HashSize: 0, 16 (for MD5), or 20 (for SHA-1) bytes
Key Material: A sequence of bytes that contain data used in generating the write
keys
IV Size: The size of the Initialization Value for Cipher Block Chaining (CBC)
encryption
 Phase 2. Server Authentication and Key Exchange

•RSA, signature only

•DSS, signature only
•RSA for fixed Diffie-Hellman; in this case the signature is used only for authentication, by
sending a certificate signed with RSA
•DSS for fixed Diffie-Hellman; again, used only for authentication
•RSA for ephemeral Diffie-Hellman
•DSS for ephemeral Diffie-Hellman
•Fortezza
Anonymous Diffie-Hellman: The message content consists of the two
global Diffie-Hellman values (a prime number and a primitive root of that
number) plus the server's public Diffie-Hellman key

Ephemeral Diffie-Hellman: The message content includes the three Diffie-

Hellman parameters provided for anonymous Diffie-Hellman, plus a
signature of those parameters.

RSA key exchange, in which the server is using RSA but has a signature-
only RSA key: Accordingly, the client cannot simply send a secret key
encrypted with the server's public key. Instead, the server must create a
temporary RSA public/private key pair and use the server_key_exchange
message to send the public key. The message content includes the two
parameters of the temporary RSA public key (exponent and modulus) plus a
signature of those parameters.

Fortezza
 Phase 3. Client Authentication and Key Exchange

RSA: The client generates a 48-byte pre-master secret and encrypts with the public key
from the server's certificate or temporary RSA key from a server_key_exchange message.
Its use to compute a master secret is explained later.
Ephemeral or Anonymous Diffie-Hellman: The client's public Diffie-Hellman parameters
are sent.
Fixed Diffie-Hellman: The client's public Diffie-Hellman parameters were sent in a
certificate message, so the content of this message is null.
Fortezza: The client's Fortezza parameters are sent.
Phase 4. Finish
 Change Cipher Spec Protocol

This protocol consists of a single message, which consists of a single byte with
the value 1. The 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.
Alert Protocol

unexpected_message bad_record_mac
decompression_failure handshake_failure
illegal_parameter close_notify
no_certificate bad_certificate
unsupported_certificate certificate_revoked
certificate_expired certificate_unknown
Transport Layer Security
 Message Authentication Code
HMAC_hash(MAC_write_secret, seq_num ||
TLSCompressed.type ||
TLSCompressed.version
|| TLSCompressed.length ||
TLSCompressed.fragment)

Pseudorandom Function

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(secret, label, seed) = P_MD5(S1, label || seed)

P_SHA-1(S2, label || seed)
Alert Codes,
Key Exchange
Encryption
Algorithms
Client
Certification
type,
Certificate
Verify &
 Finished
Messages
 HTTPS
• HTTPS (HTTP over SSL)
– combination of HTTP & SSL/TLS to secure communications between
browser & server
• documented in RFC2818
• no fundamental change using either SSL or TLS
• use https:// URL rather than http://
– and port 443 rather than 80
• encrypts
– URL, document contents, form data, cookies, HTTP headers
 HTTPS Use
• connection initiation
– TLS handshake then HTTP request(s)
• connection closure
– have “Connection: close” in HTTP record
– TLS level exchange close_notify alerts
– can then close TCP connection
– must handle TCP close before alert exchange sent or
completed
 Secure Shell (SSH)
• protocol for secure network communications
– designed to be simple & inexpensive
• SSH1 provided secure remote logon facility
– replace TELNET & other insecure schemes
– also has more general client/server capability
• SSH2 fixes a number of security flaws
• documented in RFCs 4250 through 4254
• SSH clients & servers are widely available
• method of choice for remote login/ X tunnels
 SSH Transport Layer Protocol
• server authentication occurs at transport layer, based on
server/host key pair(s)
– server authentication requires clients to know host keys in
advance
• packet exchange
– establish TCP connection
– can then exchange data
• identification string exchange, algorithm negotiation,
key exchange, end of key exchange, service request
– using specified packet format
 SSH User Authentication Protocol
• authenticates client to server
• three message types:
– SSH_MSG_USERAUTH_REQUEST
– SSH_MSG_USERAUTH_FAILURE
– SSH_MSG_USERAUTH_SUCCESS
• authentication methods used
– public-key, password, host-based
 SSH Connection Protocol
• runs on SSH Transport Layer Protocol
• assumes secure authentication connection
• used for multiple logical channels
– SSH communications use separate channels
– either side can open with unique id number
– flow controlled
– have three stages:
• opening a channel, data transfer, closing a channel
– four types:
• session, x11, forwarded-tcpip, direct-tcpip.
 SSH
Connection
Protocol
Exchange
 Port Forwarding
• convert insecure TCP connection into a secure SSH connection
– SSH Transport Layer Protocol establishes a TCP connection
between SSH client & server
– client traffic redirected to local SSH, travels via tunnel,
then remote SSH delivers to server
• supports two types of port forwarding
– local forwarding – hijacks selected traffic
– remote forwarding – client acts for server