Secure Socket Layer Originally by Yu Yang

Secure Socket Layer • Originally by Yu Yang and Lilly Wang • Modified by T. A. Yang 1

Agenda • SSL Basics • WTLS 2

SSL Facts • SSL was first developed by Netscape in 1994 and became an internet standard in 1996 ( RFC 2246 – TLS V 1. 0) • SSL is a cryptographic protocol to secure network across a connection-oriented layer • Any program using TCP can be modified to use SSL connection 3

SSL Facts • SSL connection uses a dedicated TCP/IP socket (e. g. port 443 for https) • SSL is flexible in choice of which symmetric encryption, message digest, and authentication can be used • SSL provides built-in data compression 4

SSL Usage • Authenticate the server to the client • Allow the client and the server to select cryptographic algorithms, or ciphers, that they both support • Optionally authenticate the client to the server • Use public key encryption techniques to generate a shared secret • Establish an encrypted SSL connection 5

Secure Socket Layer SSL is a secure protocol which runs above TCP/IP and allows users to encrypt data and to securely authenticate a server’s (or a vendor’s) identity HTTPS FTPS SMTPS Application layer SECURE SOCKET LAYER TCP/IP layer Transport layer 6

SSL Stack 7

SSL Record Protocol Operation 8

SSL Record Format 9

SSL Handshake SSL handshake verifies the server and allows the client and the server to agree on an encryption set before any data is sent out 10

SSL Handshake 11

SSL Handshake Server Public key Private key Client request Client Public key 12

SSL Session Key Server Private key Public key Pre. Master Session key Pre. Master Client Public key Pre-Master Session key 13

Secure Data on Network Server Private key Public key Session key Data Client Data Session key Data 14

Man-in-the-Middle Attack Server Private key Public key Session key Premaster Hacker Private key Public key Session key Premaster Pre. Public master key Client Public key Pre-master 15

Key exchange and certificate Server Private key SSL version number supported by the Public key client (v 2, v 3) SSL version number picked by the server (v 2, v 3) Ciphers supported by the client (DES, RC 2, RC 4) Ciphers picked by the server (DES, RC 2, RC 4) Client Random Number Server Random Number Certificate Client Public key 16

Verify Certificate Server Private key Public key Certificate is Good and Valid Server/vendor has been verified and authenticated Client request Certificate Client has vendor’s public key and can now encrypt pre-master to send to server/vendor Valid Checking Client Public key Certificate 17

Not-recognizable Certificate 18

SSL Handshake • The TLS Handshake Protocol involves the following steps: - Exchange hello messages to agree on algorithms, exchange random values, and check for session resumption. - Exchange the necessary cryptographic parameters to allow the client and server to agree on a premaster secret. - Exchange certificates and cryptographic information to allow the client and server to authenticate themselves. - Generate a master secret from the premaster secret and exchanged random values. - Provide security parameters to the record layer. - Allow the client and server to verify that their peer has calculated the same security parameters and that the handshake occurred without tampering by an attacker. 19

SSL Handshake 1. Client hello 2. Server hello Present Server Certificate *Request Client Certificate Server Key Exchange Client 3. Client Finish *Present Client Certificate Client Key Exchange *Certificate Verify Change Cipher Spec 4. Server Finish Change Cipher Spec Server Application Data 20

Client Hello • Sent by the client – When first connecting to a server – In response to a hello request or on its own • Contains – 32 bytes random number created by a secure random numb generator – Protocol version – Session ID – A list of supported ciphers – A list of compression methods 21

Server Hello • Sent as response if client hello is accepted – If not, a handshake failure alert is sent • Contains – 32 bytes random number created by a secure random number – Protocol version – Session ID – Cipher suite chosen – Compression method selected 22

Server Certificates • Immediately following the server hello, the server sends its certificate – Generally an X. 509. v 3 certificate • Server sends server hello done message, indicating that the hello-message phase of the handshake is complete 23

Verify Server Certificate 24

Client Certificate (optional) Client only sends a certificate upon the receipt of a certificate request – Sends after receiving server hello done – If the client does not have a suitable certificate, it sends a certificate message with no certificates. • Server will respond with a fatal handshake failure if a client certificate is necessary 25

Key Exchange • Client sends 48 -bytes pre-master, encrypted using server’s public key, to the server • Both server and client use the pre-master to generate the master secret • The same session key is generated on both client and server side using the master secret 26

Final Steps • • Client sends change_cipher_spec Client sends finished message Server sends change_cipher_spec Server sends finished message 27

SSL Architecture 28

Record Layer • Compression and decompression • A MAC is applied to each record using the MAC algorithm defined in the current cipher spec • Encryption occurs after compression • May need fragmentation 29

SSL Architecture 30

Alert Layer • Explain severity of the message and a description –fatal • Immediate termination • Other connections in session may continue • Session ID invalidated to prevent failed session to open new sessions • Alerts are compressed same as other data 31

SSL Architecture 32

Change Cipher Spec Protocol • Notify the other party to use the new cipher suite • Before the Finished message 33

Comparison of SSL V 2. 0 and V 3. 0 • SSL 2. 0 is vulnerable to “man-in-themiddle” attack. The hello message can be modified to use 40 bits encryption. • SSL 3. 0 defends against this attack by having the last handshake message include a hash of all the previous handshake message 34

Comparison of SSL V 2. 0 and V 3. 0 • SSL 2. 0 uses a weak MAC construction • In SSL 3. 0, the Message Authentication Hash uses a full 128 bits of key material for Export cipher+, while SSL 2. 0 uses only 40 bits + See http: //en. wikipedia. org/wiki/Export_of_cryptography 35

Comparison of SSL V 2. 0 and V 3. 0 • SSL 2. 0 only allows a handshake at the beginning of the connection. In 3. 0, the client can initiate a handshake routine any time • SSL 3. 0 allows server and client to send chains of certificate • SSL 3. 0 has a generalized key exchange protocol. It allows Diffie-Hellman and Fortezza key exchange • SSL 3. 0 allows for record compression and decompression 36

Problem Free? • Side channel attack – any attack based on information gained from the physical implementation of a cryptosystem, rather than brute force or theoretical weaknesses in the algorithms (compare cryptanalysis). See http: //en. wikipedia. org/wiki/Side_channel_attack for details. • Information leak in encrypted connections. Vulnerable openssl versions do not perform a MAC computation if an incorrect block cipher padding is used. An active attacker who can insert data into an existing encrypted connection is then able to measure time differences between the error messages the server sends. This information can make it easier to launch cryptographic attacks that rely on distinguishing between padding and MAC verification errors, possibly leading to extraction of the original plaintext. 37

Wireless Transport Layer Security • Part of the WAP (wireless application protocol) standard 38

WTLS Overview 39

WTLS Facts • Mainly used to secure data transport between wireless device and gateway • Built on top of datagram (UDP) instead of TCP • WTLS provides full, optimized and abbreviated handshake to reduce roundtrips in high-latency networks 40

WTLS Facts • WTLS uses different format of certificates, mainly WTLS certificate, X 509 v 1 and 968. It also supports additional cipher suites, such as RC 5, short hashes, ECC, etc; • WTLS provides built-in key-refresh mechanism for renegotiation; • WTLS can also set session resumable to continue on a previous session. 41

Reference [1] http: //www. faqs. org/faqs/computer-security/ssl[1 talk faq/ [2] http: //www. pcwebopedia. com/TERM/S/SSL. htm [3]http: //developer. netscape. com/docs/manuals/secu rity/sslin/contents. htm [4] http: //www. ece. wpi. edu/~sunar/ee 578/SSL. ppt 42