Download - SSL/TLS (ch 19)
![Page 1: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/1.jpg)
1
SSL/TLS
IT443 – Network Security AdministrationInstructor: Bo Sheng
![Page 2: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/2.jpg)
2
What Layer?
OS
App
l.
TCPIPSec
IPLAN layer
TCPSSL
IPLAN layer
ApplicationApplication
![Page 3: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/3.jpg)
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
![Page 4: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/4.jpg)
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
![Page 5: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/5.jpg)
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
![Page 6: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/6.jpg)
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
![Page 7: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/7.jpg)
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
![Page 8: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/8.jpg)
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)
![Page 9: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/9.jpg)
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)
![Page 10: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/10.jpg)
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
![Page 11: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/11.jpg)
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
![Page 12: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/12.jpg)
SSL Record Protocol
12
![Page 13: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/13.jpg)
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
![Page 14: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/14.jpg)
Protocol Steps
14
Application Data
Fragment
Compress
Add MAC
Encrypt
Add SSL Hdr
![Page 15: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/15.jpg)
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
![Page 16: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/16.jpg)
SSL Handshake Protocol
16
![Page 17: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/17.jpg)
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
![Page 18: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/18.jpg)
All the Messages
18
![Page 19: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/19.jpg)
I. Establish Security Capabilities
• Messages marked with * are mandatory19
Client ServerClient_Hello*
Server_Hello*
![Page 20: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/20.jpg)
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
![Page 21: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/21.jpg)
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
![Page 22: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/22.jpg)
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*
![Page 23: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/23.jpg)
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
![Page 24: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/24.jpg)
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
![Page 25: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/25.jpg)
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)
![Page 26: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/26.jpg)
III. Client Auth. / Key Exchange
Client ServerClient_CertificateClient_Key_Exchange*Client_Certificate_Verify
![Page 27: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/27.jpg)
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
![Page 28: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/28.jpg)
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
![Page 29: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/29.jpg)
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
![Page 30: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/30.jpg)
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
![Page 31: SSL/TLS (ch 19)](https://reader035.vdocuments.us/reader035/viewer/2022062310/5681637d550346895dd45bbb/html5/thumbnails/31.jpg)
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