190 likes | 346 Views
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.
E N D
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 Table from Stallings, and from A. Rubin
So Where to Secure the Web? • There are many strategies to securing the web • We may attempt to secure the IP Layer of the TCP/IP Stack: This may be accomplished using IPSec, for example. • 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) • 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 HTTP FTP SMTP HTTP FTP SMTP SSL/TLS TCP TCP IP/IPSEC IP At the Network Level At the Transport Level S/MIME PGP SET Kerberos SMTP HTTP UDP TCP IP 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
Fragmentation Chunk Chunk Chunk Shrunk Compression MAC Shrunk Encrypted Encrypt Encrypted Prepend Header 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
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 16384 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 • 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: (00110110) repeated 48 times for MD5 or 40 times for SHA-1 • Pad2: (01011100) 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
ClientHello ServerHello ServerCertificate ServerKeyExchange CertRequest ServerHelloEnd ClientCertificate ClientKeyExchange CertVerify ChangeCipher Finished ChangeCipher Finished 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! • rA is a nonce made of 4 bytes of timestamp and 28 bytes of random #. Similarly for rG. • 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.
ClientHello ServerHello ServerCertificate ServerKeyExchange CertRequest ServerHelloEnd ClientCertificate ClientKeyExchange CertVerify ChangeCipher Finished ChangeCipher Finished 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 KG is the private key, and hence EKG is a signature operation by the Server ValidCertAuthorities identifies the authorities the server will accept
ClientHello ServerHello ServerCertificate ServerKeyExchange CertRequest ServerHelloEnd ClientCertificate ClientKeyExchange CertVerify ChangeCipher Finished ChangeCipher Finished 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 sPM +KG 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
ClientHello ServerHello ServerCertificate ServerKeyExchange CertRequest ServerHelloEnd ClientCertificate ClientKeyExchange CertVerify ChangeCipher Finished ChangeCipher Finished 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
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. • 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 • 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