Transcript Lecture09: Web Security

Lecture 09
Web Security
Supakorn Kungpisdan, Ph.D.
[email protected]
ITEC4621: Network Security
1
Roadmap
 Web Security Considerations
 SSL and TLS
 Secure Electronic Transaction (SET)
ITEC4621: Network Security
2
A Comparison of Threats on the Web
ITEC4621: Network Security
3
Relative Location of Security Facilities
in the TCP/IP Protocol Stack
ITEC4621: Network Security
4
Roadmap
 Web Security Considerations
 SSL and TLS
 Secure Socket Layer
 Transport Layer Security
 Secure Electronic Transaction (SET)
ITEC4621: Network Security
5
SSL (Secure Socket Layer)
transport layer security service
originally developed by Netscape
version 3 designed with public input
subsequently became Internet standard known as TLS
(Transport Layer Security)
 uses TCP to provide a reliable end-to-end service
 SSL has two layers of protocols




ITEC4621: Network Security
6
SSL Architecture
ITEC4621: Network Security
7
SSL Session & Connection
 Connection: a transport that provides a suitable type of
service
 Peer-to-peer relationship
 Every connection is associated with one session
 Session: an association between a client and a server
created by handshake protocol
 Session defines a set of cryptographic parameters used among
multiple connections.
 One session may contain several connections
ITEC4621: Network Security
8
SSL Record Protocol Services
 message integrity
 using a MAC with shared secret key
 similar to HMAC but with different padding
 confidentiality
 using symmetric encryption with a shared secret key defined by
Handshake Protocol
 AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4128
 message is compressed before encryption
ITEC4621: Network Security
9
SSL Record Protocol
Services provided:
Confidentiality by encryption
and Message integrity by MAC
ITEC4621: Network Security
10
SSL Record Format
ITEC4621: Network Security
11
Steps in SSL Record Protocol
1. Fragmentation

data fragmented into blocks of 214 bytes (16384 bytes) or less
2. Compression (optional):



Lossless compression function applied
May increase message length by 1024 bytes
No compression in SSLv3 and TLS (null)
ITEC4621: Network Security
12
Steps in SSL Record Protocol: 3. MAC
data
ITEC4621: Network Security
13
Steps in SSL Record Protocol (cont.)
4. Encryption

1024 bytes from encryption +
1024 bytes from compression
May increase the length by 1024 bytes so the total length must not
exceed 214+2048 bytes
ITEC4621: Network Security
14
Steps in SSL Record Protocol (cont.)
 For stream encryption: message + MAC are encrypted
 For block encryption: padding and its length (1 byte) may
be attached after MAC so that the size of the message is a
multiple of cipher’s clock length
 E.g. data = 58 bytes, MAC = 20 bytes (SHA-1), MAC length = 1
byte
each block length is 8 bytes (64 bits using DES)
so pad length must be 1 byte so that 58+20+1+1 = 80 bytes
(divisible by 8)
ITEC4621: Network Security
15
Steps in SSL Record Protocol (cont.)
5. Append header
 Content Type (8 bits)
 Higher layer protocol used to process enclosed fragment
 Types: change_cipher_spec, alert, handshake, application_data
 Major Version (8 bits)
 For SSLv3.0, the value is 3
 Minor Version (8 bits)
 For SSLv3.0, the value is 0
 Compressed Length (16 bits)
 Length of final message (max. 214+2048 bytes)
ITEC4621: Network Security
16
SSL Protocols above Record Protocol
 Change Cipher Spec Protocol
 Alert Protocol
 Handshake Protocol
 Seen as applications of SSL Record protocol, these
protocols are compressed and encrypted using SSL
Record protocol
ITEC4621: Network Security
17
SSL Record Protocol Payload
≥
≥
ITEC4621: Network Security
18
Change Cipher Spec Protocol
 One of 3 SSL specific protocols which use the SSL Record protocol
 Simplest among SSL protocols
 To cause the pending state to be copied into the current state, which
updates the cipher suite to be used on this connection
 Basically, it tells the Record protocol to use the new set of
encryption parameters specified in phase 1 of Handshake protocol
ITEC4621: Network Security
19
Alert Protocol
 Used to convey SSL-related alerts to peer entity
 Compressed & encrypted like all SSL data
 Message consists of 2 bytes
 1st byte contains warning (1) or fatal (2)
 If 2, SSL immediately terminates connection, and no new connection
may be established. Then client must establish a new session.
 2nd byte contains a code indicating specific alert
ITEC4621: Network Security
20
Alert Protocol (cont’d)
 Alerts that are always fatal
 unexpected_message: impropriate message received
 bad_record_mac: incorrect MAC received
 decompression_failure: the function received improper
input
 handshake_failure: sender is unable to negotiate an
acceptable set of security parameter
 illegal_parameter: a field in handshake message is
inconsistent with other fields
ITEC4621: Network Security
21
Handshake Protocol
 Allows server and client to authenticate each other
 Also to negotiate encryption and MAC keys used to protect
data sent in SSL
 Each Handshake protocol message contains 3 fields
 Type (1 byte): indicates one of 10 messages
 Length (3 bytes): message length in bytes
 Content (≥ 1 byte): Type-related parameters
ITEC4621: Network Security
22
SSL Handshake Protocol Msg Types
ITEC4621: Network Security
23
Handshake
Protocol
Action
Change Cipher Spec
protocol message
ITEC4621: Network Security
24
Phase1: Establish Security Capabilities
 To initiate logical connection and to establish security
capabilities associated with it
 client_hello contains
 Version: SSL version
 Random: 32-bit timestamp and 28 bytes random number
generated by a secure random generator.
 Served as nonce during key exchange
 Session ID:
 Non-zero value  client wants to update connection parameters or
create a new connection on current session
 Zero value  client wants to create a new connection on a new session
ITEC4621: Network Security
25
Phase1: Establish Security Capabilities
(cont.)
 Ciphersuite
 Contains a list of key exchange algorithms supported by the
client (for the server to select one of these) and a CipherSpec
(definition of key exchange method)
 Compression Method
 List of compression method supported by client
ITEC4621: Network Security
26
Phase1: Establish Security Capabilities
(cont.)
 server_hello contains
 Version
 Same as that in client_hello
 Random:
 generated by server, independent of client’s Random
 Session ID
 If client’s Session ID is non-zero, Server’s is also contains the same value
 If zero, server’s Session ID contains the new value for a new session
 CipherSuite:
 a single cipher suite selected by server from those proposed by client
 Compression Method:
 the selected method from those proposed by client
ITEC4621: Network Security
27
CipherSuite
 CipherSuite contains key exchange methods and
CipherSpec
 Key exchange methods:





RSA (secret key is encrypted with RSA public key)
Fixed DH (fixed public keys),
Ephermeral DH (use one-time public key signed by sender),
Anonymous DH (no verification of public-key sender)
Fortezza scheme
 CipherSpec: includes the following:






CipherAlgorithm: encryption algo
MACAlgorithm: MD5 or SHA-1
CipherType: Stream or Block
HashSize: 0, 16 (MD5) or 20 (SHA-1) bytes
Key Material: a data used to generating the write keys
IV Size: size of IV for CBC encryption
ITEC4621: Network Security
28
Phase2: Server Authentication and Key
Exchange
 Server sends its certificate if needed.
 certificate msg is required except in anonymous DH
 server_key_exchange (to exchange DH keys) is sent if
required except two instances:
 Server has sent a certificate with fixed DH parameters (already sent in
certificate message)
 RSA key exchange is to be used (no DH parameters used)
 The parameters in server_key_exchange is used to
generate a pre-master secret using DH key exchange.
 The pre-master secret will be later used to create a master secret.
ITEC4621: Network Security
29
Phase2: Server Authentication and Key
Exchange (cont.)
 Server can request a cert from client.
 certificate_request includes:
 Certificate_type: indicates public-key algo used
 Certificate_authorities: list of acceptable CAs
 server_done
 Indicate the end of server hello. Server then waits for a client
response
ITEC4621: Network Security
30
Phase3: Client Authentication and Key
Exchange
 Client verifies server’s cert and checks if server_hello parameters are
acceptable
 If server requests for client’s cert, client sends certificate. If client doesn’t
have a cert, client sends no_certificate alert instead
 client_key_exchange contains (DH) key exchange parameters used to
generate a pre-master secret and then later a master secret
 Client may send certificate_verify to provide explicit verification of a
client cert.
All handshake msgs sent or received since
client_hello except this msg
CertificateVerify.signature.md5_hash
MD5(master_secret||pad_2||MD5(handshake_messages||
master_Secret||pad_1))
Certificate.signature.sha_hash
SHA(master_secret||pad_2||SHA(handshake_messages||
master_secret||pad_1))
ITEC4621: Network Security
31
Phase4: Finish
 Client sends change_cipher_spec and copies the pending
CipherSpec into current CipherSpec (change cipher spec protocol
message is sent)
 Client also sends finished under new algos, keys, and secrets.
 finished verifies that key exchange and authentication were
All handshake msgs sent or received since client_hello
successful.
except this msg
 finished contains two values:
MD5(master_secret||pad2||MD5(handshake_messages||
Sender||master_secret||pad1))
SHA(master_secret||pad2||SHA(handshake_messages||
Sender||master_secret||pad1))
 Server sends its own change_cipher_spec and finished to
complete Handshake protocol
ITEC4621: Network Security
32
Master Secret Creation
 The shared 48-byte pre-master secret is one-time
generated for this session for secure key exchange
 Exchange pre_master_secret
 Calculate master_secret
 Exchange pre_master_secret
 RSA: client encrypts pre_master_secret with server’s RSA public
key and sends it to server
 DH: client and server generates DH public key and create
pre_master_secret
ITEC4621: Network Security
33
Master Secret Creation (cont.)
 Create master_secret
master_secret =
MD5(pre_master_secret||SHA(‘A’||pre_master_secret||
ClientHello.random||ServerHello.random))||
MD5(pre_master_secret||SHA(‘BB’||pre_master_secret||
ClientHello.random||ServerHello.random))||
MD5(pre_master_secret||SHA(‘CCC’||pre_master_secret||
ClientHello.random||ServerHello.random))
Until 48 bytes of secret are produced
ITEC4621: Network Security
34
Generation of Cryptographic Parameters
 CipherSpecs require the following parameters






Client write MAC secret
Server write MAC secret
Client write key
Server write key
Client write IV
Server write IV
 These values are generated from the master secret
 Such values will be later used for SSL Record protocol
ITEC4621: Network Security
35
Generation of Cryptographic Parameters
(cont.)
Key_block = MD5(master_secret||SHA(‘A’||master_secret||
ServerHello.random||ClientHello.random))||
MD5(master_secret||SHA(‘BB’||master_secret||
ServerHello.random||ClientHello.random))||
MD5(master_secret||SHA(‘CCC’||master_secret||
ServerHello.random||ClientHello.random))||…
Until enough output has been generated.
ITEC4621: Network Security
36
Roadmap
 Web Security Considerations
 SSL and TLS
 Secure Socket Layer
 Transport Layer Security
 Secure Electronic Transaction (SET)
ITEC4621: Network Security
37
Difference btw SSL and TLS
 Version
 TLS Record protocol is the same as SSL Record protocol
 In TLS, major version is 3 and minor version is 1
 Message Authentication Code
 Alert Codes:
 TLS supports all SSLv3 alerts and provides additional alerts
 CipherSuites
 Key Exchange: TLS supports all SSLv3 key exchange except
Fortezza
 Encryption algos: TLS supports all SSLv3 encryption except
Fortezza
ITEC4621: Network Security
38
Roadmap
 Web Security Considerations
 SSL and TLS
 Secure Electronic Transaction (SET)
ITEC4621: Network Security
39
Secure Electronic Transaction
ITEC4621: Network Security
40
Services Provided by SET
 Secure communications channel among involved parties
 Trust by using X.509 certs
 Party privacy: parties will receive only the information that
they are intended to receive
ITEC4621: Network Security
41
SET Requirements
 Provide confidentiality of payment and ordering information
 Ensure the integrity of all transmitted data
 Provide authentication that a cardholder is a legitimate user of a
credit card account
 Provide authentication that a merchant can accept credit card
transactions through its relationship with a financial institution
 Ensure the use of the best security practices and system design
techniques to protect all legitimate parties in an e-commerce
transactions
 Create a protocol that neither depends on transport security
mechanisms nor prevents their use
ITEC4621: Network Security
42
Secure Electronic Transaction
4, 6
3
5, 10, 11
2
9
1
7
12
8
ITEC4621: Network Security
43
SET Transaction Overview
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Client opens an account
Client receives a certificate
Merchants have their own certs
The client places an order (C  M)
The merchant is verified (M  C)
The order and payment are sent (C  M)
The merchant requests payment authorization (M  PG)
Payment is approved (PG  I, I  A, I,A  PG)
The merchant receives authorization response (PG  M)
The merchant confirms the order (M  C)
The merchant provides goods or service (M  C)
The merchant requests payment (M  A)
ITEC4621: Network Security
44
Dual Signature
 In SET, two messages for two intended recipients are sent in one
message
 Order Information (OI) from client to merchant -> not revealed to the bank
 Payment Information (PI) from client to the bank -> not revealed to the
merchant
 DS = EKRc[H(H(PI)||H(OI))]
 DS provides link btw OI and PI for the client
 If merchant receives DS, H(PI), merchant can prove that client has
sent purchase request (because merchant has OI).
 If bank receives DS, H(OI), the bank can prove that client has
request it to deduct money from client’s account (because the bank
has PI).
ITEC4621: Network Security
45
Dual Signature (cont.)
 C  M: EKRc[H(H(PI)||H(OI))], h(PI)
Merchant decrypts EKRc[H(H(PI)||H(OI))]
Merchant knows OI, create h(OI)
Merchant creates H(H(PI)||H(OI)) and compares
with the received H(H(PI)||H(OI))
ITEC4621: Network Security
46
Dual Signature (cont.)
 M  PG: EKRc[H(H(PI)||H(OI))], h(OI)
PG decrypts EKRc[H(H(PI)||H(OI))]
PG knows PI, create h(PI)
PG creates H(H(PI)||H(OI)) and compares with the
received H(H(PI)||H(OI))
ITEC4621: Network Security
47
Dual Signature (cont.)
ITEC4621: Network Security
48
Questions?
ITEC4621: Network Security
49
Quiz
1. Explain SSL protocol in details by focusing on the
interaction between SSL Handshake protocol and SSL
Record protocol
2. Not only SSL, is there any other technologies that can be
used to secure web applications?
ITEC4621: Network Security
50