1
Transport Layer Security
2
Outline
Review: Transport Layer Transport Layer Attacks Defense Mechanisms:
Secure Sockets Layer (SSL)/Transport Layer Security (TLS)
Secure Shell (SSH)
3
Transport Layers
TCP/UDP
4
TCP
Transport Control Protocol Flow control and responds to congestion Reliable In-order delivery “Nice” protocol
5
TCP Segment Structure
Source port # Dest port #
32 bits
Applicationdata
(variable length)
Sequence number
Acknowledgement number
Rcvr window size
Ptr urgent dataChecksum
FSRPAUHeadlen
Notused
Options (variable length)
URG: urgent data (generally not used)
ACK: ACK #valid
PSH: push data now(generally not used)
RST, SYN, FIN:connection estab(setup, teardown
commands)
# bytes rcvr willingto accept
Counting bytes of data (not segments!)
Internetchecksum
(as in UDP)
6
TCP Sequence Numbers & ACKs
Sequence Numbers: Byte stream “number” of
1st byte in segment’s data
ACKs: Seq. # of next byte
expected from other side Cumulative ACK
Q: How does receiver handles out-of-order segments? A: TCP spec doesn’t say,
up to implementer
Host A Host B
Seq=42, ACK=79, data = ‘C’
Seq=79, ACK=43, data = ‘C’
Seq=43, ACK=80
Usertypes‘C’
Host ACKsreceipt of
echoed ‘C’
Host ACKsreceipt of
‘C’, echoesback ‘C’
timeSimple Telnet scenario
7
UDP
No reliability, flow control, congestion control Sends data in a burst Provides multiplexing and demultiplexing of
sources Many multimedia applications using UDP
8
UDP: User Datagram Protocol [RFC 768]
“No frills,” “bare bones” Internet transport protocol
“Best effort” service: UDP segments may be: Lost Delivered out of order to app
Connectionless: No handshaking between UDP
sender, receiver Each UDP segment handled
independently of others
Why is there a UDP? 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
9
UDP segment structure
Often used for streaming multimedia apps loss tolerant Rate sensitive
Other UDP uses (why?): DNS SNMP
Reliable transfer over UDP: add reliability at application layer App-specific error recovery
Source port # Dest port #
32 bits
Applicationdata
(message)
UDP segment format
Length ChecksumLength (bytes) of UDP
segment,including
header
10
Outline
Review: Transport Layer Transport Layer Attacks Defense Mechanisms:
Secure Sockets Layer (SSL)/Transport Layer Security (TLS)
Secure Shell (SSH)
11
TCP Attacks
TCP Traffic Records TCP Port Scans TCP Host Sweeps SYN Flood & TCP
Hijacking Attacks TCP Applications
Application
TCP
IP
Data Link
Physical
UDPTCP
Application
12
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 FIN, SYN-FIN, null, or
PUSH o And/or fragmented packets
Destination IP
Source IP
TTL TCP Checksum
Identification Flg Frag Offset
Ver Len Serv Length
IP
TCP
Source Port
Source Sequence Number
Acknowledge Sequence Num
Len Res WindowFlags
Checksum Urgent Pointer
Destination Port
13
TCP Port Scan Attacks
Port sweepo SYNs to ports < 1024
o Triggers when type of sweep can’t be determine
SYN port sweepo SYNs to any ports
FIN port sweepo FINs to ports < 1024
SYN/FIN can be combined; fragmented packets can be used.
High port sweepo SYNs to ports > 1023o Triggers when type of sweep
can’t be determined
FIN high port sweepo FINs to ports > 1023
Null port sweepo TCPs without SYN, FIN,
ACK, or RST to any port
Queso port sweepo FIN, SYN/FIN, and a PUSH
14
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
Possible attacks similar to port scans
Destination IP
Source IP
TTL TCP Checksum
Identification Flg Frag Offset
Ver Len Serv Length
IP
TCP
Source Port
Source Sequence Number
Acknowledge Sequence Num
Len Res WindowFlags
Checksum Urgent Pointer
Destination Port
15
SYN Flood and TCP Hijacks
Half-Open SYN attacko DoS-SYN flood attacko Ports 21, 23, 25, and 80
TCP Hijackingo Access-attempt to take over a TCP session
16
TCP Intercept (Cisco Routers)
Connection Transferred
Connection Established
Request Intercepted
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
17
TCP Hijacking
TCP hijacking works by correctly guessing sequence numbers
Newer O/S’s & firewalls eliminate problem by randomizing sequence numbers
TCP Hijacking Simplex Modeo One command followed by RST
18
UDP Attacks
UDP Traffic Records UDP Port Scan UDP Attacks UDP Applications
Application
TCP
IP
Data Link
Physical
UDPTCP
Application
19
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
Snorko Src=135, 7, or 19; Dest=135
Chargen DoSo Src=7 & Dest=19
UDP
Source Port
Length Checksum
Destination Port
Data . . .
Destination IP
Source IP
TTL UDP Checksum
Identification Flg Frag Offset
Ver Len Serv Length
IP
Active Worm vs. Virus
Active Worm A program that propagates itself over a network,
reproducing itself as it goes Virus
A program that searches out other programs and infects them by embedding a copy of itself in them
20
Active Worm vs. DDoS
Propagation Active worm: from few to many DDoS: from many to few
Relationship Active worm can be used for network
reconnaissance, preparation for DDoS
21
Instances of Active Worms (1)
Morris Worm (1988) [1]– First active worm; took down several thousand UNIX
machines on Internet Code Red v2 (2001) [2]
– Targeted, spread via MS Windows IIS servers– Launched DDoS attacks on White House, other IP addresses
Nimda (2001, netbios, UDP) [3]– Targeted IIS servers; slowed down Internet traffic
SQL Slammer (2003, UDP) [4]– Targeted MS SQL Server, Desktop Engine– Substantially slowed down Internet traffic
MyDoom (2004–2009, TCP) [5]• Fastest spreading email worm (by some estimates)• Launched DDoS attacks on SCO Group
22
Instances of Active Worms (2)
Jan. 2007: Storm [6] Email attachment downloaded malware Infected machine joined a botnet
Nov. 2008–Apr. 2009: Conficker [7] Spread via vulnerability in MS Windows servers Also had botnet component
Jun.–Jul. 2009, Mar.–May 2010: Stuxnet [8–9] Aim: destroy centrifuges at Natanz, Iran nuclear facility “Escaped” into the wild in 2010
Aug. 2011: Morto [10] Spread via Remote Desktop Protocol OSU Security shut down RDP to all OSU computers
23
How an Active Worm Spreads
Autonomous: human interaction unnecessary
24
infected machine machine
(1) Scan
(2) Probe
(3) Transfer copy
Conficker Worm Spread
25
Data normalized for each country.
Source: [7]
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 Morris Worm
fingerd (buffer overflow) sendmail (bug in “debug mode”) rsh/rexec (guess weak passwords)
Code Red, Nimda, etc. (buffer overflows) Tricking users into opening malicious email
attachments
27
Worm Exploit Techniques
Case study: Conficker worm Issues malformed RPC (TCP, port 445) to Server
service on MS Windows systems Exploits buffer overflow in unpatched systems Worm installs backdoor, bot software invisibly Downloads executable file from server, updates
itself Workflow: see backup slides (1), (2)
28
Worm Behavior Modeling (1)
Propagation model mirrors epidemic:
29
• V : total # of vulnerable nodes• N : size of address space• i(t): percentage of infected nodes among V• r : an infected node’s scanning speed
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
31
Sources: [7], Fig. 2; [8], Fig. 4
Conficker’s propagation
32
Outline
Review: Transport Layer Transport Layer Attacks Defense Mechanisms:
Secure Sockets Layer (SSL)/Transport Layer Security (TLS)
Secure Shell (SSH)
33
SSL: Secure Sockets LayerWidely deployed security
protocol Supported by almost all
browsers, web servers HTTPS Billions $/year over SSL
Variant: TLS: transport layer security (RFC 2246)
ProvidesConfidentialityIntegrityAuthentication
Original goals: Web e-commerce transactions Encryption (especially credit-
card numbers) Web-server authentication Optional client authentication Minimum hassle in doing
business with new merchantsAvailable to all TCP/IP
applications: secure socket API “above” TCP
34
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
35
Toy: A Simple Handshake
MS: Master Secret
EMS: Encrypted Master Secret
Hello
Public Key Certificate
KB+(MS) = EMS
36
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
37
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
38
Toy: Sequence Numbers
Problem: Attacker can capture and replay record or re-order records
Solution: Put sequence number into MAC:o MAC = MAC(Mx, sequence||data)o Note: No sequence number field
Problem: Attacker could replay all records Solution: Use nonce
39
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
40
Toy SSL: Summary
Hello
Certificate, Nonce
KB+(MS) = EMS
Type 0, Seq 1, DataType 0, Seq 2, Data
Type 0, Seq 1, Data
Type 0, Seq 3, Data
Type 1, Seq 4, Close
Type 1, Seq 2, Close
encr
ypte
d
bob.com
41
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
42
SSL Cipher Suite
Cipher suite Public-key algorithm Symmetric encryption algorithm MAC algorithm
SSL supports several cipher suites
Negotiation: Client, server agree on cipher suite Client offers choice Server picks one
Common SSL Symmetric Ciphers DES – Data Encryption
Standard: block 3DES – Triple strength: block RC2 – Rivest Cipher 2: block RC4 – Rivest Cipher 4: stream
SSL Public Key Encryption RSA
43
Real SSL: Handshake (1)
Purposes:
1. Server authentication
2. Negotiation: agree on crypto algorithms
3. Establish keys
4. Client authentication (optional)
44
Real SSL: Handshake (2)
1. Client sends list of algorithms it supports, along with client nonce
2. Server chooses algorithms from list; sends back: choice + certificate + server nonce
3. Client verifies certificate, extracts server’s public key, generates pre_master_secret, encrypts with server’s public key, sends to server
4. Client and server independently compute encryption and MAC keys from pre_master_secret and nonces
5. Client sends a MAC of all the handshake messages
6. Server sends a MAC of all the handshake messagesLast 2 steps protect handshake from tampering
45
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
46
SSL Record Protocol
Data
Data Fragment
Data Fragment
MAC MAC
EncryptedData and MAC
EncryptedData and MAC
RecordHeader
RecordHeader
Record Header: Content type; version; length
MAC: includes sequence number, MAC key Mx
Fragment: each SSL fragment 214 bytes (~16 Kbytes)
47
SSL Record Format
ContentType SSL Version Length
MAC
Data
1 byte 2 bytes 3 bytes
Data and MAC encrypted (symmetric algorithm)
48
Real SSLconnection
Handshake: ClientHello
Handshake: ServerHello
Handshake: Certificate
Handshake: ServerHelloDone
Handshake: ClientKeyExchangeChangeCipherSpec
Handshake: Finished
ChangeCipherSpec
Handshake: Finished
Application_data
Application_data
Alert: Warning, Close_NotifyTCP FIN follows
Everythinghenceforth
is encrypted
49
Outline
Review: Transport Layer Transport Layer Attacks Defense Mechanisms:
Secure Sockets Layer (SSL)/Transport Layer Security (TLS)
Secure Shell (SSH)
50
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
51
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
52
SSH Transport Layer Protocol Packet Exchange, Formation
* = Required** = Recommended
SSH Transport Layer Crypto Algorithms
53
54
Authentication Methods
• 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
Publickey
• The client sends a message containing a plaintext password, which is protected by encryption by the Transport Layer Protocol
Password
• 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
Hostbased
55
SSH Transport Layer Packet Exchanges
56
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)
57
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)