Web security

Presentation
on
web security
Presented by
Subhash Basishtha
Saptarshi Boruah
05/28/14 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, veriﬁed,
decompressed, reassembled ,and then delivered to
higher-level clients.

operation of ssL record
protocoL

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

operAtion of SSL reCord
protoCoL
• 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:

operAtion of SSL reCord
protoCoL
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-speciﬁc
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 certiﬁcate 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 ﬁrst 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
speciﬁc alert.

SSL ALert protoCoL
A speciﬁcation 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-1
o 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-3
o 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-4
o 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
05/28/14 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)Acquirer
5)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.05/28/14 ASSAM UNIVERSITY SILCHAR 38

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
purchase
2. 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 bank
6. Merchant’s bank send authorization to merchant
7. Merchant completes the order and sends
confirmation to the customer
8. Merchant captures the transaction from their bank
9. 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 & 2
WITH SHA
MESSAGE 2
DIGEST 2
CONCATENATE DIGESTS
TOGETHER
HASH WITH SHA TO
CREATE NEW DIGEST
DUAL SIGNATURE
PRIVATE KEY
ENCRYPT NEW DIGEST
WITH 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

Web security

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Web security (20)

Recently uploaded (19)

Web security

Editor's Notes