Chapter 16- Web Security

Web Security
• Virtually all businesses, most government agencies, and many
individuals now have Web sites.
• The number of individuals and companies with Internet
access is expanding rapidly and all of these have graphical
Web browsers.
• As a result, businesses are enthusiastic about setting up
facilities on the Web for electronic commerce.
• But the reality is that the Internet and the Web are extremely
vulnerable to compromises of various sorts.
• As businesses wake up to this reality, the demand for secure
Web services grows.
• need added security mechanisms
• The Internet is two way. Unlike traditional publishing
environments, even - electronic publishing systems
involving teletext, voice response, or fax-back, the Web
is vulnerable to attacks on the Web servers over the
Internet.

• The Web is increasingly serving as a highly visible outlet

for corporate and product information and as the
platform for business transactions. Reputations can be
damaged and money can be lost if the Web servers are
subverted.
• 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.
Web Security Threats
 Web traffic security approaches
• 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 illustrates this difference. One way to provide Web
security is to use IP security (IPsec) (Figure a).
• 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.
Web traffic security approaches
 Web traffic security approaches
• Another relatively general-purpose solution is to implement
security just above TCP (Figure b).

• 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.
 Web traffic security approaches
• 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 c 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.
 SSL (Secure Socket Layer)
• transport layer security service

• originally developed by Netscape

• version 3 designed with public review & input

• subsequently became Internet standard known

as TLS (Transport Layer Security)
 SSL Architecture
 uses TCP to provide a reliable end-to-end
service
 SSL has two layers of protocols
 SSL Architecture
 The SSL Record Protocol provides basic security
services to various higher layer protocols.

 In particular, the Hypertext Transfer Protocol (HTTP),

which provides the transfer service for Web
client/server interaction, can operate on top of SSL.

 Three higher-layer protocols are defined as part of

SSL: the Handshake Protocol, The Change Cipher Spec
Protocol, and the Alert Protocol. These SSL-specific
protocols are used in the management of SSL
exchanges
 SSL Architecture
Two important SSL concepts
• SSL connection
– a transient, peer-to-peer,
– communications link associated with 1 SSL session
• SSL session
– an association between client & server
– created by the Handshake Protocol
– define a set of cryptographic parameters
– may be shared by multiple SSL connections
• There are actually 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

• Session identifier: An arbitrary byte sequence chosen by the

server to identify an active or resumable session state.
• Peer certificate: An X509.v3 certificate of the peer. This element of the
state may be null.

• Compression method: The algorithm used to compress data prior to

encryption.

• Cipher spec: Specifies the bulk data encryption algorithm (such as null,
AES, etc.) and a hash algorithm (such as MD5 or SHA-1) used for MAC
calculation. It also defines cryptographic attributes such as the
hash_size

• Master secret: 48-byte secret shared between the client and 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:

• 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 conventional encryption key for data

encrypted by the server and decrypted by the client.
• Client write key: The conventional 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.
 SSL Record Protocol Services
• message integrity
– using a MAC with shared secret key
– similar to HMAC but with different padding
• confidentiality
– using symmetric encryption with a shared secret
key defined by Handshake Protocol
– AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza,
RC4-40, RC4-128
– message is compressed before encryption
SSL Record Protocol Operation
 SSL Record Protocol Operation
 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 SSLv3 (as well as the current version of TLS), 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. For this
purpose, a shared secret key is used.
 The calculation is defined as
SSL Record Protocol Operation
 SSL Record Protocol Operation
 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.
 The following encryption algorithms are permitted:
 SSL Record Protocol Operation
 The final step of SSL Record Protocol processing is to prepare a
header consisting of the following fields:

• Content Type (8 bits): The higher-layer protocol used to process

the enclosed fragment.
• Major Version (8 bits): Indicates major version of SSL in use. For
SSLv3, the value is 3.
• Minor Version (8 bits): Indicates minor version in use. For SSLv3,
the value is 0.
• Compressed Length (16 bits): The length in bytes of the plaintext
fragment (or compressed fragment if compression is used).The
maximum value is 214 + 2048.
 SSL Change Cipher Spec Protocol
• one of 3 SSL specific protocols which use the
SSL Record protocol
• a single message causes pending state to
become current state
• hence updating the cipher suite to be used on
this connection
SSL Record Protocol Payload
 SSL Alert Protocol
• conveys SSL-related alerts to peer entity
• It consist of two bytes
• First byte is severity
• warning or fatal
– If the level is fatal, SSL immediately terminate
connection
• Second byte is specific alert
• fatal: unexpected message, bad record mac, decompression
failure, handshake failure, illegal parameter
• warning: close notify, no certificate, bad certificate,
unsupported certificate, certificate revoked, certificate
expired, certificate unknown
• compressed & encrypted like all SSL data
 SSL Handshake Protocol
• Most complex part of SSL is
• allows server & client to:
– authenticate each other
– to negotiate encryption & MAC algorithms
– to negotiate cryptographic keys to be used
• comprises a series of messages in phases
1. Establish Security Capabilities
2. Server Authentication and Key Exchange
3. Client Authentication and Key Exchange
4. Finish
SSL Handshake Protocol
 TLS (Transport Layer Security)
• IETF standard RFC 2246 similar to SSLv3
• with minor differences
– in record format version number
– uses HMAC for MAC
– a pseudo-random function expands secrets
– has additional alert codes
– some changes in supported ciphers
– changes in certificate types & negotiations
– changes in crypto computations & padding
TLS (Transport Layer Security)
TLS (Transport Layer Security)
TLS (Transport Layer Security)
TLS (Transport Layer Security)
 TLS (Transport Layer Security)
• The data expansion function makes use of the HMAC
algorithm with either MD5 or SHA-1 as the underlying
hash function.

• As can be seen, P_hash can be iterated as many times as

necessary to produce the required quantity of data.

• For example, if P_SHA-1 was used to generate 64 bytes of

data, it would have to be iterated four times, producing
80 bytes of data of which the last 16 would be discarded.
 TLS (Transport Layer Security)
• In this case, P_MD5 would also 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.

• To make PRF as secure as possible, it uses two hash algorithms in a way

that should guarantee its security if either algorithm remains secure.
PRF is defined as

• PRF(secret, label, seed) = P_hash(S1,label || seed)

• PRF takes as input a secret value, an identifying label, and a seed value
and produces an output of arbitrary length.
 TLS (Transport Layer Security)
• Alert code:
– Record overflow, unkown CA, access_denied, decode_error,
Protocol_version, insuffiecient security,
unsupported_extension, Internal_error, decrypt_error,
– User_canceled, no_recognization
• Cipher suites
– There are several small differences between the cipher suites
available under SSLv3 and under TLS:
– Key Exchange: TLS supports all of the key exchange
techniques of SSLv3 with the exception of Fortezza.

– Symmetric Encryption Algorithms: TLS includes all of the

symmetric encryption algorithms found in SSLv3, with the
exception of Fortezza.
 HTTPS
• HTTPS (HTTP over SSL)
– combination of HTTP & SSL/TLS to secure
communications between browser & server
• documented in RFC2818
• no fundamental change using either SSL or TLS
• use https:// URL rather than http://
– and port 443 rather than 80
• encrypts
– URL, document contents, form data, cookies,
HTTP headers
 HTTPS Use
• connection initiation
– TLS handshake then HTTP request(s)
– We need to be clear that 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.
 HTTPS Use
– 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.
 HTTPS Use
• connection closure
– have “Connection: close” in HTTP record

– TLS level exchange close_notify alerts

– can then close TCP connection

– must handle TCP close before alert exchange sent

or completed
 HTTPS Use
• connection closure
– HTTP clients must also 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 (SSH)
• 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.
• SSH2 fixes a number of security flaws and documented in RFCs
4250 through 4254
• SSH clients & servers are widely available for most operating
systems
• It has become the method of choice for remote login and X
tunnelling and is rapidly becoming one of the most pervasive
applications for encryption technology outside of embedded
systems.
SSH Protocol Stack
 SSH Protocol Stack
• SSH is organized as three protocols that typically run
on top of TCP (Figure):
• 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.
 SSH Transport Layer Protocol
• server authentication occurs at transport
layer, based on server/host key pair(s)
– Server authentication occurs at the transport
layer, based on the server possessing a
public/private key pair. 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 priori knowledge of the
server's public host key.
•
 SSH Transport Layer Protocol
• packet exchange (figure: next slide)
– Next, consider events in the SSH Transport Layer Protocol.

– First, a client establishes a TCP connection to the server.

Once the connection is established, the client and server
exchange data, referred to as packets, in the data field of a
TCP segment.
SSH Transport Layer Protocol
 SSH Transport Layer Protocol
• packet exchange
– 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
SSH Transport Layer Protocol

Once an encryption
algorithm has been
negotiated, the
entire packet
(excluding the MAC
field) is encrypted
after the MAC
value is calculated.
 SSH Transport Layer Protocol
• The SSH Transport Layer packet exchange consists of a
sequence of steps.
• The first step, the identification string exchange, begins with
the client sending a packet with an identification string.
• Next comes algorithm negotiation. Each side sends an
SSH_MSG_KEXINIT containing lists of supported algorithms,
one list for each type of cryptographic algorithm, in the order
of preference to the sender.
• For each category, the algorithm chosen is the first algorithm
on the client's list that is also supported by the server.
 SSH Transport Layer Protocol
• The next step is key exchange. The specification allows for
alternative methods of key exchange, but at present only two
versions of Diffie-Hellman key exchange are specified.
• As a result of these steps, the two sides now share a master key K.
In addition, the server has been authenticated to the client. The
end of key exchange is signaled by the exchange of
SSH_MSG_NEWKEYS packets. At this point, both sides may start
using the keys generated from K, as discussed subsequently.
• The final step is service request. The client sends an
SSH_MSG_SERVICE_REQUEST packet to request either the User
Authentication or the Connection Protocol. Subsequent to this, all
data is exchanged as the payload of an SSH Transport Layer packet,
protected by encryption and MAC.
 SSH User Authentication Protocol
• The User Authentication Protocol provides the means by
which the client is authenticated to the server.
• Three types of messages are always used in the User
Authentication Protocol.
• Authentication requests from the client have type
SSH_MSG_USERAUTH_REQUEST. If the server either (a)
rejects the authentication request, or (b) accepts the request
but requires one or more additional authentication methods,
the server sends a SSH_MSG_USERAUTH_FAILURE message
that includes a list of methods that may productively continue
the dialog.
 SSH User Authentication Protocol
• If the server accepts authentication then it sends a single byte
message, SSH_MSG_USERAUTH_SUCCESS.

• The server may require one or more of the following

authentication methods:
• publickey - client sends a message to the server that contains
the client's public key, with the message signed by the client's
private key
• password - client sends a message containing a plaintext
password, protected by TLS encryption
• hostbased - authentication is performed on the client's host,
rather than the client itself
 SSH 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.
• That secure authentication connection,
referred to as a tunnel is used by the
Connection Protocol to multiple a number of
logical channels.
• All types of communication using SSH, such as
a terminal session, are supported using
separate channels.
 SSH Connection Protocol
• 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.
 SSH Connection Protocol
• Four channel types are recognized in the
SSH Connection Protocol specification:
• session - remote execution of a program
• x11 - X Window System display traffic
• forwarded-tcpip - remote port forwarding
• direct-tcpip - local port forwarding
 SSH
Connection
Protocol
Exchange
 Port Forwarding
• convert insecure TCP connection into a secure
SSH connection
– SSH Transport Layer Protocol establishes a TCP
connection between SSH client & server
– client traffic redirected to local SSH, travels via
tunnel, then remote SSH delivers to server
• supports two types of port forwarding
– local forwarding – hijacks selected traffic
– remote forwarding – client acts for server
 Port 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. This could be used to secure the traffic from an
email client on your desktop that gets email from the mail
server via POP, the Post Office Protocol.

• 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. This could be
used to securely access a server at work from a home
computer.
 Summary
• have considered:
– need for web security
– SSL/TLS transport layer security protocols
– HTTPS
– secure shell (SSH)