WEB SECURITY and SECURE SOCKET LAYER (SSL)

1. WEB SECURITY and SECURE SOCKET LAYER (SSL) Shervin Erfani Electrical and Computer Engineering Department University of Windsor November 2003 ECE Dept. – University of Windsor

2. Web Security Threats ECE Dept. – University of Windsor

3. Overview of SSL • What is SSL Protocol? • What does SSL provide? • What is the Goal of SSL? • How does it work? • What is the difference between SSL 2.0 and 3.0? ECE Dept. – University of Windsor

4. Security services in the TCP?IP network environment can be implemented at different levels: Network Layer, e.g., IPSec Transport Layer, e.g., SSL or TLS Application Layer, e.g., S/MIME, PGP, SET Secure Protocol Stacks ECE Dept. – University of Windsor

5. SSL is a secure socket layer protocol that provides communication privacy for TCP based Internet applications. SSL allows client/server applications to communicate securely. SSL is application protocol independent. What is SSL Protocol? ECE Dept. – University of Windsor

6. What is SSL Protocol? (Cont.) • SSL is a two layered protocol. The two layers are: • SSL Handshake Protocol • allows the server and client to authenticate each other • allows the server and client to negotiate secure attributes of a session. The following secure attributes must be negotiated before secure transactions can be initiated: • SSL protocol version • cryptographic algorithm and algorithm settings • optionally authentication each other (certification verification) • generate shared secrets with public-key encryption techniques • coordinates the states of the client and server. • operates on top of the SSL Record Layer. ECE Dept. – University of Windsor

7. SSL Record Protocol is used to encapsulate higher level protocols. SSL Record Protocol does: Fragmentation: The record layer fragments information blocks into 214 bytes or less SSL Plaintext records. Record Compression and Decompression. Record Payload Protection and the cipher spec: All record are protected using the current cipher spec. What is SSL Protocol?(cont.) ECE Dept. – University of Windsor

8. What Does SSL Provide? • A private connection (peer-to-peer) using symmetric encryption, e.g. DES, RC4, etc. • Peer’s Identity Authentication using asymmetric or public key cryptographic, e.g. DSS, RSA, etc. • Reliable connection using a keyed MAC. Secure hash functions (e.g., RSA, DSS, etc.) are used for MAC. ECE Dept. – University of Windsor

9. What are the Goals of SSL? • Cryptographic security • SSL should be used to establish a secure connection between two parties. • Interoperability • Independent programmers can develop applications utilizing SSL are able to exchange cryptographic parameters without knowledge of one another’s code. • Extensibility • SSL seeks to provides a framework into which new public key and bulk encryption methods can be incorporated as necessary. • Relative efficiency • SSL protocol has incorporated an optional session caching scheme to reduce the number of connections that need to be established from scratch. ECE Dept. – University of Windsor

10. SSL Session States • The session (a client-server association) state includes the following elements: • session identifier (arbitrary bytes sequences chosen by the server) • peer certificate (X.509.v3 certificates. This element may be null) • compression method (data compression algorithm) • cipher spec (specifies data encryption algorithm, a MAC algorithm and cryptographic attributes) • master secret (48-bytes secret shared between the client and server) • resumable flag (indicates whether the session can be used to initiate new connections) ECE Dept. – University of Windsor

11. SSL Connection States The connection state includes the following elements: • server and client random (Byte sequences that are chosen by the server and client for each connection) • server write MAC secret (secret used in MAC operations on data written by the server) • client write MAC secret (secret used in MAC operations on data written by the client) • server write key (cipher key for data encrypted by the server and decrypted by the client) • client write key (cipher key for data encrypted by the client and decrypted by the server) • initialization vectors (IV) (When a block cipher in CBC mode is used, an IV is maintained for each key) • sequence numbers (each party maintains separate sequence numbers for transmitted and received messages for each connection. Sequence numbers may not exceed 264-1) ECE Dept. – University of Windsor

12. How Does it Work? • The cryptographic parameters of the session state are produced by the SSL Handshake Protocol, which operates on top of the SSL Record Layer. • In the Handshake protocol: • client and server will be authenticated optionally • the following cryptographic parameters will be agreed on: • protocol version • cryptographic algorithms • the shared secret between the client and server will be generated use public-key encryption techniques ECE Dept. – University of Windsor

13. SSL Handshake Protocol Overview (Initiate a session) ECE Dept. – University of Windsor

14. SSL Handshake Protocol Overview (Resume a previous session) ECE Dept. – University of Windsor

15. How Does it Work?(Cont.) • When a new session begins, the CipherSpec encryption, hash, and compression algorithm are initialized to NULL. The current CipherSpec is used for renegotiation messages. • Hello messages: The hello messages are used to exchange security enhancement capabilities between the client and server. • Hello request: • Hello request message may be sent by the server at any time. • The client should begin the negotiation process anew by sending a client hello message • Client hello: When a client first connects to a server it is required to send the client hello as its first message. The client can also send a client hello in response to a hello request or on its own initiative in order to renegotiate the security parameters in an existing connection. The client hello message includes a variable length session identifier. • The session Ids are defined by the server. • The CipherSuite list, passed from the client to the server in the client hello message, contains the cryptographic algorithms supported by the client. ECE Dept. – University of Windsor

16. How Does it Work ?(Cont.) • The CipherSuite defines both a key exchange algorithm and a CipherSpec. • If no acceptable choices are presented to the server, a handshake failure alert will be returned and the connection closed. • Server hello: the server responds the client hello with either a handshake_failure alert or server hello. • Server certificate: If the server is to be authenticated, the server sends its certificate following the server hello. • The certificate type must be appropriate for the selected cipher suite's key exchange algorithm and is generally an X.509.v3 certificate The same message type will be used for the client's response to a certificate request message. • Server key exchange message is sent by the server if it has no certificates, has a certificates only used for signing, or Fortezza/DMS key exchange is used. • Certificates request: A non-anonymous serer can optionally request a certificate from the client, if appropriate for the selected cipher suite. ECE Dept. – University of Windsor

17. How Does it Work ?(Cont.) • Server hello done: the server hello done message is sent by the server to indicate the end of the server hello and associated messages. • Client certificate: This is the first message the client can send after receiving a server hello done and can only be sent if the server requests a certificate. • Client key exchange message depends on which public key algorithm(s) has (have) been selected. • RSA encrypted premaster secret message: RSA is being used for key agreement and authentication: the client generates a 48-byte premaster secret, encrypts it under the public key from the server’s certificate or temporary RSA key from a server key exchange, and sends the result in an encrypted premaster secret. • Fortezza key exchange message: the client derives a Token Encryption Key (TEK) using the FORTEZZA Key Exchange Algorithm (KEA). The client generates session keys (wraps them using the TEK) and IV’s and sends the results to the server. The client encrypts the random 48-byte premaster secret and sends the result ECE Dept. – University of Windsor

18. How Does it Work?(Cont.) • Client Diffie-Hellman public value: This structure conveys the client's Diffie-Hellman public value (Yc) if it was not already included in the client's certificate. • Certificate verify: This message is used to provide explicit verification of a client certificate. This message is only sent following any client certificate that has signing capability. • Finished: A finished message is always sent immediately after a change cipher specs message to verify that the key exchange and authentication processes were successful. • 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. ECE Dept. – University of Windsor

19. The Alert Protocol is used to convey SSL-related alerts to the peer entity: Messages are compressed and encrypted Each message consists of Two bytes: One byte for the severity level, one byte for the type SSL Alert Protocol ECE Dept. – University of Windsor

20. Cryptographic Computation • The key exchange, authentication, encryption, and MAC algorithms are determined by the cipher_suite selected by the server and revealed in the server hello message. • Asymmetric cryptographic computations: The asymmetric algorithms are used in the handshake protocol to authenticate parties and to generate shared keys and secrets. • RSA: When RSA is used for server authentication and key exchange, a 48-byte pre_master_secret is generated by the client, encrypted under the server's public key, and sent to the server. The server uses its private key to decrypt the pre_master_secret. Both parties then convert the pre_master_secret into the master_secret. • Diffie-Hellman: The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret. • FORTEZZA: A random 48-byte pre_master_secret is sent encrypted under the TEK and its IV. The server decrypts the pre_master_secret and converts it into a master_secret. Bulk cipher keys and IVs for encryption are generated by the client's token and exchanged in the key exchange message; the master_secret is only used for MAC computations. ECE Dept. – University of Windsor

21. Cryptographic Computation (Cont.) • Symmetric cryptographic calculations and the CipherSpec: The technique used to encrypt and verify the integrity of SSL records is specified by the currently active CipherSpec. The encryption and MAC algorithms are set to SSL_NULL_WITH_NULL_NULL at the beginning of the SSL Handshake Protocol, indicating that no message authentication or encryption is performed. The handshake protocol is used to negotiate a more secure CipherSpec and to generate cryptographic keys. • The master secret: Before secure encryption or integrity verification can be performed on records, the client and server need to generate shared secret a 48-byte master secret known only to themselves. The master secret is used to generate keys and secrets for encryption and MAC computations. • Converting the master secret into keys and MAC secrets: The master secret is hashed into a sequence of secure bytes, which are assigned to the MAC secrets, keys, and non-export IVs required by the current CipherSpec. When generating keys and MAC secrets, the master secret is used as an entropy source, and the random values provide unencrypted salt material and IVs for exportable ciphers. ECE Dept. – University of Windsor

22. What is the difference between SSL 2.0 and 3.0? • Security improvements: • SSL 2.0 is vulnerable to a "man-in-the-middle" attack. By editing the list of ciphersuite preferences in the hello messages, an active attacker can invisibly edit the list of ciphersuite preferences in the hello messages to invisibly force both client and server to use 40-bit encryption. SSL 3.0 defends against this attack by having the last handshake message include a hash of all the previous handshake messages. • SSL 2.0 uses a weak MAC construction, although post-encryption seems to stop attacks. This is fixed in 3.0. • SSL 2.0 feeds padding bytes into the MAC in block cipher modes, but leaves the padding-length field unauthenticated, which could allow active attackers to delete bytes from the end of messages. This, too, is fixed in 3.0. • In SSL 3.0, the Message Authentication Hash uses a full 128 bits of keying material, even when using an Export cipher. In SSL 2.0, Message Authentication used only 40 bits when using an Export cipher. ECE Dept. – University of Windsor

23. What is the difference between SSL 2.0 and 3.0? (Cont.) • Functionality improvements: • In SSL 2.0, the client can only initiate a handshake at the beginning of the connection. In 3.0, the client can initiate a handshake routine, even in the middle of an open session. A server can request that the client start a new handshake. Thus, the parties can change the algorithms and keys used whenever they want. • SSL 3.0 allows the server and client to send chains of certificates. This allows organizations to use a certificate hierarchy that is more than two certifications deep. • SSL 3.0 has a generalized key exchange protocol. It allows Diffie-Hellman and Fortezza key exchanges and non-RSA certificates. • SSL 3.0 allows for record compression and decompression. ECE Dept. – University of Windsor

24. What is the difference between SSL 2.0 and 3.0? (Cont.) • Backward compatibility: • SSL 3.0 can recognize an SSL 2.0 client hello and fall back to SSL 2.0. An SSL 3.0 client can also generate an SSL 2.0 client hello with the version set to SSL 3.0, so SSL 3.0 servers will continue the handshake in SSL 3.0, and SSL 2.0 server will cause the client to fall back to SSL 2.0. • Other: • SSL 3.0 separates the transport of data from the message layer. In 2.0, each packet contained only one handshake message. In 3.0, a record may contain part of a message, a whole message, or several messages. This requires different logic to process packets into handshake messages. Therefore, the formatting of the packets had to be completely changed. • Cipher specifications, handshake messages, and other constants are different. ECE Dept. – University of Windsor