Internet security and privacy SSL/TLS 1
Application layer App. TCP/UDP IP L2 L1 2
Application layer App. SSL/TLS TCP/UDP IP L2 L1 3
History of SSL/TLS Originally, SSL Secure Socket Layer, was developed by Netscape for secure HTTP connections in 1994-95. Microsoft developed a similar protocol with improved properties. Netscape included the improvements and released SSL v3 in 1996. IETF presented their own version, TLS Transport Layer Security, based on SSLv3 but with some changes. 4
SSL/TLS IETF can not present standards that use patent protected technology. It could therefor not accept SSL as it was since it was using RSA technology. TLS mandated the implementation of Diffie- Helman and Digital Signature Standard. The RSA patent expired in 2000 and few companies migrated to TLS. SSLv3 is still the most used version. RSA patents are gone and SSLv3 and TLS will hopefully merge. 5
SSL/TLS Based on public key infrastructure: all servers have a certificate signed by a CA and the clients have a set of trusted CAs. Client authentication is optional and requires that the client also has a private/public key and a valid certificate. Since the authentication method is fixed the initial protocol is simplified (compare with IPsec with eight different modes). 6
Hand shaking Alice Bob crypto proposal, R Alice choose S K = f(s, R Alice, R Bob ) certificate, crypto choice, R Bob {S} Bob, {md(k,msg CLNT )] {md(k,msg SRVR )} K = f(s, R Alice, R Bob ) S is the pre-master key K is the master key 7
Session resumption A SSL/TLS session can use one or more TCP connection (designed for HTTP 1.0). Each TCP connection can use a unique master key that can be computed without choosing a new pre-master key nor doing a public-key encryption. If the server allows session resumption it will send a session-id in its first reply. 8
Session resumption Alice Bob session-id, crypto proposal, R Alice K = f(s, R Alice, R Bob ) session-id, crypto choice, {md(k,msg)}, R bob {md(k,msg)} K = f(s, R Alice, R Bob ) 9
The master key Each connection has a master key and two random values chosen by Alice and Bob. From these value both derive two sets of: encryption key integrity key IV (if needed) The connection will thus use one set of keys in each direction. R-values include a time stamp 10
Hand shaking revisited Alice Bob choose S cp, R Alice cert, cc, R Bob {S} Bob K = f(s, R Alice, R Bob ) K = f(s, R Alice, R Bob ) Compute encryption key, integrity key and IV <e1,e2,i1,i2,v1,v2> = g(k, R Alice, R Bob ) {md(k,ms CLNT)} {md(k,msg SRVR)} 11
Client authentication Clients are normally not authenticated but the server have the option to request a certificate from the client. In a browser implementation the user will be asked which certificate to use for authentication. Client authentication is normally provided by user name and password that is protected by the secure communication to the server. 12
The version mess Version numbers are recorded in a two byte field SSLv2 uses: 02 SSLv3 uses: 30 TLS uses: 31 SSLv3 changed the location of the version number field! A v3 clients will send a v3 hello message in a v2 format with the version number set to 30! 13
Cipher suite negotiation A cipher suite consist of a description of which algorithms to use for authentication, encryption, chaining, and integrity. Each suite is given a unique number and it is a set of these numbers that the client present as a proposal. The server does not pick one but rather returns a possibly reduced set that it can support. Very different from IPsec! 14
Export regulations Export restrictions (from the US) has (2000) been lifted (except for some states) and the special handling of export approved ciphers and keys is no longer needed. The export regulations did however cause a lot of problems; not only are there export versions of the algorithms but the export versions should be able to talk to the US versions. Big confusion for what? 15
Encoding The SSL/TLS hand shake is implemented over TCP. SSL/TLS communicate using messages that are grouped in records (a large message can be broken up into several records). The record is the unit of encryption. There are four record types: Handshake Change cipher Alert Application data 16
Encrypting a record seq # Head Data SSLv3 uses a non standard implementation of HMAC. TLS follows RFC 2104. Sequence number is never sent but kept and incremented at both ends. Head Data HMAC encrypted pad Encryption uses a block cipher in CBC or RC4 17
Records and messages Hand shake record: ClientHello, ServerHello, ClientKeyExchange, Certificate, ServerHelloDone, ClientHelloDone, HandshakeFinished, CertificateReq, CertificateVerify, ServerKeyExchange Change cipher record ChangeCipher Alert record Application data record 18
Messages Alice ClientHello ServerHello Certificate ServerHelloDone ClientKeyExchange ChangeCipherSpec ChangeCipherSpec HandshakeFinised HandshakeFinished Bob 19
SSL/TLS drawback Since the TCP packets are not protected it is possible for Trudy to insert false TCP packets for example with a sequence number not yet sent. The SSL/TLS process will notice this but the TCP layer has already accepted the packet and will discard the correct one once it arrive. Trudy can also close the TCP connection but this will be noticed by SSLv3/TLS. One solution: implement TLS over UDP and do the job of TCP your self. It is always hard to protect against DoS attacks so it might not be worth it. 20
SSL/TLS usage Mainly used for web access since most servers support it (if they only had a certificate) and all clients support it. More applications come with SSL/TLS protected web interface. Could also be used to build a secure tunnel that any application can use. Also used in EAP for session key establishment key then used for L2 encryption. WTLS is the WAP version of TLS. 21