1. 1 Secure Socket Layer Yu YangYu Yang Lilly WangLilly Wang

2. 2 Agenda SSL Basics SSL Basics WTLS WTLS Security for Web Service Security for Web Service

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

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

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

6. 6 Secure Socket Layer SSL is a secure protocol which runs above TCP/IP and allows users to encrypt data and authenticate servers/vendors identity securely Application layer Transport layer TCP/IP layer SMTPSFTPSHTTPS SECURE SOCKET LAYER

7. 7 SSL Stack

8. 8 SSL Record Protocol Operation

9. 9 SSL Record Format

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

11. 11 SSL Handshake

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

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

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

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

16. 16 Key exchange and certificate SSL version number client supported (v2, v3) Ciphers supported client (DES, RC2, RC4) Client Random Number SSL version number server picked (v2, v3) Ciphers server picked (DES, RC2, RC4) Server Random Number Server Client Public key Private key Public key Certificate

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

18. 18 Not-recognizable Certificate

19. 19 Review the Certificate In IE

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

21. 21 Server Hello Request Notifies the client that they should send a client hello message to begin the negotiation processNotifies the client that they should send a client hello message to begin the negotiation process Sent by the server at any timeSent by the server at any time After the server sends a request, it does not send another one until a handshake has been completedAfter the server sends a request, it does not send another one until a handshake has been completed Client can choose to ignore them or send a Client HelloClient can choose to ignore them or send a Client Hello

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

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

24. 24 Server Certificates Immediately following the server hello, the server sends its certificateImmediately following the server hello, the server sends its certificate – Generally an X.509.v3 certificate Server sends server hello done messageServer sends server hello done message

25. 25 Verify Server Certificate

26. 26 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 no certificate alert Server will respond with a fatal handshake failure if a client certificate is necessaryServer will respond with a fatal handshake failure if a client certificate is necessary

27. 27 Verify Client Certificate

28. 28 Key Exchange Client sends 48-bytes pre-master, encrypted using server’s public key, to the serverClient 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 secretBoth server and client use the pre-master to generate the master secret A same session key is generated on both client and server side using the master secretA same session key is generated on both client and server side using the master secret

29. 29 Final Steps Client sends change_cipher_spec Client sends change_cipher_spec Client sends finished message Client sends finished message Server sends change_cipher_spec Server sends change_cipher_spec Server sends finished message Server sends finished message

30. 30 SSL Architecture

31. 31 Record Layer Compression and decompressionCompression and decompression A MAC is applied to each record using the MAC algorithm defined in the current cipher specA MAC is applied to each record using the MAC algorithm defined in the current cipher spec Encryption occurs after compressionEncryption occurs after compression May need fragmentationMay need fragmentation

32. 32 SSL Architecture

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

34. 34 SSL Architecture

35. 35 Change Cipher Spec Protocol Notify the other party to use the new cipher suiteNotify the other party to use the new cipher suite Before the Finished messageBefore the Finished message

36. 36 Comparison of SSL V2.0 and V3.0 SSL 2.0 is vulnerable to “man-in-the- middle” 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 messageSSL 2.0 is vulnerable to “man-in-the- middle” 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

37. 37 Comparison of SSL V2.0 and V3.0 SSL 2.0 uses a weak MAC constructionSSL 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 bitsIn 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

38. 38 Comparison of SSL V2.0 and V3.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 timeSSL 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 certificateSSL 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 exchangeSSL 3.0 has a generalized key exchange protocol. It allows Diffie-Hellman and Fortezza key exchange SSL 3.0 allows for record compression and decompressionSSL 3.0 allows for record compression and decompression

39. 39 Problem Free? Side channel attack – discovered by Swiss Federal Institute of Technology in LausanneSide channel attack – discovered by Swiss Federal Institute of Technology in Lausannehttp://www.newsfactor.com/perl/story/20843.html 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.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.

40. 40 Wireless Transport Layer Security

41. 41 WTLS Overview

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

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

44. 44 Web Service Security

45. 45 Comparison of Traditional Web Application and Web Service Client-server system vs multi-partyClient-server system vs multi-party Simple protocol sets vs complicated protocol setsSimple protocol sets vs complicated protocol sets

46. 46 Point-to-Point End-to-End

47. 47 Initial Specifications WS-SecurityWS-Security WS-PolicyWS-Policy WS-TrustWS-Trust WS-PrivacyWS-Privacy Follow-on Specifications WS-SecureConversationWS-SecureConversation WS-FederationWS-Federation WS-AuthorizationWS-Authorization Proposed Security Specification

48. 48 WS-Security A“ what” not “how”A“ what” not “how” Security token is embedded inside SOAP headersSecurity token is embedded inside SOAP headers Message integrity is provided by XML Signature and security tokensMessage integrity is provided by XML Signature and security tokens Message confidentiality is provided by XML Encryption with security tokensMessage confidentiality is provided by XML Encryption with security tokens

49. 49 WS-Security

50. 50 Web Service Security

51. 51 Reference [1 [1] http://www.faqs.org/faqs/computer-security/ssl-talk faq/ [2] http://www.pcwebopedia.com/TERM/S/SSL.htm [3] http://developer.netscape.com/docs/manuals/security/sslin /contents.htm [4] http://www.ece.wpi.edu/~sunar/ee578/SSL.ppt [5] http://nas.cl.uh.edu/yang/teaching/csci5931webSecurity/ ThesisProWS_Rajiv.doc ThesisProWS_Rajiv.doc