1. IT443 – Network Security Administration Instructor: Bo Sheng
SSL/TLS
IT443 – Network Security Administration
Instructor: Bo Sheng

2. What Layer? Appl. OS Application Application SSL TCP TCP IPSec IP IP
LAN layer
LAN layer

3. History SSLv2 proposed and deployed in Netscape 1.1 (1995)
PCT (Private Communications Technology) by Microsoft
SSLv3: most commonly used (1995)
was developed with public review
TLS proposed by the IETF based on SSLv3 but not compatible (1996)
Uses patent free DH and DSS instead of RSA which patent didn’t expire yet

4. SSL vs. IPsec
SSL:
Avoids modifying “TCP stack” and requires minimum changes to the application
Mostly used to authenticate servers
IPsec
Transparent to the application and requires modification of the network stack
Authenticates network nodes and establishes a secure channel between nodes
Application still needs to authenticate the users

5. … SSL Architecture Relies on TCP for reliable communication
HTTP and other applications
SSL Handshake Protocol
SSL Change Cipher Protocol
SSL Alert Protocol
SSL API
SSL Record Protocol
TCP IP …
Relies on TCP for reliable communication

6. SSL Architecture Handshake protocol: establishment of a session key
Change Cipher protocol: start using the previously-negotiated encryption / message authentication
Alert protocol: notification (warnings or fatal exceptions)
Record protocol: protected (encrypted, authenticated) communication between client and server

7. Connections and Sessions
SSL Session
an association between peers
created through a handshake, negotiates security parameters, can be long-lasting
SSL Connection
a type of service (i.e., an application) between a client and a server
transient
Multiple connections can be part of a single session

8. Basic Protocols Goal: application independent security Messages
Originally for HTTP, but now used for many applications
Each application has an assigned TCP port, e.g., https (HTTP over SSL) uses port 443
Messages
A -> B: I want to talk, ciphers I support, RA
B -> A: certificates, cipher I choose, RB
A -> B: {S}B+, {keyed hash of handshake msgs}
B -> A: {keyed hash of handshake msgs}
A <-> B: data encrypted and integrity checked with keys derived from K
Keyed hashes use K = f(S, RA, RB)

9. Basic Protocols
How do you make sure that keyed hash in message 3 is different from B’s response?
Include a constant CLNT/client finished (in SSL/TLS) for A and SRVR/server finished for B
Keyed hash is sent encrypted and integrity protected for no real reason
Keys: derived by hashing K and RA and RB
3 keys in each direction: encryption, integrity and IV
Write keys (to send: encrypt, integrity protect)
Read keys (to receive: decrypt, integrity check)

10. Session Resumption
Many secure connections can be derived from the session
Cheap: how?
Session initiation: modify message 2
B -> A: session_id, certificate, cipher, RB
A and B remember: (session_id, master key)
To resume a session: A presents the session_id in message 1
A -> B: session_id, ciphers I support, RA
B -> A: session_id, cipher I choose, RB, {keyed hash of handshake msgs}
A -> B: {keyed hash of handshake msgs}
A <-> B: data encrypted and integrity checked with keys derived from K

11. Negotiating Cipher Suites
A cipher suite is a complete package:
(encryption algorithm, key length, integrity checksum algorithm, etc.)
Cipher suites are predefined:
Each assigned a unique value (contrast with IKE)
SSLv2: 3 bytes, SSLv3: 2 bytes => up to combinations
30 defined,
256 reserved for private use: FFxx (risk of non-interoperability)
Selection decision:
In v3 A proposes, B chooses
In v2 A proposes, B returns acceptable choices, and A chooses
Suite names examples:
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL2_RC4_128_WITH_MD5

12. SSL Record Protocol

13. Protocol Steps Fragment data stream into records Compress each record
each with a maximum length of 214 (=16K) bytes
Compress each record
Create message authentication code for each record
Encrypt each record

14. Protocol Steps Application Data Fragment Compress Add MAC Encrypt
Add SSL Hdr

15. SSL Record Format
Record Type
SSL Version
Payload Length
Application Data (optionally compressed)
Encrypted
Optional MAC (16 or 20 bytes)
There is, unfortunately, some version number silliness between v2 and v3; see text for (ugly) details

16. SSL Handshake Protocol

17. Phases of Protocol Establish security capabilities
version of SSL to use
cipher + parameters to use
Authenticate server (optional), and perform key exchange
Authenticate client (optional), and perform key exchange
Finish up

18. All the Messages

19. I. Establish Security Capabilities
Client
Server
Client_Hello*
Server_Hello*
Messages marked with * are mandatory

20. Client_Hello Message Transmitted in plaintext Contents
highest SSL version understood by client
RC: a 4-byte timestamp + 28-byte random number
session ID: 0 for a new session, non-zero for a previous session
list of supported cryptographic algorithms
list of supported compression methods

21. Server_Hello Message Also transmitted in plaintext Contents
minimum of (highest version supported by server, highest version supported by client)
RS: 4-byte timestamp and 28-byte random number
session ID
a cryptographic choice selected from the client’s list
a compression method selected from the client’s list

22. II. Server Auth. / Key Exchange
Client
Server
Server_Certificate
Server_Key_Exchange
Client_Certificate_Request
Server_Handshake_Done*
The Server_Certificate message is optional, but almost always used in practice

23. Server_Certificate Message
Contains a certificate with server’s public key, in X.509 format
or, a chain of certificates if required
The server certificate is necessary for any key exchange method except for anonymous Diffie-Hellman

24. Authenticating the Server
source: sun.com
Step #4: Domain name in certificate must match domain name of server (not part of SSL protocol, but clients should check this)

25. Client_Certificate_Request Msg.
Normally not used, because in most applications
only the server is authenticated
client is authenticated at the application layer, if needed
Two parameters
certificate type accepted, e.g., RSA/signature only, DSS/signature only, …
list of certificate authorities recognized (i.e., trusted third parties)

26. III. Client Auth. / Key Exchange
Server
Client_Certificate
Client_Key_Exchange*
Client_Certificate_Verify

27. Client_Certificate_Verify Msg
Proves the client is the valid owner of a certificate (i.e., knows the corresponding private key)
Only sent following any client certificate that has signing capability
Was ist das?

28. IV. Finish Up Client Server
Change_Cipher_Spec*
Client_Finished*
Change_Cipher_Spec*
Server_Finished*
Switch to the negotiated cipher for all remaining (application) messages

29. Change_Cipher_Spec Msg
Confirms the change of the current state of the session to a newly-negotiated set of cryptographic parameters
Finished Messages
keyed hash of the previous handshake messages to prevent man-in-the-middle-attacks from succeeding

30. Alert Protocol Examples
Type 1: Warning
ex.: No_Certificate, Close_Notify
Type 2: Fatal_Alert
ex.: Unexpected_Message, Bad_MAC, etc.
connection is immediately terminated

31. Summary
SSL is the de facto authentication/encryption protocol standard for HTTP
becoming popular for many other protocols as well
Allows negotiation of cryptographic methods and parameters