ssl/tls (ch 19)
DESCRIPTION
SSL/TLS (ch 19). IT443 – Network Security Administration Instructor: Bo Sheng. What Layer?. Application. Application. Appl. SSL. TCP. TCP. IPSec. OS. IP. IP. LAN layer. LAN layer. History. SSLv2 proposed and deployed in Netscape 1.1 (1995) - PowerPoint PPT PresentationTRANSCRIPT
1
SSL/TLS
IT443 – Network Security AdministrationInstructor: Bo Sheng
2
What Layer?
OS
App
l.
TCPIPSec
IPLAN layer
TCPSSL
IPLAN layer
ApplicationApplication
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
HTTP and other applications
SSLHandshake
Protocol
SSLChange Cipher
Protocol
SSLAlert
Protocol
SSLAPI
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
– 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 65000 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
SSL Record Protocol
12
Protocol Steps1. Fragment data stream into records
– each with a maximum length of 214 (=16K) bytes
2. Compress each record
3. Create message authentication code for each record
4. Encrypt each record
13
Protocol Steps
14
Application Data
Fragment
Compress
Add MAC
Encrypt
Add SSL Hdr
SSL Record Format
• There is, unfortunately, some version number silliness between v2 and v3; see text for (ugly) details
15
RecordType SSL Version Payload
Length
Application Data(optionally compressed)
Optional MAC (16 or 20 bytes)
Encr
ypte
d
SSL Handshake Protocol
16
Phases of ProtocolI. Establish security capabilities
• version of SSL to use• cipher + parameters to use
II. Authenticate server (optional), and perform key exchange
III. Authenticate client (optional), and perform key exchange
IV. Finish up
17
All the Messages
18
I. Establish Security Capabilities
• Messages marked with * are mandatory19
Client ServerClient_Hello*
Server_Hello*
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
20
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
21
II. Server Auth. / Key Exchange
• The Server_Certificate message is optional, but almost always used in practice
22
Client Server
Server_Certifica
te
Server_Key_Excha
nge
Client_Certifica
te_Request
Server_Handshake
_Done*
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
23
Authenticating the Server
• Step #4: Domain name in certificate must match domain name of server (not part of SSL protocol, but clients should check this)
24
source: sun.com
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)
III. Client Auth. / Key Exchange
Client ServerClient_CertificateClient_Key_Exchange*Client_Certificate_Verify
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
27
IV. Finish Up
28
Client ServerChange_Cipher_Spec*
Change_Cipher_Sp
ec*
Client_Finished*
Server_Finished*
Switch to the negotiated cipherfor all remaining (application)
messages
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
29
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
30
Summary
1.SSL is the de facto authentication/encryption protocol standard for HTTP– becoming popular for many other protocols as
well
2.Allows negotiation of cryptographic methods and parameters
31