Title: Secure Sockets
1Secure Sockets
2Overview of Lecture
- We covered an overview of authenticated key
exchange protocols - In this lecture we will
- Look at issues related to Web Security
- Examine a specific implementation of such a
protocol, known as Secure Sockets
3Web Security Issues
- The Web has become the visible interface of the
Internet - Many corporations now use the Web for
advertising, marketing and sales - Web servers might be easy to use but
- Complicated to configure correctly and difficult
to build without security flaws - They can serve as a security hole by which an
adversary might be able to access other data and
computer systems
Threats Consequences Countermeasures
Integrity Modification of Data Trojan horses Loss of Information Compromise of Machine MACs and Hashes
Confidentiality Eavesdropping Theft of Information Loss of Information Privacy Breach Encryption
DoS Stopping Filling up Disks and Resources Stopped Transactions
Authentication Impersonation Data Forgery Misrepresentation of User Accept false Data Signatures, MACs
Table from Stallings, and from A. Rubin
4So Where to Secure the Web?
- There are many strategies to securing the web
- We may attempt to secure the IP Layer of the
TCP/IP Stack This may be accomplished using
IPSec, for example. - We may leave IP alone and secure on top of TCP
This may be accomplished using the Secure Sockets
Layer (SSL) or Transport Layer Security (TLS) - We may seek to secure specific applications by
using application-specific security solutions
For example, we may use Secure Electronic
Transaction (SET) - The first two provide generic solutions, while
the third provides for more specialized services - We will focus this lecture on SSL
5A Quick Look at Securing the TCP/IP Stack
HTTP
FTP
SMTP
HTTP
FTP
SMTP
SSL/TLS
TCP
TCP
IP/IPSEC
IP
At the Network Level
At the Transport Level
S/MIME
PGP
SET
Kerberos
SMTP
HTTP
TCP
UDP
IP
At the Application Level
6Overview of SSL
- The Secure Sockets Layer was originally developed
(1994) by Netscape in order to secure http
communications - Version 3 of SSL was released in 1995
- It is what we think of when we say SSL
- Slight variation became Transport Layer Security
(TLS) and was accepted by the IETF in 1999 - TLS is backward compatible with SSLv3
- TCP provides a reliable end-to-end service
- SSL consists of two sublayers
- SSL Record Protocol (where all the action takes
place) - SSL Management (Handshake/Cipher Change/ Alert
Protocols)
7SSL Preliminaries
- An SSL Session is an association between a client
and a server (created by the Handshake Protocol).
There are a set of security parameters associated
with each session - An SSL Connection is a peer-to-peer relationship,
and is transient. There may be many connections
associated with one session. The same security
parameters may apply to many connections. - Session Security Parameters
- Session Identifier
- Peer Certificate X.509v3 certificate of the peer
- Compression Optional algorithm used to compress
data - Cipher Specs Encryption Algorithm (3DES, AES,
etc.) and hash algorithm (MD5, SHA-1) - Master Secret 48-byte secret shared between
client and server
8SSL Preliminaries, pg. 2
- Connection Parameters
- Server and Client random byte sequences used for
each connection - Server MAC Key Key used in MAC operations on
data sent by the server - Client MAC Key Key used in MAC operations on
data sent by the client - Server Encryption Key Encryption key used for
data encrypted by server and decrypted by client - Client Encryption Key Encryption key used for
data encrypted by client and decrypted by server - Initialization vectors We will use CBC mode, so
we need IVs. - Sequence Numbers Each entity maintains sequence
numbers for transmitted and received messages
9SSL Record Protocol
- The SSL Record Protocol uses the keys derived
from the Handshake Protocol to securely deliver
data - Two functions
- Confidentiality and Message Integrity
Data
10SSL Record Protocol, pg. 2
- SSL Record protocol allows protocols above SSL to
be secured - Example HTTP delivers packets that are
fragmented and securely delivered - SSL does not handle retransmissions it does not
have to! TCP provides that functionality - This is quite the opposite of IPSec, which only
secures IP! - Messages are broken into blocks of at most 16384
bytes - The compression is optional and, due to message
size/type, it might not even be desirable to use! - Encryption may be stream or block mode. This is
negotiated through the Handshake protocol - If block encryption, padding is necessary in
order to fill out a block length - Padding is a sequence of padding bytes (random
junk will do) followed by 1 byte that describes
length of the pad (up to 255).
11SSL Record Protocol, pg. 3
- The Header consists of
- Content type descriptor (1 byte) For the upper
layer to use - Major Version (1 byte) What version of SSL? (3
for SSL and TLS) - Minor Version (1 byte) Indicates the revision (0
for SSLv3, 1 for TLS) - There are only a limited selection of ciphers and
MAC algorithms that are allowed - Interchange Ciphers RSA, Diffie-Hellman (signed
and unsigned), Fortezza - Bulk Encryption Cipher RC4, RC2, DES (CBC Mode),
3DES (EDE-CBC Mode), Fortezza (CBC) - MAC SHA-1 and MD5
12SSL Record Protocol, pg. 4
- The real trick to the Record Protocol is the MAC
- In SSL, the record layer computes a MAC for each
chunk of data. - In SSLv3 the MAC is
- Hash(MACws Pad2Hash(MACwsPad1SeqNumSSLC
ompSSLLenChunk)) - The pieces
- MACws Shared MAC Key
- Hash MD5 or SHA-1
- Pad1 (00110110) repeated 48 times for MD5 or 40
times for SHA-1 - Pad2 (01011100) repeated 48 times for MD5 or 40
times for SHA-1 - SeqNum Sequence number for this message
- SSLComp Higher Layer descriptor of message type
- SSLLen Length of the chunk
- Chunk The fragment of data after it has been
compressed
13SSL Handshake Protocol
- This is the beast Its where all the action
really takes place! - Basically, the Handshake protocol is used before
any application data is transmitted. - It is used to allow the server and client to
authenticate each other - To negotiate on an encryption and MAC algorithm
- Establish keys to be used
- The Handshake Protocol consists of messages
consisting of three fields - Type (1 byte) Indicates type of the message.
There are 10 types. - Length (3 bytes)
- Content The payload exchanged in each message
14SSL Handshake Protocol, pg. 2
- Round 1 Create the Connection between the Client
A and Server G (Gigafirm in my notes), and figure
out what each entity can do!
- rA is a nonce made of 4 bytes of timestamp and
28 bytes of random . Similarly for rG. - SessID 0 if new session, else is the session ID
of an existing session (and the Handshake will
update parameters) - CiphList is a list of algorithms supported by the
client in an order of decreasing preference (Key
Exchange and Encryption Cipher) - CiphChoice The cipher suite chosen by the
Server.
15SSL Handshake Protocol, pg. 3
- Round 2 Server Authentication and Key Exchange
- Server begins by sending its X.509 cert (and
associated cert chain) - Next, a public key is sent (e.g. modulus and
exponent, if RSA) - Server may Request a Cert from the Client
- Server sends end round 2 message
KG is the private key, and hence EKG is a
signature operation by the Server ValidCertAuthori
ties identifies the authorities the server will
accept
16SSL Handshake Protocol, pg. 4
- Round 3 Client Authentication and Key Exchange
- Client verifies that the Servers Cert is valid,
and checks that parameters sent are valid - If a cert was requested, then the Client sends
one - Server generates a PreMasterSecret sPM
KG is the public key, and hence EKG is a
encryption using the public key gained from the
certificate Messages1to8 is the concatenation of
first 8 messages MS is master secret and Step 9
is for verification
17SSL Handshake Protocol, pg. 5
- Round 4 Wrap-up
- Client tells Server to change cipher (via the
Change Cipher Protocol). - Server responds with its own changed cipher
message - Finished Message are hashes for verification
18Other SSL Management Functions
- There are two other Management Functions provided
by SSL - Change Cipher Spec A single byte is sent after
new cipher parameters have been agreed upon (aka.
Handshake). Pending parameters become
activated. - SSL Alert Protocol Signals that unusual
conditions have been encountered. - Each message consists of two bytes. First byte is
a (1) if a warning or a (2) if a fatal error. If
error is fatal, the connection is terminated
(other connections may continue). Second byte
says the type of error. - Unexpected_Message Fatal
- Bad_Record_MAC Fatal
- Decompression_Failure Fatal
- Handshake_Failure Fatal
- And many more
19Wrap-Up
- Many other parameters are generated from the
master secret - ClientWrite MAC Secret and ClientWrite Key
- ServerWrite MAC Secret and ServerWrite Key
- Client and Server IVs
- Parameters are generated via hashing MS is
basically a seed to a pseudorandom function. - TLS is very similar to SSL
- TLS uses HMAC instead of the concatenation-MAC
- TLS does not support Fortezza
- Minor differences in padding requirements