Secure Sockets

Overview of Lecture We covered an overview of authenticated key exchange protocols In this lecture we will –Look at issues related to Web Security –Examine a specific implementation of such a protocol, known as Secure Sockets

Web Security Issues The Web has become the visible interface of the Internet –Many corporations now use the Web for advertising, marketing and sales Web servers might be easy to use but… –Complicated to configure correctly and difficult to build without security flaws –They can serve as a security hole by which an adversary might be able to access other data and computer systems ThreatsConsequencesCountermeasures IntegrityModification of Data Trojan horses Loss of Information Compromise of Machine MACs and Hashes ConfidentialityEavesdropping Theft of Information Loss of Information Privacy Breach Encryption DoSStopping Filling up Disks and Resources Stopped Transactions AuthenticationImpersonation Data Forgery Misrepresentation of User Accept false Data Signatures, MACs Table from Stallings, and from A. Rubin

So Where to Secure the Web? There are many strategies to securing the web 1. We may attempt to secure the IP Layer of the TCP/IP Stack: This may be accomplished using IPSec, for example. 2. We may leave IP alone and secure on top of TCP: This may be accomplished using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) 3. We may seek to secure specific applications by using application-specific security solutions: For example, we may use Secure Electronic Transaction (SET) The first two provide generic solutions, while the third provides for more specialized services We will focus this lecture on SSL

A Quick Look at Securing the TCP/IP Stack TCP IP/IPSEC HTTPFTPSMTP TCP IP HTTPFTPSMTP SSL/TLS TCP IP S/MIMEPGP UDP KerberosSMTP SET HTTP At the Network Level At the Transport Level At the Application Level

Overview of SSL The Secure Sockets Layer was originally developed (1994) by Netscape in order to secure http communications Version 3 of SSL was released in 1995 –It is what we think of when we say SSL –Slight variation became Transport Layer Security (TLS) and was accepted by the IETF in 1999 –TLS is backward compatible with SSLv3 TCP provides a reliable end-to-end service SSL consists of two sublayers: –SSL Record Protocol (where all the action takes place) –SSL Management: (Handshake/Cipher Change/ Alert Protocols)

SSL Preliminaries An SSL Session is an association between a client and a server (created by the Handshake Protocol). There are a set of security parameters associated with each session An SSL Connection is a peer-to-peer relationship, and is transient. There may be many connections associated with one session. The same security parameters may apply to many connections. Session Security Parameters: –Session Identifier –Peer Certificate: X.509v3 certificate of the peer –Compression: Optional algorithm used to compress data –Cipher Specs: Encryption Algorithm (3DES, AES, etc.) and hash algorithm (MD5, SHA-1) –Master Secret: 48-byte secret shared between client and server

SSL Preliminaries, pg. 2 Connection Parameters: –Server and Client random byte sequences used for each connection –Server MAC Key: Key used in MAC operations on data sent by the server –Client MAC Key: Key used in MAC operations on data sent by the client –Server Encryption Key: Encryption key used for data encrypted by server and decrypted by client –Client Encryption Key: Encryption key used for data encrypted by client and decrypted by server –Initialization vectors: We will use CBC mode, so we need IVs. –Sequence Numbers: Each entity maintains sequence numbers for transmitted and received messages

SSL Record Protocol The SSL Record Protocol uses the keys derived from the Handshake Protocol to securely deliver data Two functions: –Confidentiality and Message Integrity Data Shrunk Compression Shrunk MAC Encrypted Encrypt Encrypted Prepend Header Chunk Fragmentation

SSL Record Protocol, pg. 2 SSL Record protocol allows protocols above SSL to be secured –Example: HTTP delivers packets that are fragmented and securely delivered –SSL does not handle retransmissions… it does not have to! TCP provides that functionality –This is quite the opposite of IPSec, which only secures IP! Messages are broken into blocks of at most bytes The compression is optional and, due to message size/type, it might not even be desirable to use! Encryption may be stream or block mode. This is negotiated through the Handshake protocol –If block encryption, padding is necessary in order to fill out a block length u Padding is a sequence of padding bytes (random junk will do) followed by 1 byte that describes length of the pad (up to 255).

SSL Record Protocol, pg. 3 The Header consists of –Content type descriptor (1 byte): For the upper layer to use –Major Version (1 byte): What version of SSL? (3 for SSL and TLS) –Minor Version (1 byte): Indicates the revision (0 for SSLv3, 1 for TLS) There are only a limited selection of ciphers and MAC algorithms that are allowed –Interchange Ciphers: RSA, Diffie-Hellman (signed and unsigned), Fortezza –Bulk Encryption Cipher: RC4, RC2, DES (CBC Mode), 3DES (EDE-CBC Mode), Fortezza (CBC) –MAC: SHA-1 and MD5

SSL Record Protocol, pg. 4 The real trick to the Record Protocol is the MAC In SSL, the record layer computes a MAC for each chunk of data. In SSLv3 the MAC is Hash(MACws|| Pad2||Hash(MACws||Pad1||SeqNum||SSLComp||SSLLen||Chunk)) The pieces: –MACws = Shared MAC Key –Hash: MD5 or SHA-1 –Pad1: ( ) repeated 48 times for MD5 or 40 times for SHA-1 –Pad2: ( ) repeated 48 times for MD5 or 40 times for SHA-1 –SeqNum; Sequence number for this message –SSLComp: Higher Layer descriptor of message type –SSLLen: Length of the chunk –Chunk: The fragment of data after it has been compressed

SSL Handshake Protocol This is the beast… Its where all the action really takes place! Basically, the Handshake protocol is used before any application data is transmitted. –It is used to allow the server and client to authenticate each other –To negotiate on an encryption and MAC algorithm –Establish keys to be used The Handshake Protocol consists of messages consisting of three fields: –Type (1 byte): Indicates type of the message. There are 10 types. –Length (3 bytes) –Content: The payload exchanged in each message

SSL Handshake Protocol, pg. 2 Round 1: Create the Connection between the Client A and Server G (Gigafirm in my notes), and figure out what each entity can do! ClientHello ClientCertificate ClientKeyExchange CertVerify ChangeCipher Finished ServerHello ServerCertificate ServerKeyExchange CertRequest ServerHelloEnd ChangeCipher Finished r A is a nonce made of 4 bytes of timestamp and 28 bytes of random #. Similarly for r G. SessID: 0 if new session, else is the session ID of an existing session (and the Handshake will update parameters) CiphList is a list of algorithms supported by the client in an order of decreasing preference (Key Exchange and Encryption Cipher) CiphChoice: The cipher suite chosen by the Server.

SSL Handshake Protocol, pg. 3 Round 2: Server Authentication and Key Exchange –Server begins by sending its X.509 cert (and associated cert chain) –Next, a public key is sent (e.g. modulus and exponent, if RSA) –Server may Request a Cert from the Client –Server sends end round 2 message ClientHello ClientCertificate ClientKeyExchange CertVerify ChangeCipher Finished ServerHello ServerCertificate ServerKeyExchange CertRequest ServerHelloEnd ChangeCipher Finished K G is the private key, and hence E KG is a signature operation by the Server ValidCertAuthorities identifies the authorities the server will accept

SSL Handshake Protocol, pg. 4 Round 3: Client Authentication and Key Exchange –Client verifies that the Server’s Cert is valid, and checks that parameters sent are valid –If a cert was requested, then the Client sends one –Server generates a PreMasterSecret s PM ClientHello ClientCertificate ClientKeyExchange CertVerify ChangeCipher Finished ServerHello ServerCertificate ServerKeyExchange CertRequest ServerHelloEnd ChangeCipher Finished +K G is the public key, and hence E +KG is a encryption using the public key gained from the certificate Messages1to8 is the concatenation of first 8 messages MS is master secret and Step 9 is for verification

SSL Handshake Protocol, pg. 5 Round 4: Wrap-up –Client tells Server to change cipher (via the Change Cipher Protocol). –Server responds with its own changed cipher message –Finished Message are hashes for verification ClientHello ClientCertificate ClientKeyExchange CertVerify ChangeCipher Finished ServerHello ServerCertificate ServerKeyExchange CertRequest ServerHelloEnd ChangeCipher Finished

Other SSL Management Functions There are two other Management Functions provided by SSL: –Change Cipher Spec: A single byte is sent after new cipher parameters have been agreed upon (aka. Handshake). “Pending” parameters become activated. –SSL Alert Protocol: Signals that unusual conditions have been encountered. u Each message consists of two bytes. First byte is a (1) if a warning or a (2) if a fatal error. If error is fatal, the connection is terminated (other connections may continue…). Second byte says the type of error. u Unexpected_Message: Fatal u Bad_Record_MAC: Fatal u Decompression_Failure: Fatal u Handshake_Failure: Fatal u And many more…

Wrap-Up Many other parameters are generated from the master secret: –ClientWrite MAC Secret and ClientWrite Key –ServerWrite MAC Secret and ServerWrite Key –Client and Server IVs –Parameters are generated via hashing… MS is basically a seed to a pseudorandom function. TLS is very similar to SSL –TLS uses HMAC instead of the concatenation-MAC –TLS does not support Fortezza –Minor differences in padding requirements