UNIT-4

Web Security: Web Security Requirements, Secure Socket Layer (SSL) and Transport Layer Security
(TLS), Secure Electronic Transaction (SET).

Transport Layer Security:

Network security entails securing data against attacks while it is in transit on a network. To
achieve this goal, many real-time security protocols have been designed. There are popular
standards for real-time network security protocols such as S/MIME, SSL/TLS, SSH, and IPsec.
As mentioned earlier, these protocols work at different layers of networking model.
For TCP/IP protocol based network, physical and data link layers are typically implemented in
the user terminal and network card hardware. TCP and IP layers are implemented in the
operating system. Anything above TCP/IP is implemented as user process.

Need for Transport Layer Security

Let's discuss a typical Internet-based business transaction.
Bob visits Alice’s website for selling goods. In a form on the website, Bob
enters the type of good and quantity desired, his address and payment card
details. Bob clicks on Submit and waits for delivery of goods with debit of
price amount from his account. All this sounds good, but in absence of
network security, Bob could be in for a few surprises.
 If transactions did not use confidentiality (encryption), an attacker could obtain his payment
card information. The attacker can then make purchases at Bob's expense.
 If no data integrity measure is used, an attacker could modify Bob's order in terms of type or
quantity of goods.
 Lastly, if no server authentication is used, a server could display Alice's famous logo but the
site could be a malicious site maintained by an attacker, who is masquerading as Alice. After
receiving Bob's order, he could take Bob's money and flee. Or he could carry out an identity
theft by collecting Bob's name and credit card details.
Transport layer security schemes can address these problems by enhancing TCP/IP based
network communication with confidentiality, data integrity, server authentication, and client
authentication.
The security at this layer is mostly used to secure HTTP based web transactions on a network.
However, it can be employed by any application running over TCP.

Philosophy of TLS Design

Transport Layer Security (TLS) protocols operate above the TCP layer. Design of these
protocols use popular Application Program Interfaces (API) to TCP, called “sockets" for
interfacing with TCP layer.
Applications are now interfaced to Transport Security Layer instead of TCP directly. Transport
Security Layer provides a simple API with sockets, which is similar and analogous to TCP's
API.

In the above diagram, although TLS technically resides between application and transport
layer, from the common perspective it is a transport protocol that acts as TCP layer enhanced
with security services.
TLS is designed to operate over TCP, the reliable layer 4 protocol (not on UDP protocol), to
make design of TLS much simpler, because it doesn't have to worry about ‘timing out’ and
‘retransmitting lost data’. The TCP layer continues doing that as usual which serves the need of
TLS.

Why TLS is Popular?

The reason for popularity of using a security at Transport Layer is simplicity. Design and
deployment of security at this layer does not require any change in TCP/IP protocols that are
implemented in an operating system. Only user processes and applications needs to be
designed/modified which is less complex.

Secure Socket Layer (SSL)

TheTLS family includes SSL versions 2 and 3 and TLS protocol. SSLv2 has been now
replaced by SSLv3, so we will focus on SSL v3 and TLS.

Brief History of SSL

 In year 1995, Netscape developed SSLv2 and used in Netscape Navigator 1.1. The SSL
version1 was never published and used. Later, Microsoft improved upon SSLv2 and introduced
another similar protocol named Private Communications Technology (PCT).
Netscape substantially improved SSLv2 on various security issues and deployed SSLv3 in
1999.The Internet Engineering Task Force (IETF) subsequently, introduced a similar TLS
(Transport Layer Security) protocol as an open standard. TLS protocol is non-interoperable
with SSLv3.
TLS modified the cryptographic algorithms for key expansion and authentication. Also, TLS
suggested use of open crypto Diffie-Hellman (DH) and Digital Signature Standard (DSS) in
place of patented RSA crypto used in SSL. But due to expiry of RSA patent in 2000, there
existed no strong reasons for users to shift away from the widely deployed SSLv3 to TLS.

Salient Features of SSL

The salient features of SSL protocol are as follows −

 SSL provides network connection security through −
o Confidentiality − Information is exchanged in an encrypted form.
o Authentication − Communication entities identify each other through the use of digital
certificates. Web-server authentication is mandatory whereas client authentication is kept
optional.
o Reliability − Maintains message integrity checks.
 SSL is available for all TCP applications.
 Supported by almost all web browsers.
 Provides ease in doing business with new online entities.
 Developed primarily for Web e-commerce.

Architecture of SSL

SSL is specific to TCP and it does not work with UDP. SSL provides Application Programming
Interface (API) to applications. C and Java SSL libraries/classes are readily available.
SSL protocol is designed to interwork between application and transport layer as shown in the
following image −
 SSL itself is not a single layer protocol as depicted in the image; in fact it is composed of two
sub-layers.
 Lower sub-layer comprises of the one component of SSL protocol called as SSL Record
Protocol. This component provides integrity and confidentiality services.
 Upper sub-layer comprises of three SSL-related protocol components and an application
protocol. Application component provides the information transfer service between client/server
interactions. Technically, it can operate on top of SSL layer as well. Three SSL related protocol
components are −
o SSL Handshake Protocol
o Change Cipher Spec Protocol
o Alert Protocol.
 These three protocols manage all of SSL message exchanges .

Functions of SSL Protocol Components

The four sub-components of the SSL protocol handle various tasks for secure communication
between the client machine and the server.

 SSL Record Protocol

o The record layer formats the upper layer protocol messages.
o It fragments the data into manageable blocks (max length 16 KB). It optionally compresses the
data.
o Encrypts the data.
o Provides a header for each message and a hash (Message Authentication Code (MAC)) at the
end.
o Hands over the formatted blocks to TCP layer for transmission.

 SSL Handshake Protocol

o It is the most complex part of SSL. It is invoked before any application data is transmitted. It
creates SSL sessions between the client and the server.
o Establishment of session involves Server authentication, Key and algorithm negotiation,
Establishing keys and Client authentication (optional).
o A session is identified by unique set of cryptographic security parameters.
o Multiple secure TCP connections between a client and a server can share the same session.
o Handshake protocol actions through four phases.
 ChangeCipherSpec Protocol
o Simplest part of SSL protocol. It comprises of a single message exchanged between two
communicating entities, the client and the server.
 Change Cipher Spec protocol which is used in the Secure Sockets Layer. This technology
uses cryptographic methods to send data between a client and a server. The protocol is
used to inform the participants that the previous encryption algorithm used for communication
between the browser and the server is to be replaced by a new one.
o As each entity sends the ChangeCipherSpec message, it changes its side of the connection
into the secure state as agreed upon.
o The cipher parameters pending state is copied into the current state.
o Exchange of this Message indicates all future data exchanges are encrypted and integrity is
protected.
 SSL Alert Protocol
o This protocol is used to report errors – such as unexpected message, bad record MAC,
security parameters negotiation failed, etc.
o It is also used for other purposes – such as notify closure of the TCP connection, notify receipt
of bad or unknown certificate, etc.

Establishment of SSL Session

As discussed above, there are four phases of SSL session establishment. These are mainly
handled by SSL Handshake protocol.
Phase 1 − Establishing security capabilities.
 This phase comprises of exchange of two messages – Client_hello and Server_hello.

 Client_hello contains of list of cryptographic algorithms supported by the client

 Server_hello contains the selected Cipher Specification (CipherSpec) and a new session_id.
 The CipherSpec contains fields like −
o Cipher Algorithm (DES, 3DES, RC2, and RC4)
o MAC Algorithm (based on MD5, SHA-1)
o Public-key algorithm (RSA)
o Both messages have “nonce” to prevent replay attack.

Phase 2 − Server authentication and key exchange.

 Server sends certificate. Client software comes configured with public keys of various “trusted”
organizations (CAs) to check certificate.
 Server sends chosen cipher suite.
 Server may request client certificate. Usually it is not done.
 Server indicates end of Server_hello.

Phase 3 − Client authentication and key exchange.

 Client sends certificate, only if requested by the server.

 It also sends the Pre-master Secret (PMS) encrypted with the server’s public key.
 Client also sends Certificate_verify message if certificate is sent by him to prove he has the
private key associated with this certificate. Basically, the client signs a hash of the previous
messages.

Phase 4 − Finish.

 Client and server send Change_cipher_spec messages to each other to cause the pending
cipher state to be copied into the current state.
 From now on, all data is encrypted and integrity protected.
 Message “Finished” from each end verifies that the key exchange and authentication
processes were successful.
All four phases, discussed above, happen within the establishment of TCP session. SSL
session establishment starts after TCP SYN/ SYNACK and finishes before TCP Fin.

Resuming a Disconnected Session

 It is possible to resume a disconnected session (through Alert message), if the client sends
a hello_request to the server with the encrypted session_id information.
 The server then determines if the session_id is valid. If validated, it exchanges
ChangeCipherSpec and finished messages with the client and secure communications resume.
 This avoids recalculating of session cipher parameters and saves computing at the server and
the client end.
 SSL Session Keys

We have seen that during Phase 3 of SSL session establishment, a pre-master secret is sent
by the client to the server encrypted using server’s public key. The master secret and various
session keys are generated as follows −
 The master secret is generated (via pseudo random number generator) using −
o The pre-master secret.
o Two nonces(random or semi-random number that is generated for a specific use) (RA
and RB) exchanged in the client_hello and server_hello messages.
 Six secret values are then derived from this master secret as −
o Secret key used with MAC (for data sent by server)
o Secret key used with MAC (for data sent by client)
o Secret key and IV used for encryption (by server)
o Secret key and IV used for encryption (by client)

2.TLS Protocol
In order to provide an open Internet standard of SSL, IETF released The Transport Layer
Security (TLS) protocol in January 1999. TLS is defined as a proposed Internet Standard in
RFC 5246.

Salient Features

 TLS protocol has same objectives as SSL.

 It enables client/server applications to communicate in a secure manner by authenticating,
preventing eavesdropping and resisting message modification.
 TLS protocol sits above the reliable connection-oriented transport TCP layer in the networking
layers stack.
 The architecture of TLS protocol is similar to SSLv3 protocol. It has two sub protocols: the TLS
Record protocol and the TLS Handshake protocol.
 Though SSLv3 and TLS protocol have similar architecture, several changes were made in
architecture and functioning particularly for the handshake protocol.

Comparison of TLS and SSL Protocols

There are main eight differences between TLS and SSLv3 protocols. These are as follows −
 Protocol Version − The header of TLS protocol segment carries the version number 3.1 to
differentiate between number 3 carried by SSL protocol segment header.
 Message Authentication − TLS employs a keyed-hash message authentication code (H-
MAC). Benefit is that H-MAC operates with any hash function, not just MD5 or SHA, as
explicitly stated by the SSL protocol.
 Session Key Generation − There are two differences between TLS and SSL protocol for
generation of key material.
o Method of computing pre-master and master secrets is similar. But in TLS protocol,
computation of master secret uses the HMAC standard and pseudorandom function (PRF)
output instead of ad-hoc MAC.
o The algorithm for computing session keys and initiation values (IV) is different in TLS than SSL
protocol.
 Alert Protocol Message −
o TLS protocol supports all the messages used by the Alert protocol of SSL, except No
certificate alert message being made redundant. The client sends empty certificate in case
client authentication is not required.
o Many additional Alert messages are included in TLS protocol for other error conditions such
as record_overflow, decode_error etc.
 Supported Cipher Suites − SSL supports RSA, Diffie-Hellman and Fortezza cipher suites.
TLS protocol supports all suits except Fortezza ( Fortezza is an information security system that
uses the Fortezza Crypto Card, a PC Card -based security token.)
 Client Certificate Types − TLS defines certificate types to be requested in
a certificate_request message. SSLv3 support all of these. Additionally, SSL support certain
other types of certificate such as Fortezza.
 CertificateVerify and Finished Messages −
o In SSL, complex message procedure is used for the certificate_verify message. With TLS, the
verified information is contained in the handshake messages itself thus avoiding this complex
procedure.
o Finished message is computed in different manners in TLS and SSLv3.
 Padding of Data −In SSL protocol, the padding added to user data before encryption is the
minimum amount required to make the total data-size equal to a multiple of the cipher’s block
length. In TLS, the padding can be any amount that results in data-size that is a multiple of the
cipher’s block length, up to a maximum of 255 bytes.
The above differences between TLS and SSLv3 protocols are summarized in the following
table.
 Secure Browsing - HTTPS
In this section, we will discuss the use of SSL/TLS protocol for performing secure web
browsing.

HTTPS Defined

Hyper Text Transfer Protocol (HTTP) protocol is used for web browsing. The function of
HTTPS is similar to HTTP. The only difference is that HTTPS provides “secure” web browsing.
HTTPS stands for HTTP over SSL. This protocol is used to provide the encrypted and
authenticated connection between the client web browser and the website server.

The secure browsing through HTTPS ensures that the following content are encrypted −

 URL of the requested web page.

 Web page contents provided by the server to the user client.
 Contents of forms filled in by user.
 Cookies established in both directions.

Working of HTTPS

HTTPS application protocol typically uses one of two popular transport layer security protocols
- SSL or TLS. The process of secure browsing is described in the following points.
 You request a HTTPS connection to a webpage by entering https:// followed by URL in the
browser address bar.
 Web browser initiates a connection to the web server. Use of https invokes the use of SSL
protocol.
 An application, browser in this case, uses the system port 443 instead of port 80 (used in case
of http).
 The SSL protocol goes through a handshake protocol for establishing a secure session as
discussed in earlier sections.
 The website initially sends its SSL Digital certificate to your browser. On verification of
certificate, the SSL handshake progresses to exchange the shared secrets for the session.
 When a trusted SSL Digital Certificate is used by the server, users get to see a padlock icon in
the browser address bar. When an Extended Validation Certificate is installed on a website, the
address bar turns green.

 Once established, this session consists of many secure connections between the web server
and the browser.

Use of HTTPS

 Use of HTTPS provides confidentiality, server authentication and message integrity to the user.
It enables safe conduct of e-commerce on the Internet.
 Prevents data from eavesdropping and denies identity theft which are common attacks on
HTTP.
Present day web browsers and web servers are equipped with HTTPS support. The use of
HTTPS over HTTP, however, requires more computing power at the client and the server end
to carry out encryption and SSL handshake.
3.Secure Electronic Transaction(SET)
Secure Electronic Transaction or SET is a system which ensures security and
integrity of electronic transactions done using credit cards in a scenario. SET is not
some system that enables payment but it is a security protocol applied on those
payments. It uses different encryption and hashing techniques to secure payments
over internet done through credit cards. SET protocol was supported in development
by major organizations like Visa, Mastercard, Microsoft which provided its Secure
Transaction Technology (STT) and NetScape which provided technology of Secure
Socket Layer (SSL).
SET protocol restricts revealing of credit card details to merchants thus keeping
hackers and thieves at bay. SET protocol includes Certification Authorities for
making use of standard Digital Certificates like X.509 Certificate.
Before discussing SET further, let’s see a general scenario of electronic
transaction, which includes client, payment gateway, client financial institution,
merchant and merchant financial institution.

Requirements in SET :
SET protocol has some requirements to meet, some of the important
requirements are :
 It has to provide mutual authentication i.e., customer (or cardholder)
authentication by confirming if the customer is intended user or not and
merchant authentication.
 It has to keep the PI (Payment Information) and OI (Order Information)
confidential by appropriate encryptions.
 It has to be resistive against message modifications i.e., no changes should be
allowed in the content being transmitted.
 SET also needs to provide interoperability and make use of best security
mechanisms.
Participants/modulesin SET :
In the general scenario of online transaction, SET includes similar participants:
1. Cardholder – customer
2. Issuer – customer financial institution
3. Merchant
4. Acquirer – Merchant financialinstirution
5. Certificate authority – Authority which follows certain standards and issues
certificates(like X.509V3) to all other participants.

SET functionalities :

o Provide Authentication
 Merchant Authentication – To prevent theft, SET allows customers
to check previous relationships between merchant and financial
institution. Standard X.509V3 certificates are used for this verification.
 Customer / Cardholder Authentication – SET checks if use of
credit card is done by an authorized user or not using X.509V3
certificates.

o Provide Message Confidentiality : Confidentiality refers to preventing
unintended people from reading the message being transferred. SET
implements confidentiality by using encryption techniques. Traditionally DES is
used for encryption purpose.
o Provide Message Integrity : SET doesn’t allow message modification with the
help of signatures. Messages are protected against unauthorized modification
using RSA digital signatures with SHA-1 and some using HMAC with SHA-1,

Dual Signature :
The dual signature is a concept introduced with SET, which aims at connecting
two information pieces meant for two different receivers :

Order Information (OI) for merchant

Payment Information (PI) for bank

You might think sending them separately is an easy and more secure way, but
sending them in a connected form resolves any future dispute possible. Here is
Generation of dual signature:

Where, hash=message digest

PI stands for payment information

OI stands for order information
PIMD stands for Payment Information Message Digest
OIMD stands for Order Information Message Digest
POMD stands for Payment Order Message Digest
H stands for Hashing
E stands for public key encryption
KPc is customer's private key
|| stands for append operation
Dual signature, DS= E(KPc, [H(H(PI)||H(OI))])

Purchase Request Generation :

The process of purchase request generation requires three inputs:
 Payment Information (PI)
 Dual Signature
 Order Information Message Digest (OIMD)
The purchase request is generated as follows:

Here,
PI, OIMD, OI all have the same meanings as before.
The new things are :
EP which is symmetric key encryption
Ks is a temporary symmetric key
KUbank is public key of bank
CA is Cardholder or customer Certificate
Digital Envelope = E(KUbank, Ks)

Purchase Request Validation on Merchant Side :

The Merchant verifies by comparing POMD generated through PIMD hashing with
POMD generated through decryption of Dual Signature as follows:
Since we used Customer private key in encryption here we use KUc which is
public key of customer or cardholder for decryption ‘D’.

Payment Authorization and Payment Capture :(marchent financial

institutation)

Payment authorization as the name suggests is the authorization of payment

information by merchant which ensures payment will be received by merchant.
Payment capture is the process by which merchant receives payment which
includes again generating some request blocks to gateway and payment gateway
in turn issues payment to merchant.