No one will manufacture a lock without a key.

Similarly God won't give problems without solutions.

Web Security Threats

Security threats can be classified 1. Passive & Active Attacks
Passive Attack : do not involve any modifications to the contents of an original message, it is just eavesdropping Release of message contents and traffic analysis Active Attack : the contents of the original message are modified in some ways Trying to pose another entity involves masquerade attack, i.e. impersonating another user Modification attacks : replay attack, and alteration of messages Fabrication causes Denial of Service attacks (DOS)

2. Location of the threat : Web server, Web browser & N/W traffic between browser & server

Threats Integrity * Modification of user data * Trojan horse browser * Modification of memory

Consequences

Countermeasures

* Modification of message traffic in transit

* Loss of info. Cryptographic * Compromise of checksum machine * Vulnerability to all other threats

Threats

Consequences

Countermeasures

Confide * Eavesdropping on the Net * Loss of info. ntiality *Theft of info from server * Loss of privacy *Theft of data from client * Info about network config * Info about which client talks to server

Encryption, Web proxies

Threats DOS

Consequences

Countermeasures Difficult to prevent

* Killing of user threads * Disruptive * Flooding machine with * Annoying bogus request * Filling up disk or memory * Prevent user from getting work done * Isolating machine by DNS attack

Threats

Consequences

Countermeasures

Auth enti cation

* Impersonation of legitimate users * Data forgery

* Misrepresentation of users * Belief that false information is valid

Cryptographic technique

Web Traffic Security Approaches

IP Security is used to provide Web security
HTTP FTP TCP IP/IPSec SMTP

It is transparent to end users and applications and provides a general-purpose solution. It includes a filtering capability so that only selected traffic need incur the overhead of IPSec processing.

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

HTTP FTP TCP SSL or TLS IP SMTP

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 SSL can be embedded in specific packages, Netscape and Microsoft Explorer browser come equipped with SSL, & most Web servers have implemented the protocol

Application-specific security services are embedded within the particular applications

S/MIME
Kerberos

PGP

SET HTTP

TCP SMTP TCP IP

UDP

The service can be tailored to the specific needs of a given application In the context of web security, an important example of this approach is Secure Electronic Transaction (SET)

Secure Socket Layer

SSL protocol is an Internet Protocol for secure exchange of information between a Web browser and a Web server i.e. reliable end-to-end secure service
It provides two basic security services : authentication and confidentiality Logically, it provides a secure pipe between the Web browser and the Web server

Position of SSL in TCP/IP

Application Layer
SSL Layer Transport Layer

The SSL layer is located between the application layer and the transport layer

Internet Layer Data Link Layer Physical Layer

SSL Protocol Stack

SSL Handshake protocol
SSL Change cipher spec protocol SSL Alert protocol HTTP

SSL Record protocol TCP

IP

HTTP 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 These SSL specific protocols are used in the management of SSL exchanges

Every successful person has a painful story. Every painful story has a successful ending.

Accept the pain and get ready for success.

How SSL works?

SSL has three sub-protocols, namely the Handshake protocol, Record protocol and the Alert protocol These three sub-protocols constitute the working of SSL

SSL Handshake Protocol

The Handshake protocol is used before any application data is transmitted
The Handshake protocol consist of a series of messages exchanged by client and server
Format of the handshake protocol message Type 1 byte Length 3 byte Content 1 or more byte

* Type (1 byte) : Indicates one of 10 messages fields Each Handshake message has three * Length (3 byte) : The length of the message in bytes

* Content (1 or more bytes) : The parameters associated with this message

SSL handshake protocol message type

Message Type
Hello_request Client_hello Server_hello Certificate Server_key_exchange Certificate_request Server_hello_done Certificate_verify Client key_exchange Finished

Parameters
None Version, random, session id, cipher suite, compression method Version, random, session id, cipher suite, compression method Chain of X.509V3 certificate Parameters, signatures Type, authorities None Signature Parameters, signature Hash value

Handshake protocol is made up of 4 phases

1. Establish security capabilities 2. Server authentication & key exchange 3. Client authentication & key exchange
Web browser

4. Finish

Web server

Phase 1 : Establish security capabilities

Used to initiate a logical connection & to establish the security capabilities that will be associated with it. This consists of two messages, client hello & server hello The exchange is initiated by the client, which sends a client_hello message with the parameters as

Web browser

Step 1 : Client hello Step 2 : Server hello

Web server

The exchange is initiated by the client, which sends a client_hello message with the parameters as Version : The highest SSL version understood by the client Random : Useful for later commn Session ID : This is a variable length session identifier Cipher suite : This list contains the cryptographic algorithms supported by the client in decreasing order

Compression method : This is a list of the compression methods the client supports
The server hello message consists of Version Random Session ID Cipher suite

Client

Server

Handshake Protocol Action

Phase 1 : Establish security capabilities, including protocols version, session ID, cipher suite, compression method & initial random numbers

Phase 2 : Server Authentication & Key Exchange

The server initiates this second phase & is sole sender of all the messages in this phase

The client is sole recipient of all these messages

This phase contains four steps as shown below
Web browser

Step 1 : Certificate

Step 2 : Server key exchange Step 3 : Certificate request Step 4 : Server hello done

Web server

1. The server sends its digital certificate, authenticating 2. It is optional. Server sends its public key to the client

3. The server can request for the clients digital certificate

4. Message indicates th the client that its portion of the hello message is complete

Client

Server

Handshake Protocol Action

Phase 1 : Establish security capabilities, including protocols version, session ID, cipher suite, compression method & initial random numbers

Phase 2 : Server may send certificate, key exchange & request certificate. Server signals end of hello message phase

Phase 3 : Client Authentication & key Exchange

Upon receipt of the server_done message, the client verify that the server provided a valid certificate The server is the sole recipient of all messages :
Web browser

Step 1 : Certificate Step 2 : Client key Exchange

Web server

Step 3 : Certificate verify

1. It is optional, requires only if the server had requested for the clients digital certificate 2. Like server key exchange, it allows the client to send info. To the server, but in the opposite direction. 3. It is necessary only if the server had demanded client authentication

Client

Server

Handshake Protocol Action

Phase 1 : Establish security capabilities, including protocols version, session ID, cipher suite, compression method & initial random numbers

Phase 2 : Server may send certificate, key exchange & request certificate. Server signals end of hello message phase

Phase 3 : Client sends certificate if requested. Client sends key exchange. Client may send certificate verification

Phase 4 : Finish
The client initiates this phase, which the server ends This phase completes the setting up of a secure connection This phase contains four steps :
Web browser

Step 1 : Change cipher specs Step 2 : Finished Step 3 : Change cipher specs Step 4 : Finished

Web server

Client

Server

Handshake Protocol Action

Phase 1 : Establish security capabilities, including protocols version, session ID, cipher suite, compression method & initial random numbers

Phase 2 : Server may send certificate, key exchange & request certificate. Server signals end of hello message phase

Phase 3 : Client sends certificate if requested. Client sends key exchange. Client may send certificate verification

Phase 4 : Change cipher suite and finish handshake protocol

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 connections, as follows * Confidentiality : This is achieved by using the secret key that is defined by the handshake protocol * Message Integrity : The Handshake protocol also defines a shared secret key that is used to form a message authentication code (MAC) The operation of the record protocol is

The SSL record protocol takes an application message as input Application data Fragment Fragmentation : The original application message is broken into blocks, so that theCompress size of each block is less than or equal to 214 bytes (16,384 bytes). Compression : The fragmented blocks are optionally compressed. Compression must be lossless. Add MAC Addition of MAC : Using the shared secret key established in handshake protocol, the MAC (message authentication code) Encrypt for each block is calculated. Encryption : Using symmetric key established in the handshake protocol, the output Append SSL record header encrypted. This of the previous step is now encryption may not increase the overall size of the block by Append header : Finally, a header is added to the encrypted block : more than 1024 bytes Content type (8 bits) Major version (8 bits) Minor version (8 bits) Compressed length (16 bits)

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). Compression : The fragmented blocks are optionally compressed. Compression must be lossless. Addition of MAC : Using the shared secret key established in handshake protocol, the MAC for each block is calculated. Encryption : Using symmetric key established 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 SSL Record Format more than 1024 bytes Append header : Finally, a header is added to the encrypted block : Content type (8 bits) Major version (8 bits) Minor version (8 bits) Compressed length (16 bits)
Content type Major version Minor Compressed version length

Encrypted

Plaintext (optionally compressed)

MAC (0, 16 or 20 bytes)

The Alert Protocol

When either the client or the server detects an error, the detecting party sends an alert message to the other party. If the error is fatal, both the parties immediately close the SSL connection.

Both the parties also destroy the session identifiers, secrets and keys associated with this connection before it is terminated. Each alert message consists of two bytes. 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 specifies the actual error
Alert protocol message format
Severity Byte 1 Cause Byte 2

Fatal Alerts

Alert Unexpected message Bad record MAC Decompression failure

Description An inappropriate message was received An incorrect MAC was received The decompression function received improper input

Handshake failure

Sender was unable to negotiate an acceptable set of security parameters given the options available
A field in the handshake message was out of range or was inconsistent with the other field

Illegal parameters

Non-Fatal Alerts
Alert No certificate Bad certificate Unsupported certificate Description Sent in response to certificate request if an appropriate certificate is not available The certificate was corrupt The type of received certificate is not supported

Certificate revoked
Certificate expired Certificate unknown

the signer of a certificate has revoked it

A certificate has expired An unspecified error occurred while processing the certificate

Close notify

Notifies the recipient that the sender will not send any more messages on this connection. Each party must send this message before closing its side of the connection

Change Cipher Spec Protocol

This protocol consists of single message, which consists of a single byte with the value 1.
1

Byte 1

The sole purpose of this message is cause the pending state to be copied into the current state, which updates the cipher suite to be used on this connection.

Transport Layer Security

Computer Security Chapter-6

31

Transport Layer Security

TLS is defined as a Proposed Internet Standard in RFC 2246 The core idea and implementation are similar
Difference between SSL and TLS

Property Version Cipher suite

SSL

TLS

3.0 1.0 Supports an algorithm Does not support Fortezza called as Fortezza Cryptography Computed Uses a pseudorandom function to create master secret
Alert Protocol As explained earlier
The No certificate alert message is deleted. The newly added : Decryption failed, Record overflow, Unknown CA, Access denied, Decode error, Export restriction, Protocol version, Insufficient security, Internal error.

Handshake Protocol

As explained earlier

Some details are changed

Computer Security Chapter-6

32

LEARN FROM WATER

It the shape of the It takes is Transparent It doesnt encroach the top It mixes up easily container it in the vessel It settles down is put into It gives life

Secure Electronic Transaction

SET is an open encryption & security specification that is designed for protecting credit card transaction on the Internet Set is not a payment system. Instead, it is a set of security protocols and formats that enables the users to employ the existing credit card payment infrastructure on the Internet in a secure manner. SET services can be summarized as follows : 1. Provides a secure communication channel among all parties involved in an e-commerce transaction 2. It provides authentication by the use of digital certificate 3. It ensures confidentiality, because the information is only available to the parties involved in a transaction & that too only when & where necessary
Computer Security Chapter-6

34

Key Features of Secure Electronic Transaction

Confidentiality of info Integrity of data Cardholder account authentication

Merchant authentication

Computer Security Chapter-6

35

SET Participants
Cardholder : A cardholder is an authorized holder of a payment card such as MasterCard or Visa, issued by issuer Merchant : A merchant is a person or organization that has goods or services to sell to the cardholder. A merchant that accepts payment cards must have a relationship with acquirer Issuer : The issuer is a financial institution, such as bank, that provides a payment card to a cardholder. Acquirer : This is a financial institution that establishes an account with a merchant & processes payment card authorizations & payments. Payment gateway : It acts as an interface between SET & the existing card payment network for payment authorizations Certificate authority : This is an authority that is trusted to provide public key certificates to cardholders, merchants and payment gateways
36
Computer Security Chapter-6

When a customer involved a the actualissues a merchants Three main parties receives is acquirer, therequests theis their The certificate to customer inissuedmake bank or it credit A financial institution, an merchant transaction for The merchant and the customer by certificate, are also assured that the merchant and the payment gateway The customer, whomerchant is the card to the accept payments 37 respective certificates issued authorized to customer certificate. card company the has for that brand of credit card

Three main parties involved in the actual transaction are The customer, the merchant and the payment gateway

The merchant and the customer make requests for their respective certificates

The certificate to customer is issued by the bank or the credit card company who has issued the card to the customer
A financial institution, an acquirer, issues a merchants certificate. When a customer receives a merchant certificate, it is also assured that the merchant is authorized to accept payments for that brand of credit card

Computer Security Chapter-6

38

The SET Model

Please verify the cardholders certificate Please verify the merchants certificate Certificate Authority Group
You can act as a CA

You can act as a CA

Certificate Authority A
Request for a certificate
Merchants certificate

Certificate Authority B
Cardholders certificate

Request for a certificate

Purchase Response Merchant

Authorization Request

Purchase Request

Cardholder

Authorization Response

Payment Gateway

39

The SET Process

1. The customer opens an account 2. The customer receives a certificate 3. The merchant receives a certificate

4. The customer places an order

5. The merchant is verified

6. The order and payment details are sent

7. The merchant requests payment authorization 8. The payment gateway authorizes the payment 9. The merchant confirms the order 10. The merchant provides goods or services 11. The merchant requests payment
Computer Security Chapter-6

40

Computer Security Chapter-6

41

SSL Vs SET
Issue
Main aim
Certification Authentication Risk of merchant fraud Risk of customer fraud Action in case of Customer fraud Practical usage

SSL
Exchange of data in an Encrypted form
two parties exchange certificate Mechanisms in place, but not very strong Possible, since customer gives financial data to merchant Possible, no mechanisms exist if a customer refuses to pay later Merchant is liable High
Computer Security Chapter-6

SET
E-commerce related payment mechanism
All the involved parties must be certified Strong mechanisms for authenticating all parties Unlikely, since customer gives financial data to payment gateway Customer has to digitally sign payment instructions Payment gateway is liable No much

42

End of Chapter 6

End of Syllabus
Happy Diwali & Best of Luck for Exam