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

2. Agenda
SSL Basics
WTLS

3. SSL Facts
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 layer
Any program using TCP can be modified to use SSL connection

4. 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

5. 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

6. 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
Application layer
Transport layer
TCP/IP layer
SMTPS
FTPS
HTTPS
SECURE SOCKET LAYER

7. SSL Stack

8. SSL Record Protocol Operation

9. SSL Record Format

10. 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

11. SSL Handshake

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

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

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

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

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

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

18. Not-recognizable Certificate

19. 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.

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

21. 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 number generator
Protocol version
Session ID
A list of supported ciphers
A list of compression methods

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

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

24. Verify Server Certificate

25. 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

26. 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

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

28. SSL Architecture

29. 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

30. SSL Architecture

31. 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

32. SSL Architecture

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

34. 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 message

35. Comparison of SSL V2.0 and V3.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

36. 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 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

37. 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 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.

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

39. WTLS Overview

40. 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

41. WTLS Facts
WTLS uses different format of certificates, mainly WTLS certificate, X509v1 and It also supports additional cipher suites, such as RC5, 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.

42. Reference
[1] faq/
[2]
[3]
[4]