Network Security (IT 461)

IT 461 Network Security

Spring 2022

Chapter 5 - Transport-Level Security

2/20/2022 Chapter 5 2
 Web Security Considerations

• The World Wide Web is fundamentally a client/server application

running over the Internet and TCP/IP intranets
• The following characteristics of Web usage suggest the need for
tailored security tools:
• Web servers are relatively easy to configure and manage
• Web content is increasingly easy to develop
• The underlying software is extraordinarily complex
• May hide many potential security flaws

2/20/2022 Chapter 5 3
 Web Security Considerations

• A Web server can be exploited as a launching pad into the

corporation’s or agency’s entire computer complex
• Casual and untrained (in security matters) users are common clients for Web-
based services
• Such users are not necessarily aware of the security risks that exist
and do not have the tools or knowledge to take effective
countermeasures

2/20/2022 Chapter 5 4
 A Comparison of Threats on the Web

Threats Consequences Countermeasures

Integrity • Modification of user data • Loss of information Cryptographic check
• Trojan horse browser • Compromise of machine sums
• Modification of memory • Vulnerability to all other
• Modification of message threats
traffic in transit
Confidentiality • Eavesdropping on the net • Loss of information Encryption, Web
• Theft of info from server • Loss of privacy proxies
• Theft of data from client
• Info about network
configuration
• Info about which client talks to
server

2/20/2022 Chapter 5 5
 A Comparison of Threats on the Web
Threats Consequences Countermeasures

Denial of Service • Killing of user threads • Disruptive Difficult to prevent

• Flooding machine with • Annoying
bogus requests • Prevent user from getting
• Filling up disk or memory work done
• Isolating machine by DNS
attacks
Authentication • Impersonation of • Misrepresentation of user Cryptographic techniques
legitimate users • Belief that false
• Data forgery information is valid

2/20/2022 Chapter 5 6
 Relative Location of Security Facilities in the
TCP/IP Protocol Stack

2/20/2022 Chapter 5 7
 Secure Sockets Layer (SSL)

• One of the most widely used security services (in the past)
• A general purpose service implemented as a set of protocols that rely
on TCP
• Could be provided as part of the underlying protocol suite and therefore be
transparent to applications
• Can be embedded in specific packages

2/20/2022 Chapter 5 8
2/20/2022 Chapter 5 9
 Transport Layer Security (TLS)

• One of the most widely used security services

• Internet standard that evolved from a commercial protocol known as
Secure Sockets Layer (SSL).
• A general purpose service implemented as a set of protocols that rely
on TCP
• Could be provided as part of the underlying protocol suite and therefore be
transparent to applications
• Can be embedded in specific packages
• For example, most browsers come equipped with TLS, and most Web servers
have implemented the protocol.

2/20/2022 Chapter 5 10
 Transport Layer Security (TLS)

• An IETF standardization initiative whose goal is to produce an

Internet standard version of SSL
• Is defined as RFC 5246
• RFC 5246 is very similar to SSLv3

2/20/2022 Chapter 5 11
 Transport Layer Security (TLS)

• Differences include:
• Version number
• Message Authentication Code
• Pseudorandom function
• Alert keys
• Cipher suites
• Client certificate types
• Certificate_verify and Finished Messages
• Cryptographic computations
• Padding
2/20/2022 Chapter 5 12
 TLS Architecture

• TLS is designed to make use of TCP to provide a reliable end-to-end

secure service. TLS is not a single protocol but rather two layers of
protocols.
• The TLS 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 TLS.

2/20/2022 Chapter 5 13
 TLS Protocol Stack

2/20/2022 Chapter 5 14
 TLS Architecture

Three higher-layer protocols are defined as part of TLS:

• The Handshake Protocol.
• The Change Cipher Spec Protocol.
• The Alert Protocol.

oThese TLS specific protocols are used in the management of

TLS exchanges
oA fourth protocol, the Heartbeat Protocol

2/20/2022 Chapter 5 15
 TLS Architecture

Two important TLS concepts are:

• TLS connection
• A transport that provides a suitable type of service
• For TLS such connections are peer-to-peer relationships
• Connections are transient
• Every connection is associated with one session
• TLS session
• An association between a client and a server
• Created by the Handshake Protocol
• Define a set of cryptographic security parameters which can be shared
among multiple connections
• Are used to avoid the expensive negotiation of new security parameters
for each connection

2/20/2022 Chapter 5 16
 TLS Architecture

• Between any pair of parties (applications such as HTTP on client and

server), there may be multiple secure connections.
• In theory, there may also be multiple simultaneous sessions between
parties, but this feature is not used in practice.
• There are a number of states associated with each session.
• Once a session is established, there is a current operating state for
both read and write (i.e., receive and send).
• In addition, during the Handshake Protocol, pending read and
write states are created. Upon successful conclusion of the
Handshake Protocol, the pending states become the current states.

2/20/2022 Chapter 5 17
 A session state is defined by the following
parameters:
• 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 and a hash algorithm used for MAC
calculation; also defines cryptographic attributes such as the hash_size
• Master secret
• 48-byte secret shared between the client and the server
• Is resumable
• A flag indicating whether the session can be used to initiate new connections

2/20/2022 Chapter 5 18
 A connection state is defined by
the following parameters:
• 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
2/20/2022 Chapter 5 19
 A connection state is defined by
the following parameters:
• 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 TLS Handshake Protocol
• The final ciphertext block from each record is preserved for use as the IV with
the following record
• 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

2/20/2022 Chapter 5 20
 TLS Record Protocol

The TLS Record Protocol provides two services for TLS connections
• Confidentiality
• The Handshake Protocol defines a shared secret key that is used for conventional
encryption of TLS payloads
• Message integrity
• The Handshake Protocol also defines a shared secret key that is used to form a message
authentication code (MAC)

2/20/2022 Chapter 5 21
 TLS 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. Received data are decrypted, verified,
decompressed, and reassembled before being delivered to higher-level
users.
• The first step is fragmentation. Each upper-layer message is fragmented
into blocks of 214 bytes (16,384 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. TLS makes use of the HMAC algorithm defined
in RFC 2104.

2/20/2022 Chapter 5 22
 TLS Record Protocol

• 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
exceed 214 + 2048.
• For stream encryption, the compressed message plus the MAC are
encrypted. Note that the MAC is computed before encryption takes
place and that the MAC is then encrypted along with the plaintext or
compressed plaintext.

2/20/2022 Chapter 5 23
 TLS Record Protocol

• 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 the length of the padding. 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 cipher block length is 16 bytes (e.g., AES) and
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, 17, 33, and so on, up to 161. At a padding length of
161, the total length is 79 + 161 = 240. A variable padding length may
be used to frustrate attacks based on an analysis of the lengths of
exchanged messages.
2/20/2022 Chapter 5 24
 TLS Record Protocol

The final step of TLS Record Protocol processing is to prepend 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 TLS in use. For TLSv2,
the value is 3.
• Minor Version (8 bits): Indicates minor version in use. For TLSv2, the value
is 1.
• 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.

2/20/2022 Chapter 5 25
 TLS Record Protocol

• The content types that have been defined are

change_cipher_spec, alert, handshake, and application_data.
• The first three are the TLS specific protocols.
• Note that no distinction is made among the various applications (e.g.,
HTTP) that might use TLS; the content of the data created by such
applications is not clear to TLS.

2/20/2022 Chapter 5 26
 Change Cipher Spec Protocol

• The Change Cipher Spec Protocol is one of the four TLS-specific

protocols that use the TLS Record Protocol, and it is the simplest.
• 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.

2/20/2022 Chapter 5 27
 Alert Protocol

• The Alert Protocol is used to convey TLS-related alerts to the peer entity.
• As with other applications that use TLS, alert messages are compressed
and encrypted, as specified by the current state.
• Each message in this protocol consists of two bytes.
• The first byte takes the value warning (1) or fatal (2) to convey the severity
of the message.
• If the level is fatal, TLS 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.
2/20/2022 Chapter 5 28
 Alert Protocol

The following alerts are always fatal:

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

2/20/2022 Chapter 5 29
 Alert Protocol

• decryption_failed: A ciphertext decrypted in an invalid way; either it was

not an even multiple of the block length or its padding values, when
checked, were incorrect.
• record_overflow: A TLS record was received with a payload
(ciphertext) whose length exceeds 214 + 2048 bytes, or the ciphertext
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.

2/20/2022 Chapter 5 30
 Alert Protocol

• 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.
• export_restriction: A negotiation not in compliance with export
restrictions on key length was detected.
• 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.
2/20/2022 Chapter 5 31
 Alert Protocol

• internal_error: An internal error unrelated to the peer or the

correctness of the protocol makes it impossible to continue.
The remaining alerts are the following:
• 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.
• bad_certificate: A received certificate was corrupt (e.g., contained a
signature that did not verify).

2/20/2022 Chapter 5 32
 Alert Protocol

• 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.
• decrypt_error: A handshake cryptographic operation failed, including
being unable to verify a signature, decrypt a key exchange, or validate
a finished message.

2/20/2022 Chapter 5 33
 Alert Protocol

• user_canceled: This handshake is being canceled 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.

2/20/2022 Chapter 5 34
 TLS Record Protocol Operation

2/20/2022 Chapter 5 35
 TLS Record Format

2/20/2022 Chapter 5 36
 TLS Record Protocol Payload

2/20/2022 Chapter 5 37
 Handshake Protocol

• The most complex part of TLS 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 a TLS record.
• The Handshake Protocol is used before any application data is
transmitted.

2/20/2022 Chapter 5 38
 Handshake Protocol

The Handshake Protocol consists of a series of messages exchanged by

client and server. Each message has three fields:
• Type (1 byte): Indicates one of 10 messages. Table 6.2 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 6.2.

2/20/2022 Chapter 5 39
 TLS Handshake Protocol Message Types

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

2/20/2022 Chapter 5 40
 Handshake Protocol

The exchange can be viewed as having four phases.

• Phase 1. Establish Security Capabilities
• Phase 2. Server Authentication and Key Exchange
• Phase 3. Client Authentication and Key Exchange
• Phase 4. Finish

2/20/2022 Chapter 5 41
 Handshake Protocol Action

2/20/2022 Chapter 5 42
 Phase 1. Establish Security Capabilities

Phase 1 initiates a logical connection and establishes 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 TLS 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 to create a new connection on this session. A zero value indicates that
the client wishes to establish a new connection on a new session.
2/20/2022 Chapter 5 43
 Phase 1. Establish Security Capabilities

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

2/20/2022 Chapter 5 44
 Phase 1. Establish Security Capabilities

The first element of the Ciphersuite parameter is the key exchange method (i.e., the means by which the cryptographic keys
for conventional encryption and MAC are exchanged). The following key exchange methods are supported.
• RSA: The secret key is encrypted with the receiver’s RSA public key. A public-key certificate for the receiver’s key must be
made available.
• Fixed Diffie–Hellman: This is a Diffie–Hellman key exchange in which the server’s certificate contains the Diffie–Hellman
public parameters signed by the certificate authority (CA). That is, the public-key certificate contains the Diffie–Hellman
public-key parameters. The client provides its Diffie–Hellman public-key parameters either in a certificate, if client
authentication is required, or in a key exchange message. This method results in a fixed secret key between two peers
based on the Diffie–Hellman calculation using the fixed public keys.
• Ephemeral Diffie–Hellman: This technique is used to create ephemeral (temporary, one-time) secret keys. In this case, the
Diffie–Hellman public keys are exchanged and signed using the sender’s private RSA or DSS key. The receiver can use the
corresponding public key to verify the signature. Certificates are used to authenticate the public keys. This would appear
to be the most secure of the three Diffie–Hellman options because it results in a temporary, authenticated key.
• Anonymous Diffie–Hellman: The base Diffie–Hellman algorithm is used with no authentication. That is, each side sends its
public Diffie–Hellman parameters to the other with no authentication. This approach is vulnerable to man-in-the-middle
attacks, in which the attacker conducts anonymous Diffie–Hellman with both parties.

2/20/2022 Chapter 5 45
 Phase 1. Establish Security Capabilities

Following the definition of a key exchange method is the CipherSpec,

which includes the following fields:
• CipherAlgorithm: Any of the algorithms mentioned earlier: RC4, RC2, DES, 3DES,
DES40, or IDEA
• 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

2/20/2022 Chapter 5 46
 Phase 2. Server Authentication and Key
Exchange
• The server begins this phase by sending its certificate if it needs to
be authenticated; the message contains one or a chain of X.509
certificates.
• The certificate message is required for any agreed-on key exchange
method except anonymous Diffie–Hellman. Note that if fixed Diffie–
Hellman is used, this certificate message functions as the server’s key
exchange message because it contains the server’s public Diffie–
Hellman parameters.

2/20/2022 Chapter 5 47
 Phase 2. Server Authentication and Key
Exchange
• Next, a server_key_exchange message may be sent if it is required. It is not required in two
instances: (1) The server has sent a certificate with fixed Diffie–Hellman parameters; or (2) RSA
key exchange is to be used.
The server_key_exchange message is needed for the following:
• 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.

2/20/2022 Chapter 5 48
 Phase 2. Server Authentication and Key
Exchange
Next, a nonanonymous server (server not using anonymous Diffie–
Hellman) can request a certificate from the client. The
certificate_request message includes two parameters: certificate_type
and certificate_authorities.
The certificate type indicates the public-key algorithm and its use:
• 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

2/20/2022 Chapter 5 49
 Phase 2. Server Authentication and Key
Exchange
• The second parameter in the certificate_request message is a list of
the distinguished names of acceptable certificate authorities.
• The final message in phase 2, and one that is always required, is the
server_done message, which is 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.

2/20/2022 Chapter 5 50
 Phase 3. Client Authentication and Key
Exchange
• Upon receipt of the server_done message, the client should verify
that the server provided a valid certificate (if required) and check that
the server_hello parameters are acceptable. If all is satisfactory, the
client sends one or more messages back to the server.
• If the server has requested a certificate, the client begins this phase
by sending a certificate message. If no suitable certificate is available,
the client sends a no_certificate alert instead.

2/20/2022 Chapter 5 51
 Phase 3. Client Authentication and Key
Exchange
Next is the client_key_exchange message, which must be sent in this phase.
The content of the message depends on the type of key exchange, as follows:
• 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.

2/20/2022 Chapter 5 52
 Phase 4. Finish

• Phase 4 completes the setting up of a secure connection. The client sends a

change_cipher_spec message and copies the pending CipherSpec into the
current CipherSpec. Note that this message is not considered part of the
Handshake Protocol but is sent using the Change Cipher Spec Protocol. The
client then immediately sends the finished message under the new
algorithms, keys, and secrets.
• The finished message verifies that the key exchange
and authentication processes were successful.
• In response to these two messages, the server sends its own change_-
cipher_spec message, transfers the pending to the current CipherSpec, and
sends its finished message. At this point, the handshake is complete and
the client and server may begin to exchange application-layer data.

2/20/2022 Chapter 5 53
 Cryptographic Computations

• Two further items are of interest:

• The creation of a shared master secret by means of the key exchange
• The shared master secret is a one-time 48-byte value (384 bits) generated for this
session by means of secure key exchange

• The generation of cryptographic parameters from the master secret

• CipherSpecs require a client write MAC secret, a server write MAC secret, a client write
key, a server write key, a client write IV, and a server write IV which are generated from
the master secret in that order
• These parameters are generated from the master secret by hashing the master secret into a
sequence of secure bytes of sufficient length for all needed parameters

2/20/2022 Chapter 5 54
 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.
• 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.
• The data expansion function makes use of the HMAC algorithm with
either MD5 or SHA-1 as the underlying hash function.

2/20/2022 Chapter 5 55
 Pseudorandom Function

• P_hash can be iterated as many times as necessary to produce

the required quantity of data.

• For example, if P_SHA256 was used to generate 80 bytes of data, it

would have to be iterated three times (through A(3)), producing 96
bytes of data of which the last 16 would be discarded. In this case,
P_MD5 would have to be iterated four times, producing exactly 64
bytes of data. Note that each iteration involves two executions of
HMAC, each of which in turn involves two executions of the
underlying hash algorithm.

2/20/2022 Chapter 5 56
 TLS Function P_hash(secret, seed)

2/20/2022 Chapter 5 57
 Heartbeat Protocol

• Heartbeat is a periodic signal generated by hardware or software to

indicate normal operation or to synchronize other parts of a system.
• A heartbeat protocol is typically used to monitor the availability of a
protocol entity.
• The Heartbeat protocol runs on top of the TLS Record Protocol and consists
of two message types: heartbeat_request and heartbeat_response.
• The heartbeat serves two purposes. First, it assures the sender that the
recipient is still alive, even though there may not have been any activity
over the under-lying TCP connection for a while. Second, the heartbeat
generates activity across the connection during idle periods, which avoids
closure by a firewall that does not tolerate idle connections.

2/20/2022 Chapter 5 58
 SSL/TLS ATTACKS

• Since the first introduction of SSL in 1994, and the subsequent

standardization of TLS, numerous attacks have been devised against
these protocols.
• The appearance of each attack has necessitated changes in the
protocol, the encryption tools used, or some aspect of the
implementation of SSL and TLS to counter these threats.

2/20/2022 Chapter 5 59
 SSL/TLS ATTACKS

We can group the attacks into four general categories:

• Attacks on the handshake protocol
• Attacks on the record and application data protocols
• Attacks on the PKI
• Other attacks

2/20/2022 Chapter 5 60
 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
• A user of a Web browser will see URL addresses that begin with https:// rather than
http://
• Its use depends on the Web server supporting HTTPS communication. For example,
some search engines do not support HTTPS.
• A normal HTTP connection uses port [Link] HTTPS is specified, port 443 is used, which
invokes SSL
• Documented in RFC 2818, HTTP Over TLS
• There is no fundamental change in using HTTP over either SSL or TLS and both implementations
are referred to as HTTPS

2/20/2022 Chapter 5 61
 HTTPS (HTTP over 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
• Cookies sent from browser to server and from server to browser
• Contents of HTTP header

2/20/2022 Chapter 5 62
 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 ClientHello 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 may also 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
• 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

2/20/2022 Chapter 5 63
 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.
• 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
• 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”

• An unannounced TCP closure could be evidence of some sort of attack so the

HTTPS client should issue some sort of security warning when this occurs

2/20/2022 Chapter 5 64
 Secure Shell (SSH)

• A protocol for secure network communications designed to be relatively

simple and inexpensive to implement
• The initial version, SSH1 was focused on providing a secure remote logon
facility to replace TELNET and other remote logon schemes that provided
no security
• SSH also provides a more general client/server capability and can be used
for such network functions as file transfer and e-mail
• SSH2 fixes a number of security flaws in the original scheme
• Is documented as a proposed standard in IETF RFCs 4250 through 4256
• SSH client and server applications are widely available for most operating
systems
• Has become the method of choice for remote login and X tunneling
• Is rapidly becoming one of the most pervasive applications for encryption technology
outside of embedded systems
2/20/2022 Chapter 5 65
 SSH Protocol Stack

2/20/2022 Chapter 5 66
 Secure Shell (SSH)

SSH is organized as three protocols that typically run on top of TCP:

• Transport Layer Protocol: Provides server authentication, data
confidentiality, and data integrity with forward secrecy (i.e., if a key is
compromised during one session, the knowledge does not affect the
security of earlier sessions). The transport layer may optionally
provide compression.
• User Authentication Protocol: Authenticates the user to the server.
• Connection Protocol: Multiplexes multiple logical communications
channels over a single, underlying SSH connection.

2/20/2022 Chapter 5 67
 Transport Layer Protocol

• Server authentication occurs at the transport layer, based on the server possessing a
public/private key pair
• A server may have multiple host keys using multiple different asymmetric encryption
algorithms
• Multiple hosts may share the same host key
• The server host key is used during key exchange to authenticate the identity of the
host
• RFC 4251 dictates two alternative trust models:
• The client has a local database that associates each host name with the corresponding public
host key
• The host name-to-key association is certified by a trusted certification authority (CA); the
client only knows the CA root key and can verify the validity of all host keys certified by
accepted CAs

2/20/2022 Chapter 5 68
 Packet Exchange

• The sequence of events in the SSH Transport Layer Protocol.

• First, the client establishes a TCP connection to the server. This is
done via the TCP protocol and is not part of the Transport
Layer Protocol.

2/20/2022 Chapter 5 69
 SSH
Transport
Layer
Protocol
Packet
Exchanges

2/20/2022 Chapter 5 70
 Packet Exchange

Once the connection is established, the client and server exchange

data, referred to as packets, in the data field of a TCP segment. Each
packet is in the following format:
• Packet length: Length of the packet in bytes, not including the packet
length and MAC fields.
• Padding length: Length of the random padding field.
• Payload: Useful contents of the packet. Prior to algorithm
negotiation, this field is uncompressed. If compression is negotiated,
then in subsequent packets, this field is compressed.

2/20/2022 Chapter 5 71
 Packet Exchange

• Random padding: Once an encryption algorithm has been

negotiated, this field is added. It contains random bytes of padding so
that the total length of the packet (excluding the MAC field) is a
multiple of the cipher block size, or 8 bytes for a stream cipher.
• Message authentication code (MAC): If message authentication has
been negotiated, this field contains the MAC value. The MAC value is
computed over the entire packet plus a sequence number, excluding
the MAC field. The sequence number is an implicit 32-bit packet
sequence that is initialized to zero for the first packet and
incremented for every packet. The sequence number is not included
in the packet sent over the TCP connection.

2/20/2022 Chapter 5 72
 SSH Transport Layer Protocol Packet
Formation

2/20/2022 Chapter 5 73
SSH Transport
Layer
Cryptographic
Algorithms

2/20/2022 Chapter 5 74
 Authentication Methods

• Publickey
• The client sends a message to the server that contains the client’s public key, with
the message signed by the client’s private key
• When the server receives this message, it checks whether the supplied key is
acceptable for authentication and, if so, it checks whether the signature is correct
• Password
• The client sends a message containing a plaintext password, which is protected by
encryption by the Transport Layer Protocol
• Hostbased
• Authentication is performed on the client’s host rather than the client itself
• This method works by having the client send a signature created with the private key
of the client host
• Rather than directly verifying the user’s identity, the SSH server verifies the identity
of the client host

2/20/2022 Chapter 5 75
 Connection Protocol

• The SSH Connection Protocol runs on top of the SSH Transport Layer Protocol and
assumes that a secure authentication connection is in use
• The secure authentication connection, referred to as a tunnel, is used by the Connection
Protocol to multiplex a number of logical channels

• Channel mechanism
• All types of communication using SSH are supported using separate channels
• Either side may open a channel
• For each channel, each side associates a unique channel number
• Channels are flow controlled using a window mechanism
• No data may be sent to a channel until a message is received to indicate that window space is
available
• The life of a channel progresses through three stages: opening a channel, data transfer, and
closing a channel

2/20/2022 Chapter 5 76
Example of
SSH
Connection
Protocol
Message
Exchange

2/20/2022 Chapter 5 77
 Channel Types

• Four channel types are recognized in the SSH Connection Protocol

specification
• Session
• The remote execution of a program
• The program may be a shell, an application such as file transfer or e-mail, a system command,
or some built-in subsystem
• Once a session channel is opened, subsequent requests are used to start the remote program
• X11
• Refers to the X Window System, a computer software system and network protocol that
provides a graphical user interface (GUI) for networked computers
• X allows applications to run on a network server but to be displayed on a desktop machine
• Forwarded-tcpip
• Remote port forwarding
• Direct-tcpip
• Local port forwarding

2/20/2022 Chapter 5 78
 Port Forwarding

• One of the most useful features of SSH

• Provides the ability to convert any insecure TCP connection into a
secure SSH connection (also referred to as SSH tunneling)
• A port is an identifier of a user of TCP. So, any application that runs on
top of TCP has a port number.
• Incoming TCP traffic is delivered to the appropriate application on
the basis of the port number (a port is an identifier of a user of TCP)

2/20/2022 Chapter 5 79
 Port Forwarding

• An application may employ multiple port numbers

• For example, for the Simple Mail Transfer Protocol (SMTP), the server
side generally listens on port 25, so an incoming SMTP request uses
TCP and addresses the data to destination port 25. TCP recognizes
that this is the SMTP server address and routes the data to the SMTP
server application.

2/20/2022 Chapter 5 80
SSH Transport
Layer Packet
Exchanges

2/20/2022 Chapter 5 81
 Summary

• Web security considerations

• Web security threats
• Web traffic security approaches

• Transport Layer Security

• TLSarchitecture
• TLSrecord protocol
• Change cipher spec protocol
• Alert protocol
• Handshake protocol
• Cryptographic computations

• HTTPS
• Connection initiation
• Connection closure

2/20/2022 Chapter 5 82
 Summary

• Secure shell (SSH)

• Transport layer protocol
• User authentication protocol
• Communication protocol

2/20/2022 Chapter 5 83
2/20/2022 Chapter 5 84
 Reference
• Stallings, W. "Network Security Essentials: Applications and
Standards." (2013).

2/20/2022 Chapter 5 85