SSL/TLS. What Layer? History. SSL vs. IPsec. SSL Architecture. SSL Architecture. IT443 Network Security Administration Instructor: Bo Sheng

Transcription

1 What Layer? /TLS IT443 Network Security Administration Instructor: Bo Sheng Application TCP IPSec IP LAN layer Application TCP IP LAN layer 1 2 History v2 proposed and deployed in Netscape 1.1 (1995) PCT (Private Communications Technology) by Microsoft v3: most commonly used (1995) was developed with public review TLS proposed by the IETF based on v3 but not compatible (1996) Uses patent free DH and DSS instead of RSA which patent didn t expire yet vs. IPsec : 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 3 4 Handshake Protocol Architecture HTTP and other applications Change Cipher Protocol Alert Protocol Record Protocol TCP IP API Architecture Handshake protocol: establishment of a session key Change Cipher protocol: start using the previouslynegotiated encryption / message authentication Alert protocol: notification (warnings or fatal exceptions) Record protocol: protected (encrypted, authenticated) communication between client and server Relies on TCP for reliable communication 5 6 1

2 Connections and Sessions Session an association between peers created through a handshake, negotiates security parameters, can be long-lasting 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 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 ) uses port 443 Messages A -> B: I want to talk, ciphers I support, R A B -> A: certificates, cipher I choose, R B 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, R A, R B ) 7 8 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 /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 R A and R B 3 keys in each direction: encryption, integrity and IV Write keys (to send: encrypt, integrity protect) Read keys (to receive: decrypt, integrity check) Session Resumption Many secure connections can be derived from the session Cheap: how? Session initiation: modify message 2 B -> A: session_id, certificate, cipher, R B 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, R A B -> A: session_id, cipher I choose, R B, {keyed hash of handshake msgs} A -> B: {keyed hash of handshake msgs} A <-> B: data encrypted and integrity checked with keys derived from K 9 10 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) v2: 3 bytes, v3: 2 bytes => up to combinations 30 defined, 256 reserved for private use: FFxx (risk of non-interoperability) Record Protocol Selection decision: In v3 A proposes, B chooses In v2 A proposes, B returns acceptable choices, and A chooses Suite names examples: _RSA_EXPORT_WITH_DES40_CBC_SHA 2_RC4_128_WITH_MD

3 Encrypted Protocol Steps 1. Fragment data stream into records each with a maximum length of 2 14 (=16K) bytes 2. Compress each record 3. Create message authentication code for each record 4. Encrypt each record Application Data Fragment Compress Add MAC Encrypt Add Hdr Protocol Steps Record Format Record Type Version Payload Length Application Data (optionally compressed) Handshake Protocol Optional MAC (16 or 20 bytes) There is, unfortunately, some version number silliness between v2 and v3; see text for (ugly) details Phases of Protocol I. Establish security capabilities version of to use cipher + parameters to use All the Messages II. III. IV. Authenticate server (optional), and perform key exchange Authenticate client (optional), and perform key exchange Finish up

4 I. Establish Security Capabilities Messages marked with * are mandatory _Hello Message Transmitted in plaintext Contents highest version understood by client R C : 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 _Hello Message Also transmitted in plaintext II. Auth. / Key Exchange Contents minimum of (highest version supported by server, highest version supported by client) R S : 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 The _Certificate message is optional, but almost always used in practice _Certificate Message Contains a certificate with server s public key, in X.509 format or, a chain of certificates if required Authenticating the source: sun.com The server certificate is necessary for any key exchange method except for anonymous Diffie-Hellman Step #4: Domain name in certificate must match domain name of server (not part of protocol, but clients should check this)

5 _Certificate_Request Msg. III. Auth. / Key Exchange 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) _Certificate_Verify Msg Proves the client is the valid owner of a certificate (i.e., knows the corresponding private key) IV. Finish Up Only sent following any client certificate that has signing capability Switch to the negotiated cipher for 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-middleattacks from succeeding 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

6 Summary 1. 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 6