1 / 23

SSL/TLS

SSL/TLS. Security requirements Secrecy to prevent eavesdroppers to learn sensitive information Entity authentication Message authentication and integrity to prevent message alteration / injection For example, if you want to buy a book at amazon.com

ivy
Download Presentation

SSL/TLS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SSL/TLS

  2. Security requirements Secrecy to prevent eavesdroppers to learn sensitive information Entity authentication Message authentication and integrity to prevent message alteration / injection For example, if you want to buy a book at amazon.com You want to be sure you are dealing with Amazon (authentication) Your credit card information must be protected in transit (confidentiality and/or integrity) As long as you have money, Amazon doesn’t care who you are (authentication need not be mutual) Web security

  3. Approaches • Web security approaches • IP Security: it is transparent to end users and applications. • Security above TCP • Application-specific security: embedded within the particular application

  4. Comparison of web security approaches HTTP FTP SMTP SET S/MIME PGP HTTP SMTP HTTP FTP SMTP SSL(TLS) TCP TCP TCP IP Sec IP IP

  5. application transport network link physical Socket layer • “Socket layer” lives between application and transport layers • SSL usually lies between HTTP (application) and TCP (transport) User Socket “layer” OS NIC

  6. SSL v1: Designed by Netscape, never deployed SSL v2: Deployed in Netscape Navigator 1.1 in 1995 SSL v3: Substantial overhaul, fixing security flaws, publicly reviewed TLS(Transport Layer Security protocol) v1 IETF standard SSLv3 with little tweak SSL(Secure Sockets Layer protocol)History

  7. Simple SSL-like Protocol • Is Alice sure she’s talking to Bob? • Is Bob sure he’s talking to Alice? I’d like to talk to you securely Here’s my certificate {KAB}Bob protected HTTP Bob Alice

  8. Simplified SSL Protocol • S is pre-master secret • K = h(S,RA,RB) • msgs = all previous messages • CLNT and SRVR are constants Can we talk?, cipher list, RA Certificate, cipher, RB {S}Bob, E(h(msgs,CLNT,K),K) h(msgs,SRVR,K) Data protected with key K Bob Alice

  9. SSL Keys • 6 “keys” derived from K = hash(S,RA,RB) • 2 encryption keys: send and receive • 2 integrity keys: send and receive • 2 IVs: send and receive • Why different keys in each direction? • Q:Why is h(msgs,CLNT,K) encrypted (and integrity protected)? • A: It adds no security…

  10. SSL Authentication • Alice authenticates Bob, not vice-versa • How does client authenticate server? • Why does server not authenticate client? • Mutual authentication is possible: Bob sends certificate requestin message 2 • This requires client to have certificate • If server wants to authenticate client, server could instead require (encrypted) password

  11. SSL MiM Attack RA RA • Q: What prevents this MiM attack? • A:Bob’s certificate must be signed by a certificate authority (such as Verisign) • What does Web browser do if sig. not valid? • What does user do if signature is not valid? certificateT, RB certificateB, RB {S1}Trudy,E(X1,K1) {S2}Bob,E(X2,K2) h(Y1,K1) h(Y2,K2) Trudy E(data,K1) E(data,K2) Alice Bob

  12. SSL Handshake Protocol Client server client_hello Phase 1 server_hello certificate server_key_exchange certificate_request Phase 2 server_hello_done certificate client_key_exchange Phase 3 certificate_verify change_cipher_spec Blue: optional message finished Phase 4 change_cipher_spec finished

  13. {client, server}_hello message Version: the highest SSL version Random 32-bit timestamp 28 bytes random number Session ID Cipher suite client_hello: Ciphers are listed in decreasing order of preference server_hello: chosen cipher Compression method Phase 1: establish security capabilities

  14. Cipher suite = (key exchange methods, cipher spec) Key exchange methods RSA: encrypt key with receiver’s public key Fixed Diffie-Hellman Server’s certificate contains DH public parameters signed by CA. The client provides its DH public parameters either in a certificate or in a key exchange message. Ephemeral Diffie-Hellman Certificate contains server’s public key. DH public parameters are signed using the server’s private key. Anonymous Diffie-Hellman Each side sends its DH public parameters to the other without authentication. Cipher Suite

  15. Cipher spec Cipher Algorithm (RC4, RC2, DES, 3DES, DES40, IDEA) MAC Algorithm (MD5, SHA-1) Cipher Type (stream or block) Is Exportable (true or false) Hash size (0 or 16 bytes for MD5, 20 bytes for SHA-1) IV size: IV size for Cipher Block Chaining(CBC) encryption

  16. S  C: certificate RSA: Certificate contains server’s public key Fixed DH: Certificate contains DH public parameters signed by CA. Ephemeral DH: Certificate contains server’s public key. S  C: server_key_exchange Anonymous DH: {g, p, gs} Ephemeral DH: {g, p, gs} + signature of {g, p, gs} RSA: if server’s key is only for a signature-only key, the server create a temporary RSA public/private keys and send the temporary public key S  C: certificate_request Cert_type (RSA or DSS for key exchange) List of acceptable certificate authorities S  C: server_hello_done, no parameters A signature is created by computing hash(client_rand || server_rand || server parameters) and encrypting it with the sender’s private key. Phase 2: Server authentication and key exchange

  17. After phase 2, client has all values required to generate the session key C  S: certificate If server requested a certificate C  S: client_key_exchange RSA: client generates 48 byte pre-master secret, encrypts it with server’s public key or temporary RSA key from a server_key_exchange message. Ephemeral or anonymous DH: client’s DH public parameters Fixed DH: null (certificate contained client’s DH key) C  S: certificate_verify Only used if client sent certificate with signing key KC CertificateVerify.signature.md5_hash = {MD5( master secret || pad2 || MD5( handshake messages || master secret || pad1 ))}KC-1 Phase 3

  18. After phase 3, client and server share master secret computed from pre-master secret, and authenticated each other Phase 4: Finish C  S: change_cipher_spec Copies the pending Cipher spec in the current CipherSpec. C  S: finished MD5( master_secret || pad2 || MD5( handshake messages || Sender || master_secret || pad1 )) ||SHA-1( master_secret || pad2 || SHA-1( handshake messages || Sender || master_secret || pad1 )) pad1 and pad2 are the values defined earlier for the MAC Handshake messages contains all messages up to now S  C: change_cipher_spec S  C: finished Phase 4

  19. Client and server perform DH calculation to create the shared pre-master secret (PS). Master secret (MS) created from pre-master secret (PS), Client random (CR), Server random (SR) MS = MD5( PS || SHA-1( ‘A’ || PS || CR || SR )) ||MD5( PS || SHA-1( ‘BB’ || PS || CR || SR )) ||MD5( PS || SHA-1( ‘CCC’ || PS || CR || SR )) CipherSpec requires client & server MAC key, client & server encryption key, client & server IV, generated from MS: MD5( MS || SHA-1( ‘A’ || MS || SR || CR )) ||MD5( MS || SHA-1( ‘BB’ || MS || SR || CR )) ||MD5( MS || SHA-1( ‘CCC’ || MS || SR || CR )) ||MD5( MS || SHA-1( ‘DDDD’ || MS || SR || CR )) || … Cryptographic computation

  20. SSL Record = Content type || Major version || Minor version || Length ||{ Data || MAC( K’, Data ) }K MAC( K’, Data ) = hash( K’ || pad2 || hash( K’ || pad1 || seq_num || compressed_type || length || Data )) hash: MD5 or SHA-1 pad1 = 0x363636… pad2 = 0x5C5C5C… seq_num: sequence number for message SSLRecord format

  21. Client has no certificate, only server authenticated C  S: client_hello S  C: server_hello Ephemeral DH key exchange, RC4 encryption, MD5-based MAC S  C: Server certificate, containing RSA public key Client checks validity + verifies URL matches certificate! S  C: Server_key_exchange: g, p, gs, {H(g, p, gs)}KS-1 S  C: server_hello_done C  S: client_key_exchange: gc C  S: change_cipher_spec C  S: finished S  C: change_cipher_spec S  C: finished Sample SSLsession

  22. SSL Sessions vs Connections • SSL session is established as shown on previous slides • SSL designed foruse with HTTP 1.0 • HTTP 1.0 usually opens multiple simultaneous (parallel) connections • SSL session establishment is costly • Due to public key operations • SSL has an efficient protocol for opening new connections given an existing session

  23. SSL Connection • Assuming SSL session exists • So S is already known to Alice and Bob • Both sides must remember session-ID • Again, K = h(S,RA,RB) session-ID, cipher list, RA session-ID, cipher, RB, h(msgs,SRVR,K) h(msgs,CLNT,K) Protected data Bob Alice • No public key operations! (relies on known S)

More Related