5.

3 WEB SECURITY

WEB SECURITY CONSIDERATIONS

The World Wide Web is fundamentally a client/server application running over the
Internet and TCP/IP intranets.
Web Security Threats

A Comparison of Threats on the Web

Threats Consequences Countermeasures

Integrity Modification of user Loss of information Cryptographic
data Trojan horse Compromise of checksums
browser machine
Modification of memory Vulnerability to all
Modification of other threats
message traffic in
transit
Confidentiality Eavesdropping on the Loss of information Encryption, web proxies
Net Theft of info from Loss of privacy
server Theft of data
from client Info about
network configuration
Info about which client
talks to server
Denial of Killing of user threads Disruptive Annoying Difficult to prevent
Service Flooding machine with Prevent user from
Bogus requests getting work done
Filling up disk or
memory Isolating
machine by DNS
attacks
Authentication Impersonation of Misrepresentation of Cryptographic
legitimate users Data user Belief that false techniques
forgery information is valid

Two types of attacks are:

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.

WEB TRAFFIC SECURITY APPROACHES

One way to provide Web security is to use IP Security. The advantage of using IPSec is
that it is transparent to end users and applications and provides a general-purpose solution.

HTTP FTP SMTP

SSL/TLS
TCP
 IP
HTTP FTP SMTP
TCP
IP/IPSec

(a) Network level (b) Transport Level

(c) Application
S/MIME PGP SET Level
Kerberos SMTP HTTP
Fig5.14: Relative UDP TCP Location of Security
Facilities in the TCP/IP IP Protocal Stack

SECURE SOCKET LAYER AND TRANSPORT LAYER SECURITY

SSL Architecture
SSL is designed to make use of TCP to provide a reliable end-to-end secure service.
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.

Fig 5.15: SSL Protocol Stack

Two important SSL concepts are the SSL session and the SSL connection, which are
defined in the specification as follows:
Connection:
A connection is a transport (in the OSI layering model definition) that provides a suitable
type of service. For SSL, such connections are peer-to-peer relationships. The connections are
transient. Every connection is associated with one session.

Session:

An SSL session is an association between a client and a server. Sessions are created
by the Handshake Protocol. Sessions define a set of cryptographic security parameters, which
can be shared among multiple connections. Sessions are used to avoid the expensive
negotiation of new security parameters for each connection.

A session state is defined by the following parameters

  Session identifier
 Peer certificate
 Compression method
 Cipher spec
 Master secret
 Is resumable
A connection state is defined by the following parameters:
 Server and client random
 Server write MAC secret
 Client write MAC secret
 Server write key
 Client write key.
 Initialization vectors
 Sequence numbers

SSL Record Protocol

The SSL Record Protocol provides two services for SSL connections:

Confidentiality: The Handshake Protocol defines a shared secret key that is used for
conventional encryption of SSL payloads.
Message Integrity: The Handshake Protocol also defines a shared secret key that is
used to form a message authentication code (MAC).
The diagram indicates the overall operation of the SSL Record Protocol. The Record
Protocol takes an application message to be transmitted, fragments the data into manageable
blocks, optionally compresses the data, applies a MAC, encrypts, adds a header, and transmits
the resulting unit in a TCP segment. Received data are decrypted, verified, decompressed, and
reassembled and then delivered to higher-level users.
The first step is fragmentation. Each upper-layer message is fragmented into blocks of
14
2 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.
The final step of SSL Record Protocol processing is to prepend a header, consisting of
the following fields:
 Content Type (8 bits): The higher layer protocol used to process the enclosed
fragment.
 Major Version (8 bits): Indicates major version of 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.
 Fig 5.16: SSL Record Protocol Operation

Change Cipher Spec Protocol

This protocol consists of a single message which consists of a single byte with the value
1.
Alert Protocol
The Alert Protocol is used to convey SSL-related alerts to the peer entity.
Each message in this protocol consists of two bytes The first byte takes the value
warning(1) or fatal(2) to convey the severity of the message. The second byte contains a code
that indicates the specific alert.
 unexpected_message: An inappropriate message was received.
 bad_record_mac: An incorrect MAC was received.
 decompression_failure: The decompression function received improper input (e.g.,
unable to decompress or decompress to greater than maximum allowable length).
 handshake_failure: Sender was unable to negotiate an acceptable set of security
parameters given the options available.
 illegal_parameter: A field in a handshake message was out of range or inconsistent
with other fields.
The remainder of the alerts is the following:
 Close notify: Notifies the recipient that the sender will not send any more messages
on this connection. Each party is required to send a close_notify alert before closing
the right side of a connection.
 No certificate: May be sent in response to a certificate request if no appropriate
certificate is available.
 bad_certificate: A received certificate was corrupt (e.g., contained a signature that
did not verify).
 unsupported_certificate: The type of the received certificate is not supported.
 certificate_revoked: A certificate has been revoked by its signer.
 certificate_expired: A certificate has expired.
 certificate_unknown: Some other unspecified issue arose in processing the
certificate, rendering it unacceptable.
Handshake Protocol

This protocol allows the server and client to authenticate each other and to negotiate an
encryption and MAC algorithm and cryptographic keys to be used to protect data sent in an SSL
record. The Handshake Protocol is used before any application data is transmitted.
The Handshake Protocol consists of a series of messages exchanged by client and
server.

Establish Security Capabilities

This phase is used to initiate a logical connection and to establish the security
capabilities that will be associated with it. The exchange is initiated by the client, which sends a
client_hello message with the following parameters:

1. Version: The highest SSL version understood by the client.

2. Random: A client-generated random structure, consisting of a 32-bit timestamp and
28 bytes generated by a secure random number generator. These values serve as nonces and
are used during key exchange to prevent replay attacks.
3. Session ID: A variable-length session identifier. A nonzero value indicates that the
client wishes to update the parameters of an existing connection or create a new connection on
this session.
4. CipherSuite: This is a list that contains the combinations of cryptographic algorithms
supported by the client, in decreasing order of preference.
5. Compression Method: This is a list of the compression methods the client supports.
After sending the client_hello message, the client waits for the server_hello message,
which contains the same parameters as the client_hello message.
Server Authentication and Key Exchange
The server begins this phase by sending its certificate; The certificate message is
required for any agreed-on key exchange method except anonymous Diffie-Hellman.
Next, a server_key_exchange message may be sent if it is required. The certificate
request message includes two parameters: certificate_type and certificate_authorities.
Client Authentication and Key Exchange

If the server has requested a certificate, the client begins this phase by sending a
certificate message.Next is the client_key_exchange message, which must be sent in this
phase.
Finally, in this phase, the client may send a certificate_verify message to provide explicit
verification of a client certificate.

SSL 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
 SSL Handshake Protocol Message Types
Message Type Parameters
certificate_request type, authorities
server_done null
certificate_verify signature
client_key_exchange parameters, signature
finished hash value

Fig 5.17: Handshake Protocol Action

 Finish
This phase completes the setting up of a secure connection. The client sends a
change_cipher_spec message and copies the pending CipherSpec into the current CipherSpec.
The client then immediately sends the finished message under the new algorithms, keys,
and secrets.
Cryptographic Computations
Master Secret Creation
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 the Diffie-Hellman calculation to create the shared
pre_master_secret.

SECURE ELECTRONIC TRANSACTION

SET is an open encryption and security specification designed to protect credit card
transactions on the Internet.
SET is not itself a payment system. Rather it is a set of security protocols and formats
that enables users to employ the existing credit card payment infrastructure on an open
network, such as the Internet, in a secure fashion.
SET provides three services:
 Provides a secure communications channel among all parties involved in a
transaction
 Provides trust by the use of X.509v3 digital certificates
 Ensures privacy because the information is only available to parties in a
transaction when and where necessary

Key Features of SET

 Confidentiality of information
 Integrity of data
 Cardholder account authentication
 Merchant authentication

SET Participants
 Cardholder: A cardholder is an authorized holder of a payment card (e.g., MasterCard,
Visa) that has been issued by an issuer.
 Merchant: A merchant is a person or organization that has goods or services to sell to
the cardholder.
 Issuer: This is a financial institution, such as a bank, that provides the cardholder with
the payment card.
 Acquirer: This is a financial institution that establishes an account with a merchant and
processes payment card authorizations and payments.
 Payment gateway: This is a function operated by the acquirer or a designated third
party that processes merchant payment messages.
 Certification authority (CA): This is an entity that is trusted to issue X.509v3 public-key
certificates for cardholders, merchants, and payment gateways.

Fig 5.18: Secure Electronic Commerce Components

SET Transaction

 Customer opens account: The customer obtains a credit card account, such as
MasterCard or Visa, with a bank that supports electronic payment and SET.
 Customer receives a certificate: After verification the customer receives X.509V3,
digital certificate which is signed by the bank. This certificate verifies the customer‟s RSA
public key and expiration date.
 Merchants have their own certificates:

 Merchants who accepts card need to have 2 certificates for 2 public keys owned
by them.
 One certificate is used for signing of message and the other is used for key
exchange.
 The merchants also need the copy of payment gateway‟s public key certificate.
 Customer places an order:
 The customer places the order containing the list of items to be purchased to the
merchant.
 The merchant returns the order form having the items, price, total price and order
number.
 Merchant is verified: The merchant along with the order form sends its certificate
copy. The customer can verify the same.
 Order and payment are sent:
 The customer sends order and payment information into the merchant along with
customer‟s certificate.
 This is order conformation of the order form.
 The payment contains the card details. This is encrypted, so it cannot be read by
the merchant.
 The certificate sent can be verified by the merchant.
  Merchant requests payment authorization: The merchant sends the payment
information to the payment gateway. The merchant requests for authentication of the
customer, credit limit, validity.
 Merchant confirms order: The merchant sends conformation of the order to the
customer.
 Merchant provides goods or service
 Merchant requests payment

Dual Signature

The purpose of the dual signature is to link two messages that are intended for two
different recipients. In this case, the customer wants to send the order information (OI) to the
merchant and the payment information (PI) to the bank. The merchant does not need to know
the customer's credit card number, and the bank does not need to know the details of the
customer's order.

The customer takes the hash (using SHA-1) of the PI and the hash of the OI. These two
hashes are then concatenated and the hash of the result is taken. Finally, the customer
encrypts the final hash with his or her private signature key, creating the dual signature. The
operation can be summarized as

DS = E(PRc, [ H ( H (PI) || H (O I )])

Where PRc is the customer's private signature key. Now suppose that the merchant is in
possession of the dual signature (DS), the OI, and the message digest for the PI (PIMD). The
merchant also has the public key of the customer, taken from the customer's certificate. Then
the merchant can compute the quantities

H (PIMS || H[OI]); D(PUc, DS)

Where PUc is the customer's public signature key. If these two quantities are equal, then
the merchant has verified the signature.

Similarly, if the bank is in possession of DS, PI, the message digest for OI (OIMD), and
the customer's public key, then the bank can compute

H(H[OI]||OIMD); D(PUc, DS)

PI = Payment information PIMD = PI message digest

OI = Order information OIMD = OI message digest
H = Hash function(SHA-1) POMD = Payment order message digest
II = Concatenation E = Encryption(RSA)
PRC = Customer‟s private signature key
Payment Processing

 Purchase request
 Payment authorization
 Payment capture

Purchase Request

Before the Purchase Request exchange begins, the cardholder has completed browsing,
selecting, and ordering. The end of this preliminary phase occurs when the merchant sends a
completed order form to the customer.
The purchase request exchange consists of four messages: Initiate Request, Initiate
Response, Purchase Request, and Purchase Response.
 verifies cardholder certificates using CA sigs
 verifies dual signature using customer's public signature key to ensure order has
not been tampered with in transit & that it was signed using cardholder's private
signature key
 processes order and forwards the payment information to the payment gateway
for authorization (described later)
 sends a purchase response to cardholder

Fig 5.19: Purchase Request – Customer

Payment Authorization
The payment authorization ensures that the transaction was approved by the issuer.
This authorization guarantees that the merchant will receive payment; the merchant can
therefore provide the services or goods to the customer. The payment authorization exchange
consists of two messages: Authorization Request and Authorization response.
 Verifies all certificates
  Decrypts digital envelope of authorization block to obtain symmetric key & then
decrypts authorization block
 Verifies merchant's signature on authorization block
 Decrypts digital envelope of payment block to obtain symmetric key & then decrypts
payment block
 Verifies dual signature on payment block
 Verifies that transaction ID received from merchant matches that in PI received
(indirectly) from customer
 Requests & receives an authorization from issuer
 Sends authorization response back to merchant

Fig 5.20: Purchase Request – Merchant

Payment Capture
To obtain payment, the merchant engages the payment gateway in a payment capture
transaction, consisting of a capture request and a capture response message.
 Merchant sends payment gateway a payment capture request
 Gateway checks request
 Then causes funds to be transferred to merchants account
 Notifies merchant using capture response