Web security
Secure Socket Layer Protocol
Secure communication over the Internet
What is SSL?
• SSL is the most commonly deployed protocol for
secure connections to web servers
• For example, if you want to buy a book at
[Link]
– You want to be sure you are dealing with Amazon
(authentication)
– Your credit card information must be protected in
transit (confidentiality and/or integrity)
– As long as you have money, Amazon doesn’t care who you
are (authentication need not be mutual)
Brief History of SSL
• SSL 1.0
– Internal Netscape design, early 1994
• SSL 2.0
– Published by Netscape, November 1994
• Versions 1 and 2 of SSL were badly broken!
• SSL 3.0
– Designed by Netscape and Paul Kocher, November 1996
• TLS 1.0
– Internet standard based on SSL 3.0, January 1999
• TLS uses HMAC instead of MAC
Common Themes
• Peer negotiation for algorithm support
– the client and server negotiation for selecting
cryptographic algorithms
• Public key encryption-based key exchange and
certificate-based authentication
• Symmetric cipher-based traffic encryption
SSL architecture
SSL SSL Change SSL
applications
Handshake Cipher Spec Alert
(e.g., HTTP)
Protocol Protocol Protocol
SSL Record Protocol
TCP
IP
SSL components
• SSL Handshake Protocol
– negotiation of security algorithms and parameters
– key exchange
– server authentication (and optionally client authentication)
• SSL Change Cipher Spec Protocol
– a single message that indicates the end of the SSL handshake
• SSL Alert Protocol
– error messages (fatal alerts and warnings)
• SSL Record Protocol
– fragmentation
– compression
– message authentication and integrity protection
– encryption
Sessions and connections
• SSL session is an association between a client and a
server
• sessions are stateful; the session state includes
security algorithms and parameters
• a session may include multiple secure connections
between the same client and server
Session states
session state
– session identifier
• arbitrary byte sequence chosen by the server to identify the session
– peer certificate
• X509 certificate
– compression method
– cipher spec
• data encryption algorithm
• MAC algorithm
– master secret
• 48-byte secret shared between the client and the server
– is resumable
• a flag indicating whether the session can be used to initiate new
connections
Connection states
connection state
– server and client random numbers
• random byte sequences chosen by the server and the client for every
connection
– server write MAC secret
• secret key used in MAC operations on data sent by the server
– client write MAC secret
• secret key used in MAC operations on data sent by the client
– server write key
• secret encryption key for data encrypted by the server
– client write key
• secret encryption key for data encrypted by the client
– initialization vectors
• an IV is maintained for each encryption key if CBC mode is used
– sending and receiving sequence numbers
• sequence numbers are 64 bits long
• reset to zero after each Change Cipher Spec message
Theme on SSL/TLS
• Peer negotiation for algorithm support
- the client and server negotiation for selecting
cryptographic algorithms
• Public key certificate-based authentication
- Why certificate ? Who creates ? What does it contain ?
• Requires Public Key Infrastructure (PKI)
• Public key based session key establishment
- RSA, Diffie-Hellman
• Symmetric key-based data confidentiality
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
Ciphersuite Negotiation
• Client hello (clientserver)
– “Hi! I speak these n ciphersuites, and here’s a
random number (nonce) I just picked”
• Server hello (clientserver)
– “Hello! We’re going to use this particular
ciphersuite, and here’s a nonce I just picked.”
Client Hello message
client_hello
– client_version
• the highest version supported by the client
– client_random
• current time + client random number
– session_id
• empty if the client wants to create a new session, or
• the session ID of an old session within which the client wants to create
the new connection
– cipher_suites
• list of cryptographic options supported by the client by preference
• a cipher suite contains the specification of the
– key exchange method, the encryption and the MAC algorithm
– exmaple: SSL_RSA_with_3DES_EDE_CBC_SHA
– compression_methods
• list of compression methods supported by the client
Server Hello message
server_hello
– server_version
• Minimum( highest version supported by client, highest version supported by server )
– server_random
• current time + server random number
– session_id
• session ID chosen by the server
– 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
Supported key exchange methods
• RSA based
– the secret key (pre-master secret) is encrypted with the server’s public key
– the server’s public key is made available to the client during the exchange
• fixed Diffie-Hellman
– the server has fix DH parameters contained in a certificate signed by a CA
– the client may have fix DH parameters certified by a CA or it may send an
unauthenticated one-time DH public value in the client_key_exchange message
• ephemeral Diffie-Hellman
– both the server and the client generate one-time DH parameters
– the server signs its DH parameters with its private RSA or DSS key
– the client may authenticate itself (if requested by the server) by signing the
hash of the handshake messages with its private RSA or DSS key
• anonymous Diffie-Hellman
– both the server and the client generate one-time DH parameters
– they send their parameters to the peer without authentication
• Fortezza
– Fortezza proprietary key exchange scheme
Certificate request and server hello done msgs
client server
• certificate_request
client_hello
– sent if the client needs to server_hello
authenticate itself
– specifies which type of certificate
certificate is requested (rsa_sign, server_key_exchange
dss_sign, rsa_fixed_dh, certificate_request
dss_fixed_dh, …) server_hello_done
certificate
• server_hello_done
client_key_exchange
– sent to indicate that the server is certificate_verify
finished its part of the key
exchange change_cipher_spec
– after sending this message the finished
server waits for client response
change_cipher_spec
finished
Finished messages
finished
– sent immediately after the change_cipher_spec message
– 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 ) )
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
• generated by client and server
• pre_master_secret = gxy mod p
Master secret key and Keying Material
• Master secret key (48-byte)
PRF(pre-master key, Nonce(client, server)) =
MD5(pre-master key || SHA(“A” || pre-master key || Nonce(client, server))) ||
MD5(pre-master key || SHA(“BB” || pre-master key || Nonce(client, server))) ||
MD5(pre-master key || SHA(“CCC” || pre-master key ||Nonce(client, server)))
• Keying Material (MAC-key, Write-key, …)
PRF(pre-master key, Nonce(client, server)) =
MD5(pre-master key || SHA(“A” || pre-master key ||Nonce(client, server))) ||
MD5(pre-master key|| SHA(“BB” || pre-master key ||Nonce(client, server))) ||
MD5(pre-master key|| SHA(“CCC” || pre-master key ||Nonce(client, server)))
|| …
SSL Record Protocol – processing overview
application data
fragmentation
SSLPlaintext
type version length
compression
SSLCompressed
type version length
msg authentication and
encryption (with padding if necessary)
SSLCiphertext
type version length MAC padding
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 214
MAC
MAC = hash( MAC_write_secret | pad_2 |
hash( MAC_write_secret | pad_1 | seq_num | type | length | fragment ) )
• supported hash functions:
– MD5
– SHA-1
– pad_1 is 0x36 repeated
– pad_2 is 0x5C repeated
SSL Alert Protocol
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
post-handshake verification of all messages
Client Server
C, VerC, SuiteC
VerS, SuiteS, signCA{S, Spub}
Choose a pre-master {Pre-master Secret}Spub
Secret
MACK(Messages 1- 3)
MACK(Messages 1- 4)
A prominent attack is Replay
Replay attacks
• SSL protects against replay attacks by including an
implicit sequence number in the MAC computation
– prevents re-order and deletion of messages
• sequence numbers are 64 bit long
Avoiding Replay attack
Client Server
C, VerC, SuiteC, NC
VerS, SuiteS, signCA{S, Spub}, NS
Choose a Pre-master {Pre-master Secret}Spub
Secret
MACK(Messages 1- 3)
MACK(Messages 1- 4)
Version Rollback Attack
• C S: C, 3.0, SuiteC, NC
• I(C) S: C, 2.0, SuiteI, NC
• S I: 2.0, SuiteS, NS, signCA{S, Spub}
• I C: 2.0, SuiteI, NS, signCA{S, Spub}
• C S: {Pre-master Secret}Spub
• …
The SSL 3.0 handshake protocol
Client Server
C, VerC, SuiteC, NC
VerS, SuiteS, signCA{S, Spub}, NS
Choose a Pre- {VerC, Pre-master Secret}Spub
master Secret
MACK(Messages 1- 3)
MACK(Messages 1- 4)
Key-exchange algorithm rollback
Key-exchange algorithm rollback
• SSL authenticates only the server’s (RSA or DH) parameters in
the server_key_exchange message.
• it doesn’t authenticate the context (key exchange algorithm in
use) in which those parameters should be interpreted.
• A fix:
– hash all messages exchanged before the server_key_exchange message
– include the hash in the signature in server_key_exchange message
TLS vs. SSL
• version number
– for TLS the current version number is 3.1
• MAC
– TLS uses HMAC
• cipher suites
– TLS doesn’t support Fortezza key exchange and Fortezza
encryption
• certificate_verify message
– the hash is computed only over the handshake messages
TLS vs. SSL cont’d
finished message
PRF( master_secret, “client finished”,
MD5(handshake_messages) | SHA(handshake_messages) )
cryptographic computations
– pre-master secret is calculated in the same way as in SSL
– master secret:
PRF( pre_master_secret, “master secret”,
client_random | server_random )
– key block:
PRF( master_secret, “key expansion”,
server_random | client_random )