O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.


867 visualizações

Publicada em

  • Entre para ver os comentários

  • Seja a primeira pessoa a gostar disto


  1. 1. SSL / TLS Internet Security Protocols
  2. 2. © Novell, Inc. All rights reserved.2 What is it used for?  Designed to provide communication security over the Internet  Authentication, Data Integrity, Confidentiality  Prevents Eavesdropping, tampering & message forgery  Application protocol independent ( POP3, IMAP, SMTP, FTP)  Virtual Private Network (SSL VPN)  Public key infrastructure(PKI)
  3. 3. © Novell, Inc. All rights reserved.3 Cryptography Heads up!!! 1. Symmetric Key Cryptography 2. Asymmetric Key Cryptography a.k.a. Public Key Cryptography
  4. 4. © Novell, Inc. All rights reserved.4 Symmetric Key Cryptography
  5. 5. © Novell, Inc. All rights reserved.5 Public Key Cryptography
  6. 6. © Novell, Inc. All rights reserved.6 History & Development Secure Network Programming (1993) SSL 1.0, 2.0 and 3.0 (1995-96) TLS 1.0(1999) TLS 1.1(2006) TLS 1.2(2008) TLS 1.3(Draft Oct. 2014)
  7. 7. © Novell, Inc. All rights reserved.7 SSL/TLS Architecture Handshake protocol Change Cipher spec Alert Application Protocol Record TCP/IP
  8. 8. © Novell, Inc. All rights reserved.8 Basic TLS Handshake TLS Client TLS Server Client Hello Offers TLS version, list of ciphers, compression methods etc. Server Hello Server chooses TLS version, Session IDs, Cipher, compression method Server Certificate (Optional) Server Key Exchange (Optional) Servers public key if certificate not available Client certificate request (Optional) Server Hello Done Client Certificate (Optional) Client KeyExchange PreMasterSecret or public key, or nothing encrypted using server’s public key Client Certificate verify (Optional) client will start using the new session keys for hashing and encrypting messages Change CipherSpec Server Finished Encrypted Application Data Change CipherSpec & Client Finished
  9. 9. © Novell, Inc. All rights reserved.9 Resumed TLS Handshake  Public key operations (e.g., RSA) are relatively expensive in terms of computational power.  TLS provides a secure shortcut in the handshake mechanism to avoid these operations: resumed sessions.  Resumed sessions are implemented using session IDs or session tickets.  Apart from the performance benefit, resumed sessions can also be used for single sign-on.  Session ID and Session tickets are used for resumed TLS handshake.
  10. 10. © Novell, Inc. All rights reserved.10 Resumed TLS Handshake (Cont.) TLS Client TLS Server Client Hello Offers TLS version, list of ciphers, compression methods etc. Older Session ID / Session Ticket Server Hello With Old / New session ID Change CipherSpec & Client Finished client will start using the new /old session keys for hashing and encrypting messages Encrypted Application Data Change CipherSpec Server Finished containing a hash and MAC over the previous handshake messages
  11. 11. © Novell, Inc. All rights reserved.11 Session ID & Session tickets Session ID:- The client associates this session id with the server's IP address and TCP port, so that when the client connects again to that server, it can use the session id to shortcut the handshake. In the server, the session id maps to the cryptographic parameters previously negotiated, specifically the "master secret". Both sides must have the same "master secret" or the resumed handshake will fail. Session Tickets:- When using session tickets, the TLS server stores its session-specific state in a session ticket and sends the session ticket to the TLS client for storing. The client resumes a TLS session by sending the session ticket to the server, and the server resumes the TLS session according to the session-specific state in the ticket. The session ticket is encrypted and authenticated by the server, and the server verifies its validity before using its contents.
  12. 12. © Novell, Inc. All rights reserved.12 TLS Record Protocol  The TLS Record Protocol is a layered protocol.  The Record Protocol takes messages to be transmitted, fragments the data into manageable blocks, optionally compresses the data, applies a MAC, encrypts, and transmits the result.  Received data is decrypted, verified, decompressed, reassembled, and then delivered to higher-level clients.  Following four protocol clients uses it: the handshake protocol, the alert protocol, the change cipher spec protocol, and the application data protocol
  13. 13. © Novell, Inc. All rights reserved.13 TLS Record Protocol(Cont.) TLS Record Header
  14. 14. © Novell, Inc. All rights reserved.14 Connection States  A TLS connection state is the operating environment of the TLS Record Protocol  There are always four connection states outstanding: the current read and write states, and the pending read and write states  All records are processed under the current read and write states.  The security parameters for the pending states can be set by the TLS Handshake Protocol, and the Change Cipher Spec can selectively make either of the pending states current
  15. 15. © Novell, Inc. All rights reserved.15 Message Authentication Code  TLS record layer uses Keyed-Hash MAC(HMAC) for authentication and integrity check of messages.  HMAC employs an iterative cryptographic hash function in combination with a premaster secret key as follows: H(secret XOR opad, H(secret XOR ipad, message))  HMAC produces a fixed length message digest which may not be sufficiently long. To remedy this successive concatenation of HMAC with different values is done as follows: P_hash(secret, seed) = H(secret, A(1) + seed) + H(secret, A(2) + seed) + H (secret, A(3) + seed) + ... where + indicates concatenation. A() is defined as: A(0) = seed = ClientHello.random + ServerHello.random A(i) = H (secret, A(i-1)) Secret = premaster secret
  16. 16. © Novell, Inc. All rights reserved.16 Master Key Generation:-  The master secret is calculated using PRF: master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47]; where + indicates concatenation.  TLS's PRF is created by applying P_hash to the secret as: PRF(secret, label, seed) = P_<hash>(secret, label, + seed) where + indicates concatenation.  The master secret is always exactly 48 bytes in length.  The Length of the premaster secret will vary depending on key exchange method.
  17. 17. © Novell, Inc. All rights reserved.17 TLS communication steps 1. Handshake and cipher suite negotiation 2. Authentication of parties 3. Key-related information exchange 4. Application data exchange The steps that make up TLS are divided into two protocols that together provide connection security: TLS Handshaking Protocols — (steps 1 – 3) Application Data Protocol — (step 4)
  18. 18. © Novell, Inc. All rights reserved.18 TLS Handshaking Protocols  It is responsible for the authentication and key exchange necessary to establish or resume secure sessions  When establishing a secure session, the Handshaking Protocol manages the following: • Cipher suite negotiation • Authentication of the server and optionally, the client • Session key information exchange.  It includes “The Handshake Protocol”, “The Alert Protocol” & “Change Cipher Spec Protocol”
  19. 19. © Novell, Inc. All rights reserved.19 TLS Handshake Protocol The Handshake Protocol is responsible for negotiating a session, which consists of the following items:-  Session Identifier:- An arbitrary byte sequence chosen by the server to identify an active or resume-able session state.  Peer Certificate:- X509v3 certificate of the peer. This element of the state may be null.  Compression Method:- The algorithm used to compress data prior to encryption.  Cipher Spec:- Specifies the pseudorandom function (PRF) used to generate keying material, the bulk data encryption algorithm (such as null, AES, etc.) and the MAC algorithm (such as MD5 HMAC-SHA1). It also defines cryptographic attributes such as the mac_length.  Master Secret:- 48-byte secret shared between the client and server.  is resumable:- A flag indicating whether the session can be used to initiate new connections.
  20. 20. © Novell, Inc. All rights reserved.20 Change Cipher Spec Protocol  The change cipher spec protocol exists to signal transitions in ciphering strategies.  The ChangeCipherSpec message is sent by both the client and the server to notify the receiving party that subsequent records will be protected under the newly negotiated CipherSpec and keys.
  21. 21. © Novell, Inc. All rights reserved.21 Alert Protocol  Alert messages convey the severity of the message (warning or fatal) and a description of the alert.  There are two alert levels in TLS 1. Fatal:- immediate termination of the connection 2. Warning:- other connections corresponding to the session may continue, but the session identifier MUST be invalidated, preventing the failed session from being used to establish new connections  For complete list of alert messages use RFC5246 Note :- alert messages are encrypted and compressed, as specified by the current connection state.
  22. 22. © Novell, Inc. All rights reserved.22 Application Data Protocol  Application data messages are carried by the record layer and are fragmented, compressed, and encrypted based on the current connection state. The messages are treated as transparent data to the record layer.
  23. 23. © Novell, Inc. All rights reserved.23 TLS Record Content Type:- This field identifies the Record Layer Protocol Type contained in this Record.
  24. 24. © Novell, Inc. All rights reserved.24 TLS Record(Cont.) Version :- This field identifies the major and minor version of TLS for the contained message. For a ClientHello message, this need not be the highest version supported by the client.
  25. 25. © Novell, Inc. All rights reserved.25 TLS Record(Cont.) Version :- This field identifies the major and minor version of TLS for the contained message. For a ClientHello message, this need not be the highest version supported by the client. Length:- The length of Protocol message(s), MAC and Padding, not to exceed 214 bytes (16 KiB).
  26. 26. © Novell, Inc. All rights reserved.26 TLS Record(Cont.) Protocol message(s):- One or more messages identified by the Protocol field. Note that this field may be encrypted depending on the state of the connection. MAC and Padding:- A message authentication code computed over the Protocol message, with additional key material included. Note that this field may be encrypted, or not included entirely, depending on the state of the connection. No MAC or Padding can be present at end of TLS records before all cipher algorithms and parameters have been negotiated and handshaked and then confirmed by sending a CipherStateChange record (see below) for signalling that these parameters will take effect in all further records sent by the same peer.
  27. 27. © Novell, Inc. All rights reserved.27 References:- • http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS _record • rfc2246, rfc5246, rfc4346 • http://msdn.microsoft.com/en- us/library/windows/desktop/aa380516%28v=vs.85%29.as px • https://www.cs.bham.ac.uk/~mdr/teaching/modules06/net sec/lectures/tls/tls.html • http://lasr.cs.ucla.edu/vahab/resources/notes_on_tls.pdf
  28. 28. © Novell, Inc. All rights reserved.28 Corporate Headquarters 1800 South, Novell Place Provo, Utah 84606 801.861.7000 (Worldwide) 800.453.1267 (Toll-free) Join us on: www.novell.com