SSL CS772 Fall 2011

Secure Socket layer Design Goals: SSLv2) SSL should work well with the main web protocols such as HTTP. Confidentiality is the top goal Server authentication is necessary. Client authentication is optional. With unknown parties communicating, spontaneity is necessary Transparency to TCP is necessary. In other words, software working on top of SSL should feel that they are only working with TCP and not SSL. SSLv3: Provide a mechanism for secure negotiating multiple cryptographic algorithms--- support far greater number of algorithms TLS: Transport Layer Protocol: A modified SSLv3 that requires implementation to support DH (Diffie-Hellman), DSS (Digital signature algorithm of NSA), and 3DES

https In HTTP a TCP connection is created and the clients send a request. The server responds with a document. When SSL is used: SSL is on top of TCP, and HTTP is on top of SSL. Since there are more handshake messages in this case, it uses HTTPS stands for Hypertext Transfer Protocol over Secure Socket Layer, or HTTP over SSL. HTTPS encrypts and decrypts the page requests and page information between the client browser and the web server using a secure Socket Layer (SSL). HTTPS by default uses port 443 as opposed to the standard HTTP port of 80. URLs beginning with HTTPS indicate that the connection between client and browser is encrypted using SSL. SSL transactions are negotiated by means of a key based encryption algorithm between the client and the server, this key is usually either 40 or 128 bits in strength (the higher the number of bits the more secure the transaction). HTTPS should not be confused with S-HTTP, a security-enhanced version of HTTP. SSL and S-HTTP have very different designs and goals so it is possible to use the two protocols together. Whereas SSL is designed to establish a secure connection between two computers, S-HTTP is designed to send individual messages securely.

Basic SSL An SSL connection is divided into two phases: (i) Handshake (ii) Data transfer Handshake: 1.Client sends the server a list of the algorithms it is wiling to support, along with a random number used as input to the key generation process 2.The server chooses a cipher out of that list and sends it back along with server’s certificate with its public key. It also send a random number. 3.Client verifies the certificate, extracts the server’s public key; client also generates a random secret string called “pre master secret” and encrypts using server’s public key and sends it to server 4.Client and server independently compute the encryption and MAC keys from the pre_master_secret and the client and server’s random values 5.Client sends a MAC of all the handshake messages to the server 6.Server sends a MAC of all the handshake messages to the client 7.The random numbers generated by server and client are useful to avoid replay attack 8.MAC exchange helps an intruder from modifying the cipher set sent from client to server, for example.

Data transfer phase: SSL Record Protocol Break up the input data stream into a series of fragments, each of which is independently protected and transmitted. At the other end, each record is decrypted and verified. The header has: content type, the length, and SSL version Content type: application_data, alert, handshake, and change_cipher_spec

Advanced SSL Session resumption –full handshake can be very expensive in terms of CPU time and number of messages –the most expensive part is the establishment of the pre_master_secret, requires public key cryptography –Resumed handshake allows a new connection to use a master_secret established in a previous handshake.

Session Resumption (contd.) Connection vs. session –A connection represents one specific communications channel (e.g., a TCP connection), along with its keys, cipher choices, sequence number state, etc. –A session is a virtual construct representing the negotiated algorithms and the master_secret. It is created every time a given client and server go through a full key exchange and establish a new master_secret. –Multiple connections can be associated with a given session. –Although all connections in a given session share the same master_secret, each has its own encryption keys, MAC keys, and IVs.

Client Authentication Useful if a server wanted to restrict access to some services to only certain authorized clients and could use client authentication to do so. Clients use their private keys to sign something that proves that it is the “client” with the private key. It is initiated by the server sending a CertificateRequest message to the client. The client responds by sending a Certificate message and a message string signed with the private key

Rehandshake A rehandshake is a new SSL handshake performed over the current protected connection The rehandshake messages are encrypted in transit Once the new handshake has finished, data will be protected using the new session state.

SSL Security What SSL provides: –Provides channel-level security---two ends of the connection know that the data being transmitted is being kept secret and that it has not been tampered with. –Server is always authenticated; client could be authenticated –All security depends on keeping the master_secret private---once this is compromised all other keys can be generated and session compromised –If an attacker has server’s private key, then the attacker can obtain the master_secret as it is sent in an encrypted form by the client. –SSL uses random numbers in a number of places---(i) Private keys for the server (and optionally for client) need to be randomly generated (ii) Client needs a random number to perform key exchange (or to generate pre_master_secret for RSA) (iii) If DSA is being used for signature than a random number is needed for each signature. (iv) For handshake values by both client and server. –The random numbers should be strong random numbers –Check the certificate chain

SSL Key derivation

What can compromise security? Master_secret is the key; if that is compromised by an attacker, all else is known to the attacker. With this compromise, confidentiality and integrity attacks are quite possible.

SSL Performance SSL is slow---depending on the protocols being used, the server hardware, and the network environment, SSL connections can be anywhere between 2 and 100 times slower than ordinary TCP connections. Some performance degradation is due to computational cost of cryptographic operations.