Network Security

• Network Security: Overview
• details about TLS
• Anonymous Communications
• TOR

A better Internet?

• in-class discussion: is it possible to redesign the Internet to avoid at least some of the antisocial behavior in today's Internet?
• without breaking what has made the Internet as successful as it is?

Network Security

• Alice and Bob are trying to communicate securely, Charlie wishes to do all sorts of mischief
• for example, if Charlie is the man in the middle, he can read all the messages between Alice and Bob, maybe remove some or all of them, and perhaps add his own
• this might be accomplished by owning or subverting a router, or with other tricks including ARP spoofing or DNS spoofing
• in theory, encryption protects the contents, authentication guarantees that the sender is a machine with the correct key
• as long as the correct public key is known, Public-Key Encryption works well (but slowly)
• in practice, applications have vulnerabilities:
  • array overflow (e.g. heartbleed) or stack overflow
  • being tricked into executing code or SQL commands (shellshock)
  • being designed for a different (e.g., secure) environment
  • not being secure against random or malicious inputs (shellshock)
• once the attacker can execute some code on a machine, privilege escalation might lead to executing other code as the superuser (root user)
• firewalls can prevent access to all applications other than the ones explicitly selected by a knowledgeable user -- but cannot protect permitted applications.

Basic Encryption

• trusted system(s): own computer, partner's computer (but can we trust our partner? Or even our own computer?)
• untrusted system: network
• plaintext encrypted to give ciphertext, decrypted to give back plaintext
• secret key is required for decryption, may be required for encryption:
  • if encryption and decryption keys are same, encryption key must be kept secret: this is secret key cryptography
  • if encryption and decryption keys are different, encryption key may be published: this is public key cryptography
  • in both cases, the decryption key must be kept secret to guarantee privacy

Security Algorithms, Protocols

• one-time pad (secret key): unbreakable, but key security is difficult because the key is a random number with the same number of bits as the message
• DES (secret key): hard to break 56-bit key, commercial use, no longer very secure, now replaced by
• AES (secret key): 128-bit key
• Kerberos (secret key): security protocol, distributes and renews session keys based on host keys
• RSA (public key): arbitrary size keys, now free
• secret key algorithms can be used in different modes, e.g. Cypher Block Chaining (CBC) or Counter (CTR) modes
• message integrity: can I prove in court that this message was sent to me by person X?

Security Observations

• security is not all-or-nothing: even using WEP is more secure than using nothing
• "security by obscurity" may be helpful if it is supplementing a strong security system, e.g. DES, but is often likely to be masking vulnerabilities, e.g. WEP
• with the internet, even people with little knowledge may be able to use others' code or compute cycles to break into a system
• security can at best guarantee the peer's identity, not their behavior
• trust is not transitive: I may trust you with my secret, I may not trust your friend whom you would trust with your secret

TLS (SSL)

• Transport Layer Security (Secure Socket Layer)
• Layer above TCP and below application protocol (typically below HTTP)
• Overall functionality:
  • server sends own public key, signed by Certificate Authority, to client
  • if client accepts public key, uses it to encrypt a random session key
  • only the server can decrypt this message (if they server secret key is kept secure)
  • a faster protocol, such as AES using the exchanged session key, can be then be used to encrypt the remainder of the session
  • the protocol also includes an authentication mechanism, based on HMAC
  • optionally, compression may be used
• only the server key needs to be authenticated
• "slow" public key encryption only used at the beginning of a session -- reusing connections helps efficiency here

TLS Vulnerabilities

• Any attack that leads to an incorrectly signed certificate!!!
• vulnerabilities mostly dependent on the specific encryption algorithms (see here and here)
• do we know whether TLS is generally secure?

Anonymous Communications

• anonymity can be sought for a variety of reasons, some of which we would consider good (crime reporting by people in fear of the criminal), others which we would not (anonymous threat by criminals)
• assuming that anonymous communication is desired, how to implement it?
• difficulties:
  • communication generally has to be two-way, at least for an acknowledgement that the recipient has received the communication
  • anything I send on the internet can be tracked, carries my IP address, and (unless encrypted), can be read by attackers
  • as a sender, I may be willing to identify myself to the intended recipient, but not to others
    • so how would I know who I am really talking to?

Pseudonymous Communications

• I wish to choose an arbitrary name that people can use to communicate with me
• without giving away my real name
• e.g. dating sites, many email systems
• sometimes IP addresses and domain names

Other Attacks

• "The great firewall of China": the Chinese government blocks access to many popular sites it has no control over
• many other governments do the same
• other governments (try to) block specific kinds of content, e.g. certain political expressions connected with WWII are forbidden in Germany
• most of these can be defeated by using a Virtual Private Network: an encrypted tunnel to a router outside the controlled network
• however, a VPN is not anonymous: the owner of the VPN can tell who is using the VPN and where they connect to

The Onion Router

• TOR
• Suppose I create a VPN to node A
• on this VPN, I send to node B some content encrypted for node B
• the content for node B is encrypted content for node C
• I can repeat this as many times as I wish
• the final node, node X, gets the content for my intended destination, node Y
• node Y can reply to X, which can encrypt and send it to the node before it in the chain
• any given node only knows the upstream node and the downstream node
• only node Y (and possibly node X) can see the contents
• these layers of encryption are metaphorically like layers of an onion

TOR details

• developed at the U.S. Naval Research Laboratory by Syverson, Reed, and Goldschlag
• further developed by DARPA
• first release by Syverson, Dingledine and Mathewson in 2002
• supported by the U.S. government "to aid democracy advocates in authoritarian states"
• can be used for any purpose by anyone who disagrees with any government -- and even by people who do not disagree with any government

TOR weaknesses

• non-TOR traffic, e.g., if incorrectly configured, DNS queries could still go out in the clear
• in-browser "features", including Java/script and cookies
• fingerprinting, that is, detecting information leaked from one's system (e.g. OS type in the HTTP header)
• bootstrapping: downloading the TOR software could be detected or blocked, or (if the signature is spoofed) the software could be modified in transit
• if an attacker has a comprehensive list of TOR nodes, it may be easy to detect that someone is using TOR
• any OS weaknesses
• TOR (or any other system) does not prevent users from revealing their own identity

Other anonymity systems

• I2P is the Invisible Internet Project, designed to anonymize communications within the I2P network -- addresses are simply public keys
• Freenet is designed for anonymous sharing of content
• AllNet is designed to allow secure and authenticated interpersonal communications
• BitMessage broadcasts encrypted messages to all nodes in the network, each of which is supposed to save the messages for two days

Multi-Hop Latency

• Measuring Link Bandwidths Using a Deterministic Model of Packet Delay (Lai and Baker, SigComm 2000):
  • l is the link number, s the packet size, b_l the bandwidth of link l
  • in the absence of queueing delays (t_q = 0),
• with wormhole routing, replace s/b_i with max(0, s/b_i - s/b_i-1)
• if t_q = 0, and if for some x the bandwidth b_x << b_l for all other links l, then t =~ s/b_l
• if t_q = 0, and all n links have the same bandwidth b, then t =~ ns/b_l

Throughput

• Send throughput: for "send only", only tells you about the speed of the sending machine
• Receive throughput: how many bits per second we received, given that the sender was sending as fast as possible
• "Goodput": received correctly, by application (for lossy protocols)
• have to define terms carefully: do you count retransmissions? packet losses? erroneous packets?
• due to congestion management, TCP throughput may be much less than send/receive throughput tested using UDP
• especially true in the case of lost packets or packets with errors

Improving Throughput

• get a faster network (56Kb/s modem might be the bottleneck)
• get a faster computer (old 386 might not be able to send at 100Mb/s)
• get a faster application (ssh might spend a lot of time encrypting and decrypting, rsync spends a lot of time searching the disk)
• get a faster protocol (80% of network bandwidth is pretty good when using TCP even on a local area)

Internet Performance

• some connections are great
• some destinations are permanently unreachable from others
• some destinations (e.g. volcano from UH) have a high error rate (at one time, typically 4% of packets lost)
• congestion is unpredictable
• throughput is unpredictable
• web page caching (e.g. project 3, Akamai) helps "perceived" throughput

Overall Performance Issues

• time is what people really care about:
  • RTT for real-time traffic
  • response time (often connected with RTT, sometimes with throughput)
  • overall time to complete a task (throughput)
• some combination of a * RTT + b * bandwidth
• the math matters!

Network Architecture

• networking protocol architectures:
  • OSI
  • TCP/IP
  • ATM
• encoding
• compression
• multimedia
• encryption
• authentication
• secret key encryption and key management
• public key encryption and key management
• "the future"

Network Protocol Architectures: OSI

• a standard model for talking about networking protocols
• 7 layers: application, presentation, session, transport, network, data link, physical
• each layer communicates with:
  • logically, its peer(s)
  • actually, the layer below it
  • the layer above (by presenting an API)
• presentation covers encoding (big- and little-endian)
• session covers management of shared state

Network Protocol Architectures: TCP/IP

• not a standard (predates OSI)
• application, transport (TCP, UDP), IP, "below IP" (Ethernet, ATM, PPP/SLIP, etc)
• specific to the internet
• "below IP" layer needs to support:
  • single-"hop" packet (datagram) transmission
  • delivery according to an IP address (ARP/broadcast, ATM-ARP, configuration)
• application layer will use the sockets interface

Network Protocol Architectures: ATM

• a way of precisely defining the interfaces among many different protocols
• layers:
  • upper layers: control plane (signaling), user plane (data)
  • ATM Adaptation layer (AAL): convergence sublayer, segmentation and reassembly sublayer
  • ATM layer (53-byte cells, VPI/VCI)
  • physical layer: transmission convergence sublayer, physical medium dependent sublayer
• UNI, NNI, P-NNI

Network Protocol Architectures

• OSI model (minus session and usually presentation) is what people most frequently use in talking about protocols
• OSI model minus session/presentation and with DL/physical merged is very similar to Internet model
• ATM (and ATM-like) models only used for telephony-related protocols
• why do we need to talk about protocol layers?
  • often, the complexity is in the interaction
  • some functions belong at one point in the network stack (framing), others are pervasive
  • DL-level encryption is very different from application-level encryption

Data Encoding

• presentation layer (bit/byte encoding belongs on the physical layer)
• numeric data: bit/byte order, size(s)
• string data: termination
• collections (arrays, structures): how much checking should we do, how much flexibility do we allow?
• images and sound: many standards (GIF, JPEG, TIFF, MPEG, etc) with different properties, different rates of compression
• MIME brings all of these together

Data Compression

• presentation layer (but makes encryption more effective)
• compression ratio: 1 is no compression oo is complete compression
• amount of information per bit: unpredictable data has 1 bit of information per bit of data, predictable data has less than 1 bit of information per bit of data
• lossless compression: decompressing yields the same bit(s) as before compression
• at most, lossless compression can reduce data to the number of bits of information
• lossy compression: human senses interpolate lower quality images, audio

Multimedia networking

• real-time: voice, video
• non-real-time: voice, video, graphics, hypertext, shared media (chatrooms, blackboards)
• for real-time, would need bandwidth reservation, but compression means bandwidth varies
• in case of congestion, selectively drop "less essential" frames (CLP bit...) -- leads to lower quality but still acceptable transmission
• for non-real-time, the only issue is how long we have to wait before the data is presented

Encryption and Authentication

• model: Alice communicates with Bob over an insecure network
• attack: Charlie can
  • listen on the network
  • perhaps insert new packets that look like they came from Alice or Bob
  • perhaps remove packets from Alice or Bob
• if the communication is encrypted, Charlie cannot obtain the information being sent
• if the communication is authenticated, all the data received from Alice (or Bob) was actually sent by Alice (or Bob)

Security

• trusted system(s): own computer, partner's computer
• untrusted system: network
• plaintext encrypted to give ciphertext, decrypted to give back plaintext
• secret key is required for decryption, may be required for encryption:
  • if encryption and decryption keys are same, encryption key must be kept secret: this is secret key cryptography
  • if encryption and decryption keys are different, encryption key may be published: this is public key cryptography
  • in both cases, the decryption key must be kept secret to guarantee privacy

Security Algorithms, Protocols

• one-time pad (secret key): unbreakable, but key security is difficult because the key is a random number the same size as the message
• DES (secret key): hard to break 56-bit key, commercial use
• Kerberos (secret key): security protocol, distributes and renews session keys based on host keys
• RSA (public key): arbitrary size keys, now free
• message integrity: can I prove in court that this message was sent to me by person X?

Key management and Secret Key Systems

• key length must be large enough to foil guessing attacks
• key must be selected at random (especially for small keys)
• key distribution is the main issue for secret key systems
• how do you talk to strangers?
• Kerberos: have a central point that knows everyone's secret, can generate new secrets for exchanges between Alice and Bob

Public Key Systems

• one key used to encrypt, one to decrypt
• c = E(k_public, p)
• p = D(k_private, c)
• so D(k_private, E(k_public, p)) = p
• so E(k_public, D(k_private, p)) = p can be used as an authentication mechanism
• another authentication mechanism: send p, checksum(p + key)
• this last can be defeated if we can compute the key given the checksum
• how do you know the public key is for who you think it is?

Potential Futures

• how fast can we go?
• wireless: 802.11 and cellular. What are the limits?
• Ethernet seems to be dominating over ATM: what is the next hot new technology?
• fragmentation of the Internet: intranets, firewalls, NAT, ...
• when (if ever) will we switch to IPv6?
• will the Web look like television? what will replace the Web and the Internet, and when?
• peer-to-peer networks