Secure Sockets Layer (SSL) Lecture 2 – NETW4006 NETW4006-Lecture2

Content History Presentation Security Services SSL handshake SSL Handshake Step-by-Step and Simplified Considerations References NETW4006-Lecture2

History Secure Sockets Layer (SSL) is developed by Netscape Communications Corporation and RSA Data Security, Inc. to allow secure communication for client-server applications Transport Layer Security (TLS) is the open-standard replacement for SSL from the Internet Engineering Task Force (IETF) OSI Layer – Application Layer, Presentation, Session, Transport, Network, Data Link, Physical NETW4006-Lecture2

Web Security Threats Threats Integrity Modification of user data Trojan horse browser Modification of memory Modification of message traffic in transit Confidentiality Eavesdropping on the Net Theft of information from server Theft of data from client Information about network configuration Denial of Service Killing of user threads Filling up disk or memory Isolating machine by DNS attacks Authentication Impersonation of legitimate users Data forgery NETW4006-Lecture2

Web Security Requirements Threats Data Integrity It is concerned with protecting information from unauthorized,accidnetial modification. It is achieved through checksums and Message Authentication Code (MAC) Confidentiality It is concerned with ensuring that only authorized persons understand the transmitted data. It is achieved through encryption. Authentication It is concerned with ensuring the identity of a party within some security domain. It is achieved through challenge response, username-password and certificates. Non Repudiation It is concerned with ensuring that a party cannot repudiate some action. It is achieved through digital signatures. NETW4006-Lecture2

SSL sits between Application Layer & Network Layer NETW4006-Lecture2

SSL and TLS add encryption and authentication to TCP/IP Between TCP layer and application layer: for HTTP (Hyper Text Transfer Protocol), but also for SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol), POP (Post Office Protocol), etc. TLS – Transport Layer Security NETW4006-Lecture2

SSL Architecture. "SSL Record layer": data fragmentation, data ciphering, authentication, data compression "SSL handshake protocol": SSL session negotiation for "SSL Record layer" "SSL change cipher": data ciphering algorithm negotiation for the session "SSL alert protocol": Alerts between the client and the server in case of sequence errors, certification or authentication errors. It also provides the end of a session if a fatal error happens Session: An association with client & server. Sessions are created byHandshake protocol. NETW4006-Lecture2

Security Services- SSL Record Protocol Confidentiality symmetric (secret-key) and asymmetric (public-key) cipher algorithm to encrypt information in a secure and efficient manner. Integrity MD5 (128 bits), SHA-1 (160 bits) Server authentication and client authentication use of signatures and certificates Based on public key cryptographic algorithms: RSA (Rivest, Shamir and Adelman) and Diffie-Hellmann CA could certify the association <key-entity> (entity = server or client) by signing the certificate establishing the association Handshake protocl defines a shared secret key used for conventional encryption- confidentiality Message Integrity – Handshake protocol defines shared key used for Message Authentication Code. NETW4006-Lecture2

Protocol takes an application message to be transmitted, fragments the data in to manageable blocks, optionally compress the data, applies a MAC,encrypts, adds a header , and transmits the resulting unit in a TCP segment. Fragmentation 16384 or less Protocol takes an application message to be transmitted, fragments the data in to manageable blocks, optionally compress the data, applies a MAC,encrypts, adds a header , and transmits the resulting unit in a TCP segment. Fragmentation 16384 or less NETW4006-Lecture2

SSL Handshake for a Secure Connection – Definition (1) During the handshake, the server and the client agree on the encryption methods and keys that will be used for the remainder of the communications During the handshake, the server authentication is always determined (and client authentication if required by the server) NETW4006-Lecture2

SSL Handshake for a Secure Connection - Issues (2) The client and the server (Alice and Bob), would like to communicate securely Often the client and server do not know each other If they want to use symmetric cryptographic scheme they can not exchange the symmetric key (shared key) without a secure channel (key distribution problem) But they can use a public key cryptographic scheme in an insecure channel When a client application requests a connection, the SSL-enabled server presents its certificate to prove its identity before data is transmitted NETW4006-Lecture2

SSL Handshake for a Secure Connection – Steps (3) The client sends a connection request to the server The request includes the SSL (or TLS) options that the client supports The server returns its certificate and a list of supported Cipher Suites which includes: SSL/TLS support options, the algorithms used for key exchange, and digital signatures. A secure, encrypted session is established when both client and server have agreed upon a Cipher Suite NETW4006-Lecture2

SSL Handshake Step-by-Step and Simplified (1) The client requests a secure transaction ("client_hello") by establishing an HTTP connection to port 443 (https) and sends along information with Session ID Client Accepted Cipher Schemes + Key Sizes Client Accepted Compression Algorithms Caeser cipher, classical cipher(polyalphebetics,vignere,transposition), stream cipher(rabbit, RC4, seal) etc Lossless and loosy algorithms.. NETW4006-Lecture2

SSL Handshake Step-by-Step and Simplified (2) The server uses the Session ID to determine if a new SSL session (session state) should be established. The server sends back: Server Accepted Cipher Scheme + Key Sizes based on client previously sent list ("server_hello"). Server Accepted Compression Algorithm based on client previously sent list Server Digital Certificate Client Authentication Request: optional and only if server is configured to do so Server looks the request from client , if its non zero – then same value will the used by server , if not then the session id field contains the value for a new session. NETW4006-Lecture2

SSL Handshake Step-by-Step and Simplified (3) (X.509) The client then: Authenticates the server based on the trust granted to the CA that issued and signed the server’s digital certificate Generates a random symmetric key (pre-master key) and encrypts pre-master key using the server public key issued from the server certificate Sends the encrypted symmetric key + its digital certificate if requested by the server NETW4006-Lecture2

SSL Handshake Step-by-Step and Simplified (4) The server: Tries to authenticate the client based on the trust granted to the CA that issued and signed the client’s digital certificate If authentication fails, the session ends Otherwise or if no authentication was required, the server uses its private key to decrypt the symmetric key (pre-master) NETW4006-Lecture2

SSL Handshake Step-by-Step and Simplified (5) Both the client and the server use the pre-master to generate: another symmetric key, known as the session key (master key) The master is computed using hash functions MD5 and SHA The master key is the key used for exchanging data with the symmetric ciphering algorithm previously negotiated between the client and the server NETW4006-Lecture2

SSL Handshake Step-by-Step and Simplified (6) The client now has the information it needs to establish a secure communication: It sends a message to the server saying that it will start using the new session key for data encryption It sends a separate message encrypted with the master key informing that it finished its part of the handshake The server does the same as 6. a) and 6. b) NETW4006-Lecture2

SSL Handshake Step-by-Step and Simplified (7) The SSL handshake is complete and the session begins with all data exchanges encrypted and decrypted with the (master) session key The session key is used because it is symmetric and much faster than ciphering with public/private keys The session key is valid only for the session and is not re-keyed during the session NETW4006-Lecture2

NETW4006-Lecture2

Considerations Only a properly closed session can be resumed. Generation of the keys is quite a slow operation,  SSL protocol supports sessions The session is defined as a set of information necessary for the re-use of already exchanged information for another SSL-secured data exchange The session data includes cipher suites and keys used Support for sessions in your application can increase the efficiency of SSL protocol if more than one connection is done from the client to the server Only a properly closed session can be resumed. NETW4006-Lecture2