W6NS
Network Security Essentials: Applications and Standards
Sixth Edition
Chapter 6
Transport-Level Security
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
If this PowerPoint presentation contains mathematical equations, you may need to check that your computer has the following installed:
1) MathType Plugin
2) Math Player (free versions available)
3) NVDA Reader (free versions available)
The topic of Web security is a broad one and can easily fill a book. In this chapter,
we begin with a discussion of the general requirements for Web security and then focus
on three standardized schemes that are becoming increasingly important as part of Web
commerce and that focus on security at the transport layer: SSL/TLS, HTTPS, and SSH.
Web Security Considerations
The World Wide Web is fundamentally a client/server application running over the Internet and T C P/I P 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
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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
The World Wide Web is fundamentally a client/server application running over the
Internet and TCP/IP intranets. As such, the security tools and approaches discussed
so far in this book are relevant to the issue of Web security. However, the following
characteristics of Web usage suggest the need for tailored security tools:
• Although Web browsers are very easy to use, Web servers are relatively easy
to configure and manage, and Web content is increasingly easy to develop, the
underlying software is extraordinarily complex. This complex software may
hide many potential security flaws. The short history of the Web is filled with
examples of new and upgraded systems, properly installed, that are vulnerable
to a variety of security attacks.
• A Web server can be exploited as a launching pad into the corporation’s or
agency’s entire computer complex. Once the Web server is subverted, an attacker
may be able to gain access to data and systems not part of the Web
itself but connected to the server at the local site.
• 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
Table 6-1 A Comparison of Threats on the Web (1 of 2)
| Blank | Threats | Consequences | Countermeasures |
| Integrity | Modification of user data Trojan horse browser Modification of memory Modification of message traffic in transit | Loss of information Compromise of machine Vulnerability to all other threats | Cryptographic checksums |
| Confidentiality | Eavesdropping on the net Theft of info from server Theft of data from client Info about network configuration Info about which client talks to server | Loss of information Loss of privacy | Encryption, Web proxies |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Table 6.1 provides a summary of the types of security threats faced when using
the Web. One way to group these threats is in terms of passive and active attacks.
Passive attacks include eavesdropping on network traffic between browser and
server and gaining access to information on a Web site that is supposed to be restricted.
Active attacks include impersonating another user, altering messages in
transit between client and server, and altering information on a Web site.
Another way to classify Web security threats is in terms of the location of the
threat: Web server, Web browser, and network traffic between browser and server.
Issues of server and browser security fall into the category of computer system security;
Part Six of this book addresses the issue of system security in general but is also
applicable to Web system security. Issues of traffic security fall into the category of
network security and are addressed in this chapter.
Table 6-1 A Comparison of Threats on the Web (2 of 2)
| Blank | Threats | Consequences | Countermeasures |
| Denial of Service | Killing of user threads Flooding machine with bogus requests Filling up disk or memory Isolating machine by D N S attacks | Disruptive Annoying Prevent user from getting work done | Difficult to prevent |
| Authentication | Impersonation of legitimate users Data forgery | Misrepresentation of user Belief that false information is valid | Cryptographic techniques |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Table 6.1 provides a summary of the types of security threats faced when using
the Web. One way to group these threats is in terms of passive and active attacks.
Passive attacks include eavesdropping on network traffic between browser and
server and gaining access to information on a Web site that is supposed to be restricted.
Active attacks include impersonating another user, altering messages in
transit between client and server, and altering information on a Web site.
Another way to classify Web security threats is in terms of the location of the
threat: Web server, Web browser, and network traffic between browser and server.
Issues of server and browser security fall into the category of computer system security;
Part Six of this book addresses the issue of system security in general but is also
applicable to Web system security. Issues of traffic security fall into the category of
network security and are addressed in this chapter.
Figure 6-1 Relative Location of Security Facilities in the T C P/I P Protocol Stack
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
A number of approaches to providing Web security are possible. The various approaches
that have been considered are similar in the services they provide and, to
some extent, in the mechanisms that they use, but they differ with respect to their
scope of applicability and their relative location within the TCP/IP protocol stack.
Figure 6.1 illustrates this difference. One way to provide Web security is
to use IP security (IPsec) (Figure 6.1a). The advantage of using IPsec is that it is
transparent to end users and applications and provides a general-purpose solution.
Furthermore, IPsec includes a filtering capability so that only selected traffic need
incur the overhead of IPsec processing.
Another relatively general-purpose solution is to implement security just
above TCP (Figure 6.1b). The foremost example of this approach is the Secure
Sockets Layer (SSL) and the follow-on Internet standard known as Transport
Layer Security (TLS). At this level, there are two implementation choices. For full
generality, SSL (or TLS) could be provided as part of the underlying protocol suite
and therefore be transparent to applications. Alternatively, SSL can be embedded
in specific packages. For example, Netscape and Microsoft Explorer browsers come
equipped with SSL, and most Web servers have implemented the protocol.
Application-specific security services are embedded within the particular
application. Figure 6.1c shows examples of this architecture. The advantage of this
approach is that the service can be tailored to the specific needs of a given application.
5
Transport Layer security (T S L)
One of the most widely used security services
T L S is an Internet standard that evolved from a commercial protocol known as Secure Sockets Layer (S S L)
T L S is a general purpose service implemented as a set of protocols that rely on T C P
T L S could be provided as part of the underlying protocol suite and therefore be transparent to applications
Alternatively, T L S can be embedded in specific packages
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
6
One of the most widely used security services is Transport Layer Security (TSL) ;
the current version is Version 1.2, defined in RFC 5246. TLS is an Internet standard
that evolved from a commercial protocol known as Secure Sockets Layer
(SSL) . Although SSL implementations are still around, it has been deprecated by
IETF and is disabled by most corporations offering TLS software. TLS is a general-purpose
service implemented as a set of protocols that rely on TCP. At this level,
there are two implementation choices. For full generality, TLS could be provided
as part of the underlying protocol suite and therefore be transparent to applications.
Alternatively, TLS can be embedded in specific packages. For example, most
browsers come equipped with TLS, and most Web servers have implemented the
protocol.
Figure 6-2 S S L/T L S Protocol Stack
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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, as illustrated in
Figure 6.2.
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. Three higher-layer protocols are defined as part of TLS: the Handshake
Protocol; the Change Cipher Spec Protocol; and the Alert Protocol. These TLS specific
protocols are used in the management of TLS exchanges and are examined
later in this section. A fourth protocol, the Heartbeat Protocol, is defined in a separate
RFC and is also discussed subsequently in this section.
7
T L S Architecture (1 of 2)
Two important T L S concepts are
T L S connection
A transport that provides a suitable type of service
For T L S such connections are peer-to-peer relationships
Connections are transient
Every connection is associated with one session
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
8
Two important TLS concepts are the TLS session and the TLS connection,
which are defined in the specification as follows:
■ Connection: A connection is a transport (in the OSI layering model definition)
that provides a suitable type of service. For TLS, such connections are peer-to-peer
relationships. The connections are transient. Every connection is associated
with one session.
■ Session: A TLS 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.
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.
T L S Architecture (2 of 2)
T L S 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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
9
Two important TLS concepts are the TLS session and the TLS connection,
which are defined in the specification as follows:
■ Connection: A connection is a transport (in the OSI layering model definition)
that provides a suitable type of service. For TLS, such connections are peer-to-peer
relationships. The connections are transient. Every connection is associated
with one session.
■ Session: A TLS 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.
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.
A Session State Is Defined by the Following Parameters: (1 of 2)
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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
10
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 (such as null, AES,
etc.) and a hash algorithm (such as MD5 or SHA-1) used for MAC calcula tion.
It 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.
A Session State Is Defined by the Following Parameters: (2 of 2)
Cipher spec
Specifies the bulk data encryption algorithm and a hash algorithm used for M A C 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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
11
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 (such as null, AES,
etc.) and a hash algorithm (such as MD5 or SHA-1) used for MAC calcula tion.
It 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.
A Connection State is Defined by the Following Parameters: (1 of 3)
Server and client random
Byte sequences that are chosen by the server and client for each connection
Server write M A C secret
The secret key used in M A C operations on data sent by the server
Client write M A C secret
The secret key used in M A C operations on data sent by the client
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
12
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.
• 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. Thereafter, 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.
A Connection State is Defined by the Following Parameters: (2 of 3)
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 C B C mode is used, an initialization vector (IV) is maintained for each key
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
13
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.
• 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. Thereafter, 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.
A Connection State is Defined by the Following Parameters: (3 of 3)
This field is first initialized by the S S L 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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
14
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.
• 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. Thereafter, 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.
T L S Record Protocol
The T L S Record Protocol provides two services for T L S connections
Confidentiality
The Handshake Protocol defines a shared secret key that is used for conventional encryption of T L S payloads
Message integrity
The Handshake Protocol also defines a shared secret key that is used to form a message authentication code (M A C)
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
15
TLS Record Protocol defines 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)
Figure 6-3 T L S Record Protocol Operation
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 6.3 indicates the overall operation of the 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 (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. In TLSv2 no compression algorithm
is specified, so the default compression algorithm is null.
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.
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.
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.
16
Figure 6-4 S S L Record Format
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 6.4 illustrates the TLS record format.
17
Figure 6-5 T L S Record Protocol Payload
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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 (Figure 6.5a), 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.
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 (Figure 6.5b). 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.
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.
The Handshake Protocol consists of a series of messages exchanged by client
and server. All of these have the format shown in Figure 6.5c.
18
Table 6-2 T L S 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 |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Each message has
three fields:
• Type (1 byte): Indicates one of ten 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.
Figure 6-6 Handshake Protocol Action
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 6.6 shows the initial exchange needed to establish a logical connection
between client and server. The exchange can be viewed as having four phases.
20
Cryptographic Computations (1 of 2)
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 generated for this session by means of secure key exchange
The generation of cryptographic parameters from the master secret
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
21
Two further items are of interest: (1) the creation of a shared master secret by means
of the key exchange and (2) the generation of cryptographic parameters from the
master secret.
The shared master secret is a one-time 48-byte value
(384 bits) generated for this session by means of secure key exchange. The creation
is in two stages. First, a pre_master_secret is exchanged. Second, the master_
secret is calculated by both parties. For pre_master_secret exchange, there
are two possibilities.
• RSA: A 48-byte pre_master_secret is generated by the client, encrypted
with the server’s public RSA key, and sent to the server. The server decrypts
the ciphertext using its private key to recover the pre_master_secret.
• Diffie-Hellman: Both client and server generate a Diffie-Hellman public key.
After these are exchanged, each side performs
Cryptographic Computations (2 of 2)
CipherSpecs require a client write M A C secret, a server write M A C 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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
22
Two further items are of interest: (1) the creation of a shared master secret by means
of the key exchange and (2) the generation of cryptographic parameters from the
master secret.
The shared master secret is a one-time 48-byte value
(384 bits) generated for this session by means of secure key exchange. The creation
is in two stages. First, a pre_master_secret is exchanged. Second, the master_
secret is calculated by both parties. For pre_master_secret exchange, there
are two possibilities.
• RSA: A 48-byte pre_master_secret is generated by the client, encrypted
with the server’s public RSA key, and sent to the server. The server decrypts
the ciphertext using its private key to recover the pre_master_secret.
• Diffie-Hellman: Both client and server generate a Diffie-Hellman public key.
After these are exchanged, each side performs
Figure 6-7 T L S Function P_hash (Secret, Seed)
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
The PRF is based on the data expansion function (Figure 6.7)
23
Heartbeat Protocol (1 of 2)
A 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 T L S Record Protocol
Consists of two message types: heartbeat request and heartbeat response
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
In the context of computer networks, a 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. In the specific case of TLS, a Heartbeat protocol was defined in 2012 in
RFC 6250 (Transport Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) Heartbeat Extension ).
The Heartbeat protocol runs on top of the TLS Record Protocol and consists
of two message types: heartbeat_request and heartbeat_response .
The use of the Heartbeat protocol is established during Phase 1 of the Handshake
protocol (Figure 6.6). Each peer indicates whether it supports heartbeats. If heartbeats
are supported, the peer indicates whether it is willing to receive heartbeat_request
messages and respond with heartbeat_response messages or only
willing to send heartbeat_request messages.
A heartbeat_request message can be sent at any time. Whenever a request
message is received, it should be answered promptly with a corresponding
heartbeat_response message. The heartbeat_request message includes
payload length, payload, and padding fields. The payload is a random content
between 16 bytes and 64 Kbytes in length. The corresponding heartbeat_response
message must include an exact copy of the received payload. The padding
is also random content. The padding enables the sender to perform a path
MTU (maximum transfer unit) discovery operation, by sending requests with increasing
padding until there is no answer anymore, because one of the hosts on
the path cannot handle the message.
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 underlying
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.
The requirement for the exchange of a payload was designed into the Heartbeat
protocol to support its use in a connectionless version of TLS known as Datagram
Transport Layer Security (DTLS). Because a connectionless service is subject
to packet loss, the payload enables the requestor to match response messages to
request messages. For simplicity, the same version of the Heartbeat protocol is used
with both TLS and DTLS. Thus, the payload is required for both TLS and DTLS.
Heartbeat Protocol (2 of 2)
The heartbeat serves two purposes:
It assures the sender that the recipient is still alive, even though there may not have been any activity over the underlying T C P connection
It generates activity across the connection during idle periods, which avoids closure by a firewall that does not tolerate idle connections
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
In the context of computer networks, a 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. In the specific case of TLS, a Heartbeat protocol was defined in 2012 in
RFC 6250 (Transport Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) Heartbeat Extension ).
The Heartbeat protocol runs on top of the TLS Record Protocol and consists
of two message types: heartbeat_request and heartbeat_response .
The use of the Heartbeat protocol is established during Phase 1 of the Handshake
protocol (Figure 6.6). Each peer indicates whether it supports heartbeats. If heartbeats
are supported, the peer indicates whether it is willing to receive heartbeat_request
messages and respond with heartbeat_response messages or only
willing to send heartbeat_request messages.
A heartbeat_request message can be sent at any time. Whenever a request
message is received, it should be answered promptly with a corresponding
heartbeat_response message. The heartbeat_request message includes
payload length, payload, and padding fields. The payload is a random content
between 16 bytes and 64 Kbytes in length. The corresponding heartbeat_response
message must include an exact copy of the received payload. The padding
is also random content. The padding enables the sender to perform a path
MTU (maximum transfer unit) discovery operation, by sending requests with increasing
padding until there is no answer anymore, because one of the hosts on
the path cannot handle the message.
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 underlying
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.
The requirement for the exchange of a payload was designed into the Heartbeat
protocol to support its use in a connectionless version of TLS known as Datagram
Transport Layer Security (DTLS). Because a connectionless service is subject
to packet loss, the payload enables the requestor to match response messages to
request messages. For simplicity, the same version of the Heartbeat protocol is used
with both TLS and DTLS. Thus, the payload is required for both TLS and DTLS.
S S L/T L S Attacks
Attack categories
Attacks on the handshake protocol
Attacks on the record and application data protocols
Attacks on the P K I
Other attacks
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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.
Attack Categories We can group the attacks into four general categories:
■ Attacks on the handshake protocol: As early as 1998, an approach to compromising
the handshake protocol based on exploiting the formatting and
implementation of the RSA encryption scheme was presented [BLEI98]. As
countermeasures were implemented the attack was refined and adjusted to not
only thwart the countermeasures but also speed up the attack [e.g., BARD12].
■ Attacks on the record and application data protocols: A number of vulnerabilities
have been discovered in these protocols, leading to patches to counter the
new threats. As a recent example, in 2011, researchers Thai Duong and Juliano
Rizzo demonstrated a proof of concept called BEAST (Browser Exploit Against
SSL/TLS) that turned what had been considered only a theoretical vulnerability
into a practical attack [GOOD11]. BEAST leverages a type of cryptographic
attack called a chosen-plaintext attack. The attacker mounts the attack by
choosing a guess for the plaintext that is associated with a known ciphertext. The
researchers developed a practical algorithm for launching successful attacks.
Subsequent patches were able to thwart this attack. The authors of the BEAST
attack are also the creators of the 2012 CRIME (Compression Ratio Info-leak
Made Easy) attack, which can allow an attacker to recover the content of web
cookies when data compression is used along with TLS [GOOD12]. When used
to recover the content of secret authentication cookies, it allows an attacker to
perform session hijacking on an authenticated web session.
■ Attacks on the PKI: Checking the validity of X.509 certificates is an activity
subject to a variety of attacks, both in the context of SSL/TLS and elsewhere.
For example, [GEOR12] demonstrated that commonly used libraries for
SSL/TLS suffer from vulnerable certificate validation implementations. The
authors revealed weaknesses in the source code of OpenSSL, GnuTLS, JSSE,
ApacheHttpClient, Weberknecht, cURL, PHP, Python and applications built
upon or with these products.
■ Other attacks: [MEYE13] lists a number of attacks that do not fit into any of
the preceding categories. One example is an attack announced in 2011 by the
German hacker group The Hackers Choice, which is a DoS attack [KUMA11].
The attack creates a heavy processing load on a server by overwhelming the
target with SSL/TLS handshake requests. Boosting system load is done by
establishing new connections or using renegotiation. Assuming that the majority
of computation during a handshake is done by the server, the attack creates
more system load on the server than on the source device, leading to a DoS.
The server is forced to continuously recompute random numbers and keys.
The history of attacks and countermeasures for SSL/TLS is representative of
that for other Internet-based protocols. A “perfect” protocol and a “perfect” implementation
strategy are never achieved. A constant back-and-forth between threats
and countermeasures determines the evolution of Internet-based protocols.
H T T P S (H T T P over S S L) (1 of 2)
Refers to the combination of H T T P and S S L to implement secure communication between a Web browser and a Web server
The H T T P S capability is built into all modern Web browsers
A user of a Web browser will see U R L addresses that begin with https:// rather than http://
If H T T P S is specified, port 443 is used, which invokes S S L
Documented in R F C 2818, H T T P Over T L S
There is no fundamental change in using H T T P over either S S L or T L S and both implementations are referred to as H T T P S
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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, some
search engines do not support HTTPS. Google provides HTTPS as an option:
https://google.com.
The principal difference seen by a user of a Web browser is that URL (uniform
resource locator) 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
HTTPS is 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.
H T T P S (H T T P over S S L) (2 of 2)
When H T T P S 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 H T T P header
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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, some
search engines do not support HTTPS. Google provides HTTPS as an option:
https://google.com.
The principal difference seen by a user of a Web browser is that URL (uniform
resource locator) 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
HTTPS is 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.
Connection Initiation (1 of 3)
For H T T P S, the agent acting as the H T T P client also acts as the T L S client
The client initiates a connection to the server on the appropriate port and then sends the T L S Client Hello to begin the T L S handshake
When the T L S handshake has finished, the client may then initiate the first H T T P request
All H T T P data is to be sent as T L S application data
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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. Normal HTTP behavior, including 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. 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. As we have seen, 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 Initiation (2 of 3)
There are three levels of awareness of a connection in H T T P S:
At the H T T P level, an H T T P client requests a connection to an H T T P server by sending a connection request to the next lowest layer
Typically the next lowest layer is T C P, but it may also be T L S/S S L
At the level of T L S, a session is established between a T L S client and a T L S server
This session can support one or more connections at any time
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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. Normal HTTP behavior, including 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. 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. As we have seen, 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 Initiation (3 of 3)
A T L S request to establish a connection begins with the establishment of a T C P connection between the T C P entity on the client side and the T C P entity on the server side
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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. Normal HTTP behavior, including 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. 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. As we have seen, 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 (1 of 2)
An H T T P client or server can indicate the closing of a connection by including the line Connection: close in an H T T P record
The closure of an H T T P S connection requires that T L S close the connection with the peer T L S entity on the remote side, which will involve closing the underlying T C P connection
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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”. Note that an implementation that does this may choose to reuse the session.
This should only be done when the application knows (typically through detecting
HTTP message boundaries) that it has received all the message data that it
cares about.
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. However, the 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.
Connection Closure (2 of 2)
T L S implementations must initiate an exchange of closure alerts before closing a connection
A T L S 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 T C P closure could be evidence of some sort of attack so the H T T P S client should issue some sort of security warning when this occurs
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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”. Note that an implementation that does this may choose to reuse the session.
This should only be done when the application knows (typically through detecting
HTTP message boundaries) that it has received all the message data that it
cares about.
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. However, the 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.
Secure Shell (S S H)
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Secure Shell (SSH) is 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. A new version, SSH2, fixes a number of security flaws in the
original scheme. SSH2 is documented as a proposed standard in IETF RFCs 4250
through 4256.
SSH client and server applications are widely available for most operating systems.
It has become the method of choice for remote login and X tunneling and is
rapidly becoming one of the most pervasive applications for encryption technology
outside of embedded systems.
34
Figure 6-8 S S H Protocol Stack
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
SSH is organized as three protocols that typically run on top of TCP
(Figure 6.8):
• 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.
35
Transport Layer Protocol (1 of 2)
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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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. In any case, the server host key is used during key exchange to authenticate
the identity of the host. For this to be possible, the client must have a
prior knowledge of the server’s public host key. RFC 4251 dictates two alternative
trust models that can be used:
1. The client has a local database that associates each host name (as typed by
the user) with the corresponding public host key. This method requires no
centrally administered infrastructure and no third-party coordination. The
downside is that the database of name-to-key associations may become burdensome
to maintain.
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. This alternative eases the maintenance
problem, since ideally, only a single CA key needs to be securely stored
on the client. On the other hand, each host key must be appropriately certified
by a central authority before authorization is possible.
Transport Layer Protocol (2 of 2)
R F C 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 (C A); the client only knows the C A root key and can verify the validity of all host keys certified by accepted C As
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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. In any case, the server host key is used during key exchange to authenticate
the identity of the host. For this to be possible, the client must have a
prior knowledge of the server’s public host key. RFC 4251 dictates two alternative
trust models that can be used:
1. The client has a local database that associates each host name (as typed by
the user) with the corresponding public host key. This method requires no
centrally administered infrastructure and no third-party coordination. The
downside is that the database of name-to-key associations may become burdensome
to maintain.
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. This alternative eases the maintenance
problem, since ideally, only a single CA key needs to be securely stored
on the client. On the other hand, each host key must be appropriately certified
by a central authority before authorization is possible.
Figure 6-9 S S H Transport Layer Protocol Packet Exchanges
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 6.9 illustrates 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. Once the connection is established, the client and server exchange data,
referred to as packets, in the data field of a TCP segment.
38
Figure 6-10 S S H Transport Layer Protocol Packet Formation
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Each packet is in the following
format (Figure 6.10).
• 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.
• Random padding: Once an encryption algorithm has been negotiated, this
field is added. It contains random bytes of padding so that that 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.
Once an encryption algorithm has been negotiated, the entire packet (excluding
the MAC field) is encrypted after the MAC value is calculated.
The SSH Transport Layer packet exchange consists of a sequence of steps
(Figure 6.9).
39
Table 6-3 S S H Transport Layer Cryptographic Algorithms (1 of 4)
| Cipher | Cipher |
| 3des-cbc* | Three-key 3D E S in C B C mode |
| blowfish-cbc | Blowfish in C B C mode |
| twofish256-cbc | Two fish in C B C mode with a 256-bit key |
| twofish192-cbc | Two fish with a 192-bit key |
| twofish128-cbc | Two fish with a 128-bit key |
| aes256-cbc | A E S in C B C mode with a 256-bit key |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
* = Required
** = Recommended
Table 6.3
shows the allowable options for encryption, MAC, and compression. For each category,
the algorithm chosen is the first algorithm on the client’s list that is also supported
by the server.
40
Table 6-3 S S H Transport Layer Cryptographic Algorithms (2 of 4)
| Cipher | Cipher |
| aes192-cbc | A E S with a 192-bit key |
| aes128-cbc** | A E S with a 128-bit key |
| Serpent256-cbc | Serpent in C B C mode with a 256-bit key |
| Serpent192-cbc | Serpent with a 192-bit key |
| Serpent128-cbc | Serpent with a 128-bit key |
| arcfour | R C4 with a 128-bit key |
| cast128-cbc | C A S T-128 in C B C mode |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
* = Required
** = Recommended
Table 6.3
shows the allowable options for encryption, MAC, and compression. For each category,
the algorithm chosen is the first algorithm on the client’s list that is also supported
by the server.
41
Table 6-3 S S H Transport Layer Cryptographic Algorithms (3 of 4)
| MAC Algorithm | M A C Algorithm |
| hmac-sha1* | H M A C-S H A1; digest length = key length = 20 |
| hmac-sha1-96** | First 96 bits of H M A C S H A1; digest length = 12; key length = 20 |
| hmac-md5 | H M A C-M D5; digest length = key length = 16 |
| hmac-md5-96 | First 96 bits of H M A C-M D5; digest length = 12; key length = 16 |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
* = Required
** = Recommended
Table 6.3
shows the allowable options for encryption, MAC, and compression. For each category,
the algorithm chosen is the first algorithm on the client’s list that is also supported
by the server.
42
Table 6-3 S S H Transport Layer Cryptographic Algorithms (4 of 4)
| Compression algorithm | Compression algorithm |
| none* | No compression |
| zlib | Defined in R F C 1950 and R F C 1951 |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
* = Required
** = Recommended
Table 6.3
shows the allowable options for encryption, MAC, and compression. For each category,
the algorithm chosen is the first algorithm on the client’s list that is also supported
by the server.
43
Authentication Methods (1 of 2)
Public key
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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
The server may require one or more of the following
authentication methods.
• publickey: The details of this method depend on the public-key algorithm
chosen. In essence, 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. Thus, a host that supports multiple clients would provide authentication
for all its clients. This method works by having the client send a signature
created with the private key of the client host. Thus, rather than directly
verifying the user’s identity, the SSH server verifies the identity of the client
host—and then believes the host when it says the user has already authenticated
on the client side.
Authentication Methods (2 of 2)
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 S S H server verifies the identity of the client host
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
The server may require one or more of the following
authentication methods.
• publickey: The details of this method depend on the public-key algorithm
chosen. In essence, 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. Thus, a host that supports multiple clients would provide authentication
for all its clients. This method works by having the client send a signature
created with the private key of the client host. Thus, rather than directly
verifying the user’s identity, the SSH server verifies the identity of the client
host—and then believes the host when it says the user has already authenticated
on the client side.
Connection Protocol (1 of 2)
The S S H Connection Protocol runs on top of the S S H 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 S S H are supported using separate channels
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
The SSH Connection Protocol runs on top of the SSH Transport Layer Protocol
and assumes that a secure authentication connection is in use. That secure authentication
connection, referred to as a tunnel, is used by the Connection Protocol to
multiplex a number of logical channels.
All types of communication using SSH, such as a terminal
session, are supported using separate channels. Either side may open a channel. For
each channel, each side associates a unique channel number, which need not be the
same on both ends. 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.
Connection Protocol (2 of 2)
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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
The SSH Connection Protocol runs on top of the SSH Transport Layer Protocol
and assumes that a secure authentication connection is in use. That secure authentication
connection, referred to as a tunnel, is used by the Connection Protocol to
multiplex a number of logical channels.
All types of communication using SSH, such as a terminal
session, are supported using separate channels. Either side may open a channel. For
each channel, each side associates a unique channel number, which need not be the
same on both ends. 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.
Figure 6-11 Example of S S H Connection Protocol Message Exchange
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 6.11 provides an example of Connection Protocol Message
Exchange.
48
Channel Types (1 of 2)
Four channel types are recognized in the S S H 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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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: This 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: This is remote port forwarding, as explained in the next
subsection.
• direct-tcpip: This is local port forwarding, as explained in the next subsection.
Channel Types (2 of 2)
X11
Refers to the X Window System, a computer software system and network protocol that provides a graphical user interface (G U I) 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
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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: This 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: This is remote port forwarding, as explained in the next
subsection.
• direct-tcpip: This is local port forwarding, as explained in the next subsection.
Port Forwarding
One of the most useful features of S S H
Provides the ability to convert any insecure T C P connection into a secure S S H connection (also referred to as S S H tunneling)
Incoming T C P traffic is delivered to the appropriate application on the basis of the port number (a port is an identifier of a user of T C P)
An application may employ multiple port numbers
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
One of the most useful features of SSH is port forwarding. In essence,
port forwarding provides the ability to convert any insecure TCP connection
into a secure SSH connection. This is also referred to as SSH tunneling. We need to
know what a port is in this context. 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. 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.
Figure 6-12 S S H Transport Layer Packet Exchanges
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 6.12 illustrates the basic concept behind port forwarding. We have a
client application that is identified by port number x and a server application identified
by port number y . At some point, the client application invokes the local TCP
entity and requests a connection to the remote server on port y . The local TCP
entity negotiates a TCP connection with the remote TCP entity, such that the connection
links local port x to remote port y .
To secure this connection, SSH is configured so that the SSH Transport Layer
Protocol establishes a TCP connection between the SSH client and server entities,
with TCP port numbers a and b , respectively. A secure SSH tunnel is established over
this TCP connection. Traffic from the client at port x is redirected to the local SSH
entity and travels through the tunnel where the remote SSH entity delivers the data to
the server application on port y . Traffic in the other direction is similarly redirected.
SSH supports two types of port forwarding: local forwarding and remote forwarding.
Local forwarding allows the client to set up a “hijacker” process. This will
intercept selected application-level traffic and redirect it from an unsecured TCP
connection to a secure SSH tunnel. SSH is configured to listen on selected ports.
SSH grabs all traffic using a selected port and sends it through an SSH tunnel. On
the other end, the SSH server sends the incoming traffic to the destination port dictated
by the client application.
With remote forwarding, the user’s SSH client acts on the server’s behalf. The
client receives traffic with a given destination port number, places the traffic on the
correct port and sends it to the destination the user chooses. A typical example of
remote forwarding is the following. You wish to access a server at work from your
home computer. Because the work server is behind a firewall, it will not accept an
SSH request from your home computer. However, from work you can set up an
SSH tunnel using remote forwarding.
52
Summary (1 of 2)
Transport Layer Security
T L S architecture
T L S record protocol
Change cipher spec protocol
Alert protocol
Handshake protocol
Cryptographic computations
Heartbeat protocol
S S L/T L S attacks
T L Sv1.3
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Chapter 6 summary.
Summary (2 of 2)
Web security considerations
Web security threats
Web traffic security approaches
H T T P S
Connection initiation
Connection closure
Secure shell (S S H)
Transport layer protocol
User authentication protocol
Communication protocol
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Chapter 6 summary.
Copyright
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
55
1
2
64
-