More on SSL/TLS
Internet security: TLS
 TLS is one of the more prominent internet security
protocols.
 Transport-level on top of TCP
 Good example of practical application of cryptography
 End-to-end protocol: it secures communication from
originating client to intended server destination
 No need to trust intermediaries
 Has API which is similar to “socket” interface used for
normal network programming.
 So fairly easy to use.
Threats
 Eavesdropping?
 Encrypts communication
 Manipulation (such as injection or MITM attacks)?
 Guarantees integrity through use of a MAC
 (Also avoids replay attacks this way)
 Impersonation?
 Uses signatures
 Availability?
 Well, no. (This is the internet.)
SSL/TSL
 SSL = Secure Sockets Layer (the old version)
 TLS = Transport Layer Security (current standard)
 Terms are often used interchangeably at this point
SSL/TLS In Network Layering
 Big picture: Add security to ANY application that uses TCP
7
Application
7
Application
7
SSL / TLS
4
Transport
4
Transport (TCP)
3
(Inter)Network
3
(Inter)Network
2
Link
2
Link
1
Physical
1
Physical
Normal webbrowsing
Regular web surfing - http: URL
But if we click here …
TLS adds the “s” to https
Web surfing with TLS/SSL - https: URL
Note: Amazon makes sure that all of
these images, etc., are now also fetched
via https: URLs.
Doing so gives the web page full integrity,
in keeping with end-to-end security.
(Browsers do not provide this “promotion”
automatically.)
How connection starts
HTTPS Connection (SSL / TLS)
Amazon
Server
 • The
client (browser)
connects
Browser
(client) connects
via Browser
via
TCPtotoAmazon’s
https serverHTTPS server
TCP
 Client picks 256-bit random
• number
Client picks
random
RB and256-bit
sends along
a
number
RB, sends
list
of supported
cryptoover list of
crypto itprotocols
options
supports it supports
 • Server
picks
256-bitrandom
Serverthen
picks
256-bit
random number RS and picks
number R , selects protocols to
the protocolS
use for this session
 Server sends certificate
Server
sends
its certificate
 • Client
must
thenover
validate
certificate
• (all of this is in the clear)
 Note: all of this is in cleartext
• Client now validates cert
S YN
SYN A
CK
AC K
Hell
o
(TLS . My rn
d
(SSL +RSA+A # = RB .
I
+RS
E
A+3 S128+S suppor
t
DES
+MD HA1) or
5) or
…
t’s use
e
L
.
1
# = RS
d
n
r
8+SHA
y
2
1
M
S
E
SA+A
TLS+R
y cert
m
s
’
e
r
He
ta
a
d
f
KB o
3
2
~
Next:
HTTPS Connection (SSL / TLS), conʼt
 Assuming RSA is chosen, client
Amazon
• Fornext
RSA,
browseraconstructs
long
constructs
longer (368Browser
Server
(368
“Premaster
Secret”
bit)bits)
“premaster
secret”
PS PS
y cert
m
s
’
e
Her
The value
PS is
• Browser
sends
PSencrypted
encrypted using
at a
d
f
o
using thepublic
server’s
public
Amazon’s
RSA
key key
KAmazon
KB
3
2
~

Then
using
PS,
R
,
and
R
,
S
PS
• Using PS, RB, and BRS, browser
&
{PS}
K Amazon
bothderive
sides can
derive
server
symm.
cipher keys
keys
and MAC
(CBsymmetric
, CS) & MAC
integrity
keys (IB, IS)
PS
keys
pairs,
one
– integrity
One pair to
use(two
in each
direction
for each direction)
 Actually, these 3 values seed a
pseudo-random number
generator, which allows client
and server to repeatedly query
And final bits…
HTTPS Connection (SSL / TLS), conʼt
 The client
and
server
exchange
• For
RSA,
browser
constructs long
(368 bits)over
“Premaster
MACs computed
the Secret” PS
dialog so
far
• Browser
sends PS encrypted using
Amazon’s
RSAthe
key KAmazon
 If it’s a good
MAC,public
you see
PS
• Using
PS,browser
RB, and RS, browser &
little lock
in your
server derive symm. cipher keys
 All traffic(C
is now
encrypted
B, CS) & MAC integrity keys (IB, IS)
with symmetric
protocol
– One pair
to use in each direction
(generally
AES) & server exchange MACs
• Browser
computed
over
entire dialog so far
 Messages
are also
numbered
to stop
attacks
• If replay
good MAC,
Browser displays
• All subsequent communication
encrypted w/ symmetric cipher (e.g.,
AES128) cipher keys, MACs
– Messages also numbered to thwart
replay attacks
Amazon
Server
Browser
my c
Here’s
ert
da ta
f
o
KB
~ 2-3
{P S }
KA
mazon
M AC
( d i a lo
g,IB )
,I S)
g
o
l
a
i
d
M AC (
{M , M
1
AC (M
1 ,I
B )}C
B
,I S)} C S
M
2
(
C
, MA
{M 2
PS
Or, with Diffie-Hellman
Alternative: Key Exchange via Diffie-Hellman
• For Diffie-Hellman, server
 Server
insteadrandom
generates
a
generates
a, sends
public
params
andsends
ga mod
random
a, and
ga pmod p
t
my cer
s
’
e
r
e
H
– Signed with server’s public key
 Signed with server’s public key
• Browser
signature
 Client
verifiesverifies
and then
• Browser
generates
random b,
generates
b and
sense the
= gab mod p, sends
valuecomputes
gb mod bPS
over
to server
 Both sides can then compute
also
PS•=Server
gab mod
p computes
ab
PS = g mod p
 Communication is then the
• Remainder is as before: from PS,
same
– from PS, RB, and RS,
RB, and RS, browser
& server
bothderive
sides symm.
get cipher
keys
and
cipher
keys
(CB, CS)
integrity
keys.integrity keys (IB, IS),
and MAC
etc…
Amazon
Server
Browser
PS
da ta
f
o
KB
~2 -3
-1 azon
Am
}
K
p
a m od
{g , p, g
g b m od
MAC
(dialo
p
g,IB )
,I S)
g
o
l
a
i
d
MA C(
{M , M
1
A C (M
1 ,I
B )}C
B
PS
…
But wait…
 I glossed over that bit about validating a certificate!
 A certificate is a signed statement about someone else’s
public key.
 Note: Doesn’t say anything about who gave you that public
key! It just states that a given public key belongs to “Bob”,
and verifies this with a digital signature made from a
different key/pair – say from “Alice”
 Bob can then prove who he is when you send him
something, since the only way to read it is to BE him
 However, you have to trust Alice! She is basically
testifying that this is Bob’s key.
The server’s certificate
 Inside the certificate is:
 Domain name associated with certificate (such as
amazon.com)
 The public key (e.g. 2048 bits for RSA)
 A bunch of other info
 Physical address
 Type of certificate, etc.
 Name of certificate’s issuer (often Verisign)
 Optional URL to revocation center for checking if a certificate
has been revoked
 A public key signature of a hash (SHA-1) of all this, made
using the issuer’s private key (we’ll call this S)
How to validate
 The client compares domain name in certificate with URL
 Client accesses a separate certificate belonging to the
issuer
 These are hardwired into client, so are trusted.
 The client applies the issuer’s public key to verify S and get
hash of what issuer signed.
 Then compare with its own SHA-1 hash of Amazon’s
certificate.
 Assume the hashes match, now have high confidence we
are talking to valid server
 Assuming that the issuer can be trusted!
What can we catch?
 If attacker captures our traffic (maybe using wifi sniffer
and breaking our inadequate WEP security protocol)
 No problem: communication is encrypted by us.
 What about DNS cache poisoning?
 No problem: client goes to wrong server, but is able to detect
the impersonation.
 What if the attacker hijacks connection and injects new
traffic (MITM style)?
 No problem: they can’t read our traffic, so can’t really inject!
Can’t even do a replay.
 And so on – this blocks most common attacks.
But what if can’t get a certificate?
No certificate found
 Well, if one is not found, most browsers will warn the user
that the connection is unverified.
 You can still proceed – but authentication is missing from the
protocol now!
 What security do we still have here?
 We lose everything! The attacker who hijacked can read,
modify, and impersonate.
 Note that OTHER attackers are still blocked, but the other
end is not verified here.
Some limitations
 Cost of public-key cryptography: Takes non-trivial CPU
processing (fairly minor)
 Hassel of buying and maintaining certificates (again fairly
minor these days)
 DoS amplificaiton: The client can effectively force the
server to do public key operations.
 Need to integrate with other sites not using HTTPS.
 Latency (the real issue):
 Extra round trips mean pages take longer to load.
Additional limitations
 TCP level denial of service can still be an issue
 SYN flooding
 RST injection
 Etc.
 SQL injection or XSS or server side code issues are still a
potential problem.
 Other vulnerabilities in the browser code.
 Any flaws in crypto protocols.
 User flaws (the big one): weak passwords, phishing, etc.
Example:
Regular web surfing - http: URL
So no integrity - a MITM
attacker can alter pages
returned by server …
And when we click here …
… attacker has changed the corresponding link so
that it’s ordinary http rather than https!
We never get a chance to use TLS’s protections! :-(
“sslstrip” attack
Another:
Another:
Cont:
Next:
And:
And finally, OK:
What do most users see?
The equivalent as seen by most Internet users:
 Note: This is a real windows message!
 Far too many just click “yes”.
(note: an actual Windows error message!)