1 / 57

Transport Layer Security

Transport Layer Security. Outline. Review: Transport Layer Transport Layer Attacks Defense Mechanisms: Secure Sockets Layer (SSL)/Transport Layer Security (TLS) Secure Shell (SSH). Transport Layers. TCP/UDP. TCP. Transport Control Protocol Flow control and responds to congestion

frye
Télécharger la présentation

Transport Layer Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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. 32 bits Source port # Destport # Sequence number Acknowledgement number Head len Not used Rcvr window size U A P R S F Checksum Ptrurgent data Options (variable length) Application data (variable length) TCP Segment Structure URG: urgent data (generally not used) Counting bytes of data (not segments!) ACK: ACK # valid PSH: push data now (generally not used) # bytes rcvr willing to accept RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP)

  6. time 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 B Host A User types ‘C’ Seq=42, ACK=79, data = ‘C’ Host ACKs receipt of ‘C’, echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ Host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 Simple 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 32 bits Source port # Destport # Length (bytes) of UDP segment, including header Checksum Length Application data (message) UDP segment format

  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 Application TCP TCP UDP IP Data Link Physical

  12. TCP Port Scans • TCP port scanoccurs when one host searches for multiple TCP services on a singlehost • Common scans use normal TCP-SYN • Stealth scans use • FIN, SYN-FIN, null, or PUSH • And/or fragmented packets T C P Source Port Destination Port Source Sequence Number Acknowledge Sequence Num Len Res Flags Window Checksum Urgent Pointer I P Ver Len Serv Length Identification Flg Frag Offset TTL TCP Checksum Source IP Destination IP

  13. TCP Port Scan Attacks • High port sweep • SYNs to ports > 1023 • Triggers when type of sweep can’t be determined • FIN high port sweep • FINs to ports > 1023 • Null port sweep • TCPs without SYN, FIN, ACK, or RST to any port • Queso port sweep • FIN, SYN/FIN, and a PUSH • Port sweep • SYNs to ports < 1024 • Triggers when type of sweep can’t be determine • SYN port sweep • SYNs to any ports • FIN port sweep • FINs to ports < 1024 • SYN/FIN can be combined; fragmented packets can be used.

  14. TCP Host Sweeps • A TCP host sweepoccurs 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 T C P Source Port Destination Port Source Sequence Number Acknowledge Sequence Num Len Res Flags Window Checksum Urgent Pointer I P Ver Len Serv Length Identification Flg Frag Offset TTL TCP Checksum Source IP Destination IP

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

  16. 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

  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 • One command followed by RST

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

  19. UDP Attacks • UDP port scans similar to TCP ones • UDP flood (disabled) • Many UDPs to same host • UDP Bomb • UDP length < IP length • Snork • Src=135, 7, or 19; Dest=135 • ChargenDoS • Src=7 & Dest=19 U D P Source Port Destination Port Length Checksum Data . . . I P Ver Len Serv Length Identification Flg Frag Offset TTL UDP Checksum Source IP Destination IP

  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

  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

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

  23. 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

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

  25. Conficker Worm Spread 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 (Email worms, Stuxnet) • Local subnet scanning • Preferentially scans targets that reside on the same subnet. (Code Red II & Nimda)

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

  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)

  29. Worm Behavior Modeling (1) • Propagation model mirrors epidemic: • 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:

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

  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 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 credit-card 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

  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: • MAC = MAC(Mx, sequence||data) • 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) Data Length Type MAC

  40. Hello Certificate, Nonce KB+(MS) = EMS Type 0, Seq1, Data Type 0, Seq2, Data Type 0, Seq1, Data Type 0, Seq3, Data Type 1, Seq4, Close Type 1, Seq2, Close Toy SSL: Summary bob.com encrypted

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

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

  44. Real SSL: Handshake (2) • Client sends list of algorithms it supports, along with 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

  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. Data Data Fragment MAC Data Fragment MAC Record Header Encrypted Data and MAC Record Header Encrypted Data and MAC SSL Record Protocol Record Header: Content type; version; length MAC: includes sequence number, MAC key Mx Fragment: each SSL fragment 214 bytes (~16 Kbytes)

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

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

  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

More Related