Details information about SSL(Secure sockets layer) and TLS(Transport layer secutity).

1. Security at the Transport
Layer : SSL and TLS

2. Location of SSL or TLS
• SSL and TLS belong to transport layer which
provides end-to-end security for applications
that use a reliable transport layer protocol
such as TCP.
• It provide security services for transactions
on the Internet.
Application Layer
SSL or TLS
TCP
IP

3. SSL-Secure Sockets Layer
• SSL was developed by NetScape in 1994.
• It was design to provide security and compression services to data
generated from the application layer (usually used protocol is
HTTP).
• Data received from the application is compressed(optional), signed,
and encrypted before it passed next layer.

4. SSL Services
1. Fragmentation : It divide the data into blocks of 214 bytes.
2. Compression : Fragmented data is compressed using one of the
lossless compression methods. This services is optional.
3. Message Integrity : To preserve the integrity of data, SSL use keyed-
hash function to create MAC.
4. Confidentiality : To provide confidentiality, the original data and MAC
are encrypted using symmetric-key cryptography.
5. Framing : A header is added to encrypted payload. The payload is then
passed to a reliable transport layer protocol.

5. SSL-Key Exchange Algorithms
Key Exchange
Algorithms
NULL RSA
Anonymous
Diffie-
Hellman
Ephemeral
Diffie-
Hellman
Fixed Diffie-
Hellman
Fortezza

6. RSA
In this method, the pre-master secret is a 48-byte random number created
by client, encrypted with the server’s RSA public key, and than its is send
to the server.

7. Anonymous Diffie-Hellman
• Is the most simplest and insecure method.
• The pre-master secret is established between the client and
server using Diffie-Hellman(DH) protocol.
• Here the DH half-key is send in plain text.

8. Ephemeral Diffie-Hellman
• In this, each party sends a Diffie-Hellman key signed by its private
key.
• Receiver party need to verify the signature using the private key
of the sender.
• And the private key are exchanged using RSA or DSS digital
signature certificates.

9. Fortezza
• It is a registered trademark of the U.S National Security Agency.
• Protocol was develop for the Defense Department only.

10. Encryption/Decryption Algorithms
Encryption
Algorithms
NULL
Stream
RC4
Block
RC2
Block DES
Block
IDEA
Block
Fortezza

11. Compression Algorithms
• Compression is optional in SSLv3.
• Default compression method is NULL.

12. Cryptographic Parameter Generation
• To achieve message integrity and confidentiality, SSL needs 6
cryptographic secrets, 4 keys and 2 IVs.
• Client and Server each needs one key for message authentication,
one key for encryption and one IV for block encryption.
• SSL requires both direction side keys to be different so if there is
an attack in one direction, the other direction is not affected.

13. Procedure…
1. The client and server exchange two random numbers; one is created by
the client and other by the server.
2. The client and server exchange one pre-master secret using one of the
key-exchange algorithms.
3. A 48-byte master secret is created from the pre-master secret by applying
two hash functions(SHA-I and MD5).
4. The master secret is used to create variable-length key material by
applying the same set of hash functions and prepending with different
constants.
5. 6 different keys are extracted from the key material.
Client-Server Auth key, Client-Server Enc Key, Client-Server IV.

14. Sessions and Connections
• session: this is an association between a client and a server that
defines a set of parameters such as algorithms used, session
number etc.
• connection: this is a logical client/server link, associated with the
provision of a suitable type of service. In SSL terms, it must be a
peer-to-peer connection with two network nodes.

15. Session state parameters
• Session identifier: this is an identifier generated by the server to identify a session with a
chosen client,
• Peer certificate: X.509 certificate of the peer,
• compression method: a method used to compress data prior to encryption,
• Algorithm specification termed CipherSpec: specifies the bulk data encryption algorithm
(for example DES) and the hash algorithm (for example MD5) used during the session,
• Master secret: 48-byte data being a secret shared between the client and server,
• “is resumable”: this is a flag indicating whether the session can be used to initiate new
connections.

16. Connection State parameters
• Server and client random: random data generated by both the client and server for
each connection,
• Server write MAC secret: the secret key used for data written by the server,
• Client write MAC secret: the secret used for data written by the client,
• Server write key: the bulk cipher key for data encrypted by the server and
decrypted by the client,
• Client write key: the bulk cipher key for data encrypted by the client and decrypted
by the server,
• Sequence number: sequence numbers maintained separately by the server for
messages transmitted and received during the data session.

17. Four Protocols

18. 1.Handshake Protocol
• It uses messages to negotiate cipher suite,to authenticate the
server to client and client to server.
• Done in 4 phases..

19. Phase 1:Establishing Security Capability
• Here client and server announce their security capability and
choose those that are convenient for both.
• Two messages are exchanged : ClientHello and ServerHello.
• The parties agree upon particular compression method.
•

20. ClientHello
• The highest SSL version number the client can support
• A 32-byte random number that will be used for master secret key
generation.
• A session ID
• A cipher suite that defines the list of algorithms that the client
can support.
• A list of compression methods that the client can support.

21. SessionHello
• An SSL version number.
• A 32-byte random number that will be used for master secret key
generation.
• A session ID.
• The selected cipher set from the client list.
• The selected compression method from the client list.

22. Phase 2:Server Key Exchange and
Authentication
• Certificate : If it is required, the server sends a certificate
message to authenticate itself.
• ServerKeyExchange : It includes its contribution to the pre-master
secret.
• CertificateRequest : The server may require the client to
authenticate itself,so it sends this message in phase 2 for
certification from client in phase 3.
• ServerHelloDone : The last message is a signal to the client that
phase 2 is over and client needs to start Phase 3.

23. Phase 3:Client Key Exchange and
Authentication
• Certificate : To certify itself to the server, client sends a
certificate message.
• ClientKeyExchange : It includes its contribution to the pre-master
secret.
• CertificateVerify : Client needs to send an corresponding private
key for the certificate it sends, it is needed to thwart an imposter
who sends the certificate and claims that it comes from the
client.

24. Phase 4:Finalizing and Finishing
• Client
• ChangeCipherSpec : The client sends a ChangeCipherSpec message to show
that it has moved all of the cipher suite set and the parameters from the
pending state to the active state.
• Finished : It is sent by client. It is a Finished message that announces the end
of the handshaking protocol by the client.
• Server:
• ChangeCipherSpec : The server sends a ChangeCipherSpec message to show
that it has moved all of the cipher suite set and the parameters from the
pending state to the active state.
• Finished : It is sent by server. It is a Finished message that announces the end
of the handshaking protocol is totally completed.

25. Change Cipher Spec Protocol(CCS)
• The change cipher spec protocol is used to change the encryption
being used by the client and server. It is normally used as part of
the handshake process to switch to symmetric key encryption.
• The CCS protocol is a single message that tells the peer that the
sender wants to change to a new set of keys, which are then
created from information exchanged by the handshake protocol.
• This protocol consists of a single message which consists of a
single byte .

26. Continue..

27. Alert Protocol
• Alert messages convey the severity of the message and a
description of the alert.
• The primary use of this protocol is to report the cause of failure.
Status changes include such things as error condition like invalid
message received or message cannot be decrypted, as well as
things like the connection has closed.

28. Continue..

29. Record Protocol
• Breaking Down the Data from Application
layers, with fixed length.
• Compress the Data
• Add Message Authentication Code, Which is
calculated with the help of Integrity Key.
• Encrypt the packets(which was broked
down with fixed length).
• Add SSL header's in the packets with fixed
length. Which consists the following
headers, which combinely form a 5byte
header.
• 1 Byte Protocol Definition
• 2 Byte Protocol version
• 2 Byte Length

30. Message Format
• Protocol : This 1 byte field the source or destination of the encapsulated message.It is used for
multiplexing and demultiplexing .The value are 20 for ccs protocol,21 for alert protocol,22for
handshake protocol,23 for data from application layer
• Version : This 2 byte field defines the version of SSL ,one byte for major version and another other
is for minor .
• Length : this id 2 byte field defines the size of the message in byte.
Message formate of Record protocol Header

31. Change cipher spec
• This additional one byte field in the message is called
ccs protocol.
• This done at the handshake protocol because for
exchanging the key.
• The default value is 1.

32. Alert Protocol
• Level : 1 byte field defines error level.
2 levels of error – warning and fatal.
• Description : 1 byte description defines type of error.

33. Handshake Protocol
• Generic Header :

34. Hello Request Message
• Rarely used.
• Request from server to client to start a session.
• Then client sends Client Hello Message.

35. ClientHello Message

36. ServerHello Message

37. Certificate Message

38. ServerKeyExchange Message
• Sent from server to client.
• Contains Key generated by the server.
• Format is dependent on cipher suite.
• If server has sent a certificate message,
then message also contains a signed
parameter.

39. CertificateRequest Message
• Sent from server to client to authenticate itself using acceptable
certificates.

40. ServerHelloDone Message
• Last message in second phase of handshaking.

41. Certificate Verify Message
• Last message of Phase 3
• Client proves that it actually owns the private key related to it’s
public-key certificate.
• Hash is created by client and signed using MD5.

42. Client Key Exchange Message
• Second Message of third phase.

43. Finished Message
• It shows that negotiation is
over.
• Contains all the messages
which were exchanged
during handshaking,
followed by sender role,
master secret and padding.
• Format depends on type of
suite.

44. Application Data
• Record protocol adds a
signature i.e. MAC at the end
of the fragment coming from
application layer.
• General Header with protocol
value 23.

45. Transport Layer Security(TLS)
• The Transport Layer Security (TLS) protocol is the IETF standard
version of the SSL protocol. The two are very similar, with slight
differences

46. Version
• The first difference is the version number (major and minor). The
current version of SSL is 3.0; the current version of TLS is 1.0. In
other words, SSLv3.0 is compatible with TLSv1.0.

47. Generation of Cryptographic Secrets
• Data Expansion Functions

48. Pseudorandom Function(PRF)

49. Master Secret

50. Key Material

51. Alert Protocol

52. Handshake Protocol

53. Finished Message