Web Security

SATISH NANNAWARE
COMPUTER ENGINEERING
DR.BATU,LONERE
Web Security
• Web now widely used by business, government, individuals
• but Internet & Web are vulnerable
• have a variety of threats
• integrity
• confidentiality
• denial of service
• authentication
• need added security mechanisms
Web Traffic Security Approaches
SSL (Secure Socket Layer)
• transport layer security service
• originally developed by Netscape
• version 3 designed with public input
• SSL v3.0 was specified in an Internet Draft (1996)
• subsequently became Internet standard known as TLS (Transport
Layer Security)
• TLS can be viewed as SSL v3.1
• uses TCP to provide a reliable end-to-end service
• SSL has two layers of protocols
 SSL Architecture

• The SSL Record Protocol provides basic security

services to various higher-layer protocols such as
HTTP which provides the transfer service for Web
client/server interaction, can operate on top of SSL.

• Three higher-layer protocols are also defined as

part of SSL: the Handshake Protocol, Change
Cipher Spec Protocol, and Alert Protocol.

• These SSL-specific protocols are used in the

management of SSL exchanges.
SSL Architecture
➢ SSL connection
⚫a transient, peer-to-peer, communications link
⚫associated with 1 SSL session
➢ SSL session
⚫an association between client & server
⚫created by the Handshake Protocol
⚫define a set of cryptographic parameters which may be shared by multiple SSL
connections
➢sessions are stateful; the session state includes security algorithms and
parameters
➢a session may include multiple secure connections between the same
client and server
➢ connections of the same session share the session state
Session State
•Session identifier: An arbitrary byte sequence chosen by the server
to identify an active or resumable session state.
•Peer certificate: An X509.v3 certificate of the peer. This element of
the state may be null.
•Compression method: The algorithm used to compress data prior to
encryption.
•Cipher spec: Specifies the data encryption and a hash algorithm used
for MAC calculation.
• Master secret: 48-byte secret shared between the client and server.
•Is resumable: A flag indicating whether the session can be used to
initiate new connections.
Connection State

•Server and client random: Byte sequences that are chosen by the server
and client for each connection.
•Server write MAC secret: The secret key used in MAC operations on data
sent by the server.
•Client write MAC secret: The secret key used in MAC operations on data
sent by the client.
•Server write key: The secret encryption key for data encrypted by the
server and decrypted by the client.
Connection State (Contd..)
•Client write key: The symmetric encryption key for data encrypted by the
client and decrypted by the server.
•Initialization vectors: When a block cipher in CBC mode is used, an
initialization vector (IV) is maintained for each key.
• Sequence numbers:
• Each party maintains separate sequence numbers for transmitted and received
messages for each connection.
• When a party sends or receives a change cipher spec message, the appropriate
sequence number is set to zero.
• Sequence numbers may not exceed 264 – 1.
SSL Record Protocol Services
• confidentiality
• using symmetric encryption with a shared secret key defined by Handshake
Protocol
• AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128
• message is compressed before encryption
• message integrity
• using a MAC with shared secret key
SSL Record Protocol Operation
Fragmentation and Compression
• Each upper layer message is fragmented into blocks of
214 bytes or less.

• Compression is optional.

• Compression must be lossless.

MAC
MAC = hash( MAC_write_secret | pad_2 |
hash( MAC_write_secret | pad_1 | seq_num | type | length | fragment ) )
back
• MAC_write_secret = shared secret key
• seq_num = the sequence number for this message
• type = the higher level protocol used to process this fragment
• length = length of the compressed fragment
• fragment = compressed/ plaintext fragment
• supported hash functions: MD5 and SHA-1
• pad_1 is 0x36 repeated 48 times (MD5) or 40 times (SHA-1)
• pad_2 is 0x5C repeated 48 times (MD5) or 40 times (SHA-1)
• similar to HMAC but the pads are concatenated in SSLv3 and are XORed in HMAC.
13
Encryption
• Compressed message plus the MAC are encrypted using symmetric
encryption.
• Encryption may not increase the content length by more than 1024 bytes,
so that the total length may not exceed 214 + 2048.
• supported algorithms
• block ciphers (in CBC mode)
• RC2_40
• DES_40
• DES_56
• 3DES_168
• IDEA_128
• Fortezza_80
• stream ciphers
• RC4_40
• RC4_128
• if a block cipher is used, then padding is applied
• last byte of the padding is the padding length
Header
• type
• the higher level protocol used to process the enclosed fragment
• possible types:
• change_cipher_spec
• alert
• handshake
• application_data
• version
• SSL version, currently 3.0
• length
• length (in bytes) of the enclosed fragment or compressed fragment
• max value is 214 + 2048

15
SSL Change Cipher Spec Protocol
• one of 3 SSL specific protocols which use the SSL Record protocol
• a single message
• causes pending state to become current
• hence updating the cipher suite in use
SSL Alert Protocol
• conveys SSL-related alerts to peer entity
• each alert message consists of 2 fields (bytes)
• first field (byte): “warning” or “fatal”
• second field (byte):
• fatal
• unexpected_message
• bad_record_MAC
• decompression_failure
• handshake_failure
• illegal_parameter
• warning
• close_notify
• no_certificate
• bad_certificate
• unsupported_certificate
• certificate_revoked
• certificate_expired
• certificate_unknown
• in case of a fatal alert
• connection is terminated
• session ID is invalidated → no new connection can be established within this session
 SSL Handshake Protocol
➢ allows server & client to:
⚫ authenticate each other
⚫ to negotiate encryption & MAC algorithms
⚫ to negotiate cryptographic keys to be used

The Handshake Protocol is used before any application data is

transmitted.
➢ comprises a series of messages in phases
1. Establish Security Capabilities
2. Server Authentication and Key Exchange
3. Client Authentication and Key Exchange
4. Finish
SSL Handshake Protocol
• Type
• Indicates one of ten messages
• Length
• Length of message in bytes
• Content
• Parameters associated with this message
SSL Handshake Protocol Message Types
 SSL Handshake Protocol – overview
client server
client_hello Phase 1: Negotiation of the session ID, key exchange
server_hello algorithm, MAC algorithm, encryption algorithm, and
exchange of initial random numbers

certificate
Phase 2: Server may send its certificate and key
server_key_exchange
exchange message, and it may request the client
certificate_request to send a certificate. Server signals end of hello
phase.
server_hello_done

certificate
Phase 3: Client sends certificate if requested and may
client_key_exchange send an explicit certificate verification message.
certificate_verify Client always sends its key exchange message.

change_cipher_spec

finished
Phase 4: Change cipher spec and finish handshake
change_cipher_spec

finished
21
PHASE 1: ESTABLISHING SECURITY CAPABILITIES
Hello messages
• client_hello
• client_version
• the highest version supported by the client
• client_random
• Timestamp (4 bytes) + pseudo random bytes (28 bytes)
• These values serve as nonces and can be used during key exchange to prevent replay attacks.
• session_id
• empty if the client wants to create a new session, or
• the session ID of an old session with which the client wants to create the new connection
• cipher_suites
• list of cryptographic options supported by the client ordered by preference
• a cipher suite contains the specification of the
• key exchange method, the encryption and the MAC algorithm
• the algorithms implicitly specify the hash_size, IV_size, and key_material parameters (part of the Cipher Spec of the
session state)
• example: SSL_RSA_with_3DES_EDE_CBC_SHA
• compression_methods
• list of compression methods supported by the client

23
Hello messages cont’d
• server_hello
• server_version
• min( highest version supported by client, highest version supported by server )
• server_random
• Timestamp + random bytes
• random bytes must be independent of the client random
• session_id
• if the client wanted to resume an old session:
• server checks if the session is resumable
• if so, it responds with the session ID and the parties proceed further
• if the client wanted a new session
• server generates a new session ID
• cipher_suite
• single cipher suite selected by the server from the list given by the client
• compression_method
• single compression method selected by the server

24
Supported key exchange methods
• RSA (SSL_RSA_with...)
• the secret key is encrypted with the server’s public RSA key
• the server’s public key is made available to the client during the exchange
• fixed Diffie-Hellman (SSL_DH_RSA_with… or SSL_DH_DSS_with…)
• ephemeral Diffie-Hellman (SSL_DHE_RSA_with… or SSL_DHE_DSS_with…)
• anonymous Diffie-Hellman
• Fortezza
• Fortezza proprietary key exchange scheme

25
Cipher and MAC algorithms
• CipherAlgorithm: Any of the algorithms mentioned earlier: RC4, RC2, DES,
3DES, DES40, IDEA, or Fortezza
• MACAlgorithm: MD5 or SHA-1
• CipherType: Stream or Block
• IsExportable: True or False
• HashSize: 0, 16 (for MD5), or 20 (for SHA-1) bytes
• Key Material: A sequence of bytes that contain data used in generating the
write keys
• IV Size: The size of the Initialization Value for Cipher Block Chaining (CBC)
encryption
PHASE 2: SERVER AUTHENTICATION AND KEY
EXCHANGE
 SSL Handshake Protocol – overview
client server
client_hello Phase 1: Negotiation of the session ID, key exchange
server_hello algorithm, MAC algorithm, encryption algorithm, and
exchange of initial random numbers

certificate
Phase 2: Server may send its certificate and key
server_key_exchange
exchange message, and it may request the client
certificate_request to send a certificate. Server signals end of hello
phase.
server_hello_done

certificate
Phase 3: Client sends certificate if requested and may
client_key_exchange
send an explicit certificate verification message.
certificate_verify Client always sends its key exchange message.

change_cipher_spec
finished
Phase 4: Change cipher spec and finish handshake
change_cipher_spec
finished
28
Server certificate and key exchange messages
• certificate
• required for every key exchange method except for anonymous DH
• contains one or a chain of X.509 certificates (up to a known root CA)

• server_key_exchange
• sent only if the certificate does not contain enough information to complete the key
exchange
• Not required in two instances: (1) The server has sent a certificate with fixed Diffie-Hellman
parameters or (2) a RSA key exchange is to be used
• Required in case of
• Anonymous Diffie-Hellman: consists of the two global Diffie-Hellman values
• Ephemeral Diffie-Hellman

29
Certificate request and server hello done
msgs
• certificate_request
• sent if the client needs to authenticate itself
• The certificate_request message includes two parameters:
• certificate_type (rsa_sign, dss_sign, rsa_fixed_dh, dss_fixed_dh, rsa_ephemeral_dh,
dss_ephemeral_dh, fotezza_kea)
• certificate_authorities
• server_hello_done
• sent to indicate that the server is finished its part of the key exchange
• after sending this message the server waits for client response
• the client should verify that the server provided a valid certificate and the
server parameters are acceptable
back

30
PHASE 3: CLIENT AUTHENTICATION AND KEY
EXCHANGE
 SSL Handshake Protocol – overview
client server
client_hello Phase 1: Negotiation of the session ID, key exchange
server_hello algorithm, MAC algorithm, encryption algorithm, and
exchange of initial random numbers

certificate
Phase 2: Server may send its certificate and key
server_key_exchange
exchange message, and it may request the client
certificate_request to send a certificate. Server signals end of hello
phase.
server_hello_done

certificate
Phase 3: Client sends certificate if requested and may
client_key_exchange send an explicit certificate verification message.
certificate_verify Client always sends its key exchange message.

change_cipher_spec

finished
Phase 4: Change cipher spec and finish handshake
change_cipher_spec

finished
32
Client authentication and key exchange
• certificate
• sent only if requested by the server
• If not available, send no_certificate alert

• client_key_exchange
• Depends on the key exchange method
• RSA: The client generates a 48-byte pre-master secret and encrypts with the public key from
the server’s certificate
• Ephemeral or Anonymous Diffie-Hellman: The client’s public Diffie-Hellman parameters are
sent.
• Fixed Diffie-Hellman: The client’s public Diffie-Hellman parameters were sent in a certificate
message, so the content of this message is null.

• certificate_verify
• sent only if the client sent a certificate
• provides client authentication
33
PHASE 4: FINISH
Finished messages
• Finished
• completes the setting up of a secure connection
• client sends a change_cipher_spec message and copies the pending
CipherSpec into the current CipherSpec (sent using the Change Cipher Spec
Protocol)
• Client then immediately sends the finished message
• first message that uses the newly negotiated algorithms, keys, IVs, etc.
• used to verify that the key exchange and authentication was successful
• contains the MD5 and SHA-1 hash of all the previous handshake messages:
35
Server’s Response
• Finally server sends its own change_cipher_spec message, transfers
the pending to the current CipherSpec and sends its finished
message.
• At this point, the handshake is complete and the client and server
may begin to exchange application-layer data.
Master Secret Creation
• The shared master secret is a one-time 48-byte value generated for
this session.
• RSA: A 48-byte pre_master_secret is generated and shared by the client.
• Diffie-Hellman: Both client and server generate a Diffie-Hellman public key.
After these are exchanged, each side performs the Diffie-Hellman calculation
to create the shared pre_master_secret.
Cryptographic Computations
➢ generation of cryptographic parameters
⚫ client write MAC secret, a server write MAC secret, a client write key, a server
write key, a client write IV, and a server write IV
⚫ generated by hashing master secret
GENERATION OF CRYPTOGRAPHIC
PARAMETERS
• parameters are generated from the master secret by hashing the
master secret into a sequence of secure bytes of sufficient length for
all needed parameters.
TLS (Transport Layer Security)
• IETF standard RFC 5246 similar to SSLv3
• with minor differences
• in record format version number
• uses HMAC for MAC
• a pseudo-random function expands secrets
• based on HMAC using SHA-1 or MD5
• has additional alert codes
• some changes in supported ciphers (Fortezza not supported)
• changes in certificate types & negotiations
• changes in crypto computations & padding
• Cryptographic Computations are different
• Variable padding length up to maximum of 255 bytes
TLS
• Certificate_verify and Finished messages
• In the TLS certificate_verify message, the MD5 and SHA-1 hashes are
calculated only over handshake_messages.
• the hash calculation in SSL also includes the master secret and pads.
• Finished Messages
HMAC for TLS
HMAC computation in TLS differs from SSLv3 in that the padding bytes are
XORed with the secret key instead of being concatenated with the secret
key.
HMAC for TLS
The MAC calculation covers all of the fields covered by the SSLv3
calculation, plus the field TLSCompressed.version, which is the version
of the protocol being employed.
Psuedorandom Function (PRF)

back
HTTPS
➢ HTTPS (HTTP over SSL)
⚫ combination of HTTP & SSL/TLS to implement secure
communications between browser & server
• documented in RFC2818
• no fundamental change using either SSL or TLS
➢ use https:// URL rather than http://
⚫ and port 443 rather than 80
➢ encrypts
• URL of the requested document
• Contents of the document
• Contents of browser forms (filled in by browser user)
• Cookies sent from browser to server and from server to
browser
• Contents of HTTP header
HTTPS Use
• connection initiation
• TLS handshake then HTTP request(s)
• connection closure
• have “Connection: close” in HTTP record
• TLS level exchange close_notify alerts
• can then close TCP connection
• must handle TCP close before alert exchange sent or completed