Transport Layer Security
James Walden
Northern Kentucky University
Topics
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Cryptography Concepts
Public Key Cryptography
Hash Functions
Random Number Generation
The TLS Protocol
Public Key Infrastructure (PKI)
MITM Attacks
Implementation Issues
Protocol Issues
TLS Defenses (Pinning, HSTS)
CSC 666: Secure Software Engineering
Cryptography Concepts
Communication
channel
Sender
encrypt
Recipient
decrypt
ciphertext
plaintext
plaintext
plaintext
shared
secret
key
Alice
shared
secret
key
Eve
(eavesdropper)
CSC 666: Secure Software Engineering
Bob
Cryptanalysis Threat Models
Ciphertext only: adversary has only ciphertext;
goal is to find plaintext, possibly key.
Known plaintext: adversary has ciphertext,
corresponding plaintext; goal is to find key.
Chosen plaintext: adversary may supply
plaintexts and obtain corresponding ciphertext;
goal is to find key.
Kerckhoff’s Principle
Cryptosystem security should only depend on
1. Quality of shared encryption algorithm E
2. Secrecy of key K
The best attack against such a system is
 Exhaustive key search (a/k/a Brute Force)
 Note that this assumes that all keys are equally
likely to be chosen, i.e. are randomly generated.
Brute Force Attack
Exhaustive search of keyspace by decrypting
ciphertext C with all possible keys K.
 Must determine if DK(C) is a likely plaintext
 Requires some knowledge of format
(language, doc type)
For N possible keys,
 Worst case is N decryptions.
 Mean case is N/2 decryptions.
Example: DES has 56-bit keys
 Average time to find key is 255 decryptions.
Is 128 bits enough?
128-bit keyspace permits 2128 keys
 340,282,366,920,938,463,463,374,607,431,768,211,456
or
 3.4 x 1038 keys
Cracking 1 trillion (1012) keys per second requires
 3.4 x 1026 seconds or
 1.08 x 1019 years
Cracking 1 trillion keys per second on 1 billion CPUs
 requires 1.08 x 1010 years = 10.8 billion years
Stream Ciphers
Features
 Use encryption algorithm to generate a pseudorandom stream of bits called keystream.
 XOR keystream with plaintext bit stream to generate
ciphertext bit stream.
Stream
Cipher
1
1
0
0
⊕
1
0
1
0
Plaintext stream
1
0
Ciphertext stream
=
0
1
CSC 666: Secure Software Engineering
Block Ciphers
Features
 Divide message into fixed size blocks.
 Pad plaintext if it doesn’t fit into blocks.
 Encrypt each plaintext block with algorithm.
PKCS#7 Padding
 Padding value = number of bytes appended.
 Padding verified and removed after decryption.
7
7
7
7
7
7
7
4
4
4
4
CSC 666: Secure Software Engineering
Electronic Code Book Mode
Encrypt each block independently.
E(block) = Cblock each time block appears
Therefore attacker can build dictionary of blocks.
ECB encryption of bitmap hides
colors but image is still discernible.
Cipher Block Chaining Mode
XOR each block with previous ciphertext
block. Random initialization vector (IV)
used for 1st block.
CBC encryption of bitmap looks random.
Advanced Encryption Standard
AES was winner of open NIST competition (1997-2000)
 Rijndael, designed by Joan Daemen and Vincent Rijmen.
 Published as FIPS 197 in November 2001.
 128-bit block cipher
 Variable key length: 128-, 192-, or 256-bit keys.
Replacement for DES
 DES vulnerable to brute force attacks due to 56-bit keys.
 Triple DES is very slow.
Symmetric Key Distribution
Requires each pair of communicating parties
to share a (separate) secret key.
shared
secret
shared
secret
shared
secret
shared
secret
shared
secret
shared
secret
n (n-1)/2
keys
Public-Key Cryptography
Separate keys for encryption and decryption.
Communication
channel
Sender
encrypt
plaintext
Recipient
decrypt
plaintext
ciphertext
plaintext
Bob’s public
key
Alice
Bob’s private
key
Eve
(eavesdropper)
Bob
Public Key Distribution
Only one key is needed for each recipient
private
private
public
public
private
public
public
n key
pairs
private
Requirements
1. It must be computationally easy to
encipher or decipher a message given
the appropriate key.
2. It must be computationally infeasible to
derive the private key from the public
key.
3. It must be computationally infeasible to
determine the private key from a chosen
plaintext attack.
One-Way Trapdoor Functions
Trapdoor one-way Function: One-way function
whose inverse is easy to calculate only if given a
special piece of information.
Example: Prime factoring
 Easy to calculate product.
 Difficult to calculate prime factors from product.
 Easy to calculate one prime factor, given others.
Note: Better attacks than brute force exist.
 While prime factoring is hard, it’s not as hard as a
brute force search of all keys.
 128-bit keys are not sufficient for public keys!
 Key size required depends on which trapdoor fn used.
Diffie-Hellman Key Exchange
Compute shared key w/o trusted 3rd party.
Based on discrete logarithm problem
 Given integers n and g and prime number p,
compute k such that n = gk mod p.
 Solutions known for small p.
 Computationally infeasible for
large p.
Shared Constants
 prime modulus p,
 integer base g ≠ {0, 1, p–1}
Diffie-Hellman Algorithm
1.
2.
3.
4.
5.
Alice chooses a random private key k
Computes public key A = gk mod p and sends to Bob.
Bob chooses a random private key k’
Computes public key B = gk’ mod p and sends to Alice.
Alice computes secret key
1. K1 = Bk mod p
6. Bob computes secret key
1. K2 = Ak’ mod p
7. Encrypt messages w/ symmetric cipher using K1=K2 as
the shared secret key.
Diffie-Hellman Example
Assume p = 53 and g = 17
Alice chooses kAlice = 5
Then KAlice = 175 mod 53 = 40
Bob chooses kBob = 7
Then KBob = 177 mod 53 = 6
Shared key:
Alice computation: KBobkAlice mod p = 65 mod 53
= 38
Bob computation: KAlicekBob mod p = 407 mod 53
= 38
Diffie-Hellman Activity
Assume p = 51 and g = 19.
Find a student to pair with.
 Each student picks a random private key.
 Compute public key with irb.
irb(main):001:0> (19**7).modulo(51)
=> 43
Share your public key with your partner.




Compute shared, secret key using irb.
Compare shared key with partner.
If they match, congratulations!
If they don’t, find out what went wrong.
RSA Algorithm
Choose two large prime numbers p, q
 Let the modular base n = pq.
 Choose e < n so e is relatively prime to (n).
 Compute inverse of e, d, as private key.
Public key: (e, n)
Private key: d
Encipher: c = me mod n
Decipher: m = cd mod n
Man-in-the-Middle Attacks
MITM is an active network attack in which attacker
routes packets through his machine, modifying
them in the process.
Attacker needs to start with one of these attacks:





ARP spoofing
DHCP spoofing
DNS hijacking or cache poisoning
Route hijacking
DNS cache poisoning
Then he can modify packets as desired.
CSC 666: Secure Software Engineering
ARP Spoofing
LAN: 192.168.1.x
CLIENT
SERVER
Regular traffic
switch
Alice
.10
Bob
.100
Using arp poisoning
MAC: 00:0A:E4:3B:47:7E
MAC: 00:0A:E4:2E:9B:11
gratuitous arp reply
Bob’s IP→ Cracker’s MAC
arpspoof 192.168.1.10 192.168.1.100
victim ip
gateway ip
MAC: 00:22:64:34:60:88
gratuitous arp reply
Alice’s IP→ Cracker’s MAC
arpspoof 192.168.1.100 192.168.1.10
victim ip
gateway ip
Cracker
.1
Hash Functions
Hash Function h: MMD
 Input M: variable length message M
 Output MD: fixed length “Message Digest” of input
Many inputs produce same output (called a collision)
 Limited number of outputs; infinite number of inputs
 Avalanche effect: small input change -> big output change
Example (insecure) hash function
 Sum 32-bit words of message mod 232
M
h
MD=h(M)
MACs for Data Integrity
Given a message M and shared secret key K, Alice
computes H(K||M) and sends M and this hash to Bob.
Communication
channel
h
MAC
message M
Alice
6B34339
shared
secret
key
(attack detected)
=? 87F9024
4C66809
4C66809
MAC
received
MAC
Mallory
(modifying)
h
computed
MAC
message M’
shared
secret
key
Bob
Secure Hash Function
A function h = hash(m) must have 3 properties to be
secure:
1. Pre-image resistance: Given a hash h it should be difficult to
find any message m such that h = hash(m). Functions that lack
this property are vulnerable to preimage attacks.
2. Second pre-image resistance: Given an input m1 it should be
difficult to find another input m2 such that m1 ≠ m2 and hash(m1)
= hash(m2). Functions that lack this property are vulnerable to
second-preimage attacks.
3. Collision resistance: It should be difficult to find two different
messages m1 and m2 such that hash(m1) = hash(m2). Such a
pair is called a cryptographic hash collision. This property is
sometimes referred to as strong collision resistance. It requires
a hash value at least twice as long as that required for
preimage-resistance; otherwise collisions may be found by a
birthday attack.
Digital Signatures
Message-Digest Algorithm 5 (MD5)
 Developed by Ron Rivest in 1991
 Uses 128-bit hash values
 Merkle–Damgård construction
 Still widely used in legacy applications even
though collision vulnerabilities allow forgery of
digital signatures and SSL certificates.
MD5 Collision Attack History
1. Initial attacks (2004) could only
find collisions in files that
differed only in last few bytes.
2. Early attacks (2008) used
cluster of 200 PS3s for a
couple of days.
3. Current attacks can find a
collision in seconds on single
PC.
Lesson: Cryptanalytic attacks
always improve. Change
algorithms before they do.
Secure Hash Algorithm (SHA-1)
 Developed by NSA; approved federal std by NIST
 SHA-0 (1993) and SHA-1 (1995)
 160-bit hash values
 Merkle–Damgård construction
 SHA-1 developed to correct insecurity of SHA-0
 SHA-1 still found in legacy applications
 Vulnerabilities less severe than those of MD5
 Can find SHA-1 collision in 269 operations.
 Can find SHA-0 collision in 239 operations.
SHA-2
 Developed by NSA; approved federal std by NIST
 SHA-2 (2001)
 224, 256, 384, or 512-bit hash values
 Merkle–Damgård construction
 Current recommended hash function for security
applications like digital signatures or SSL certificates.
 Cryptanalysts making progress but no breaks
 Can only find collisions if modify hash algorithm by
reducing number of rounds from 80 (SHA-512) to 46 or 64
(SHA-256) to 41.
SHA-3
 Winner of open NIST competition (2007-2012)
 Draft standard published in 2014.
 Keccak (2012)
 224, 256, 384, or 512-bit hash values.
 Concerns about NIST changes to 128- and 256-bit values
only.
 An alternative to SHA-2
 Not a replacement as SHA-2 is not broken.
 Built on sponge-function instead of Merkle–Damgård
construction like MD5, SHA-1, SHA-2 so that the same
cryptanalytic techniques will not work against SHA-3.
Random Number Generation
PRNGs are
 Statistically random, but
 Predictable.
 Given same seed, generate same sequence.
CSRNGs are
 Statistically random and not predictable.
 Seed themselves at times with random bits
from hardware (time between keystrokes,
hard drive movements, etc.)
CSC 666: Secure Software Engineering
Ivy Bridge RNG
 Added with Ivy Bridge Core iN CPUs in 2012.
 One RNG per die, not per core.
 Entropy source is thermal noise.
Random Number APIs
Windows
 rand() – insecure PRNG, uses LCG
 CryptGenRandom() – CSRNG
 CryptGenKey() – to securely generate keys
Java
 java.util.Random – insecure PRNG
 java.security.SecureRandom – CSRNG
 Relies on OS, so SecureRandom can fall
back to insecure Random if OS does not
provide /dev/random or similar
CSC
Transport Layer Security (TLS)
TLS protocol provides security features for
other protocols, such as HTTP, IMAP, etc.
1.
2.
3.
4.
Authentication of server to client.
Optional authentication of client to server.
Confidentiality of communication.
Integrity of communication.
TLS 1.0 was published in 1999.
 SSL 2.0 was first released in 1995 (insecure)
 TLS 1.2 is most recent, defined in 2008.
CSC 666: Secure Software Engineering
TLS Operation
CSC 666: Secure Software Engineering
TLS Handshake
CSC 666:
Cipher Suites
1. Key Exchange Algorithm
 Used to exchange session keys for bulk encryption algorithm.
 Examples: RSA, Diffie-Hellmann, Elliptic Curve Diffie-Hellman
2. Bulk Encryption Algorithm
 Used to encrypt message stream.
 Examples: RC4-128, Triple-DES, AES-128, AES-256
3. Message Authentication Code
 MAC is keyed hash function to ensure integrity.
 Based on MD5, SHA-1, or SHA-2, key based on master secret.
4. Pseudorandom Function
 Used to create master secret, a 48-byte secret shared with both
parties. Used to create session keys.
TLS Cipher Suite Example
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
 DHE is the Key Exchange Algorithm
 RSA for Authentication (digital signatures)
 AES is the Bulk Encryption Algorithm
 128 is the length of the keys
 CBC is the mode used for the BEA.
 SHA is the MAC algorithm used for HMAC.
Key Size and Security
Protection
Symmetric Public DiffieKey
Hellman
Elliptic
Curve
Hash
Short term against small
organizations
64
816
816
128
128
Very short term against
agencies
80
1248
1248
160
160
Short term against
agencies (10 years)
96
1776
1776
192
192
Medium term against
agencies (20 years)
112
2432
2432
224
224
Long term protection
(30 years)
128
3248
3248
256
256
Long term protection with
increased defense
against quantum
computers.
256
15424
15424
512
512
ECRYPT2 recommendations from www.keylength.com
TLS Client Test
Test browser TLS by going to
 https://www.ssllabs.com/ssltest/viewMyClient.html
 Does your browser support latest TLS version?
 Does your browser support weak cipher suites?
Check other clients by going to
 https://www.ssllabs.com/ssltest/clients.html
 Are you or your customers using any of the clients
that are missing secure TLS versions and features?
CSC 666: Secure Software Engineering
TLS Server Test
 Go to https://www.ssllabs.com/ssltest/
 Test the following servers
 www.nku.edu
 www.google.com
 A server of your own choice.
 Compare configurations with top servers
at https://www.trustworthyinternet.org/ssl-pulse/
 Discuss server configurations.
CSC 666: Secure Software Engineering
X.509 Digital Certificates
Certificate contains
 Serial number
 Identity of issuer, who produced certificate.
 Identity of subject.
 Public key of subject.
 Range of dates for which certificate is valid.
 Digital signature from issuer.
Signature means that issuer vouches that
 Public key belongs to subject, e.g.
 You really are connected to example.com.
Client has list of trusted certificate authorities (CAs)
 Client will trust certificate if it is signed by one of those CAs or if
issuer has a certificate that was signed by CA.
How Clients Use Certificates
Bulletproof SSL and TLS, Figure 3.1
Abstract Syntax Notation One
ASN.1 is standard for transporting complex data
structures over a network in a machine
independent manner with multiple coding rules:




BER: Basic Encoding Rules
DER: Distinguished Encoding Rules
PER: Packed Encoding Rules
XER: XML Encoding Rules
X.509 certificates are encoded using PEM
 PEM (Privacy Enhanced Mail) is Base64 DER
 DER is subset of BER with only one way to encode.
 http://lapo.it/asn1js/ will decode certificates.
CSC 666: Secure Software Engineering
View Certificate Exercise
Steps to View
1. Pick a HTTPS URL.
2. Click on padlock icon.
3. Select View Certificate or Certificate Info.
Questions
1. Who is the owner of the certificate?
2. Who signed the certificate?
3. When does the certificate expire?
CSC 666: Secure Software Engineering
Certificate Authorities
CA is an entity that issues digital certificates.
 Trusted 3rd party that enables public key cryptography.
 Root CA certificates embedded in browser or OS.
 Hundreds of CAs exist in dozens of countries.
CSC 666: Secure Software Engineering
Obtaining a Certificate
1. Create a public/private key pair.
 Choose appropriate algorithm and key size.
2. Create Certificate Signing Request (CSR)
 Contains public key and identity information.
 Sign CSR with applicant’s private key.
3. Send CSR to CA.
4. CA validates CSR.
 Checks that applicant matches identity.
5. CA sends certificate to applicant.
CSC 666: Secure Software Engineering
Certificate Validation
 Domain Validation (DV) certificates are issued
based on proof of control over a domain name.
 Send confirmation e-mail to one of the standard
approved e-mail addresses.
 If applicant follows link in e-mail, cert is validated.
 Organization Validation (OV) certificates
require identity and authenticity validation but
validation requirements are not consistent.
 Extended Validation (EV) certificates are
issued with standard identity and authenticity
validation procedures documented by the
CA/Browser Forum (https://cabforum.org/)
Certificate Revocation
Certificates are revoked when
 Private key is compromised or no longer in use.
 Certificate was issued to wrong entity (faulty validation).
Certificate Revocation List (CRL)
 List of serial numbers of revoked certificates that have
not yet expired.
 Can be large, so lookup can be slow.
Online Certificate Status Protocol (OCSP)
 Check revocation status of a single certificate.
 CA specifies their OCSP servers in issued certificates.
CSC 666: Secure Software Engineering
Revocation Problems
Revocation is slow
 Revocation status data is valid for 10 days.
Revocation is a blacklist technology
 CRLs were designed as a blacklist.
 OCSP was implemented as a blacklist, using CRL
data and interpreting no response as not revoked.
Libraries and command line tools don’t check
 Default configuration is not to check for revocation.
OCSP leaks information about browsing habits
 Monitor small # of OCSP servers vs entire Internet.
 OCSP stapling fixes by allowing servers to do OCSP.
CSC 666: Secure Software Engineering
PKI Incidents
 2001: VeriSign tricked into issuing two code-signing certificates to
someone claiming to represent Microsoft. Certificates not trusted by
Windows, but GUI would ask user to accept certificate from
Microsoft.
 2008: Security researcher Mike Zusman obtained certificate for
login.live.com by using a personal live.com e-mail address,
sslcertificates@live.com.
 2008: CertStar (a Comodo branch) is found to issue certificates
without any domain name validation. Tester obtains mozilla.org
cert.
 2011: Comodo resellers issue certificates for login. yahoo.com,
mail.google.com, login.skype.com, etc.
 2011: Dutch CA DigiNotar totally compromised; hundreds of
certificates issue, including *.*.com and *.*.org. Could not revoke
because did not know which certificates issued. Company’s root
certificates were revoked and DigitNotar declared bankruptcy.
PKI Weaknesses
Domain owner permission not required
 Any CA can issue a certificate for any domain.
 Do CAs issue certificates for surveillance?
Weak domain validation
 DV relies on domain ownership information from insecure
WHOIS protocol.
 Relatively easy to hijack e-mail accounts.
Some CAs have become too big to fail
 Only small CAs have been removed from root stores.
Revocation is slow and unreliable
 Revocation status data is valid for 10 days.
 Browsers interpret no OCSP response as no revocation.
Ivan Ristic’s TLS Threat Model
https://www.ssllabs.com/downloads/SSL_Threat_Model.png
Classic SSL MITM Attack
Browser
MITM
Server
Client requests TLS connection
Attacker establishes TLS
connection with client using
MITM certificate.
Attacker establishes TLS
connection with server.
Client requests data via HTTPS
Attacker decrypts client request
and forwards to server.
Client receives data from
server over SSL link with MITM.
Attacker decrypts server data
and forwards to client.
CSC 666: Secure Software Engineering
Browser Certificate Warnings
CSC 666: Secure Software Engineering
SSL Stripping MITM Attack
Browser
MITM
Server
HTTP Request
Attacker rewrites HTTPS to HTTP
Client receives page with only
HTTP links.
Client clicks on link, sending
sensitive data over HTTP
instead of HTTPS.
Attacker sends sensitive data to
site over HTTPS.
CSC 666: Secure Software Engineering
Implementation Issues
 Heartbleed (OpenSSL)
 View server memory (keys, passwords)
 https://sslimgs.xkcd.com/comics/heartbleed_explanation.png
 Goto Fail (Apple)
if ((err = SSLHashSHA1.update(&hashCtx,
&signedParams)) != 0)
goto fail;
goto fail;
 MS14-066 (Windows)
 Secure Channel flaw allowed remote code execution.
CSC 666: Secure Software Engineering
Renegotiation Attacks
CSC 666: Secure Software Engineering Bulletproof SSL and TLS, Figure 7.1
Side Channel Attacks
Compression Side Channel Attacks
 CRIME, TIME, BREACH attacks.
 Insert JavaScript malware into browser.
 Manipulate data to change compression result, then
observe diffs in compressed encrypted output.
 Allows recovery of cookies, CSRF tokens.
Lucky 13 Padding Oracle Attack




Exploits lack of integrity protection for padding.
Insert JavaScript malware into browser.
Guess bytes, modify padding to include.
8192 HTTP requests to get 1 byte of plaintext.
CSC 666: Secure Software Engineering
Certificate Pinning
Browser checks certificate against
 Trusted copy of TLS certificate or public key stored
in browser.
 Successfully detected ANSSI (French info security
agency) MITM attacks using unauthorized Google
certificates in 2013.
Pinned certificates are created by
 Preloading (Chrome comes with *.google pins).
 Loading on first connection to site.
Pinned certificates can expire based on
 Public-Key-Pins HTTP header max-age field.
 Certificate expiration date.
HSTS
HTTP Strict Transport Security (HSTS)
 Plaintext URLs rewritten to use TLS.
 All certificate errors treated as fatal.
Web sites support by using header
 Strict-Transport-Security: max-age;
includeSubDomains
Browsers (all except IE) support by
 Accepting header.
 Preloading list of HSTS sites.
Protects against SSLstrip attacks, as long as
HSTS header is not stripped in browser’s 1st
connection to site.
References
1.
2.
3.
4.
5.
6.
Brian Chess and Jacob West, Secure Programming
with Static Analysis, Addison-Wesley, 2007.
David Gourley et. Al., HTTP: The Definitive Guide,
O’Reilly, 2002.
Dafydd Stuttart and Marcus Pinto, The Web
Application Hacker’s Handbook, 2nd Edition, Wiley,
2011.
Ivan Ristic, Bulletproof SSL and TLS, Feisty Duck,
2014.
Sanctum, “HTTP Response Splitting Whitepaper,”
http://www.packetstormsecurity.org/papers/general/whi
tepaper_httpresponse.pdf, 2004.
Michael Zalewski, The Tangled Web: A Guide to
Securing Modern Web Applications, No Starch Press,
2011.
CSC 666: Secure Software Engineering