1

Chapter 7

WEB Security

2

Outline

• Web Security Considerations• Secure Socket Layer (SSL) and

Transport Layer Security (TLS)• Secure Electronic Transaction

(SET)• Recommended Reading and WEB

Sites

3

Web Security Considerations

• The WEB is very visible.• Complex software hide many

security flaws.• Web servers are easy to configure

and manage.• Users are not aware of the risks.

4

Web security threats

• Passive attacks - eavesdropping on network traffic

• Active attacks - impersonating another user, altering messages in transit, altering information on a Web site.

• Attacks on Web server, Web browser and network traffic between browser and server

5

Security facilities in the TCP/IP protocol stack

6

SSL and TLS

• SSL was originated by Netscape• TLS working group was formed

within IETF• First version of TLS can be viewed

as an SSLv3.1

7

SSL Architecture

8

SSL Record Protocol Operation

9

SSL Record Format

10

SSL Record Protocol Payload

11

Handshake Protocol

• The most complex part of SSL.• Allows the server and client to

authenticate each other.• Negotiate encryption, MAC

algorithm and cryptographic keys.• Used before any application data

are transmitted.

12

Handshake Protocol Action

13

Transport Layer Security

• The same record format as the SSL record format.• Defined in RFC 2246.• Similar to SSLv3.• Differences in the:

– version number– message authentication code– pseudorandom function– alert codes– cipher suites – client certificate types– certificate_verify and finished message– cryptographic computations– padding

14

Secure sockets layer summary

• transport layer security to any TCP-based app using SSL services.

• used between Web browsers, servers for e-commerce (shttp).

• security services:– server

authentication– data encryption – client

authentication (optional)

• server authentication:– SSL-enabled browser

includes public keys for trusted CAs.

– Browser requests server certificate, issued by trusted CA.

– Browser uses CA’s public key to extract server’s public key from certificate.

• check your browser’s security menu to see its trusted CAs.

15

SSL (summary continued)

Encrypted SSL session:• Browser generates

symmetric session key, encrypts it with server’s public key, sends encrypted key to server.

• Using private key, server decrypts session key.

• Browser, server know session key– All data sent into TCP

socket (by client or server) encrypted with session key.

• SSL: basis of IETF Transport Layer Security (TLS).

• SSL can be used for non-Web applications, e.g., IMAP.

• Client authentication can be done with client certificates.

16

Secure Electronic Transactions

• An open encryption and security specification.

• Protect credit card transaction on the Internet.

• Companies involved:– MasterCard, Visa, IBM, Microsoft,

Netscape, RSA, Terisa and Verisign• Not a payment system.• Set of security protocols and formats.

17

SET Services

• Provides a secure communication channel in a transaction.

• Provides trust by the use of X.509v3 digital certificates.

• Ensures privacy.

18

SET Overview

• Key Features of SET:– Confidentiality of information– Integrity of data– Cardholder account

authentication– Merchant authentication

19

SET Participants

20

Sequence of events for transactions

1. The customer opens an account.2. The customer receives a certificate.3. Merchants have their own certificates.4. The customer places an order.5. The merchant is verified.6. The order and payment are sent.7. The merchant request payment authorization.8. The merchant confirm the order.9. The merchant provides the goods or service.10.The merchant requests payments.

21

Dual signature

• Customer has to send OI to the merchant and payment information to the bank;

• Merchant does not need to know the customer’s credit card number and the bank does not need to know the detail’s of the customer’s order;

• Merchant should be precluded from linking OI from one transaction with PI from another transaction

22

Dual Signature

H(OI))]||)(([ PIHHEDScKR

23

Dual signature

• Merchant computes H(PIMD||H(OI) and Dkuc[DS} to get the OI and verify customer signature

• Bank computes H(H(PI)||OIMD) and Dkuc[DS] to get the PI and verify customer the signature

• Customer has linked the OI and PI and can prove the linkage

24

Purchase request exchange

• Initiate request - client to merchant (includes brand of card to be used and nonce)

• Initiate response - merchant to client ( includes merchant’s signature certificate, two nonces, payment gateway’s key exchange certificate)

• Purchase request - client to merchant (next slide)

• Verification of the request by the merchant• Purchase response - merchant to client

(acknowledges the order )

25

Payment processing

Cardholder sends Purchase Request

26

Verification of the purchase request

27

Payment authorization

– Authorization Request - merchant to payment gateway - includes purchase related info, authorization related info, certificates

– Verification of the request by the payment gateway (indirectly by the issuer)

– Authorization Response - by the payment gateway (indirectly by the issuer) - guarantees that the merchant will receive payment - includes authorization related info, capture token info and gateway certificate

28

Payment Capture

• Merchant to payment gateway: Capture Request - includes the payment amount, the transaction ID and capture token

• payment gateway send a fund transfer request to the issuer over the private payment network

• Payment gateway to merchant: Capture Response - notifies the merchant about the fund transfer