Presentation is loading. Please wait.

Presentation is loading. Please wait.

Transport Layer Security 1. Outline r Review: Transport Layer r Transport Layer Attacks r Defense Mechanisms: m Secure Sockets Layer (SSL)/Transport Layer.

Similar presentations


Presentation on theme: "Transport Layer Security 1. Outline r Review: Transport Layer r Transport Layer Attacks r Defense Mechanisms: m Secure Sockets Layer (SSL)/Transport Layer."— Presentation transcript:

1 Transport Layer Security 1

2 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

3 Transport Layers r TCP/UDP 3

4 TCP r Transport Control Protocol r Flow control and responds to congestion r Reliable In-order delivery r “Nice” protocol 4

5 TCP Segment Structure Source port # Dest port # 32 bits Application data (variable length) Sequence number Acknowledgement number Rcvr window size Ptr urgent data Checksum F SR PAU Head len Not used 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 willing to accept Counting bytes of data (not segments!) Internet checksum (as in UDP) 5

6 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 A Host B Seq=42, ACK=79, data = ‘C’ Seq=79, ACK=43, data = ‘C’ Seq=43, ACK=80 User types ‘C’ Host ACKs receipt of echoed ‘C’ Host ACKs receipt of ‘C’, echoes back ‘C’ time Simple Telnet scenario 6

7 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

8 UDP: User Datagram Protocol [RFC 768] r “No frills,” “bare bones” Internet transport protocol r “Best effort” service: UDP segments may be: m Lost m 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 No connection establishment (which can add delay) r Simple: no connection state at sender, receiver r Small segment header r No congestion control: UDP can blast away as fast as desired 8

9 UDP segment structure r Often used for streaming multimedia apps m loss tolerant m 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 Source port #Dest port # 32 bits Application data (message) UDP segment format Length Checksum Length (bytes) of UDP segment, including header 9

10 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

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 11

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 TTLTCPChecksum IdentificationFlgFrag Offset VerLenServLength IPIP TCPTCP Source Port Source Sequence Number Acknowledge Sequence Num LenResWindowFlags ChecksumUrgent Pointer Destination Port 12

13 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

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 TTLTCPChecksum IdentificationFlgFrag Offset VerLenServLength IPIP TCPTCP Source Port Source Sequence Number Acknowledge Sequence Num LenResWindowFlags ChecksumUrgent Pointer Destination Port 14

15 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

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 16

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 Mode o One command followed by RST 17

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

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  Snork o Src=135, 7, or 19; Dest=135  Chargen DoS o Src=7 & Dest=19 UDPUDP Source Port LengthChecksum Destination Port Data... Destination IP Source IP TTLUDPChecksum IdentificationFlgFrag Offset VerLenServLength IPIP 19

20 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

21 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

22 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 worm (by some estimates) Launched DDoS attacks on SCO Group 22

23 Instances of Active Worms (2)  Jan. 2007: Storm [6]  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

24 How an Active Worm Spreads  Autonomous: human interaction unnecessary 24 infected machine (1) Scan (2) Probe (3) Transfer copy

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

26 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 ( worms, Stuxnet) Local subnet scanning – Preferentially scans targets that reside on the same subnet. (Code Red II & Nimda) 26

27 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 attachments 27

28 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

29 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

30 Worm Behavior Modeling (2)  Multiply (*) by V ⋅ dt and collect terms: 30

31 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 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

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

34 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

35 Toy: A Simple Handshake MS: Master Secret EMS: Encrypted Master Secret Hello Public Key Certificate K B + (MS) = EMS 35

36 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: m K c = encryption key for data sent from client to server m M c = MAC key for data sent from client to server m K s = encryption key for data sent from server to client m M s = MAC key for data sent from server to client r Keys derived from key derivation function (KDF) m Takes master secret and (possibly) some additional random data and creates the keys 36

37 Toy: Data Records r Why not encrypt data in constant stream as we write it to TCP? m Where would we put the MAC? If at end, no message integrity until all data processed. m 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 LengthDataMAC 37

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

39 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(M x, sequence||type||data) LengthType Data MAC 39

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

41 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

42 SSL Cipher Suite r Cipher suite m Public-key algorithm m Symmetric encryption algorithm m MAC algorithm r SSL supports several cipher suites r Negotiation: Client, server agree on cipher suite m Client offers choice m 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 42

43 Real SSL: Handshake (1) Purposes: 1. Server authentication 2. Negotiation: agree on crypto algorithms 3. Establish keys 4. Client authentication (optional) 43

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 messages Last 2 steps protect handshake from tampering 44

45 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 m 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 45

46 SSL Record Protocol Data Fragment Data Fragment MAC Encrypted Data and MAC Encrypted Data and MAC Record Header Record Header Record Header: Content type; version; length MAC: includes sequence number, MAC key M x Fragment: each SSL fragment 2 14 bytes (~16 Kbytes) 46

47 SSL Record Format Content Type SSL Version Length MAC Data 1 byte 2 bytes3 bytes Data and MAC encrypted (symmetric algorithm) 47

48 Real SSL connection Handshake: ClientHello Handshake: ServerHello Handshake: Certificate Handshake: ServerHelloDone Handshake: ClientKeyExchange ChangeCipherSpec Handshake: Finished ChangeCipherSpec Handshake: Finished Application_data Alert: Warning, Close_Notify TCP FIN follows Everything henceforth is encrypted 48

49 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

50 Secure Shell (SSH); Protocol Stack r Protocol for secure network communications designed for simplicity, easy to implement (Telnet replacement) r SSH client and server applications widely available for most OSes m Has become method of choice for remote login, X tunneling m Pervasive application for encryption technology outside of embedded systems r SSH provides general client/server capability: can be used for network functions, e.g., file transfer, TCP IP SSH Protocol Stack 50

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 51

52 SSH Transport Layer Protocol Packet Exchange, Formation 52

53 * = Required ** = Recommended SSH Transport Layer Crypto Algorithms 5353

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 Passwor d 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 54

55 SSH Transport Layer Packet Exchanges 55

56 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 DoS prevention services (e.g., CloudFlare, Prolexic) m Blacklisting attackers’ IP addresses r SSL/TLS offer transport layer security r SSH enables secure authentication (transport layer) 56

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.ppthttps://infosec.ufl.edu/itsa/attacks-ronnau.ppt W. Stallings, Network Security Essentials, Pearson, 2014, (Ch. 7) 57


Download ppt "Transport Layer Security 1. Outline r Review: Transport Layer r Transport Layer Attacks r Defense Mechanisms: m Secure Sockets Layer (SSL)/Transport Layer."

Similar presentations


Ads by Google