SSLtalk

2012 © m@tthewa.co.uk
Why use TLS / SSL
And how does it work?

What we will cover
History of TLS SSL
Purpose of SSL
Understand Asymmetric and Symmetric Cryptography
Drawbacks
Uses of SSL
Public Key Infrastructure (PKI)
Its position in the OSI model
Overview of the Handshake and Record layers & cipher suite’s
Why you’re exposed without it
Questions - Further reading

History

History
1994 - Secure Sockets Layer (SSL) was developed by
Netscape as a protocol which permitted persistent and
secure transactions

History
secure transactions
1997 - an Open Source version of Netscape’s patented
version was created, which is now OpenSSL

History
secure transactions
1997 - an Open Source version of Netscape’s patented
version was created, which is now OpenSSL
1999 - the existing protocol was extended by a version
now known as Transport Layer Security (TLS). By
convention, the term "SSL" is used even when
technically the TLS protocol is being used.

Using SSL we can
Conﬁrm identity - certiﬁcate
CSR process with trusted
root providers (OS out of
box) e.g. TWATE, Comodo
Encrypt the conversation

What is SSL?
Uses Asymmetric and
Symmetric cryptography
Uses Public Key
Infrastructure (PKI)
RFC-5246

What is SSL?
Uses Asymmetric and
Symmetric cryptography
Uses Public Key
Infrastructure (PKI)
RFC-5246
RFC-xxxx stands for "Request for Comment"
This refers to a description of a standard for new or modiﬁed internet or networking
protocols. When standards are proposed, they are made available for public comment
so that they can be reﬁned and agreed upon. Internet Engineering Task Force (IETF)

SSL Cryptography
Asymmetric public-key cryptography
Something which is asymmetric displays asymmetry
Asymmetry is the opposite of symmetry i.e. they are not the same
Cryptography (or cryptology; from Greek κρυπτός, "hidden, secret code"
Pair of keys used to encrypt and decrypt - both  
a public and private (secret) key is needed. They work mathematically together
to achieve this
Symmetric private-key (shared secret key) both keys are the same, less CPU
intensive

Public Key Infrastructure
PKI is a system for the creation, storage, and distribution of digital certificates
which are used to verify that a particular public key belongs to a certain entity.
The PKI creates digital certificates which map public keys to entities, securely
stores these certificates in a central repository, and revokes them if needed
A PKI consists of
A certificate authority (CA) that both issues and verifies the digital
certificates
A registration authority (RA) which verifies the identity of users requesting
information from the CA, binds keys to users which may or may not be
separate from the CA
A central directory - a secure location in which to store and index keys

Drawbacks of SSL / TLS
Increased processor load - This is the most
significant drawback to implementing SSL / TLS.
Cryptography is CPU intensive. As a result, there is a
performance penalty when using SSL hence more
power consumed- less green
Administrative overhead - An SSL / TLS environment
is more complex and requires maintenance due to
expiry dates; the system administrator needs to
configure understand and manage certificates.

How does it
work?
When used with email Asymmetric
keys can be used to sign and / or
encrypt the message
The keys work together, with one being used to perform the inverse operation of the other.
If the public key is used to encrypt data, only the private key of the pair can decrypt it and
vice versa.
This relationship allows us to do two important things
Firstly, anyone can obtain the public key for a subject and use it to encrypt data that only the
user with the private key can decrypt.
Secondly, if a subject encrypts data using its private key, anyone can decrypt the data by
using the corresponding public key. This is the foundation for digital signatures.

Deep dive - OSI model

SSL / TLS is layered between the
application protocol layer and TCP/
IP layer, hence it can secure and
then send application data to the
transport layer

transport layer
Because it works between the
application layer and the TCP/IP
layer, it can support multiple
application layer protocols

transport layer
Because it works between the
application layer and the TCP/IP
layer, it can support multiple
application layer protocols
SSL / TLS protocol can be divided
into two layers.The Handshake
Protocol Layer and the Record
Protocol Layer

Handshake Layer
The Handshake layer provides a number of very
important security functions. It performs a set of
exchanges that starts authentication and negotiates
the encryption, hash, and compression algorithms
(cipher suite)
hashing e.g. MD5, SHA-1(use a salt)
encryption uses cipher
symmetric - DES, AES
asymmetric - RSA

Cipher Suites
Each named cipher suite deﬁnes the following;
key exchange algorithm
a bulk encryption algorithm
a message authentication code (MAC) algorithm
pseudorandom function (PRF).

Cipher Suites more detail
The key exchange algorithm is used to determine if and how the client and
server will authenticate during the handshake.
The bulk encryption algorithm is used to encrypt the message stream. It also
includes the key size and the lengths of explicit and implicit initialisation vectors
(cryptographic nonces).
The message authentication code (MAC) algorithm is used to create the
message digest, a cryptographic hash of each block of the message stream.
The pseudorandom function (PRF) is used to create the master secret, a 48-byte
secret shared between the two peers in the connection. The master secret is used
as a source of entropy when creating session keys, such as the one used to create
the MAC.

Algorithms used
Examples of algorithms used;
key exchange - RSA, Difﬁe-Hellman, ECDH, SRP, PSK
authentication - RSA, DSA, ECDSA
bulk ciphers - RC4, Triple DES, AES, IDEA, DES, or Camellia.
message authentication - for TLS, a Hash-based Message Authentication Code
using MD5 or one of the SHA-1 hash functions are used. For SSL, SHA, MD5,
MD4, and MD2 are used

Record Layer
The purpose of the SSL record layer is to take an
application message to be transmitted, fragment the
data which needs to be sent, encapsulate it with
appropriate headers and create an object just called a
record, which is encrypted and can be forwarded for
sending under the TCP protocol.

Client initiates secure session request
https://someurl.tld

https://someurl.tld
Server sends Certiﬁcate with public key

https://someurl.tld
Client checks certiﬁcate with CA and if it has been revoked;
If not used with known CA - allows user to accept risk

https://someurl.tld
Client generates random symmetric key and encrypts
it using servers public key

https://someurl.tld
Client generates random symmetric key and encrypts
it using servers public key
Client and Server now know the symmetric key
and use this to encrypt / decrypt rest of conversation

CA’s and CRL’s

CA’s and CRL’s
Certiﬁcate Authority (CA) - approved list in OS and
browsers out of the box; i.e. public keys of all major
certiﬁcate authorities

CA’s and CRL’s
NB. Subordinate CA’s are usually used so that Root
CA can revoke all Subordinates

CA’s and CRL’s
NB. Subordinate CA’s are usually used so that Root
CA can revoke all Subordinates
CA also has Certiﬁcate Revocation List - browser user
online search

Obtain X.509 certificate from
a CA
certificate signing request (CSR) - Contains details of
purpose, user, location and your public key
generate a CSR from the entity you want to use it with, part of this process will
first generate a key pair, keeping the private key secret, and will include your
details, and the encodes it using PKCS#10 standard; a binary format for
encoding CSRs for use with X.509.
you may need to provide further evidence of your identity, and the certificate
authority may contact the applicant for further information
if the request is successful, the certificate authority will send back an identity
certificate that has been digitally signed with the private key of the certificate
authority - and hence other people can validate it with the CA public key

NB. you can decode this locally using OpenSSL
openssl req -in myreq.pem -noout -text
the private key never leaves you

Browser process with CA
Your web browser downloads the web server's certificate, which contains the
public key of the web server. This certificate is signed with the private key of a
trusted certificate authority
Your web browser comes installed with the public keys of all of the major certificate
authorities. It uses this public key to verify that the web server's certificate was
indeed signed by the trusted certificate authority and has not been revoked
The certificate contains the domain name and/or ip address of the web server. Your
web browser confirms that the address listed in the certificate is the one to which it
has an open connection and that it has not expired
If necessary - prompts the user to accept any risks

Bob and Alice

So why do we need it

Exploiting vulnerable trafﬁc
Don't do this at work!!!

protocols like POP3, SMTP, site logons not using
encryption expose your personal data.
Packet captures

HTTP session hijacking

"sidejacking" - allowing you to do anything the user can
do on a particular website. On an open wireless
network, cookies are basically shouted through the air,
making these attacks extremely easy. e.g. Facebook,
only used to secure your logon, everything else was
then plain text - still need to tick a box

"sidejacking" - allowing you to do anything the user can
do on a particular website. On an open wireless
network, cookies are basically shouted through the air,
making these attacks extremely easy. e.g. Facebook,
only used to secure your logon, everything else was
then plain text - still need to tick a box
Twitter forced all third party developers to use OAuth
then immediately released (and promoted) a new
version of their insecure website. When it comes to
user privacy, SSL is a must!

http://codebutler.com/ﬁresheep

Firesheep

Firesheep
Firefox plugin that
exposes Twitter and
Facebook cookies
easily
uses a packet sniffer to
intercept unencrypted
cookies

Man in the Middle (MITM)
eavesdropping - the attacker sits between the victim
and the service they are using. With HTTP this would
be transparent - HTTPS helps you identify the
conversation is who you think it is
http://en.wikipedia.org/wiki/Man-in-the-middle_attack
shows easy to use free tools to perform such things
ARP poisoning e.g. KARMA for WIFI
DNS Spooﬁng

Man in the Middle (MITM)
eavesdropping - the attacker sits between the victim
and the service they are using. With HTTP this would
be transparent - HTTPS helps you identify the
conversation is who you think it is
http://en.wikipedia.org/wiki/Man-in-the-middle_attack
shows easy to use free tools to perform such things
ARP poisoning e.g. KARMA for WIFI
DNS Spooﬁng
Do you ignore this?

Final Questions?

What did we learn

What did we learn
Why SSL is important - check your Facebook settings

What did we learn
Difference between Hash and Cipher

What did we learn
MITM

What did we learn
MITM
Sidejacking

What did we learn
MITM
Sidejacking
CA’s and how Revocation works

What did we learn
MITM
Sidejacking
When was SSL ﬁrst invented

What did we learn
MITM
Sidejacking
When was SSL ﬁrst invented
Can a public key decrypt a private key

SSLtalk

More Related Content

What's hot

Viewers also liked

Similar to SSLtalk

SSLtalk