As part of a “Computing Everywhere” course organized by Jeremy Birnholtz, I ran a two-hour lecture on Internet technologies with two different groups of students. Overall, I think that the classes went well, and I wanted to reflect a little bit about it, and make my materials available for anyone wanting to teach a similar class. The goal was to give students an intuitive understanding of the technologies that underpin the internet, and how they relate to security, privacy, etc.

Here are my slides, an instruction sheet, and my proposal (pdf) (tex).

The whole class was built around a message passing activity which my advisor Aaron Shaw uses in his undergraduate class. The basic idea is that a few students are “users”, a few are servers (e.g., Facebook and Instagram), and the rest of the students in the middle are routers.

As students filed in, I made sure that they sat as close together as possible to make a dense network. I then assigned users and servers at the edges of the class, such that the most direct routes would cross each other.

Packet routing / IP

For the initial activity, users cut up memes into small squares, which they then had to get to a server using envelopes. They addressed them, and routers passed them where they needed to go.

I then made a few routers malicious - one would pass things the wrong way, and the other would conspicuously throw packets onto the floor. This set us up to talk about how IP addresses are very similar to street addresses, and help routers know where to send packets. We also talked about decentralization and the ability to avoid problems without top-down control or knowledge.

TCP

I had students talk in groups about the weaknesses of our original simulation, and how a system of envelopes and messages might solve them. They came up with some good ideas, which were very similar to TCP. I explained that TCP is a layer that sits above IP, where packets are numbered, and servers send “I got #X” messages back after every packet is received. We ran the simulation again, but for this and future runs we just had one user and one server participate. Note: in the second session, I switched which user and server participated in each run, which worked better and kept students more engaged. At this point I also showed the students Wireshark. I started sniffing packets while I downloaded a cat meme, and showed how the image was broken into packets, and how ACKs were received.

Server-side security

Again, I had students think about vulnerabilities of the system. At this point, we talked about how anyone could send packets pretending to be you. We talked about how authentication works - you send a username and password, and the server sends back a cookie, which you then include in all future messages (the “cookie” was a picture of a cookie).

At this point, I introduced two new nefarious nodes: a hacker and a spy. The hacker replaced the image you were trying to upload with her own image, and the spy took notes about who was sending what to whom. This helped students to recognize a huge flaw in the system - rogue routers can very easily impersonate even authenticated users.

SSL with locks and boxes

To explain SSL, I pulled out a box and two locks, each with two keys, and asked the students to discuss in groups how they might send messages securely with these tools, where “securely” means knowing 1) who sent the packet and 2) that no one else viewed or changed it, even though neither the user nor the server can control the path that a packet takes.

Think about it yourself for a moment, and try to figure it out. It’s trickier than it sounds.

This is the part of the lesson I was most proud of, and most nervous about. I was really impressed that in both sessions the students pretty much figured it out. As they explored their ideas, I would have them try them out in the simulation, and talk through it together. In the end, we talked about how SSL works:

1. The server makes available a box with a unlocked Lock 1 on it, and keeps both keys (We didn’t talk about certificates here, but could have).
2. The user keeps one key to Lock 2, and puts in Lock 2 and the other key to Lock 2 in the box
3. The user puts a message with their username and password in the box
4. The user locks the box with Lock 1, and sends it back to the server. This works because only the server has the key to Lock 1, so no one else can intercept the box en route. The authentication message lets them know who sent the message and Lock 2.
5. The server removes the key to Lock 2, puts a cookie in the box, and replaces Lock 1 with Lock 2 and locks it.
6. The user opens Lock 2 with their key, and now both the user and the server can send messages back and forth in a box locked with a lock that only they can open.

Proxies, VPN, and Tor

While SSL stopped the hacker, we talked about a final technical vulnerability - the spy can no longer see message content, but can still see who is sending messages to whom. We talked about how proxies, VPN, and Tor each work in different ways to try to solve that problem by hiding the user’s identity. We did one final simulation of Tor + SSL + cookies, and showed that we pretty well solved the vulnerabilities that we had identified. I also showed them the Tor browser, and talked about the weaknesses (speed, many sites don’t trust Tor exit nodes, IP address is unpredictable).

PEBCAC

Finally, we talked about how most of the Internet’s current security problems (spam, stolen credit card info, etc.) are at a higher level in the stack - they are human problems, caused by phishing or people choosing weak passwords.

Overall, it was a really fun lecture. The students that I had were super great and interested in the topic, and the activities were really fun. Please feel free to use any and all of my materials; I’d love to hear if you do!