Transport Layer Security 1 Outline r Review Transport

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 1 st 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 B Host A User types ‘C’ Seq=4 2, ACK =79, d ata = ‘ ta = 3, da =4 CK 79, A C’ ‘C ’ Host ACKs receipt of ‘C’, echoes back ‘C’ Seq= Host ACKs receipt of echoed ‘C’ Seq=4 3, ACK =80 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 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 q TCP Traffic Records q TCP Port Scans q TCP Host Sweeps q SYN Flood & TCP Hijacking Attacks q TCP Applications Application TCP UDP IP Data Link Physical 11

TCP Port Scans q TCP port scan occurs when one host searches for multiple TCP services on a single host q Common scans use normal TCP-SYN q 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 q Port sweep o SYNs to ports < 1024 o Triggers when type of sweep can’t be determine q SYN port sweep o SYNs to any ports q FIN port sweep o FINs to ports < 1024 q High port sweep o SYNs to ports > 1023 o Triggers when type of sweep can’t be determined q FIN high port sweep o FINs to ports > 1023 q Null port sweep o TCPs without SYN, FIN, ACK, or RST to any port SYN/FIN can be combined; q Queso port sweep fragmented packets can be used. o FIN, SYN/FIN, and a PUSH 13

TCP Host Sweeps q A TCP host sweep occurs when one host searches for a single TCP service on multiple hosts q Common scans use normal TCP-SYN q Stealth scans q Use FIN, SYN-FIN, and null q 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 q Possible attacks similar to port scans 14

SYN Flood and TCP Hijacks q Half-Open SYN attack o Do. S-SYN flood attack o Ports 21, 23, 25, and 80 q TCP Hijacking o Access-attempt to take over a TCP session 15

TCP Intercept (Cisco Routers) Request Intercepted Connection Established Connection Transferred q TCP SYN flooding can overwhelm server and cause it to deny service, exhaust memory or waste processor cycles q TCP Intercept protects network by intercepting TCP connection requests and replying on behalf of destination q Can be configured to passively monitor TCP connection requests and respond if connection fails to get established in configurable interval 16

TCP Hijacking q TCP hijacking works by correctly guessing sequence numbers q Newer O/S’s & firewalls eliminate problem by randomizing sequence numbers q TCP Hijacking Simplex Mode o One command followed by RST 17

UDP Attacks q UDP Traffic Records q UDP Port Scan q UDP Attacks q UDP Applications Application TCP UDP IP Data Link Physical 18

UDP Attacks q UDP port scans similar to TCP ones q UDP flood (disabled) o Many UDPs to same host q UDP Bomb o UDP length < IP length q 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 q Chargen Do. S 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. DDo. S r Propagation m Active worm: from few to many m DDo. S: from many to few r Relationship m Active worm can be used for network reconnaissance, preparation for DDo. S 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 v 2 (2001) [2] – Targeted, spread via MS Windows IIS servers – Launched DDo. S 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 My. Doom (2004– 2009, TCP) [5] • Fastest spreading email worm (by some estimates) • Launched DDo. S 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 24

Conficker Worm Spread Data normalized for each country. Source: [7] 25

Scanning Strategy • Random scanning – Probes random addresses in the IP address space (CRv 2) • 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) r 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) r. Multiply (*) by V ⋅ dt and collect terms: 30

Modeling the Conficker Worm r This model’s predicted worm propagation similar to Conficker’s actual propagation Conficker’s propagation Sources: [7], Fig. 2; [8], Fig. 4 31

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) 32

SSL: Secure Sockets Layer r Widely deployed security r Original goals: protocol m Web e-commerce transactions m Supported by almost all m Encryption (especially creditbrowsers, web servers card numbers) m HTTPS m Web-server authentication m Billions $/year over SSL m Optional client authentication m Minimum hassle in doing r Variant: TLS: transport layer business with new merchants security (RFC 2246) r Available to all TCP/IP r Provides m Confidentiality m Integrity applications: secure socket API “above” TCP m Authentication 33

Toy SSL: A Simple Secure Channel r Handshake: Alice and Bob use their certificates, private keys to authenticate each other and exchange shared secret r Key Derivation: Alice and Bob use shared secret to derive set of keys r Data Transfer: data to be transferred is broken up into series of records r Connection Closure: special messages to securely close connection 34

Toy: A Simple Handshake Hello rtificate Public Key Ce KB +(MS) = EMS MS: Master Secret EMS: Encrypted Master Secret 35

Toy: Key Derivation r Considered bad to use same key for more than one cryptographic operation m Use different keys for message authentication code (MAC) and encryption r Four keys: Kc = encryption key for data sent from client to server m Mc = MAC key for data sent from client to server m Ks = encryption key for data sent from server to client m Ms = MAC key for data sent from server to client r Keys derived from key derivation function (KDF) m m Takes master secret and (possibly) some additional random data and creates the keys 36

Toy: Data Records r Why not encrypt data in constant stream as we write it to TCP? m m 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? r Instead, break stream in series of records m Each record carries a MAC m Receiver can act on each record as it arrives r Issue: in record, receiver needs to distinguish MAC from data m Want to use variable-length records Length Data MAC 37

Toy: Sequence Numbers q Problem: Attacker can capture and replay record or re-order records q Solution: Put sequence number into MAC: o o MAC = MAC(Mx, sequence||data) Note: No sequence number field q Problem: Attacker could replay all records q Solution: Use nonce 38

Toy: Control Information r Problem: Truncation attack: m Attacker forges TCP connection close segment m One or both sides thinks there is less data than there actually is. r Solution: Record types, with one type for closure m Type 0 for data; type 1 for closure r MAC = MAC(Mx, sequence||type||data) Length Type Data MAC 39

Toy SSL: Summary Hello Certificate, Nonce KB+(MS) = EMS Type 0, Seq 1, Data encrypted Type 0, Seq 2, Data 1, Type 0, Seq bob. com Data Type 0, Seq 3, Data Type 1, Seq 4, Close Type 1, Seq 2, C 40

Toy SSL Isn’t Complete r How long are fields? r Which encryption protocols? r Want negotiation? m Allow client and server to support different encryption algorithms m Allow client and server to choose together specific algorithm before data transfer 41

SSL Cipher Suite r Cipher suite m m m Public-key algorithm Symmetric encryption algorithm MAC algorithm r SSL supports several cipher suites r Negotiation: Client, server agree on cipher suite Client offers choice m Server picks one Common SSL Symmetric Ciphers § DES – Data Encryption Standard: block § 3 DES – Triple strength: block § RC 2 – Rivest Cipher 2: block § RC 4 – Rivest Cipher 4: stream SSL Public Key Encryption § RSA m 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) r Why two random nonces? r Suppose Trudy sniffs all messages between Alice & Bob r 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 m Solution: Bob sends different random nonce for each connection. This causes encryption keys to be different on the two days m Trudy’s messages will fail Bob’s integrity check m 45

SSL Record Protocol 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 Handshake: Client. Hel lo erver. Hello Handshake: S ertificate C : e k a h s d n a H o. Done erver. Hell S : e k a h s d n a H Handshake: Client. K ey. Exchange Change. Cipher. Sp ec Everything henceforth is encrypted Handshake: Finished Change. Cipher. Sp : Fin Handshake ec ished Application_data ta Application_da TCP FIN follows Alert: Warning, Close _N otify 48

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) 49

Secure Shell (SSH); Protocol Stack r r Protocol for secure network communications designed for simplicity, easy to implement (Telnet replacement) SSH client and server applications widely available for most OSes m m r 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 q Server authentication occurs at the transport layer, based on server’s public/private key pair q A server may have multiple host keys using multiple different asymmetric encryption algorithms q Multiple hosts may share the same host key q Server host key is used during key exchange to authenticate the identity of the host 51

SSH Transport Layer Protocol Packet Exchange, Formation 52

SSH Transport Layer Crypto Algorithms * = 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 Password • 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 r TCP, UDP main Internet transport layer protocols r TCP, UDP susceptible to attacks: m SYN floods m Port scans m etc. r Defenses include: m TCP intercept (routers) m Do. S prevention services (e. g. , Cloud. Flare, Prolexic) m Blacklisting attackers’ IP addresses r SSL/TLS offer transport layer security r 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/Network. Security/Net. Sec 5 e-Instructor/ (Ch. 7) 57