Presentation is loading. Please wait.

Presentation is loading. Please wait.

Transport Layer Security

Similar presentations


Presentation on theme: "Transport Layer Security"— 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 TCP Segment Structure Source port # Dest port # Application data
32 bits Application data (variable length) Sequence number Acknowledgement number Rcvr window size Ptr urgent data Checksum F S R P A U Head len Not used Options (variable length) 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 TCP Sequence Numbers & ACKs
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 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 time 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 Other UDP uses (why?):
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 # Dest port # Length (bytes) of UDP segment, including header Length Checksum 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 scan occurs when one host searches for multiple TCP services on a single host 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 Port sweep High port sweep SYN 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. 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

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

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

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

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

26 Scanning Strategy Random scanning Hitlist 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)

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

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 \frac{\mathrm{d}i(t)}{\mathrm{d}t} = \frac{rV}{N} \cdot i(t) \cdot (1 - i(t)) \noindent\text{Solution} i(t) = \frac{\exp\left\{\frac{rV}{N} \cdot t + C\right\}}{\exp\left\{\frac{rV}{N} \cdot t + C\right\} - 1}, \smallskip\\\text{\qquad where } \exp\{t\} \equiv e^t, C \text{ is constant}

30 Worm Behavior Modeling (2)
Multiply (*) by V ⋅ dt and collect terms: \Large{\underbrace{V \cdot \mathrm{d}i(t)}_\text{(1)} = \underbrace{(r \cdot i(t) \cdot V \cdot \mathrm{d}t)}_\text{(2)} \underbrace{\left( (1 - i(t)) \cdot \frac{V}{N} \right)}_\text{(3)}}\smallskip,\\ \text{where (1): infection rate among vulnerable nodes},\\\text{\quad(2): \% (infected) vulnerable nodes scanning for others, and}\\\text{\quad(3): \% vulnerable nodes that aren't yet infected}.

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
Hello Public Key Certificate KB+(MS) = EMS MS: Master Secret EMS: Encrypted Master Secret

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) Length Type Data MAC

40 Toy SSL: Summary Hello Certificate, Nonce KB+(MS) = EMS
Type 0, Seq 1, Data Type 0, Seq 2, Data Type 0, Seq 3, Data Type 1, Seq 4, Close Type 1, Seq 2, Close 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 Cipher suite SSL supports several cipher suites
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: 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 SSL Record Protocol Record Header: Content type; version; length
Data Fragment MAC Encrypted Data and MAC Record Header 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 Data and MAC encrypted (symmetric algorithm) Content
Type SSL Version Length MAC Data 1 byte 2 bytes 3 bytes Data and MAC encrypted (symmetric algorithm)

48 Real SSL connection Everything henceforth is encrypted TCP FIN follows
Handshake: ClientHello Handshake: ServerHello Handshake: Certificate Handshake: ServerHelloDone Handshake: ClientKeyExchange ChangeCipherSpec Handshake: Finished Application_data Alert: Warning, Close_Notify Real SSL connection 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, TCP IP SSH is organized as three protocols that typically run on top of TCP (Figure 6.8): • Transport Layer Protocol: Provides server authentication, data confidentiality, and data integrity with forward secrecy (i.e., if a key is compromised during one session, the knowledge does not affect the security of earlier sessions). The transport layer may optionally provide compression. • User Authentication Protocol: Authenticates the user to the server. • Connection Protocol: Multiplexes multiple logical communications channels over a single, underlying SSH connection. 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 Server authentication occurs at the transport layer, based on the server possessing a 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. In any case, the server host key is used during key exchange to authenticate the identity of the host. For this to be possible, the client must have a prior knowledge of the server’s public host key. RFC 4251 dictates two alternative trust models that can be used: 1. The client has a local database that associates each host name (as typed by the user) with the corresponding public host key. This method requires no centrally administered infrastructure and no third-party coordination. The downside is that the database of name-to-key associations may become burdensome to maintain. The host name-to-key association is certified by a trusted certification authority (CA). The client only knows the CA root key and can verify the validity of all host keys certified by accepted CAs. This alternative eases the maintenance problem, since ideally, only a single CA key needs to be securely stored on the client. On the other hand, each host key must be appropriately certified by a central authority before authorization is possible.

52 SSH Transport Layer Protocol Packet Exchange, Formation
Figure 6.9 illustrates the sequence of events in the SSH Transport Layer Protocol. First, the client establishes a TCP connection to the server. This is done via the TCP protocol and is not part of the Transport Layer Protocol. Once the connection is established, the client and server exchange data, referred to as packets, in the data field of a TCP segment.

53 SSH Transport Layer Crypto Algorithms
Table 6.3 shows the allowable options for encryption, MAC, and compression. For each category, the algorithm chosen is the first algorithm on the client’s list that is also supported by the server. * = Required ** = Recommended

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 The server may require one or more of the following authentication methods. • publickey: The details of this method depend on the public-key algorithm chosen. In essence, 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 the supplied key is acceptable for authentication and, if so, it checks whether the 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. Thus, a host that supports multiple clients would provide authentication for all its clients. This method works by having the client send a signature created with the private key of the client host. Thus, rather than directly verifying the user’s identity, the SSH server verifies the identity of the client host—and then believes the host when it says the user has already authenticated on the client side.

55 SSH Transport Layer Packet Exchanges
Figure 6.12 illustrates the basic concept behind port forwarding. We have a client application that is identified by port number x and a server application identified by port number y . At some point, the client application invokes the local TCP entity and requests a connection to the remote server on port y . The local TCP entity negotiates a TCP connection with the remote TCP entity, such that the connection links local port x to remote port y . To secure this connection, SSH is configured so that the SSH Transport Layer Protocol establishes a TCP connection between the SSH client and server entities, with TCP port numbers a and b , respectively. A secure SSH tunnel is established over this TCP connection. Traffic from the client at port x is redirected to the local SSH entity and travels through the tunnel where the remote SSH entity delivers the data to the server application on port y . Traffic in the other direction is similarly redirected. SSH supports two types of port forwarding: local forwarding and remote forwarding. Local forwarding allows the client to set up a “hijacker” process. This will intercept selected application-level traffic and redirect it from an unsecured TCP connection to a secure SSH tunnel. SSH is configured to listen on selected ports. SSH grabs all traffic using a selected port and sends it through an SSH tunnel. On the other end, the SSH server sends the incoming traffic to the destination port dictated by the client application. With remote forwarding, the user’s SSH client acts on the server’s behalf. The client receives traffic with a given destination port number, places the traffic on the correct port and sends it to the destination the user chooses. A typical example of remote forwarding is the following. You wish to access a server at work from your home computer. Because the work server is behind a firewall, it will not accept an SSH request from your home computer. However, from work you can set up an SSH tunnel using remote forwarding.

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, (Ch. 7)


Download ppt "Transport Layer Security"

Similar presentations


Ads by Google