WEB Security

1
 Web Security Considerations
 Transport Layer Security (TLS)

2
 Web now widely used by business, government, individuals
 but Internet & Web are vulnerable
 have a variety of threats
◦ Integrity
 The customer and the vendor need to be sure that the
contents of the message are not modified during
transmission.
◦ Confidentiality
 The customer and the vendor need to be sure that an
imposter does not intercept sensitive information such as a
credit card number.
◦ denial of service
◦ Authentication
 The customer need to be sure that the server belongs to the
actual vendor, not an imposter. The customer does not want
to give an imposter her credit card number.
 need added security mechanisms

3
4
 SSL – Secure Socket Layer
 TLS – Transport Layer Security
 both provide a secure transport connection
between applications (e.g., a web server and a
browser)
 SSL was developed by Netscape
 SSL version 3.0 has been implemented in many
web browsers (e.g., Netscape Navigator and MS
Internet Explorer) and web servers and widely
used on the Internet
 SSL v3.0 was specified in an Internet Draft (1996)
 it evolved into TLS specified in RFC 2246
 TLS can be viewed as SSL v3.1

5
6
 TLS is designed to make use of TCP to
provide a reliable end-to-end secure service.
 SSL is not a single protocol but rather two
layers of protocols.
 Two important TLS concepts are the TLS
session and the TLS connection, which are
defined in the specification as follows.

7
 Session: An TLS session is an association
between a client and a server. Sessions are
created by the Handshake Protocol. Sessions
define a set of cryptographic security parameters
which can be shared among multiple
connections. Sessions are used to avoid the
expensive negotiation of new security parameters
for each connection.

 Connection: A connection is a transport that

provides a suitable type of service. For TLS, such
connections are peer-to-peer relationships. The
connections are transient. Every connection is
associated with one session.

8
 A session state is defined by the following parameters.
 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 bulk data encryption algorithm
(such as null,AES, etc.) and a hash algorithm (such as MD5
or SHA-1) used for MAC calculation. It also defines
cryptographic attributes such as the hash_size.
 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.

9
 A connection state is defined by the following
parameters.
 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.
 Client write key: The symmetric encryption key
for data encrypted by the client and decrypted by
the server.

10
 Initialization vectors: When a block cipher in CBC
mode is used, an initialization vector (IV) is
maintained for each key. This field is first
initialized by the TLS Handshake Protocol.
Thereafter, the final ciphertext block from each
record is preserved for use as the IV with the
following record.

 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.

11
12
 TLS Handshake Protocol
◦ negotiation of security algorithms and parameters
◦ key exchange
◦ server authentication and optionally client authentication
 TLS Record Protocol
◦ fragmentation
◦ compression
◦ message authentication and integrity protection
◦ encryption
 TLS Alert Protocol
◦ error messages (fatal alerts and warnings)
 TLS Change Cipher Spec Protocol
◦ a single message that indicates the end of the TLS
handshake

13
 The TLS Record Protocol provides two
services for TLS connections:
◦ Confidentiality: The Handshake Protocol defines a
shared secret key that is used for conventional
encryption of TLS payloads.

◦ Message Integrity: The Handshake Protocol also

defines a shared secret key that is used to form a
message authentication code(MAC).

14
15
 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 (as well as the current version of
TLS), no compression algorithm is specified,
so the default compression algorithm is null.

16
 The next step in processing is to compute a
message authentication code over the
compressed data. For this purpose, a shared
secret key is used.
 The calculation is defined as.

17
18
 Next, the 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.
 The following encryption algorithms are
permitted:

19
 Fortezza can be used in a smart card
encryption scheme.
 For stream encryption, the compressed
message plus the MAC are encrypted.
 Note that the MAC is computed before
encryption takes place and that the MAC is
then encrypted along with the plaintext or
compressed plaintext.
 For block encryption, padding may be added
after the MAC prior to encryption.

20
 The final step of TLS Record Protocol processing
is to prepare a header consisting of the following
fields:
 Content Type (8 bits): The higher-layer protocol
used to process the enclosed fragment.
 Major Version (8 bits): Indicates major version of
TLS in use. For TLS, the value is 3.
 Minor Version (8 bits): Indicates minor version in
use. For TLSv3, the value is 0.
 Compressed Length (16 bits): The length in bytes
of the plaintext fragment (or compressed
fragment if compression is used).The maximum
value is 214+2048.

21
22
 This protocol consists of a single message,
which consists of a single byte with the 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.

23
 is used to convey TLS-related alerts to the peer
entity.
 Each message in this protocol consists of two
bytes .
 The first byte takes the value warning (1) or fatal
(2) to convey the severity of the message.
 If the level is fatal, TLS immediately terminates
the connection.
 Other connections on the same session may
continue, but no new connections on this session
may be established.
 The second byte contains a code that indicates
the specific alert.

24
 alerts that are always fatal

25
 Remaining alerts

26
27
 The most complex part of TLS.
 Allows the server and client to authenticate
each other.
 Negotiate encryption, MAC algorithm and
cryptographic keys.
 Used before any application data are
transmitted.

28
 The Handshake Protocol consists of a series
of messages exchanged by client and server.
 Each message has three fields:
 Type (1 byte): Indicates one of 10 messages.
 Length (3 bytes): The length of the message
in bytes.
 Content ( ≥bytes): The parameters associated
with this message;

29
30
31
 PHASE 1. ESTABLISH SECURITY CAPABILITIES
◦ This phase is used to initiate a logical connection
and to establish the security capabilities that will
be associated with it.
◦ The exchange is initiated by the client, which
sends a client_hello message with the following
parameters:
◦ Version: The highest TLS version understood by
the client.
◦ Random: A client-generated random structure
consisting of a 32-bit timestamp and 28 bytes
generated by a secure random number generator.
◦ These values serve as nonces and are used during
key exchange to prevent replay attacks.

32
 Session ID:
◦ A variable-length session identifier.
◦ A nonzero value indicates that the client wishes to update the
parameters of an existing connection or to create a new
connection on this session.
◦ A zero value indicates that the client wishes to establish a new
connection on a new session.

 CipherSuite:
◦ This is a list that contains the combinations of cryptographic
algorithms supported by the client, in decreasing order of
preference.
◦ Each element of the list (each cipher suite) defines both a key
exchange algorithm and a CipherSpec;

 Compression Method: This is a list of the compression methods

the client supports.

33
 After sending the client_hello message, the client waits for
the server_hello message, which contains the same
parameters as the client_hello message.
 For the server_hello message, the following conventions
apply.
 The Version field contains the lower of the versions
suggested by the client and the highest supported by the
server.
 The Random field is generated by the server and is
independent of the client’s Random field.
 If the SessionID field of the client was nonzero, the same
value is used by the server; otherwise the server’s SessionID
field contains the value for a new session.
 The CipherSuite field contains the single cipher suite selected
by the server from those proposed by the client.
 The Compression field contains the compression method
selected by the server from those proposed by the client.

34
 The first element of the CipherSuite parameter is the key
exchange method (i.e., the means by which the cryptographic
keys for conventional encryption and MAC are
exchanged).The following key exchange methods are
supported.
 RSA: The secret key is encrypted with the receiver’s RSA
public key.
 A publickey certificate for the receiver’s key must be made
available.
 Fixed Diffie-Hellman: This is a Diffie-Hellman key exchange
in which the server’s certificate contains the Diffie-Hellman
public parameters signed by the certificate authority (CA).
 The client provides its Diffie-Hellman public-key parameters
either in a certificate, if client authentication is required, or
in a key exchange message.
 This method results in a fixed secret key between two peers
based on the Diffie-Hellman calculation using the fixed public
keys.

35
 Ephemeral Diffie-Hellman: This technique is used to
create ephemeral (temporary, one-time) secret keys. In
this case, the Diffie-Hellman public keys are exchanged,
signed using the sender’s private RSA or DSS key.
 The receiver can use the corresponding public key to
verify the signature.
 Certificates are used to authenticate the public keys.
This would appear to be the most secure of the three
Diffie-Hellman options, because it results in a
temporary, authenticated key.

36
 Anonymous Diffie-Hellman: The base Diffie-
Hellman algorithm is used with no
authentication.
 That is, each side sends its public Diffie-
Hellman parameters to the other with no
authentication.
 This approach is vulnerable to man-in-the
middle attacks, in which the attacker
conducts anonymous Diffie-Hellman with
both parties.
 Fortezza: the technique defined by US
National security Agency.
 Developed for defense department.

37
 Following the definition of a key exchange method is
the CipherSpec, which includes the following fields.
 Cipher Algorithm: 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

38
  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)
◦ may contain
 public RSA key suitable for encryption, or
 public RSA or DSS key suitable for signing only, or
TLS Handshake Protocol / Phase 2

 fix DH parameters
 server_key_exchange
◦ sent only if the certificate does not contain enough information to
complete the key exchange (e.g., the certificate contains an RSA
signing key only)
◦ may contain
 public RSA key (exponent and modulus), or
 DH parameters (p, g, public DH value), or
 Fortezza parameters
◦ digitally signed
 if DSS: SHA-1 hash of (client_random | server_random | server_params)
is signed
 if RSA: MD5 hash and SHA-1 hash of (client_random | server_random |
server_params) are concatenated and encrypted with the private RSA key
39
  certificate_request
◦ sent if the client needs to authenticate itself
◦ specifies which type of certificate is requested
TLS Handshake Protocol / Phase 2

(rsa_sign, dss_sign, rsa_fixed_dh, dss_fixed_dh, …)

 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

40
  certificate
◦ sent only if requested by the server
◦ may contain
 public RSA or DSS key suitable for signing only, or
 fix DH parameters
TLS Handshake Protocol / Phase 3

 client_key_exchange
◦ always sent (but it is empty if the key exchange method is fix DH)
◦ may contain
 RSA encrypted pre-master secret, or
 client one-time public DH value, or
 Fortezza key exchange parameters
 certificate_verify
◦ sent only if the client sent a certificate
◦ provides client authentication
◦ contains signed hash of all the previous handshake messages
 if DSS: SHA-1 hash is signed
 if RSA: MD5 and SHA-1 hash is concatenated and encrypted with the
private key
MD5( master_secret | pad_2 | MD5( handshake_messages | master_secret | pad_1 ) )
SHA( master_secret | pad_2 | SHA( handshake_messages | master_secret | pad_1 ) )

41
  finished
◦ sent immediately after the change_cipher_spec
TLS Handshake Protocol / Phase 4

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:
MD5( master_secret | pad_2 | MD5( handshake_messages | sender | master_secret |
pad_1 ) ) |
SHA( master_secret | pad_2 | SHA( handshake_messages | sender | master_secret |
pad_1 ) )
where “sender” is a code that identifies that the sender is the
client or the server (client: 0x434C4E54; server: 0x53525652)
42
  pre-master secret
◦ if key exchange is RSA based:
 generated by the client
 sent to the server encrypted with the server’s public RSA key
◦ if key exchange is Diffie-Hellman based:
 pre_master_secret = gxy mod p
 master secret (48 bytes)
master_secret = MD5( pre_master_secret | SHA( “A” | pre_master_secret | client_random |
server_random )) | MD5( pre_master_secret | SHA( “BB” | pre_master_secret |
TLS Handshake Protocol

client_random | server_random )) | MD5( pre_master_secret | SHA( “CCC” |

pre_master_secret | client_random | server_random ))
 keys, MAC secrets, IVs
MD5( master_secret | SHA( “A” | master_secret | client_random | server_random )) |
MD5( master_secret | SHA( “BB” | master_secret | client_random | server_random )) |
MD5( master_secret | SHA( “CCC” | master_secret | client_random | server_random )) | …

key block :
client write MAC secret server write MAC secret client write key server write key …

43
 TLS supports all of the alert codes defined in
SSLv3 with the exception of no_certificate.
 A number of additional codes are defined in
TLS; of these, the following are always fatal.

44
45
46