Transport Layer Security
1
Outline
r Review: Transport Layer
r Transport Layer Attacks
r Defense Mechanisms:
m Secure Sockets Layer (SSL)/Transport Layer Security
(TLS)
m Secure Shell (SSH)
2
Transport Layers
r TCP/UDP
3
TCP
r Transport Control Protocol
r Flow control and responds to congestion
r Reliable In-order delivery
r “Nice” protocol
4
TCP Segment Structure
32 bits
URG: urgent data
(generally not used)
ACK: ACK #
valid
PSH: push data now
(generally not used)
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
Internet
checksum
(as in UDP)
Source port #
Dest port #
Sequence number
Counting bytes
of data (not
segments!)
Acknowledgement number
Head Not
UA P R S F
len used
Checksum
Rcvr window size
Ptr urgent data
Options (variable length)
# bytes
rcvr willing
to accept
Application
data
(variable length)
5
TCP Sequence Numbers & ACKs
Sequence Numbers:
m Byte stream “number” of
1st byte in segment’s
data
ACKs:
m Seq. # of next byte
expected from other side
m Cumulative ACK
Q: How does receiver handles
out-of-order segments?
m A: TCP spec doesn’t say,
up to implementer
Host A
User
types
‘C’
Host B
Host ACKs
receipt of
‘C’, echoes
back ‘C’
Host ACKs
receipt of
echoed ‘C’
time
Simple Telnet scenario
6
UDP
r No reliability, flow control, congestion control
r Sends data in a burst
r Provides multiplexing and demultiplexing of
sources
r Many multimedia applications using UDP
7
UDP: User Datagram Protocol [RFC
768]
r “No frills,” “bare bones”
Internet transport protocol
r “Best effort” service: UDP
segments may be:
m
m
Lost
Delivered out of order to app
r Connectionless:
m No handshaking between UDP
sender, receiver
m Each UDP segment handled
independently of others
Why is there a UDP?
r
r
r
r
No connection establishment
(which can add delay)
Simple: no connection state at
sender, receiver
Small segment header
No congestion control: UDP
can blast away as fast as desired
8
UDP segment structure
r Often used for streaming
32 bits
multimedia apps
m
m
loss tolerant
Rate sensitive
r Other UDP uses (why?):
m DNS
m SNMP
r Reliable transfer over UDP:
add reliability at application
layer
m
App-specific error recovery
Length
(bytes)
of UDP
segment,
including
header
Source port #
Dest port #
Length
Checksum
Application
data
(message)
UDP segment format
9
Outline
r Review: Transport Layer
r Transport Layer Attacks
r Defense Mechanisms:
m Secure Sockets Layer (SSL)/Transport Layer Security
(TLS)
m Secure Shell (SSH)
10
TCP Attacks
 TCP Traffic Records
 TCP Port Scans
 TCP Host Sweeps
 SYN Flood & TCP
Hijacking Attacks
 TCP Applications
Application
TCP
UDP
IP
Data Link
Physical
11
TCP Port Scans
 TCP port scan occurs when
one host searches for
multiple TCP services on a
single host
 Common scans use normal
TCP-SYN
 Stealth scans use
o
o
FIN, SYN-FIN, null, or
PUSH
And/or fragmented packets
T
C
P
I
P
Source Port Destination Port
Source Sequence Number
Acknowledge Sequence Num
Len Res Flags
Window
Checksum
Urgent Pointer
Ver Len Serv
Length
Identification Flg Frag Offset
TTL
TCP
Checksum
Source IP
Destination IP
12
TCP Port Scan Attacks
 Port sweep
o SYNs to ports < 1024
o Triggers when type of sweep
can’t be determine
 SYN port sweep
o SYNs to any ports
 FIN port sweep
o FINs to ports < 1024
SYN/FIN can be combined;
fragmented packets can be
used.
 High port sweep
o SYNs to ports > 1023
o Triggers when type of sweep
can’t be determined
 FIN high port sweep
o FINs to ports > 1023
 Null port sweep
o TCPs without SYN, FIN,
ACK, or RST to any port
 Queso port sweep
o FIN, SYN/FIN, and a PUSH 13
TCP Host Sweeps
 A TCP host sweep occurs
when one host searches
for a single TCP service
on multiple hosts
 Common scans use normal
TCP-SYN
 Stealth scans
 Use FIN, SYN-FIN, and null
 And/or fragmented packets
T
C
P
I
P
Source Port Destination Port
Source Sequence Number
Acknowledge Sequence Num
Len Res Flags
Window
Checksum
Urgent Pointer
Ver Len Serv
Length
Identification Flg Frag Offset
TTL
TCP
Checksum
Source IP
Destination IP
 Possible attacks similar to
port scans
14
SYN Flood and TCP Hijacks
 Half-Open SYN attack
o DoS-SYN flood attack
o Ports 21, 23, 25, and 80
 TCP Hijacking
o Access-attempt to take over a TCP session
15
TCP Intercept (Cisco Routers)
Request
Intercepted
Connection
Established
Connection Transferred
 TCP SYN flooding can overwhelm server and cause it to deny
service, exhaust memory or waste processor cycles
 TCP Intercept protects network by intercepting TCP connection
requests and replying on behalf of destination
 Can be configured to passively monitor TCP connection
requests and respond if connection fails to get established in
configurable interval
16
TCP Hijacking
 TCP hijacking works by correctly guessing
sequence numbers
 Newer O/S’s & firewalls eliminate problem
by randomizing sequence numbers
 TCP Hijacking Simplex Mode
o One command followed by RST
17
UDP Attacks
 UDP Traffic Records
 UDP Port Scan
Application
 UDP Attacks
 UDP Applications
TCP
UDP
IP
Data Link
Physical
18
UDP Attacks
 UDP port scans similar to
TCP ones
 UDP flood (disabled)
o Many UDPs to same host
 UDP Bomb
o UDP length < IP length
 Snork
U
D
P
Source Port
Length
Destination Port
Checksum
Data . . .
Ver Len Serv
Length
Identification Flg Frag Offset
I
TTL
UDP
Checksum
P
Source IP
Destination IP
o Src=135, 7, or 19; Dest=135
 Chargen DoS
o Src=7 & Dest=19
19
Active Worm vs. Virus
r Active Worm
m A program that propagates itself over a network,
reproducing itself as it goes
r Virus
m A program that searches out other programs and
infects them by embedding a copy of itself in them
20
Active Worm vs. DDoS
r Propagation
m Active worm: from few to many
m DDoS: from many to few
r Relationship
m Active worm can be used for network
reconnaissance, preparation for DDoS
21
Instances of Active Worms (1)
r Morris Worm (1988) [1]
– First active worm; took down several thousand UNIX
machines on Internet
r Code Red v2 (2001) [2]
– Targeted, spread via MS Windows IIS servers
– Launched DDoS attacks on White House, other IP addresses
r Nimda (2001, netbios, UDP) [3]
– Targeted IIS servers; slowed down Internet traffic
r SQL Slammer (2003, UDP) [4]
– Targeted MS SQL Server, Desktop Engine
– Substantially slowed down Internet traffic
r MyDoom (2004–2009, TCP) [5]
• Fastest spreading email worm (by some estimates)
• Launched DDoS attacks on SCO Group
22
Instances of Active Worms (2)
r Jan. 2007: Storm [6]
m Email attachment downloaded malware
m Infected machine joined a botnet
r Nov. 2008–Apr. 2009: Conficker [7]
m Spread via vulnerability in MS Windows servers
m Also had botnet component
r Jun.–Jul. 2009, Mar.–May 2010: Stuxnet [8–9]
m Aim: destroy centrifuges at Natanz, Iran nuclear facility
m “Escaped” into the wild in 2010
r Aug. 2011: Morto [10]
m Spread via Remote Desktop Protocol
m OSU Security shut down RDP to all OSU computers
23
How an Active Worm Spreads
r Autonomous: human interaction unnecessary
(1) Scan
(2) Probe
(3) Transfer copy
infected
machine
machine
24
Conficker Worm Spread
Data normalized for each country.
Source: [7]
25
Scanning Strategy
• Random scanning
– Probes random addresses in the IP address space (CRv2)
• Hitlist scanning
– Probes addresses from an externally supplied list
• Topological scanning
– Uses information on compromised host (Email worms,
Stuxnet)
• Local subnet scanning
– Preferentially scans targets that reside on the same subnet.
(Code Red II & Nimda)
26
Techniques for Exploiting
Vulnerabilities
r Morris Worm
m fingerd (buffer overflow)
m sendmail (bug in “debug mode”)
m rsh/rexec (guess weak passwords)
r Code Red, Nimda, etc. (buffer overflows)
r Tricking users into opening malicious email
attachments
27
Worm Exploit Techniques
r Case study: Conficker worm
m Issues malformed RPC (TCP, port 445) to Server
service on MS Windows systems
m Exploits buffer overflow in unpatched systems
m Worm installs backdoor, bot software invisibly
m Downloads executable file from server, updates
itself
r Workflow: see backup slides (1), (2)
28
Worm Behavior Modeling (1)
Propagation model mirrors epidemic:
•V:
•N:
• i(t):
•r:
total # of vulnerable nodes
size of address space
percentage of infected nodes among V
an infected node’s scanning speed
29
Worm Behavior Modeling (2)
Multiply (*) by V ⋅ dt and collect terms:
30
Modeling the Conficker Worm
This model’s predicted worm propagation similar
to Conficker’s actual propagation
Conficker’s propagation
Sources: [7], Fig. 2; [8], Fig. 4
31
Outline
Review: Transport Layer
Transport Layer Attacks
Defense Mechanisms:
Secure Sockets Layer (SSL)/Transport Layer
Security (TLS)
Secure Shell (SSH)
32
SSL: Secure Sockets Layer
Widely deployed security
protocol
Supported by almost all
browsers, web servers
HTTPS
Billions $/year over SSL
Variant: TLS: transport layer
security (RFC 2246)
Provides
Confidentiality
Integrity
Authentication
Original goals:
Web e-commerce transactions
Encryption (especially creditcard numbers)
Web-server authentication
Optional client authentication
Minimum hassle in doing
business with new merchants
Available to all TCP/IP
applications: secure socket
API “above” TCP
33
Toy SSL: A Simple Secure Channel
Handshake: Alice and Bob use their certificates,
private keys to authenticate each other and
exchange shared secret
Key Derivation: Alice and Bob use shared secret
to derive set of keys
Data Transfer: data to be transferred is broken up
into series of records
Connection Closure: special messages to securely
close connection
34
Toy: A Simple Handshake
MS: Master Secret
EMS: Encrypted Master Secret
35
Toy: Key Derivation
Considered bad to use same key for more than one
cryptographic operation
Use different keys for message authentication code (MAC) and
encryption
Four keys:
Kc = encryption key for data sent from client to server
Mc = MAC key for data sent from client to server
Ks = encryption key for data sent from server to client
Ms = MAC key for data sent from server to client
Keys derived from key derivation function (KDF)
Takes master secret and (possibly) some additional random data
and creates the keys
36
Toy: Data Records
Why not encrypt data in constant stream as we write it to
TCP?
Where would we put the MAC? If at end, no message integrity
until all data processed.
E.g., with instant messaging, how can we do integrity check over
all bytes sent before displaying?
Instead, break stream in series of records
Each record carries a MAC
Receiver can act on each record as it arrives
Issue: in record, receiver needs to distinguish MAC from
data
Want to use variable-length records
Length
Data
MAC
37
Toy: Sequence Numbers
 Problem: Attacker can capture and replay record
or re-order records
 Solution: Put sequence number into MAC:
o
o
MAC = MAC(Mx, sequence||data)
Note: No sequence number field
 Problem: Attacker could replay all records
 Solution: Use nonce
38
Toy: Control Information
Problem: Truncation attack:
Attacker forges TCP connection close segment
One or both sides thinks there is less data than there
actually is.
Solution: Record types, with one type for closure
Type 0 for data; type 1 for closure
MAC = MAC(Mx, sequence||type||data)
Length
Type
Data
MAC
39
Toy SSL: Summary
encrypted
bob.com
40
Toy SSL Isn’t Complete
How long are fields?
Which encryption protocols?
Want negotiation?
Allow client and server to support different encryption
algorithms
Allow client and server to choose together specific
algorithm before data transfer
41
SSL Cipher Suite
Cipher suite
Public-key algorithm
Symmetric encryption algorithm
MAC algorithm
Common SSL Symmetric
Ciphers
 DES – Data Encryption
Standard: block
 3DES – Triple strength: block
 RC2 – Rivest Cipher 2: block
 RC4 – Rivest Cipher 4: stream
SSL supports several cipher
suites
Negotiation: Client, server SSL Public Key Encryption
agree on cipher suite
 RSA
Client offers choice
Server picks one
42
Real SSL: Handshake (1)
Purposes:
1. Server authentication
2. Negotiation: agree on crypto algorithms
3. Establish keys
4. Client authentication (optional)
43
Real SSL: Handshake (2)
1. Client sends list of algorithms it supports, along with
2.
3.
4.
5.
6.
client nonce
Server chooses algorithms from list; sends back:
choice + certificate + server nonce
Client verifies certificate, extracts server’s public key,
generates pre_master_secret, encrypts with server’s
public key, sends to server
Client and server independently compute encryption
and MAC keys from pre_master_secret and nonces
Client sends a MAC of all the handshake messages
Server sends a MAC of all the handshake messages
Last 2 steps protect handshake from tampering
44
Real SSL: Handshake (3)
Why two random nonces?
Suppose Trudy sniffs all messages between Alice
& Bob
Next day, Trudy sets up TCP connection with
Bob, sends exact same sequence of records
Bob (Amazon) thinks Alice made two separate orders
for the same thing
Solution: Bob sends different random nonce for each
connection. This causes encryption keys to be different
on the two days
Trudy’s messages will fail Bob’s integrity check
45
SSL Record Protocol
Data
Data
Fragment
Record
Header
Encrypted
Data and MAC
Data
Fragment
MAC
Record
Header
MAC
Encrypted
Data and MAC
Record Header: Content type; version; length
MAC: includes sequence number, MAC key Mx
Fragment: each SSL fragment 214 bytes (~16 Kbytes)
46
SSL Record Format
1 byte
Content
Type
2 bytes
3 bytes
SSL Version
Length
Data
MAC
Data and MAC encrypted (symmetric algorithm)
47
Real SSL
connection
Everything
henceforth
is encrypted
TCP FIN follows
48
Outline
Review: Transport Layer
Transport Layer Attacks
Defense Mechanisms:
Secure Sockets Layer (SSL)/Transport Layer Security
(TLS)
Secure Shell (SSH)
49
Secure Shell (SSH); Protocol Stack
Protocol for secure network
communications designed for
simplicity, easy to implement
(Telnet replacement)
SSH client and server
applications widely available
for most OSes
Has become method of choice
for remote login, X tunneling
Pervasive application for
encryption technology outside
of embedded systems
SSH provides general
client/server capability: can be
used for network functions, e.g.,
file transfer, e-mail
TCP
IP
SSH Protocol Stack
50
SSH Transport Layer Protocol
 Server authentication occurs at the transport
layer, based on server’s public/private key pair
 A server may have multiple host keys using
multiple different asymmetric encryption
algorithms
 Multiple hosts may share the same host key
 Server host key is used during key exchange to
authenticate the identity of the host
51
SSH Transport Layer Protocol Packet
Exchange, Formation
payload
COMPRESS
seq #
pktl
pdl
compressed payload
ENCRYPT
padding
MAC
ciphertext
SSH Packet
pktl = packet length
pdl = padding length
52
SSH Transport Layer Crypto Algorithms
Cipher
MAC algorithm
3des-cbc*
Three-key 3DES in
CBC mode
hmac-sha1*
HMAC-SHA1; digest
length = key length = 20
blowfish-cbc
Blowfish in CBC mode
hmac-sha1-96**
First 96 bits of HMACSHA1; digest length =
12; key length = 20
twofish256-cbc
Twofish in CBC mode
with a 256-bit key
hmac-md5
HMAC-MD5; digest
length = key length = 16
twofish192-cbc
Twofish with a 192-bit
key
hmac-md5-96
First 96 bits of HMACMD5; digest length = 12;
key length = 16
twofish128-cbc
Twofish with a 128-bit
key
aes256-cbc
AES in CBC mode
with a 256-bit key
aes192-cbc
AES with a 192-bit key
none*
No compression
aes128-cbc**
AES with a 128-bit key
zlib
Defined in RFC 1950
and RFC 1951
Serpent256-cbc
Serpent in CBC mode
with a 256-bit key
Serpent192-cbc
Serpent with a 192-bit
key
Serpent128-cbc
Serpent with a 128-bit
key
arcfour
RC4 with a 128-bit key
cast128-cbc
CAST-128 in CBC
mode
Compression algorithm
* = Required
** = Recommended
53
Authentication Methods
Publickey
• The client sends a message to the server that contains the client’s public key,
with the message signed by the client’s private key
• When the server receives this message, it checks whether supplied key is
acceptable for authentication; if yes, it checks whether signature is correct
Passwor
d
• The client sends a message containing a plaintext password, which is
protected by encryption by the Transport Layer Protocol
Hostbased
• Authentication is performed on the client’s host rather than the client itself
• This method works by having the client send a signature created with the
private key of the client host
• Rather than directly verifying the user’s identity, the SSH server verifies the
identity of the client host
54
SSH Transport Layer Packet Exchanges
55
Final Remarks
TCP, UDP main Internet transport layer protocols
TCP, UDP susceptible to attacks:
SYN floods
Port scans
etc.
Defenses include:
TCP intercept (routers)
DoS prevention services (e.g., CloudFlare, Prolexic)
Blacklisting attackers’ IP addresses
SSL/TLS offer transport layer security
SSH enables secure authentication (transport layer)
56
Acknowledgment
The slides are partially based on:
J.F. Kurose and K.W. Ross, Computer Networking: A Top-Down
Approach Featuring the Internet, Addison Wesley, 2011
L. Ronnau, “Securing Routers Against Hackers and Denial of
Service Attacks,” https://infosec.ufl.edu/itsa/attacks-ronnau.ppt
W. Stallings, Network Security Essentials, Pearson, 2014,
http://williamstallings.com/NetworkSecurity/NetSec5e-Instructor/
(Ch. 7)
57