Web security

Presentation on

web security

Presented bySubhash BasishthaSaptarshi Boruah

04/12/23 1ASSAM UNIVERSITY SILCHAR

contents Introduction Issues related to web security -client-side issues -server-side issues -data on transmission issues Solution to web security: SSL SSL Architecture Its advantages and uses SET: conclusion


introduction

o Now-a-days almost everything relies on computers and all the sensitive tasks are done through the web:

-communication(email) -shopping(online store) -transportation(e-ticketing) -database access -entertainment etc. “web security involves protecting those information

by preventing,detecting and responding to attacks”


Web security: client-side security risks

Browser risks: -Crashes the browser, damages the user's system, or

merely creates an annoyance. -The misuse of personal information knowingly or

unknowingly provided by the end-user. Active content, such as ActiveX controls and Java

applets:– Introduces the possibility that Web browsing will

introduce viruses or other malicious software into the user's system,

Web security: server-side security risks

Risk: Allow unauthorized remote users to: – Steal confidential documents. – Execute commands on the server host machine

to modify the system. – Gain information about the Web server's host

machine to break into the system. – Launch denial-of-service attacks, rendering the

machine temporarily unusable.


server-side security risks(contd..)

Bugs in the Web server - Buggy software opens up security holes.

Misconfiguration problems in the Web server – A poorly configured Web server can punch a hole in the

most carefully designed firewall system.


Security risk of data in transmission

• Risk: Interception of network data sent from browser to server or vice versa via network eavesdropping. – Eavesdroppers can operate from any point on

the pathway between browser and server .

• Reason: The TCP/IP protocol was not designed with security in mind; hence it is vulnerable to network eavesdropping.


Secure Socket Layer

(SSL)


SSL

SSL is the most used security protocol for authentication on the Web and developed by Netscape communication in 1995.

SSL secures data exchange between a client and a server by encrypting it.

SSL runs above TCP/IP and below higher-level protocols such as HTTP.

SSL protocol allows client-server applications to communicate in such a way that they prevent eavesdropping, tampering or message forgery.


SSL provides 3 main things:• End Point Authentication

– The server is the actual party you wish to communicate with, not someone faking their identity.

• Message Integrity– The data exchange with the server has not been modified along the

way. If it is, it can be easily detected.

• Confidentiality– Data is encrypted. A hacker cannot read your information by simply

looking at the packets on the network.


How SSL works:

• Secure Web pages feature “https” in their URL instead of the usual “http”.

• The browser sees the https in the URL and initiates a connection to the SSL port on the Web server.


SSL Architecture

SSL is designed to make use of TCP to provide a reliable end-to-end secure service.

SSL is a two layer protocol: -at the lower level there is SSL record

protocol and - at the upper level there are higher layer protocol

such as handshake protocol, change cipher spec protocol and the alert protocol.


SSL Architecture


SSL Record protocol

• The SSL Record Protocol is used to encapsulate various higher-level protocols.

• The SSL Record Protocol takes the upper-layer application message to be transmitted, Fragments the data into manageable blocks, optionally compresses the data, applies an MAC, encrypts, adds a header, and transmits the result to TCP.

• The received data is decrypted, verified, decompressed, reassembled ,and then delivered to higher-level clients.


Operation of SSL record protocol



• The first step is fragmentation. Each upper-layer message is fragmented into blocks of 214 Bytes (16384 bytes) or less.

• Next, compression is optionally applied. Compression must be lossless and may not increase the content length by more than 1024 bytes. In SSLv3,no compression algorithm is specified, so the default compression algorithm is null.

• The next step in processing is to compute Message Authentication Code over the compressed data. For this purpose, a shared secret key is used.


MAC operation



• Next, the compressed message plus the MAC are encrypted using symmetric encryption. Encryption may not increase the content length by more than 1024 bytes. The following encryption algorithms are permitted:



The final step of SSL Record Protocol processing is to append a header, consisting of the following fields:

o Content Type (8 bits): The higher layer protocol used to process the enclosed fragment.

o Major Version (8 bits): Indicates major version of SSL in use. For SSLv3, the value is 3.

o Minor Version (8 bits): Indicates minor version in use. For SSLv3, the value is 0.

o Compressed Length (16 bits): The length in bytes of the plaintext fragment (or compressed fragment if compression is used).

SSL Change Cipher Spec Protocol

• The Change Cipher Spec Protocol is the simplest of the three SSL-specific protocols.

• This protocol consists of a single message,which is compressed and encrypted under the current CipherSpec. The message consists of a single byte of value 1.

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

• The client sends a change CipherSpec message following handshake key exchange and certificate verify messages (if any),and the server sends one after successfully processing the key exchange message it received from the client


SSL Alert Protocol

• One of the content types supported by the SSL Record Layer is the alert type.

• Alert messages consist of 2 bytes. -The first byte takes the value warning to convey the

seriousness of the message. If the level is fatal, SSL immediately terminates the connection.

-The second byte contains a code that indicates the specific alert.


SSL Alert Protocol

A specification of SSL-related alerts that are always fatal is listed in the following:

• unexpected_message: An inappropriate message was received.

• bad_record_mac: An incorrect MAC was received.• decompression_failure: The decompression function

received improper input (e.g., unable to decompress).• handshake_failure: Sender was unable to negotiate an

acceptable set of security parameters given the options available.

• illegal_parameter: A field in a handshake message was out of range or inconsistent with other fields.


SSL Handshake protocol

• The SSL Handshake Protocol is operated on top of the SSL Record Layer and it is the most important and most complex part of SSL.

• 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 the client and the server.


Contd… Each message has three fields as follows:• Type (1 byte): Indicates one of 10 messages as indicated in the following

table.• Length (3 bytes): The length of the message in bytes.• Content ( 0 bytes): The parameters associated with this message; these

are listed in the following Table.

Fig: Handshake Protocol Action

Handshake Phase

Phase-1o This phase is used to initiate a logical connection and to establish the

security capabilities that will be associated with it.

o The exchange is initiated by the client, which sends a client_hello message with the parameters such as Version, Session ID, CipherSuite, Compression Method etc.

o After sending the client_hello message, the client waits for the server_hello message , which contains the same parameters as the client_hello message.

Handshake Phase

Phase-2

o The server begins this phase by sending its certificate, if it needs to be

authenticated; the message contains one or a chain of X.509 certificates.o Next, a server key_exchange message may be sent if it is required.o Next, a nonanonymous server can request a certificate from the client.

The certificate_request message includes two parameters: certificate_type and certificate_authorities.

o The final message in Phase 2, and one that is always required, is the server_done message , which is sent by the server to indicate the end of the server hello and associated messages.

Handshake Phase

Phase-3o Upon receipt of the server_done message, the client should verify that

the server provided a valid certificate.o If the server has requested a certificate, the client begins this phase by

sending a certificate message. If no suitable certificate is available, the client sends a no_certificate alert instead.

o Next is the client_key_exchange message , which must be sent in this phase. The content of the message depends on the type of key exchange. For e.g: In Anonymous Diffie-Hellman: The client's public Diffie-Hellman parameters are sent.

o Finally, in this phase, the client may send a certificate_verify message to provide explicit verification of a client certificate. This message is only sent following any client certificate that has signing capability

Handshake Phase

Phase-4o This phase completes the setting up of a secure connection.o The client sends a change_cipher_spec message and copies the pending

CipherSpec into the current CipherSpec. o The client then immediately sends the finished message under the new

algorithms, keys, and secrets. o The finished message verifies that the key exchange and authentication

processes were successful. o In response to these two messages, the server sends its own

change_cipher_spec message, transfers the pending to the current CipherSpec, and sends its finished message.

Contd…

The handshake is now complete: the server is authenticated and any information

exchanged between the browser and the server is protected.

SSL Uses

• SSL enables secure communication on an insecure network such as the Internet.

• Most web-based online purchases and monetary transactions are now secured by SSL– Online banking– Credit card purchases


Advantages

• SSL it already built into browsers.– There is no need to install extra software

• The server that the user wants to connect has no significant reduction in speed.– SSL was developed with server performance in mind.

• SSL can be used as an alternative for Virtual Private Network (VPN).– VPN creates a virtual pipeline from a client directly to the

server.– SSL secures data transmitted through the web to the

server.


Secure Electronic Transaction

(SET)


Introduction

• SET is a protocol designed to ensure that merchant and cardholders can conduct business over insecure networks..

• Developed by Visa and MasterCard

04/12/23 ASSAM UNIVERSITY SILCHAR 34

Purpose

The purpose of the SET protocol is to establish payment transactions that

• Provide confidentiality of information;• Ensure the integrity of payment instructions • Authenticate both the cardholder and the

merchant .• To maintain privacy i.e information made

available only when and where necessary


SET Participants

There are six main entities in SET:1)Cardholder (customer)2)Merchant (web server)3)Issuer (cardholder’s bank)4)Acquirer5)Payment gateway(is a device operated by an

acquirer. Sometime, separate these two entities)6)Certificate Authority


Participants in the SET System


Contd…

The participants in the SET system, which include the following: • Cardholder: A cardholder is an authorized holder of a

payment card (e.g., MasterCard, Visa) that has been issued by an issuer.

• Merchant: A merchant is a person or organization that has goods or services to sell to the cardholder.

• Issuer: This is a financial institution, such as a bank, that provides the cardholder with the payment card.

• Acquirer: This is a financial institution that establishes an account with a merchant and processes payment card authorizations and payments.


Contd..

• Payment gateway: This is a function operated by the acquirer or a designated third party that processes merchant payment messages. The payment gateway interfaces between SET and the existing bankcard payment networks for authorization and payment functions.

• Certification authority (CA): This is an entity that is trusted to issue X.509v3 public-key certificates for cardholders, merchants, and payment gateways.


How It Work ?

Both cardholders and merchants must register

with CA first, before they can buy or sell on the Internet. Once registration is done, cardholder and merchant can start to do transactions.


Contd...

SET involve 9 basic steps in this protocol, which are :1. Customer browses website and decides on what to

purchase2. Customer sends order and payment information,

which includes 2 parts in one message: a. Purchase Order – this part is for merchant b. Card Information – this pat is for merchant’s bank

only.3. Merchant forwards card information (part b) to their

bank


Contd...

4. Merchant’s bank checks with Issuer for payment authorization

5. Issuer send authorization to Merchant’s bank6. Merchant’s bank send authorization to merchant7. Merchant completes the order and sends

confirmation to the customer8. Merchant captures the transaction from their bank9. Issuer prints credit card bill (invoice) to customer


SET Transactions


Key Technologies of SET

• Confidentiality of information: DES• Integrity of data: RSA digital signatures with SHA-1

hash codes• Cardholder account authentication: X.509v3 digital

certificates with RSA signatures • Merchant authentication: X.509v3 digital certificates

with RSA signatures• Privacy: separation of order and payment information

using dual signatures


SET Certificate Hierarchy


Examples

• Examples of Certificate Chain For Merchant


Dual Signature

A new application of digital signatures is introduced in SET, namely the concept of dual signatures.

Dual signatures is needed when two messages are need to be linked securely but only one party is allowed to read each.


Dual Signatures• Links two messages securely but allows only one party to read each.

MESSAGE 1

DIGEST 1

NEW DIGEST

HASH 1 & 2WITH SHA

MESSAGE 2

DIGEST 2

CONCATENATE DIGESTSTOGETHER

HASH WITH SHA TOCREATE NEW DIGEST

DUAL SIGNATURE

PRIVATE KEYENCRYPT NEW DIGESTWITH SIGNER’S PRIVATE KEY


Goal

• Goal: Limit Information to A “Need-to-Know” Basis:

– Merchant does not need credit card number.– Bank does not need details of customer order.– It Afford the customer extra protection in terms of

privacy by keeping these items separate.


Why Dual Signature?

• Suppose that customers send the merchant two messages:• The signed order information (OI).• The signed payment information (PI).• In addition, the merchant passes the payment

information (PI) to the bank.• If the merchant can capture another order information (OI)

from this customer, the merchant could claim this order goes with the payment information (PI) rather than the original.

• So this link is needed to prove that payment is intended for this order and not some other one.


Dual Signature Operation

• The operation for dual signature is as follows:– Take the hash (SHA-1) of the payment and order information.– These two hash values are concatenated [H(PI) || H(OI)] and then

the result is hashed.– Customer encrypts the final hash with a private key creating the

dual signature.DS = EKRC [ H(H(PI) || H(OI)) ]


DS Verification by Merchant

• The merchant has the public key of the customer obtained from the customer’s certificate.

• Now, the merchant can compute two values:H(PIMD || H(OI))DKUC[DS]

• Should be equal!


DS Verification by Bank

• The bank is in possession of DS, PI, the message digest for OI (OIMD), and the customer’s public key, then the bank can compute the following:

H(H(PI) || OIMD)DKUC [ DS ]


What did we accomplish?

• The merchant has received OI and verified the signature.

• The bank has received PI and verified the signature.• The customer has linked the OI and PI and can prove

the linkage.


Payment Processing

There are three main phases in a secure electronic transaction:

• Purchase request• Payment authorization• Payment capture


Contd…

Purchase Request:- The purchase request exchange consists of four messages:

• Initiate Request• Initiate Response• Purchase Request and • Purchase Response. Payment Authorization:-During the processing of

an order from a cardholder, the merchant authorizes the transaction with the payment gateway.


Contd..

• Payment Capture:-The merchant creates a digitally signed payment request that includes the final transaction amount, the transaction ID, and other transaction information.



SET Overhead

Simple purchase transaction:• Four messages between merchant and customer• Four messages between merchant and payment gateway• 4 certificate verifications• Multiple servers need copies of all certificates


SET Future Technology


conclusion

• The web is very vulnerable to attacks. It does not provide a secure communication for exchanging information between the client and the server. But these two protocol namely SSL and SET makes it possible to become the web more secure for exchanging information as well as making electronic transaction between the client and the server.


Thank you
