Chapter-7

Web Security
 Secure Socket Layer(SSL)-
Introduction-
• The SSL protocol is an Internet protocol for secure exchange of information between a Web browser and a Web server.
• It provides two basics security services- authentication and confidentiality.
• Logically, it provides a secure pipe between the Web browser and the Web server.

The position of SSL in TCP/IP protocol suite-

• SSL can be conceptually considered as an additional layer in the TCP/IP protocol suite.
• The SSL layer is located between the application layer and the transport layer as shown in fig.
 • As such, the communication between the various TCP/IP protocol layers is now as shown in fig-

✔ How SSL Works?

• SSL has three sub protocols,-
1. Handshake Protocol
2. Record Protocol
3. The Alert Protocol
1. The Handshake Protocol-
• The handshake protocol consists of a series of messages between the client and the server.
• Each of these messages has the format shown in fig-

• As shown in fig., each handshake message has three fields, as follows-

• Type(1 byte)- This field indicates one of the ten possible message types. These ten message types are listed in fig-
 • Length (3 bytes)- This field indicates the length of the message in bytes.
• Content (1 or more bytes)- This field contains the parameters associated with this message, depending on the message
type.

• The handshake protocol is actually made up of four phases as shown in fig. These phases are –
1. Establish security capabilities
2. Server authentication and key exchange
3. Client authentication and key exchange
4. Finish
Phase 1: Establish Security Capabilities-
• This first phase of the SSL handshake is used to initiate a logical connection and establish the security capabilities
associated with that connection.
• This consists of two messages,- the client hello and the server hello, as shown in fig.
• As shown in fig, the process starts with a client hello message from the client to the server.
• It consists of the following parameters-
• Version: This field identifies the highest version of SSL that the client can support. This can be 2,3 or 3.1.
• Random: This field is useful for the later, actual communication between the client and the server. It contains two
sub-fields-
1. A 32-bit date-time field that identifies the current system date and time on the client computer.
2. A 28-byte random number generated by the random number generator software built inside the client computer.
• Session id: This is a variable length session identifier. If this field contains a non-zero value, it means that there is
already a connection between the client and the server, and the client wishes to update the parameters of that connection.
A zero value in this field indicates that the client wants to create a new connection with the server.
• Cipher suite: This list contains a list of the cryptographic algorithms supported by the client (e.g. RSA, Diffie-Hellman,
etc.), in the decreasing order of preference.
• Compression method: This field contains a list of the compression algorithms supported by the client.

• The server hello message consists of the following fields:

• Version: This field identifies the lower of the version suggested by the client and the highest supported by the server.
E.g. if the client had suggested version 3, but the server also supports version 3.1, the server will select 3.
• Random: This field has the same structure as the Random field of the client. However, the Random value suggested by
the server is completely independent of the client’s Random value.
• Session id: If the session id value sent by the client was non-zero, the server uses the same value. Otherwise, the server
creates a new session id and outs it in this field.
• Cipher suite: Contains a single cipher suite, which the server selects from the list sent earlier by the client.
• Compression method: Contains a compression algorithm, which the server selects from the list sent earlier by the client.
 Phase 2: Server Authentication and Key Exchange-
• The server initiates this second phase of the SSL handshake and is the sole sender of all the messages in this phase,
• The client is the sole recipient of all these messages.
• This phase contains four steps as shown in fig. These steps are-
1. Certificate
2. Server key exchange
3. Certificate request
4. Server hello done.
 Phase 3: Client Authentication and Key Exchange-
• The client initiates this third phase of the SSL handshake and is the sole sender of all the messages in this phase,
• The server is the sole recipient of all these messages.
• This phase contains three steps as shown in fig. These steps are-
1. Certificate
2. Client key exchange
3. Certificate verify
Phase 4: Finish-
• The client initiates this fourth phase of SSL handshake, which the server ends.
• This phase contains four steps, as shown in fig.

• The first two messages are from the client : Change cipher specs, Finished.
• The server responds back with two identical messages : Change cipher specs, Finished.
✔ The Record Protocol-
• The Record Protocol in SSL comes into picture after a successful handshake is completed between the client and the
server.
• This protocol provides two services to an SSL connection, as follows-
1. Confidentiality: This is achieved by using the secret key that is defined by the handshake protocol.
2. Integrity: The handshake protocol also defines a shared secret key (MAC) that is used for assuring the message
integrity.
• The operation of the record protocol is shown in fig-
1. Fragmentation: The original application message is broken into blocks, so that the size of each block is less than or equal
to 214 bytes(16,384 bytes).
2. Compression: The fragmented blocks are optionally compressed. The compression process must not result into the loss of
the original data, which means that this must be loss-less compression mechanism.
3. Addition of MAC: Using the shared secret key established previously in the handshake protocol, the Message
Authentication Code(MAC) for each block is calculated.
4. Encryption: Using the symmetric key established previously in the handshake protocol, the output of the previous step is
now encrypted. This encryption may not increase the overall size of the block by more than 1024 bytes.
• Following table lists the permitted encryption algorithms-
 5. Append header: Finally, a header is added to the encrypted block. The header contains the following fields-
a. Content type (8 bits)-Specifies the protocol used for processing the record in the next higher level .
b. Major version (8 bits)- Specifies the major version of the SSL protocol in use. For instance, if SSL version 3.1 is in use ,
this field contains 3.
c. Minor version (8 bits)- Specifies the minor version of the SSL protocol in use. For instance, if SSL version 3.0 in use,
this field contains 0.
d. Compressed length (16 bits)- Specifies the length in bytes of the original plain text block ( or the compressed block, if
compression is used)

The final SSL message now looks as shown in fig-

✔ The Alert protocol-
• When either the client or the server detects as error, the detecting party sends as alert message to the other party.
• Each alert message consists of two bytes- The first byte signifies the type of error. If it is a warning, this byte contains 1.
If the error is fatal, this byte contains 2.
• The second byte specifies the actual error.

• List of fatal alerts (error)-

• List of non-fatal alerts-

• Closing and Resuming SSL connection-

• Before ending their communication, the client and the server must inform each other that their side of the connection is
ending.
• Each party sends a Close notify alert to the other party. This ensures a graceful closure of the connection.
• When a party receives this alert, it must immediately stop whatever it is doing, send its own Close notify alert and end the
connection from its side as well.
• If an SSL connection ends without a Close notify from either party, it cannot be resumed.
 Transport Layer Security (TLS)
• TLS is an IETF standardization initiative, whose goal is to come out with an Internet standard version of SSL.
• Differences between SSL and TLS
 Secure Electronic Transaction (SET)-
• The SET is an open encryption and security specification that is designed for protecting credit card transactions on the
Internet.
• SET services can be summarized as follows-
1. It provides a secure communication channel among all the parties involved in an e-commerce transaction.
2. It provides authentication by the use of digital certificates.
3. It ensures confidentiality, because the information is only available to the parties involved in a transaction and that too
only when and where necessary.

SET Participants-
• Cardholder- Using the Internet, consumers and corporate purchases interact with merchants for buying goods and
services. A Cardholder is an authorized holder of a payment card such as MasterCard or Visa that has been issued by an
Issuer.
• Merchant- A merchant is a person or an organization that wants to sell goods or services to cardholders. A merchant must
have a relationship with an Acquirer for accepting payments on the Internet.
• Issuer- The issuer is a financial institution (such as bank) that provides a payment card to a cardholder. The most critical
point is that issuer is the ultimately responsible for the payment of the cardholder’s debt.
• Acquirer-This is a financial institution that has a relationship with merchants for processing payment card authorizations
and payments. The reason for having acquires is that merchants accept credit cards of more than one brand, but are not
interested in dealing with so many bankcard organizations or issuers. Instead, an acquirer provides the merchant an
assurance( with the help of issuer) that a particular cardholder account is active and that the purchase amount does not
exceed the credit limits ,etc. The acquirer also provides electronic funds transfer to the merchant account. Later, the issuer
reimburses the acquirer using some payment network.
 • Payment Gateway- This can be taken up by the acquirer or an organization as a dedicated function. The payment
gateway processes the payment messages on behalf of the merchant. Specifically in SET, the payment gateway acts as an
interface between SET and the existing card payment networks for payment authorizations. The merchant exchanges SET
messages with the payment gateway over the Internet. The payment gateway, in turn, connects to the acquirer’s systems
using a dedicated network line in most cases.
• Certification Authority (CA)- This is an authority that is trusted to provide public key certificates to cardholders,
merchant and payment gateways.

The SET Process-

1. The customer opens an account-The customer opens a credit card account (such as MasterCard or Visa) with a bank
(issuer) that supports electronic payment merchants and the SET protocol.
2. The customer receives a certificate- After the customer’s identity is verified (with the help of details such as passport,
business documents etc. ) , the customer receives a digital certificates from a CA. The certificate also contains such as the
customer’s public key and its expiration date.
3. The merchant receives a certificate- A merchant that wants to accept a certain brand of credit cards must posses a
digital certificate.
4. The customer places an order- This is typical shopping cart process wherein the customer browses the list of items
available, searches for specific items, selects one or more of them and places the order. The merchant, in turn, sends back
details such as the list of items selected, their quantities, prices, total bill etc. back to the customer for his record, with the
help of an order form.
5. The merchant is verified- The merchant also sends its digital certificate to the customer. This assures the customer that
he is dealing with a valid merchant.
 6. The order and payment details are sent- The customer sends both the order and payment details to the merchant along
with the customer’s digital certificate. The order confirms the purchase transaction with reference to the items mentioned in
the order form. The payment contains credit card details. However, the payment information is so encrypted that the merchant
cannot read it. The customer’s certificate assures the merchant of the customer’s identity.
7. The merchant requests payment authorization- The merchant forwards the payment details sent by the customer to the
payment gateway via the acquirer (or to the acquirer if the acquirer also acts as the payment gateway) and requests the
payment gateway to authorize the payment (i.e. ensure that the credit card is valid and that the credit limits are not breached.)
8. The payment gateway authorizes the payment- Using the credit card information received from the merchant, the
payment gateway verifies the details of the customer’s credit card with the help of the issuer, and either authorizes or
rejects the payment.
9. The merchant confirms the order- Assuming that the payment gateway authorizes the payment, the merchant sends a
confirmation of the order to the customer.
10. The merchant provides goods or services- The merchant now ships the goods or provides the services as per the
customer’s order.
11. The merchant requests payment- The payment gateway receives a request from the merchant for making the payment.
The payment gateway interacts with the various financial institutions such as the issuer, acquirer and the cleaning house to
effect the payment from the customer’s account to the merchant’s account.
SSL Versus SET-