e-PGPathshala

Subject : Computer Science

Paper: Cryptography and Network Security
Module: Web Security :SSL and TLS
Module No: CS/CNS/36
Quadrant 1 – e-text
Cryptography and Network Security
Module – 36 Web Security:SSL and TLS

Learning Objectives
 To identify variety of threats and web security issues
 To identify need for security
 Keep security simple
 Detect intrusions with the help of security mechanism
Introduction
The World Wide Web is widely used by businesses, government agencies, and many
individuals. But the Internet and the Web are extremely vulnerable to compromises of
various sorts, with a range of threats as shown. These can be described as passive
attacks including eavesdropping on network traffic between browser and server and
gaining access to information on a Web site that is supposed to be restricted, and
active attacks including impersonating another user, altering messages in transit
between client and server, and altering information on a Web site. The web needs
added security mechanisms to address these threats and we focus on security at the
transport layer: SSL/TLS, HTTPS, and SSH.

1. Web Security Considerations

World Wide Web is fundamentally a client/server application running over the
Internet and TCP/IP intranets. The Web presents new challenges not generally
appreciated in the context of computer and network security:
  The Internet is two way. Unlike traditional publishing environments, even
electronic publishing systems involving Teledex, 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.

1.1 Web Security Threats

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.
 Table 1.1 A Comparison of Threats on the Web

1.2 Web Traffic Security Approaches

A number of approaches to provide 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 1.1 illustrates this difference. 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. Further, IPsec includes a
filtering capability so that only selected traffic need incur the overhead of IPsec
processing.

Figure 1.1 Relative Location of Security Facilities in the TCP/IP Protocol Stack

Another relatively general-purpose solution is to implement security just above TCP.

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.

2. Secure Socket Layer (SSL)

Netscape originated SSL. Version 3 of the protocol was designed with public review
and input from industry and was published as an Internet draft document.
Subsequently, when a consenses was reached to submit the protocol for Internet
standardization, the TLS working group was formed within the IETF to develop a
common standard.
2.1 SSL Architecture
SSL is designed to make use of TCP to provide a reliable end-to-end secure service.
SSL is not a single protocol but rather two layers of protocol, as shown in Figure 2.1.
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 also defined as part of SSL: the Handshake Protocol,
Change Cipher Spec Protocol, and Alert Protocol. These SSL-specific protocols are
used in the management of SSL exchanges.

Figure 2.1 SSL Protocol Stack

Two important SSL concepts are the SSL connection and the SSL session:
• Connection: A connection is a network transport that provides a suitable type of
service, such connections are transient, peer-to-peer relationships, associated with one
session.
• Session: An SSL session is an association between a client and a server, 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.
2.2 SSL Record Protocol
SSL Record Protocol defines two services for SSL connections:
• Message Integrity: The Handshake Protocol also defines a shared secret key that is
used to form a message authentication code (MAC), which is similar to HMAC.
• Confidentiality: The Handshake Protocol defines a shared secret key that is used
for conventional encryption of SSL payloads. The message is compressed before
being concatenated with the MAC and encrypted, with a range of ciphers being
supported. P-515

Figure 2.2 SSL Record Protocol Operation

Figure 2.2 shows 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. Figure 2.3 illustrates the SSL record format. IT 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. The
maximum value is 214 + 2048.

Figure 2.3 SSL Record Format

2.3 Change Cipher Spec Protocol

The Change Cipher Spec Protocol is one of the three SSL-specific protocols that use
the SSL Record Protocol, and it is the simplest. It consists of a single message (Figure
2.4a), which consists of single byte with the value 1. Its purpose is to cause the
pending state to be copied into the current state, which updates the cipher suite to be
used on this connection.

2.4 Alert Protocol

 The Alert Protocol is used to convey SSL-related alerts to the peer entity. As with
other applications that use SSL, alert messages are compressed and encrypted, as
specified by the current state. Each message in this protocol consists of two bytes
(Figure 2.4b). 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. The first group shown are the fatal alerts, the others are warnings.

Figure 2.4 SSL Record Protocol Payload

2.4 Handshake Protocol

The most complex part of SSL 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 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.
The format of the Handshake Protocol shown in Figure 2.4c. Each message has three
fields:

 Type (1byte): Indicates one of 10 messages. Table 2.1 lists the defined message
types.
 Length (3bytes): The length of the message in bytes.
 Content (≥ 0 bytes): The parameters associated with this message; these are listed
in Table 2.1.
 Table 2.1 SSL Handshake Protocol Message Types

Fig 2.5 shows the initial exchange needed to establish a logical connection between
client and server. The exchange can be viewed in 4 phases:

 Phase 1. Establish Security Capabilities - This phase is used by the client to

initiate a logical connection and to establish the security capabilities that will be
associated with it.
 Phase 2. Server Authentication and Key Exchange - The server begins this
phase by sending its certificate if it needs to be authenticated.
 Phase 3. Client Authentication and Key Exchange - The client should verify that
the server provided a valid certificate if required and check that the server_hello
parameters are acceptable.
 Phase 4. Finish - This phase completes the setting up of a secure connection. The
client sends a change_cipher_spec message and copies the pending CipherSpec into
the current CipherSpec.
 Figure 2.5 Handshake Protocol Action

3. Transport Layer Security (TLS)

TLS is an IETF standardization initiative whose goal is to produce an Internet
standard version of SSL. TLS is defined as a Proposed Internet Standard in RFC
2246. RFC 2246 is very similar to SSLv3. Some of the minor differences in the areas
are:
 Version Number: The TLS Record Format is the same as that of the SSL Record
Format (Figure 2.3), and the fields in the header have the same meanings. The one
 difference is in the current version of TLS, the Major Version is 3 and the Minor
Version is 1.
 Message Authentication Code (MAC): There are two differences between the
SSLv3 and TLS MAC schemes: the actual algorithm and the scope of the MAC
calculation. TLS makes use of the HMAC algorithm defined in RFC 2104.
 Pseudo-random Function: TLS makes use of a pseudorandom function referred to
as PRF to expand secrets into blocks of data for purposes of key generation or
validation. The objective is to make use of a relatively small shared secret value but
to generate longer blocks of data in a way that is secure from the kinds of attacks
made on hash functions and MACs. In Figure 2.6 illustrate the PRF is based on the
following data expansion function.
 Alert Codes: TLS supports all of the alert codes defined in SSLv3 with the
exception of no_certificate.
 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.
 Client Certificate Types: TLS defines the following certificate types to be
requested in a certificate_request message: rsa_sign, dss_sign, rsa_fixed_dh, and
dss_fixed_dh. These are all defined in SSLv3. In addition, SSLv3 includes
rsa_ephemeral_dh, dss_ephemeral_dh, and fortezza_kea. TLS does not include the
Fortezza scheme.
 Figure 2.6 TLS Function P_hash (secret, seed)

 Certificate_Verify and Finished Messages: In the TLS certificate_verify

message, the MD5 and SHA-1 hashes are calculated only over
handshake_messages. Recall that for SSLv3, the hash calculation also included the
master secret and pads.
 Cryptographic Computations: The pre_master_secret for TLS is calculated in the
same way as in SSLv3. As in SSLv3, the master_secret in TLS is calculated as a
hash function of the pre_master_secret and the two hello random numbers.
 Padding: In SSL, the padding added prior to encryption of user data is the
minimum amount required so that the total size of the data to be encrypted is a
multiple of the cipher's block length. In TLS, the padding can be any amount that
 results in a total that is a multiple of the cipher's block length, up to a maximum of
255 bytes.

4. Secure Electronic Transactions (SET)

SET is an open encryption and security specification designed to protect credit card
transactions on the Internet. SETv1 emerged from a call for security standards by
MasterCard and Visa in 1996. Beginning in 1996, there have been numerous tests of
the concept, and by 1998 the first wave of SET-compliant products was available.
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. In essence, SET provides three
services:
• Provides a secure communications channel among all parties involved in a
transaction.
• Provides trust through the use of X.509v3 digital certificates.
• Ensures privacy because the information is only available to parties in a
transaction when and where necessary.

4.1 SET Requirements

SET specification lists the following business requirements for secure payment
processing with credit cards over the Internet and other networks:
● Provide confidentiality of payment and ordering information: It is necessary to
assure cardholders that this information is safe and accessible only to the intended
recipient. Confidentiality also reduces the risk of fraud by either party to the
transaction or by malicious third parties. SET uses encryption to provide
confidentiality.
● Ensure the integrity of all transmitted data: That is, ensure that no changes in
content occur during transmission of SET messages. Digital signatures are used to
provide integrity.
 ● Provide authentication that a cardholder is a legitimate user of a credit card
account: A mechanism that links a cardholder to a specific account number reduces
the incidence of fraud and the overall cost of payment processing. Digital signatures
and certificates are used to verify that a cardholder is a legitimate user of a valid
account.
● Provide authentication that a merchant can accept credit card transactions
through its relationship with a financial institution: This is the complement to the
preceding requirement. Cardholders need to be able to identify merchants with whom
they can conduct secure transactions. Again, digital signatures and certificates are
used.
● Ensure the use of the best security practices and system design techniques to
protect all legitimate parties in an electronic commerce transaction: SET is a
well-tested specification based on highly secure cryptographic algorithms and
protocols.
● Create a protocol that neither depends on transport security mechanisms nor
prevents their use: SET can securely operate over a "raw" TCP/IP stack. However,
SET does not interfere with the use of other security mechanisms, such as IPSec and
SSL/TLS.
● Facilitate and encourage interoperability among software and network
providers: The SET protocols and formats are independent of hardware platform,
operating system, and Web software.

4.2 Key Features of SET

To meet the requirements just outlined, SET incorporates the following features:
 Confidentiality of information
 Integrity of data
 Cardholder account authentication
 Merchant authentication
4.3 SET Participants
Figure4.1 indicates the participants in the SET system, being:
• Cardholder: The purchasers interact with merchants from personal computers
over the Internet.
• Merchant: A person or organization that has goods or services to sell to the
cardholder.
• Issuer: A financial institution, such as a bank, that provides the cardholder with
the payment card.
• Acquirer: A financial institution that establishes an account with a merchant and
processes payment card authorizations and payments.
• Payment gateway: A function operated by the acquirer or a designated third party
that processes merchant payment messages.
• Certification authority (CA): An entity that is trusted to issue X.509v3 public-
key certificates for cardholders, merchants, and payment gateways.

Figure 4.1 Secure Electronic Commerce Components

4.4 SET Transaction
The sequence of events that are required for a transaction.
• The customer opens an account: The customer obtains a credit card account, such
as MasterCard or Visa, with a bank that supports electronic payment and SET.
• The customer receives a certificate: After suitable verification of identity, the
customer receives an X.509v3 digital certificate, which is signed by the bank.
• Merchants have their own certificates: A merchant who accepts a certain brand
of card must be in possession of two certificates for two public keys owned by the
merchant: one for signing messages, and one for key exchange.
• The customer places an order: This is a process that may involve the customer
first browsing through the merchant's Web site to select items and determine the
price.
• The merchant is verified: In addition to the order form, the merchant sends a copy
of its certificate, so that the customer can verify that he or she is dealing with a
valid store.
• The order and payment are sent: The customer sends both order and payment
information to the merchant, along with the customer's certificate.
• The merchant requests payment authorization. The merchant sends the payment
information to the payment gateway, requesting authorization that the customer's
available credit is sufficient for this purchase.
• The merchant confirms the order. The merchant sends confirmation of the order
to the customer.
• The merchant provides the goods or service. The merchant ships the goods or
provides the service to the customer.
• The merchant requests payment. This request is sent to the payment gateway,
which handles all of the payment processing.
4.5 Dual Signature
The purpose of the SET dual signature is to link two messages that are intended for
two different recipients, the order information (OI) for the merchant and the payment
information (PI) for 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, however the two items must be linked in a way that can be used to resolve
disputes if necessary. Figure 4.2 shows the use of a dual signature to meet the
requirements. The customer takes the hash (using SHA-1) of the PI and the hash of
the OI, concatenates them, and hashes the result. Finally, the customer encrypts the
final hash with his or her private signature key, creating the dual signature. This can
be summarized as: DS=E(PRc, [H(H(PI)||H(OI))]).

Figure 4.2 Construction of Dual Signature

4.5.1 Payment Processing

Table 4.1 lists the transaction types supported by SET. In some detail at the
following transactions:
 Purchase request
 Payment authorization
 Payment capture
 Table 4.1 SET Transaction Types
4.5.2 SET Purchase Request
The purchase request exchange consists of four messages: Initiate Request, Initiate
Response, Purchase Request, and Purchase Response. In order to send SET messages
to the merchant, the cardholder must have a copy of the certificates of the merchant
 and the payment gateway. The customer requests the certificates in the Initiate
Request message, sent to the merchant. The merchant generates a response and signs
it with its private signature key. The cardholder verifies the merchant and gateway
certificates by means of their respective CA signatures and then creates the OI and PI.
Next, the cardholder prepares the Purchase Request message with Purchase-related
information & Order-related information. The Purchase Response message includes a
response block that acknowledges the order and references the corresponding
transaction number.

Figure 4.3 Cardholder Sends Purchase Request

In Figure 4.3 shows the details of the contents of the Purchase Request message
generated by the customer. The message includes the following:
1. Purchase-related information: This information will be forwarded to the payment
gateway by the merchant and consists of PI, dual signature and OI message digest
(OIMD).
2. Order-related information: This information needed by the merchant and consists
of: OI, dual signature, PI message digest (PIMD).
3. Cardholder certificate: This contains the cardholder’s public signature key.

Figure 4.4 Merchant Verifies Customer Purchase Request

When the merchant receives the Purchase Request message, it performs the following
actions (Figure 4.4):
1. Verifies cardholder certificates using CA signatures.
 2. 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.
3. Processes order and forwards the payment information to the payment gateway for
authorization.
4. Sends a purchase response to cardholder.

4.5.3 Payment Authorization

 The merchant sends an Authorization Request message to the payment gateway
consisting of the following:
1. Purchase-related information.
2. Authorization-related information.
3. Certificates.
 The payment gateway performs the following tasks:
1. Verifies all certificates.
2. Decrypts digital envelope of authorization block to obtain symmetric key &
then decrypts authorization block.
3. Verifies merchant's signature on authorization block.
4. Decrypts digital envelope of payment block to obtain symmetric key & then
decrypts payment block.
5. Verifies dual signature on payment block.
6. Verifies that transaction ID received from merchant matches that in PI
received (indirectly) from customer.
7. Requests & receives an authorization from issuer.
8. Sends authorization response back to merchant.
 Having obtained authorization from the issuer, the payment gateway returns an
Authorization Response message to the merchant. It includes the following
elements:
1. Authorization-related information.
 2. Capture token information.
3. Certificate.
4.5.3 Payment Capture
To obtain payment, the merchant sends a capture request message to the payment
gateway, for which the merchant generates, signs, and encrypts a capture request
block, including payment amount and transaction ID. The payment gateway
receives the capture request message, decrypts and verifies the capture request block
and decrypts and verifies the capture token block. It then checks for consistency
between the capture request and capture token. It then creates a clearing request sent
to the issuer over the private payment network, which causes funds to be transferred
to the merchant’s account. The gateway then notifies the merchant of payment in a
Capture Response message, which includes a capture response block that the
gateway signs and encrypts, plus the gateway’s signature key certificate. The
merchant software stores the capture response to be used for reconciliation with
payment received from the acquirer.

Summary
In this module, need for web security, SSL/TLS transport layer security
protocols, SET secure credit card payment protocols are considered to provide a better
security in web. SSL provides secure channel over any TCP based protocol and it has
an optional for server authentication with public key cryptography. SSL security
provides good randomness and protects server’s private keys.