Secure Communications Protocols

1
Faculty of Information Technology – Cyber Security Department
Secure Socket Layer

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

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 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 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 authenticate servers identity securely.

HTTPS FTPS SMTPS Application

layer

SECURE SOCKET LAYER

Transport
TCP/IP layer layer

6
SSL Stack

7
 SSL components

• SSL Handshake Protocol

• negotiation of security algorithms and parameters
• key exchange
• server authentication and optionally client authentication.
• SSL Record Protocol
• fragmentation
• compression
• message authentication and integrity protection
• encryption
• SSL Alert Protocol
• error messages (fatal alerts and warnings)
• SSL Change Cipher Spec Protocol
• a single message that indicates the end of the SSL handshake 8
SSL Record Protocol Operation

9
SSL Record Format

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
The Idea

• Encrypt the web traffic between two sites, so no one can

listen in and get credit card numbers.

• Uses something called “Secure Sockets Layer” (SSL).

12
The Implementation

• The secure web site includes a digital certificate signed by some

certificate authority. The certificate includes the server name, its
public key, IP number, and an expiration date. It is typically
signed with a 1024 bit key by the CA.

• The list of certificate authorities that you trust to identify people

is available in Netscape by clicking on the lock icon at top; in IE,
Internet Options->Content.

13
How It Works

• The browser reads the site certificate; if it is signed by one of

the trusted certificate authorities, browser accepts the
certificate as valid.

• If the certificate is signed by some unknown certificate

authority, Netscape will ask you if you want to trust the guy
who signed it.

14
How It Works (Basic Protocol )

• The browser negotiates a secure session using something like the

following protocol:

1: A->B: hello
2: B->A: Hi, I'm Bob, bobs-certificate
3: A->B: prove it
4: B->A: Alice, This Is bob
{ digest[Alice, This Is Bob] } bobs-private-key
5: A->B: ok bob, here is a secret {secret} bobs-public-key
6: B->A: {some message}secret-key

15
How It Works
• Step 1: your browser introduces itself to the secure server.

• Step 2: the server responds by sending back a message with the

certificate included.

• Step 3: Your browser tells the secure site to prove its identity,
that it really is who it says it is.

16
How It Works

• Step 4: The secure server proves who it is by creating a message

for the browser, generating a “fingerprint” of that message, and
encrypting the “fingerprint” with the private key that is matched
to the public key in the certificate. The browser decrypts the
“fingerprint” generated by the server using the public key
provided in the certificate.

17
How It Works

• At this point the browser is sure that the server is who it says
it is. It can send it secret messages encrypted with the public
key provided in the certificate. The server (and only the
server) can decrypt these messages, because only it has the
private key.

18
 How It Works

• At this point what typically happens is that the browser generates

a session key using a completely different encryption algorithm.
• A new session key is generated for every connection; this does
not have to be a public key algorithm.
• You can use any encryption algorithm you like; usually a faster
conventional, non-PK algorithm is used. This is usually 40 or 128
bits long in Netscape.

19
How It Works

•You’ll use a completely different key for

encrypting traffic to the web site every
time you connect. This makes cracking
communication more difficult; you need
to discover the keys for every session
rather than just one key.

20
How SSL Works: the Handshake in Detail

21
SSL Handshake

Server

Public Private
key key

Client
request

Client

Public key
22
 SSL Session Key

Server

Private Public Pre- Session key

key key Master

Pre-
Master

Client

Public key Pre-Master Session key

23
 Secure Data on Network

Server

Private Public Session Data Session key Data

key key key

Data

Client

Data Session key Data

24
 Key exchange and certificate

Server

Private Public
key key

SSL version number client SSL version number

supported (v2, v3) server picked (v2, v3)
Ciphers supported client Ciphers server picked
(DES, RC2, RC4) (DES, RC2, RC4)
Client Random Number Server Random Number

Client
Certificate
Public key
25
 Verify Certificate
Server

Private Public
key key
Certificate is Good and Valid

Server has been verified and authenticated

Client
request Client has Server public key and
can now encrypt pre-master to send
Certificate to server/vendor

Client Valid
Checking

Public key
Certificate
26
Not-recognizable Certificate

27
Review the Certificate In
IE

28
 SSL Handshake

Client hello

Server hello

Present Server Certificate

*Request Client Certificate
Server Key Exchange

Client
Client Finish
*Present Client Certificate
Client Key Exchange
*Certificate Verify
Change Cipher Spec

Server Finish
Change Cipher Spec
Server

Application Data

29
 Server Hello Request

• Notifies the client that they should send a client hello message
to begin the negotiation process.
• Sent by the server at any time.
• After 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 Hello.

30
 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 which are : random number created by a secure

random number generator, Protocol version, Session ID, A list of supported
ciphers and A list of compression methods.

31
 Server Hello
• Sent as response if client hello is accepted If not, a
handshake failure alert is sent .

• Contains 32 bytes which are: random number created

by a secure random number generator, Protocol version.
Session ID, Cipher suite chosen, Compression method
selected.

32
 Server Certificates

• Immediately following the server hello, the server sends its

certificate Generally an X.509.v3 certificate

• Server sends server hello done message

33
Verify Server Certificate

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

35
Verify Client Certificate

36
 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.
• A same session key is generated on both client and server
side using the master secret.

37
 Final Steps

• Client sends change_cipher_spec

• Client sends finished message
• Server sends change_cipher_spec
• Server sends finished message

38
SSL Architecture

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

40
SSL Architecture

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

42
SSL Architecture

43
 Change Cipher Spec Protocol

• Notify the other party to use the new cipher suite

Before the Finished message.

44
 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

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

46
• 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

47