Secure Sockets Overview of Lecture l We

Secure Sockets

Overview of Lecture l We covered an overview of authenticated key exchange protocols l 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 l The Web has become the visible interface of the Internet – Many corporations now use the Web for advertising, marketing and sales l 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 Threats Do. S Modification of Data Loss of Information MACs and Hashes Compromise of Machine Eavesdropping Loss of Information Theft of Information Confidentiality Countermeasures Trojan horses Integrity Consequences Privacy Breach Stopping Stopped Transactions Encryption Filling up Disks and Resources Authentication Impersonation Misrepresentation of User Data Forgery Accept false Data Table from Stallings, and from A. Rubin Signatures, MACs

So Where to Secure the Web? l 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) l The first two provide generic solutions, while third provides for more specialized services l We will focus this lecture on SSL

A Quick Look at Securing the TCP/IP Stack HTTP FTP HTTP SMTP FTP SMTP SSL/TLS TCP IP/IPSEC IP At the Network Level At the Transport Level S/MIME PGP Kerberos SMTP UDP SET HTTP TCP IP At the Application Level

Overview of SSL l The Secure Sockets Layer was originally developed (1994) by Netscape in order to secure http communications l 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 SSLv 3 l TCP provides a reliable end-to-end service l SSL consists of two sublayers: – SSL Record Protocol (where all the action takes place) – SSL Management: (Handshake/Cipher Change/ Alert Protocols)

SSL Preliminaries l l l An SSL Session is an association between a client and a server (created by the Handshake Protocol). There 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. 509 v 3 certificate of the peer Compression: Optional algorithm used to compress data Cipher Specs: Encryption Algorithm (3 DES, AES, etc. ) and hash algorithm (MD 5, SHA-1) – Master Secret: 48 -byte secret shared between client and server

SSL Preliminaries, pg. 2 l 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 l The SSL Record Protocol uses the keys derived from the Handshake Protocol to securely deliver data l Two functions: – Confidentiality and Message Integrity Data Fragmentation Chunk Compression Shrunk MAC Shrunk Encrypted Prepend Header Encrypted Chunk

SSL Record Protocol, pg. 2 l 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! l Messages are broken into blocks of at most 16384 bytes l The compression is optional and, due to message size/type, it might not even be desirable to use! l 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 l 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 SSLv 3, 1 for TLS) l 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: RC 4, RC 2, DES (CBC Mode), 3 DES (EDE-CBC Mode), Fortezza (CBC) – MAC: SHA-1 and MD 5

SSL Record Protocol, pg. 4 l The real trick to the Record Protocol is the MAC In SSL, the record layer computes a MAC for each chunk of data. l In SSLv 3 the MAC is l Hash(MACws|| Pad 2||Hash(MACws||Pad 1||Seq. Num||SSLComp||SSLLen||Chunk)) l The pieces: – – – – MACws = Shared MAC Key Hash: MD 5 or SHA-1 Pad 1: (00110110) repeated 48 times for MD 5 or 40 times for SHA-1 Pad 2: (01011100) repeated 48 times for MD 5 or 40 times for SHA-1 Seq. Num; 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 l This is the beast… Its where all the action really takes place! l 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 l 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 l Client. Hello Server. Hello ate Server. Certific Round 1: Create the Connection between the Client A and Server G (Gigafirm in my notes), and figure out what each entity can do! hange Server. Key. Exc Cert. Request nd Server. Hello. E Client. Certific ate Client. Key. Exc hange Cert. Verify Change. Ciphe r Finished r Change. Ciphe Finished • r. A is a nonce made of 4 bytes of timestamp and 28 bytes of random #. Similarly for r. G. • Sess. ID: 0 if new session, else is the session ID of an existing session (and the Handshake will update parameters) • Ciph. List is a list of algorithms supported by the client in an order of decreasing preference (Key Exchange and Encryption Cipher) • Ciph. Choice: The cipher suite chosen by the Server.

SSL Handshake Protocol, pg. 3 l Client. Hello Server. Hello ate Server. Certific hange Server. Key. Exc Cert. Request nd Server. Hello. E 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 Client. Certific ate Client. Key. Exc hange Cert. Verify Change. Ciphe r Finished r Change. Ciphe Finished KG is the private key, and hence EKG is a signature operation by the Server Valid. Cert. Authorities identifies the authorities the server will accept

SSL Handshake Protocol, pg. 4 l Client. Hello Server. Hello ate Server. Certific hange Server. Key. Exc Cert. Request 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 Pre. Master. Secret s. PM nd Server. Hello. E Client. Certific ate Client. Key. Exc hange Cert. Verify Change. Ciphe r Finished r Change. Ciphe Finished +KG is the public key, and hence E+KG is a encryption using the public key gained from the certificate Messages 1 to 8 is the concatenation of first 8 messages MS is master secret and Step 9 is for verification

SSL Handshake Protocol, pg. 5 l Client. Hello Server. Hello ate Server. Certific hange Server. Key. Exc Cert. Request nd Server. Hello. E Client. Certific ate Client. Key. Exc hange Cert. Verify Change. Ciphe r Finished r Change. Ciphe Finished 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

Other SSL Management Functions l 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 u 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. Unexpected_Message: Fatal Bad_Record_MAC: Fatal Decompression_Failure: Fatal Handshake_Failure: Fatal And many more…

Wrap-Up l Many other parameters are generated from the master secret: – – l Client. Write MAC Secret and Client. Write Key Server. Write MAC Secret and Server. Write 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