Secure socket layer

The primary goal of SSL is to provide privacy and
data integrity between two communicating
applications over the network
The SSL or TLS protocol is layered on top of
reliable transport layer protocols such as TCP
TLS is defined in RFC 2246, 4346, 5246
SSL is application protocol independent such
that higher level protocols can layer on top of it
SSL/TLS does not specify how the higher level
protocols add security with TLS

SSL 1.0
Developed by Netscape in early 1994
Never released publicly
SSL 2.0
Published by Netscape in early 1995
Contained number of security flaws
SSL 3.0
Designed to cover previous flaws, released 1996
TLS 1.0
Internet standard based on SSL 3.0, January 1999
Not interoperable with SSL 3.0 (can back down to SSL)

Cryptographic security: provides secure
connection
Interoperability: enables applications to utilize
TLS, independent of their implementation
Extensibility: provides a framework to
incorporate new encryption methods
Relative Efficiency: incorporate an optional
session caching scheme to reduce the number
of connections that need to be established

TLS allow peers to agree upon security
parameters, authenticate themselves and
report errors to each other.
TLS takes messages to be transmitted,
fragments the data into manageable blocks,
optionally compresses the data, applies a MAC,
encrypts, and transmits the result.
Received data is decrypted, verified,
decompressed, and reassembled, then
delivered to higher level clients.

TLS Record Protocol
provides secure connection using properties such
as private and reliable connection
encapsulates various high level protocols such as
TLS Handshake Protocol
TLS Handshake Protocol
allows Server-Client to authenticate each other and
negotiate keys and cryptographic algorithms before
data is transmitted by application protocol

Connection is Private
symmetric encryption such as DES or RC4 is used
keys generated uniquely for each connection based
on secret negotiated by TLS Handshake Protocol
can be used without encryption
Connection is reliable
Message transport includes a message integrity
check using a keyed MAC (Message Auth Code)
Secure hash function (e.g. SHA, MD5, etc) used for
MAC computations
can operate without a MAC

Peer's identity can be authenticated using
asymmetric, or public key cryptography e.g.
RSA, DSS (optional but required for at least a
single peer)
negotiation of a shared secret is secure and
unavailable to eavesdroppers
negotiation is reliable with no modification in
its communication without being detected

Most of the operations in TLS record and
handshake layer require a keyed MAC
Secure digest of data is protected by a secret
TLS uses HMAC to carry out handshakes with the
algorithms MD5 and SHA1
Data expansion function defined as
P_hash(secret,seed)
= HMAC_hash(secret, A(1) + seed) +
HMAC_hash(secret, A(2) + seed) +
HMAC_hash(secret, A(3) + seed) + …
iterated to produce the required quantity of data

construction required to do expansion of secrets into
blocks of data for the purposes of key generation or
validation
takes as input a secret, seed, and an identifying label
and produces an output of arbitrary length
PRF is secured by using atleast two hash algorithms
TLS's PRF is created by splitting the secret into two
halves and using one half to generate data with MD5
and the other half to generate data with SHA-1, then
exclusive-o’ring the outputs of these two expansion
functions together
PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
P_SHA-1(S2, label + seed)

receives uninterpreted data from higher layers
and fragments information blocks into TLS-
plaintext records carrying data in chunks
records are compressed using the compression
algorithm defined in the current session state
Encryption and MAC functions translate a
compressed record into a TLS-cipher text
Stream ciphers convert compressed fragments
into cipher text fragment structures.
MAC is computed before encryption

Message
Frag1 Frag2 Frag3
Com1 Com2 Com3
Encrypt2Encrypt1 Encrypt3
Data Stream
App Data
Record Proto
Units
Compressed
Units
MAC
Encrypted
Units
TCP Packet

The Record Protocol requires an algorithm to
generate keys, IVs, and MAC secrets from the
security parameters provided by the handshake
protocol
Master secret is hashed into a sequence of
secure bytes, which are assigned to the MAC
secrets, keys, and non-export IVs required by
the current connection state
When generating keys and MAC secrets, the
master secret is used as an entropy source, and
random values provide unencrypted salt
material and IVs for exportable ciphers

TLS Record protocol operates using connection
states
Connection states specifies compression, bulk
encryption and MAC algorithms with parameters,
MAC secret, bulk encryption keys and IVs for
connections in both read and write directions
There are 4 connection states (current read and
write states, and pending read and write states)
records are processed in the current read and write
states
TLS Handshake protocol can set the security
parameters for the pending states and can
selectively change pending states to current state

Consists of a suite of three sub-protocols
Handshake protocol, Alert protocol and
Change Cipher Spec protocol
used to allow peers to agree upon security
parameters for record layer, authenticate
themselves, instantiate negotiated security
parameters, and report errors to each other
responsible for negotiating a session
Many connections can be instantiated using
same session through resumption feature of TLS

Used to signal transitions in ciphering strategies
Such transitions signals can be sent by both the
client and server
The receiver on receipt of signals instructs the
Record Layer to immediately copy the read
pending state into the read current state
The sender after sending such signal instructs
the Record Layer to make the write pending
state the write active state

supported by the TLS Record layer
used to convey alert messages with the severity
of the message and a description of the alert
alert messages are encrypted and compressed
Closing alerts
client and server must share knowledge that the
connection is ending to avoid a truncation attacks
Either party may initiate the close by sending close
notify alert
Error alerts
On error detection, the detecting party informs the
other party about the error using an error alert

Alerts Level Description
bad_record_mac Fatal incorrect MAC
decryption_failed Fatal invalid way of ciphertext decryption
record_overflow Fatal record length more than 2^14+2048 bytes
decompression_failure Fatal Improper input to decompression function
handshake_failure Fatal unable to negotiate acceptable security params
bad/unsupported_certi Fatal/W certificate of corrupt/unsupported type
illegal_parameter Fatal field in handshake was out of range
access_denied Fatal sender decided not to proceed with negotiation
decode_error Fatal message could not be decoded (incorrect length)
decrypt_error Fatal/W handshake cryptographic operation failed
export_restriction Fatal negotiation incompliant with export restrictions
insufficient_security Fatal server requires more secure ciphers
internal_error Fatal Internal error unrelated to peer or protocol
no_renegotiation Warn renegotiation is not possible

operates on top of the TLS Record Layer
produces cryptographic parameters of the
session state
Handshake messages are supplied to TLS Record
Layer, which are processed and transmitted
according to the current active session state.
Hello Request message can be sent at any time
and not bound by ordering rules, but it should
be ignored by the client when it is in the middle
of an handshake
handshake messages are intended to have
transmission precedence over application data

Exchange hello messages to agree on algorithms,
exchange random values, and check for session
resumption
Exchange cryptographic parameters to allow client-
server to agree on a premaster secret
Exchange certificates and cryptographic info to allow
client-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 peer calculated
security parameters and that the handshake occurred
without tampering by an attacker

Selected Cipher Suite
Selected Comp Algo
Selected Version
S X509 Certificate
Cryptographic Info
SSL Client SSL Server
Session ID
Random Data
Cipher Suite List
Compression Algo List
Version List
CL X509 Certificate
Premaster secret
ClientHello
Certificate
ServerKeyExchange
CertificateRequest
ServerHello
ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
Finished
[ChangeCipherSpec]
Application Data
Finished
[ChangeCipherSpec]

Algorithms I Support,
My random Number
Verify Certificate and extract
server’s public key,
Encrypt pre-master’s secret
with server’s public key
Send checksum of
handshake messages using
secret key
Compare checksum
on the client side
Compute secret key
Use these algorithms,
My random number,
My digital certificate
Compare checksum on server side
Send checksum of
handshake messages
using secret key
Decrypt pre-master secret
key with server’s private key
Compute secret key
Client Server

ServerHello
[ChangeCipherSpec]
Finished
Application Data
SSL Client SSL Server
ClientHello
[ChangeCipherSpec]
Finished
Application Data

OpenSource implementation of the SSL and TLS protocols
and basic cryptographic functions
Provides generic TLS/SSL server and client implementation.
Used to create, sign, verify and check certificates.
Create a self signed certificate using following commands
openssl req -x509 -nodes -days 365 -newkey rsa:1024
-keyout mykey.pem -out mycert.pem
openssl req -new -x509 -extensions v3_ca -keyout
mykey.pem -out mycert.pem -days 365 -config ./openssl.cnf
Verify the certificate created:
openssl verify mycert.pem
Display the X509 certificate:
openssl x509 -in mycert.pem -text -noout

Check a Certificate Signing Request (CSR) :
openssl req -text -noout -verify -in CSR.csr
Check a private key:
openssl rsa -in privateKey.key -check
Launch secure server using specified certificate:
openssl s_server -accept 4433 -cert mycert.pem
-key mykey.pem -www -state -debug
Launch secure client using SSL/TLS to connect:
openssl s_client -connect localhost:4433

Secure socket layer

More Related Content

What's hot (20)

Similar to Secure socket layer (20)

More from Emprovise (20)

Recently uploaded (20)

Secure socket layer

Editor's Notes