Librepunk Podcasts

logo for trash cat tech chat

002 - Talking about networking

from trash cat tech chat

22 May 2022

Listen: ogg | mp3

Show Notes

trash cat (they/them) and ear7h (he/him) talk about how the internet works, why it's insecure, and how we can hack security onto it.

Timestamps

Transcript

[Intro]

trash cat: You're listening to trash cat tech chat, a Librepunk podcast.

Introductions

tc: I'm trash cat. My pronouns are they/them.

ear7h: And I'm ear7h [pronounced "earth"]. My pronouns are he/him.

Introducing networking

tc: Do you want to actually introduce the topic today?

e: Yeah, sure, I could talk about it. So, basically, I'm not, like, a super privacy-focused person, but I am more of a nerd about like, some of the networking stuff. And I've recently taken a class where I learned a lot about networking, and so I thought it'd be pretty interesting to kind of go through like, my uninformed side about web privacy, but informed about networking and then trash cat's expertise about privacy. And handling specifically all the biggest vulnerabilities that networking has. You know, since it wasn't built with the idea of privacy and all those things in mind.

tc: So do you want to just kinda start at the bottom and work your way up?

e: Yeah, I think so. That's probably the best way. For those who aren't aware, there's this thing called the OSI 7-layer model which, it kinda defines how basically computers and applications can talk to each other, starting from the very bottom, which is like, bits, and just kind of getting over physical mediums or like, sending information through a wire. At the very top, there's like, application data where you're sending... Basically, it's like, IPC [inter-process communication]. So like, if you want to send some, like, magical command to your browser, that would be at the very [top] layer. And then in the middle, there's various things in-between. So, something like, you've probably heard like IP or Internet Protocol or like TCP or HTTP. Those are all kind of in the middle. Um, yeah.

Physical and link layer

e: I think, so like, to start at the bottom would be -- at least in terms of the privacy stuff, would be like, with the link layer, or the physical medium. So basically, you're trying to send bits through a wire, right? Or through, like, free space, through the air. And one of the fundamental problems with privacy there is that anyone can tap into your wire. Assuming they have physical access to it. Or anyone can tap into the -- Anyone can put up an antenna and listen to, like, radio waves. And so, yeah, I guess that might be a good starting point.

tc: Yeah. So we can talk about like, encryption to protect that. Do you know, how do you protect, like, physical wires? Is there a good way to ensure that you have a secure, like, Ethernet connection or something?

e: Um... I don't think so, besides like, physical, like, locking things down, right?

tc: Right.

e: And making sure people can't get into the physical locations. And so, one thing to talk about that is that there's like, an interesting picture that my professor showed us that was this random room in AT&T, or like, Verizon's infrastructure, like where all their cables kinda went through. This random room where one wire went in, and one wire went out. And there was like, 2 keys that you had to use to get in there. Like, there was 2 locks on either side of the door. And like, nobody knew what that was.

tc: Weird.

e: Yeah. Well, turns out that it was actually, like, the NSA.

tc: Ah. Okay. Well, that explains it.

both: [laugh]

e: Yeah. Yeah. Um... And so there's, yeah. It's things like that. And then, the other thing was like, there was an artist who went in and like -- So, the way that we talk across continents and stuff, so that -- basically, there's wires that are going underneath, like under, like through the water, right? Like, fiber optic cables like between like, us and like, Japan. And there's an artist who went in to kinda research this stuff and they knew where it was, or kind of figured out where some of these cables were and just like, went -- dove underwater and took pictures of it. Just to show that like, literally anybody, you know, like, to these like, thousands of miles of cable in the ocean. Anybody could just go in and tap the cable and read data off of it. Ethernet, I think, you can tap into Ethernet without necessarily like, interrupting the signals, but you would at least have to break, I think, the sheath of the cable itself and stuff, so like...

tc: Yeah.

e: ...it would be at least visible. But, yeah. And I guess... I think the reason why I bring this up is because basically, at the higher levels, it's where, like, the problems start. Right? Like... You can't have, like, a private physical connection. I mean, I guess you can, in a very theoretical room, but there's various blocks. Yeah.

tc: But you essentially have to implement the privacy or the security protections at a higher level.

Network layer and identifiers

e: Yeah, exactly. So even then, so I guess we can take a step up which would be, like, frames or IP packets. So at that level, you're not just sending data. You've figured out how to send data, like zeros and ones, reliably. Somewhat reliably. Or at least, handle the unreliability. Well, not really. Okay, sorry. Uh, but then you're starting to put the data into groups, so like frames or packets. And you're sending them to certain destinations in that network, right? So like, if you have a bunch of things connected through Ethernet -- Something I didn't know until this class was that you can actually have -- according to the Ethernet standard, you can actually connect multiple computers on a single Ethernet line. That's how they used to do it. It wasn't all just like, one Ethernet to one router. I don't know, that's kind of a fun fact. I don't know. But at that point, you're sending addresses. You're sending an address along with your packet to where it's supposed to go, and an address where some data is supposed to return to. So that's, I think, where most of the privacy... maybe not most, but there's a big thing about privacy there, right? If you're sending stuff to other computers on the internet, then whoever's like, in the middle is gonna know -- or even the other people next to you are gonna know who you're sending that data to.

tc: Yeah, for sure. It's hard to have anonymity when you have to have a return address, right? [laughs]

e: Yeah. Exactly. You're basically saying, "This is me." And I think the solution -- I don't know if it's too early to get into it, but like, that's where, like, Tor comes in, right?

tc: Yeah. And I mean, there's a bunch of stuff going on there, right? You've got, like, IP addresses, but you've also got MAC addresses where you're talking to the router and stuff, right? And...

e: Yeah.

tc: ...kind of every step along the way, you need... an identifier, and that identifier can be used to violate your privacy, right? [laughs]

e: Yeah. Yeah.

tc: Um... One of the things -- and I do want to get to Tor, but -- one of the things that I learned somewhat recently is -- So, I think people have been talking about for a while the idea of like, you can be tracked short-range by like, your phone's MAC address or something, right? If, like, you're connecting to Wi-Fi in a store or something, they can, based on your proximity to different Wi-Fi access points, they can maybe figure out where you are, at least approximately, within the store.

e: Right.

tc: One of the things that... sort of was discovered recently, which is really creepy, is um... Oh, sorry, I should explain what a MAC address is. [laughs] Do you remember what it stands for? Because I do not remember what MAC stands for off-hand. [Editor's note: Media Access Control]

e: Oh god, I should, but I...

tc: [laughs]

e: ...don't. I...

tc: Machine... Machine something Code, right?

e: Machine Address Code, maybe?

tc: Yeah, that sounds right. [laughs]

e: Yeah...

tc: Part of the problem is "MAC" means so many different things in the world of computers, right? [laughs]

e: Yeah.

tc: And I'm more of a cryptography person, so I'm used to it meaning Message Authentication Code.

e: Right, right.

tc: Uh... [laughs] Anyway, um... So, a MAC address is a hardware address for a networked device, basically. So like, your Wi-Fi card or your Bluetooth card or whatever, your Ethernet card... will have a unique address to that piece of hardware. Right?

e: Yeah.

tc: And correct me if I say anything wrong here.

e: I guess, I also want to specify that the MAC address is specifically used when you're talking to like... you're within one network. So like, Wi-Fi-connected devices will talk to each other using the MAC address or using the... Or, Ethernet, like if you're all on the same Ethernet line, you'd use the MAC address to connect. But not necessarily like... if you want to send data to somebody all the way across the world, you wouldn't send yours and their MAC address on there.

tc: Right. And thank you, that's an important distinction.

e: Yeah.

tc: But yeah, so you have to broadcast your MAC address, though, to like, a router or whatever that you're talking to...

e: Yeah.

tc: ...locally. Right? So, one of the things that I learned recently is iPhones take note of other MAC addresses of other devices on the same local network and then report those to Apple.

e: Oh wow.

tc: And they include -- If the iPhone has location data turned on, they include location tagging. So what that enables Apple to do, right?, is to -- And I'll include a link in the show notes of what I'm talking about, this article. But what that... I mean, we don't know what Apple does with that data, right?

e: Right.

tc: But what it enables Apple to do is to track people over time, across different places, based on their proximity to iPhones, essentially. [laughs] Based on, like, you know, if you go to the library, and someone with an i-- and you connect to the library Wi-Fi, and someone with an iPhone is connected to the library Wi-Fi, and they can see your MAC address... then Apple can know that you're, that your device is at the library. Or, whatever. Right?

e: Yeah.

tc: Even if -- even if you're not using an iPhone yourself, other iPhones will rat on you, and that's... creepy! [laughs]

e: [laughs] Yeah, that's... yeah.

tc: Um... [laughs] But yeah, so um... You want to talk about like, proxies, VPNs, Tor, that kind of stuff?

e: Uh, I guess before that, one thing that I just remembered was like, I guess the reverse side of it. I guess another one of the kind of weird dystopian, I guess, or like, more niche knowledge about Wi-Fi was like, a research paper where I think people could track, like... You can track somebody's location using Wi-Fi signals. Like, just the signals. Sorry, how do I explain this? If you either, I think, listen with an antenna outside of a room... you can figure out, like, where someone is in that room, if their device has Wi-Fi on it.

tc: Oh, like, based on the device emitting Wi-Fi signals?

e: Yeah, yeah. And I think like...

tc: Huh.

e: And this is more -- Oh, and I think it's actually you can also, like, figure the shape of the room, but that's more, like... I mean, it's not exclusive to Wi-Fi. That's just, you know, if you blast -- You're basically, like, using sonar, but it can go kinda through the room itself, then like, figure out the shape of the room. Which is like, yeah, pretty...

tc: Creepy stuff. [laughs]

e: Yeah. [laughs] But I guess we could move up to the IP layer. So yeah, to explain the IP versus like, Ethernet or Wi-Fi is that, like I said earlier, it's like, those are... You know, you set up one kind of device and then things will talk to just that device through Wi-Fi... like a router. Yeah. You would talk to the router like, through Wi-Fi or through Ethernet. But if you want to talk to somebody who's not necessarily connected to the same device, then you go to what's called the inter-networking layer. The internet layer. And then you can send messages between routers. So from, you know, my phone, to my router, to trash cat's router, to trash cat's phone. So yeah, I mean, there it's like, you know, it's almost worse than the MAC address because now you have the like... the IP is supposed to be globally identifiable. In some sense. Um... Yeah, but okay, so the... like, proxies, or VPNs, they kinda take care of some of the anonymity... Well, theoretically...

tc: Kinda, yeah.

e: ...by making it so instead of like, sending stuff from like, your own router so everybody knows like, the router in your home. Instead of sending all of the stuff there, you send it to some other server, like on the cloud, at a different IP address, and that server sends stuff to wherever you actually want it to go.

tc: I feel like I should... do a little side note here to say, the actual, like, purpose for virtual private networks as a piece of software, as a protocol, is to enable you to access remote resources. Like if you're at home and want to access your work computer remotely or something like that. Right? But what VPN primarily means now is like a commercial VPN, essentially some company runs... essentially an encrypted proxy connection for you so that you can run your traffic through their IP address. Yeah, is that fair to say? Like, that's what VPN kind of means now. [laughs]

e: Yeah, yeah.

tc: Yeah, and so, there are some uses to this. One of them is encryption, but I think we should talk about that at a higher level.

e: Yeah, I agree.

tc: But for IP address privacy, a VPN can obfuscate what your IP address is from other computers that you're talking to by making it look like you're using -- like you are the IP address of the VPN server. So like, I don't know, I'm in the United States. If, say, I want to appear to be someone they don't know in Germany, I can use a German VPN server to make my IP address look like a German IP address. Or something like that. It's kind of like saying, you know, uh... It's kind of like a secret admirer note or something where you're like, "I don't want to deliver this in-person", so you ask a friend, "Hey, will you deliver this for me?" Right?

e: Yeah. Yeah. I was gonna say the same thing. Like, you can think of it like, you know, talking about computers just like regular mail. Right? First, you're like, send it to your friend, and your friend can then send it to the actual place where you want it to go.

tc: Yeah.

e: And... Right, so that like, that kinda works. Right?

tc: It kinda works, yeah. But the problem with it, right?, is that the VPN server then knows what you're doing, right? Or in the analogy of the secret admirer letter, your friend knows "Oh, you are writing a letter to this person." Right?

e: Yup.

tc: And so... depending on your threat model, that might be fine. Or it might not be. And what's kind of a better approach is -- well, what is a better approach if your goal is anonymity from the other computer you're talking to (the server or whatever) -- is something called "onion routing". And um... Do you want me to go ahead and explain onion routing?

e: Yeah, I'm not, like, super familiar with it. I mean, I can kind of guess the concept, but I don't know, like, enough to explain it.

tc: So... essentially... um... I mean, essentially the concept is like, what if you took multiple VPNs that are run by different people, so they're not, uh, they don't have a holistic view of what the other ones are doing, and you chain them together? It's kind of like that. The idea is you wrap your traffic in multiple layers of encryption, and then you send it through multiple intermediary servers until it reaches its destination. So like, I do want to briefly explain the encryption 'cause that's important. The key thing there is... so, say we're talking about Tor, 'cause that's the, you know, main onion routing network. With Tor, what you're gonna do is -- there are a bunch of nodes, or these relay servers, right? And you're gonna choose 3 of them. And there's a protocol for that, and we don't need to worry about how that works. But you're gonna take 3 servers, and you're going to encrypt the traffic such that each server peels off a layer of the encryption. (It's called "onion routing" because, as we all know from Shrek, onions have layers. And it's layers of encryption.) So, the first server peels off the first layer of encryption, but there's still more encryption beneath it, so it can't see what's going on. And so the first server knows who you are, and it knows there's some encrypted traffic. It sends it on to the second server. The second server peels off the next layer of encryption. And so then that reveals what the next, the third, server should be, but it's still encrypted traffic beneath that. And then the third server, when it receives it, peels off the final layer of encryption, and now, it's decrypted the traffic, but it doesn't know where it came from. It just knows it came from the second node, and the second node only knows that it came from the first node. So, the first node doesn't know what you're doing, but it does know who you are. The third node doesn't know who you are, but it does know what you're doing. And the second node doesn't know anything, really. It just knows that it's forwarding encrypted traffic. And yeah, that's the idea of onion routing. It is very important, obviously, that these nodes are not run by the same person. Right? [laughs] Because if I run the entire chain, or even the first and third node, I can, at least theoretically, corroborate that information and figure out, "Oh, this person was sending this data." But, assuming that we do have that proper decentralization of the network, that the nodes are not all run by the same entity, then we can have this strong anonymity from it where no one in the chain knows both what you're doing and who you are. They can know at most one of those things.

e: Interesting. Um, okay. I guess, I've always wondered how they pick where to go...

tc: That is a good question. Um, I know there is an answer, and I don't know what the answer is. [laughs]

e: Yeah.

tc: Um, I mean, I can tell you a little bit about the network, or... there are multiple onion routing networks, right?

e: Mm-hmm.

tc: Tor has a... Tor has a little bit of centralization in it, in that there are 10... they're called Directory Authorities, which are these like, "highly trusted" (quote-unquote) servers that... they have to agree on a -- Their job is to keep track of the Tor nodes and to say, "These are the nodes that are currently contributing to the network, that are currently relaying traffic for people. That -- By connecting to the directory authorities when you first connect to the Tor network, it enables you to start using the network. You don't have to like, go find the nodes yourself. You just are given, like, "Here's a list of the nodes." Nodes are -- like, node operators are supposed to identify themselves and to say, "These are the nodes that I am running" so that people know not to choose more than one from that list at a time. But, you know, what if someone doesn't declare it but does set up a bunch of nodes to try to... It's called a Sybil attack, this type of thing where you set up a bunch of nodes to try to gain undue influence over the network, basically.

e: Gotcha.

tc: And that's a problem, and my understanding is that the way Tor tries to handle that is, um, they have various techniques for trying to identify when someone is doing a Sybil attack, and then when they are, the directory authorities kind of mark the nodes as bad and say "These are malicious. Don't use these."

e: Hm, I see.

tc: So, that was a little bit of information, but I don't actually know what the... you know, how your computer actually decides which nodes to use.

e: Yeah, yeah, yeah. That actually answers, I guess, what my underlying question was, was like... There's a -- I guess, part of like, the last podcast, right? There's like, some trust that has to be put in there to be like, "Yeah, okay, these are not the same." I mean, there's heuristics, right? But there's not a completely perfect way to solve that.

tc: Yeah, and in... in the context of Tor -- which, this is not the case with all onion routing networks -- but in the context of Tor, there is that trust... um... I mean, you are trusting the directory authorities to maintain a good record of things. And, in turn, they kind of decide whether or not to trust different nodes. So you're kind of delegating the trust there.

e: Yeah.

tc: Um... With other networks, with, like, I2P for example, which... sort of pedantics maybe, I2P uses a thing called "garlic routing" rather than "onion routing". It's based on onion routing, and it's... similar, but there are some differences... beyond the scope of this conversation. [laughs] But with I2P, which essentially does onion routing, right?, you don't have that central list of 10 directory authorities. You just... You, like, connect to a bootstrap node the first time you use the network, and you download like, a partial list of "Here are some nodes", and then you use those to find more nodes that they know about and just, like... You have to build up your own version of what you think the network looks like.

e: Yeah, gotcha.

tc: Which is really cool, and it makes I2P more decentralized in that way, but it's also a lot... less convenient because you... Effectively, to use I2P, you have to keep it running... most of the time. Like, more often than not, you have to have I2P running so that you can maintain your own view of the network.

e: Yeah, I've dabbled with it, and I think I remember one of the problems was like, you can't even connect to the whole network, right? Like, when you first log in.

tc: Yeah. Yeah, I2P -- like, I like I2P. I genuinely like I2P a lot. But, it's frustrating to use. You have to, like -- I mean, you basically have to start the program and then leave it running for like 24 hours before you can really use it to do anything. [laughs]

e: Yeah. Yeah. I agree. I also thought it was, like, pretty cool. It was pretty interesting. Like, I've never... I've never actually used Tor, but I have like, dabbled with I2P a little bit.

tc: That's funny. [laughs] That's funny 'cause Tor is way more, like, normal than I2P to use.

e: Yeah. Yeah, I know. So, I don't know, I was like, "Oh, that seems interesting" but it was like... Yeah, I don't know, it was strange, and it's like... It's weird thinking of like... And I think, if you connect to it, you also have to like, run-- or like, the software does both the running and the rout-- like, you know, the connection and the proxying.

tc: Yes. Um, you don't have to. You can choose not to route information for your peers, but by default, yeah. Tor has this separation between the nodes that are the servers in the network that people connect to, and the people who use the network as clients. And I2P doesn't really have that. Like, everyone is both a client and a server or a relay.

e: Yeah.

tc: Which again makes it more decentralized but also less convenient to use.

e: Yeah.

tc: Right?

e: Yeah.

tc: [laughs] I feel like that was a whole rabbit hole.

e: Yeah.

tc: But yeah, onion routing can protect your IP address.. [laughs]

e: [laughs]

tc: ...is the takeaway from this section, I think.

e: Yeah. I mean, it's good. I mean, I guess part of my prompt, I guess, was to get us to do -- talk about like, more of the technical aspects of it.

DNS

e: Should we go up a level, or is there some...?

tc: Uh, yeah, let's talk about like, DNS and TCP and stuff like that. I guess DNS is technically application layer, right? Even though it's necessary for other things?

e: Uh, yeah... Yeah, I guess it is.

tc: Okay, so want to talk about like, TCP, UDP, that kind of stuff?

e: Um, sure. Well, I think -- We can actually talk about DNS first, I think. Just because the issues are kind of the same.

tc: Yeah.

e: And they're almost like, worse than before -- than like, with IP because... So, I think, you may have explained it before, but for those who don't know, DNS is the domain name system, and the cliché analogy or metaphor is that it's like an address book. Just, everything on the internet, right?, as we were saying is kind of like, addressed with an IP address, so that's just a bunch of random numbers. DNS is just the system that when you give it a specific name like duckduckgo[.com] or google.com, gives you the IP address that you should send your stuff to. And the way that it's worse, it means, like, not only... You know, if you're looking something up on the internet, whoever can see the DNS request, which like, as we said before, is kind of like... uh, it's kind of changing, but a lot of it is just plain text. Whoever can see you make those requests will also -- not just see like, the IP address, will see the exact, like, name that you're searching for. So if you're, like... If there's a bunch of servers that are hosted kind of under the same IP address, that are like, you know, one's Google, and the other one's like, Google Docs or something, and the other one's Google Images, and they all have the same IP address, they will see -- If somebody sees your DNS request, they'll see not just that you're going to Google but that you're going to a specific website under Google.

tc: Yeah. And that's also -- I'm skipping ahead a little bit, but that's also going to be the case with HTTP and other things, right?

e: Yeah. The problem, I think, though, with DNS even moreso is that it's...

tc: It's insecure? [laughs]

e: Yeah, it's insecure. But also, it's like, so low-level, right? It's kind of like... It is a higher-level protocol, but it's also kind of like, tucked in to every single request that most people are gonna make, you know? Like, most people are not gonna be typing in an IP address into their URL bar.

tc: Or maintaining a hosts file. [laughs]

e: Yeah. Exactly.

tc: Yeah.

e: Or even, like, application developers aren't gonna be putting in IP addresses into their app when it's making a request, so, yeah. It's kind of like, tucked in, and it's hidden. And it's surprising to me that, like, the encryption parts of it are so, like...

tc: Lacking? [laughs]

e: Yeah. Yeah. There isn't, like... I don't know. Anytime I look up DNS encryption I'm like -- I walk away an hour later like, just trying to forget I did any of that.

tc: Yeah, it's... The situation with DNS and security is not good. For anyone listening, it's not good. As with everything with the internet, networking, whatever, DNS is not designed to be secure, was not designed with security in mind. We just have this thing where you say in plain text, "Hey, what's this domain?" you know, "example.com?" And then someone replies in plain text, "Oh, it's this thing. It's this IP address: 12.34.56.78." And you say, "Thanks!" Well, you don't say "Thanks", but you, you know. It's UDP, right? There's no handshaking. But you uh [laughs], you go on and trust that that's correct. And so, basically, by default with DNS, we don't have... really any security properties. We can build some on. So, we have this thing called DNSSEC, which is -- it stands for something longer than it should. It's like DNS (Domain Name System) SECurity mmm... Extension or something. I think there's an extra word that isn't accounted for in the acronym for some reason. [Editor's note: It's Domain Name System Security Extensions.] Doesn't matter. We have this thing called DNSSEC which you might think secures DNS, and it partially does, but it's like... So, DNSSEC offers authentication and integrity. Essentially, you can get signed DNS responses that say, "Yes, this is [this IP address], signed [the authority on this matter]." Right? And, so that's cool. But practically speaking, because of the way things work, I think DNSSEC is just not at all widely adopted. It's kind of one of those things where it's like, if you turn it on, it breaks everything, so you turn it off.

e: Hmm.

tc: Uh, which is cool and useful and uh, yeah...

e: [laughs]

tc: And the other thing about DNSSEC is it does not provide confidentiality. So while you might be getting authentication and integrity -- you might know when using DNSSEC that this is a good response by whoever's authority -- it's not private, the process of you finding that out. So, your ISP (your internet service provider) or whoever else on your network or whatever, can still see which domains you're looking up.

e: Yeah.

tc: Which is not ideal. So, there are some other things that you can do. There's um, there was a project called DNSCrypt, which was supposed to actually encrypt the DNS requests. I think that project is, like, dead or inactive, or like, the original project died and some people are maintaining it for some reason, but they're not actively working on it, or some-- I don't know. I think DNSCrypt is not really a thing people use anymore. And then there are kind of two other competing standards, which are DNS-over-TLS and DNS-over-HTTPS. Which, I realize by bringing these up, I'm kind of jumping ahead to "What is TLS? What is HTTPS?" but um... basically, those are... My understanding is those are effectively the same thing because HTTPS, the HTTP protocol that we use for web traffic, the S stands for "Secure"... HTTPS is secured with TLS, which is Transport Layer Security, which is the successor to a thing called SSL (Secure Sockets Layer). That's not super important right now. The thing that I wanted to highlight when saying that is DNS-over-TLS and DNS-over-HTTPS are both using the same underlying encryption protocol. It's called TLS. The difference between them is mostly how they operate, where DNS-over-TLS... It runs on its own port, which... I don't really want to explain ports right now. It doesn't look like normal DNS traffic. It doesn't look like HTTP traffic. It doesn't look like HTTPS traffic. It looks like its own thing. And it's encrypted DNS. DNS-over-HTTPS is kind of the same thing, but it looks like HTTPS traffic. Um, and so... there's some kind of political stuff going on there, which is interesting, and I don't really have a defined stance on it. But um... DNS-over-TLS is sort of just like, "Hey, do encryption. Your ISP can see that you're doing DNS." DNS-over-HTTPS sort of weaponizes users against their internet service providers in a sense, where if their ISP is trying to censor, control, eavesdrop on their DNS for whatever reason, it makes it harder to do that without blocking off their ability to do HTTPS traffic altogether. Um, which I think is interesting. I don't really have a defined stance on that, but I thought it was worth mentioning.

e: Yeah. I think that does bring up something interesting about DNS, though, that it is simultaneously like, really high-level... well, not really high-level, kinda high-level, and also crucial to how normal people will use the internet.

tc: Yeah, you just cannot use the internet without it, basically.

e: Yeah, yeah.

tc: Uhh [laughs] I mean, you caaaaan but...

e: Yeah.

tc: ...only sites you already know.

e: Exactly. And it's also -- because of that, right?, it is the target of like, nation-state firewalls and things of that nature.

tc: Yeah, and like... I mean, a lot of... I mean, it's a very convenient way to implement censorship. And... I'm gonna use the word "censorship" here very broadly, okay? I don't necessarily mean it in a bad way. It can be used for example, to block ads or malicious software, malicious domains. But it's a very convenient avenue for blocking things that you don't want to be accessed. To just say, "We will not-- I will not resolve DNS requests for this domain."

e: Yeah. And something about the fact that there's names, right?, involved makes it kind of easier in a sense to block information. I was looking up on Wikipedia the other day. Like, you can use, you know, keywords to block DNS requests. And so that can mean like, you know, cuss words or whatever in a school environment or something. And that can cause other things to break. You and I probably know that like -- how easy it is to like, break something by... how easy it is to get wrong the, like, keyword censorship or blocking things, you know. There's so many names out there that like, are words that have like, cuss words kind of like in them or something like that that it makes things break in very unexpected ways. And annoying ways. I think what you were saying earlier about DNS might be a good way to... Or, sorry, about TLS and all that stuff would be a good way to kind of segue into the transport layer, I guess.

tc: Sure, um, I do wanna... while we're on DNS, I think it's worth mentioning... Because we talked about, you know, proxies, VPNs, Tor, stuff like that, onion routing, I think it's worth mentioning how those things work together.

e: Mm. Okay.

tc: Because... So, some of it depends on your setup, right? But generally... when you're using a VPN or an onion routing system or something like that, generally if the system is set up correctly, it will actually proxy your DNS requests. So, you will say, basically, "I want to look up -- I want to go to example.com." And so, you say that to your VPN provider, to the Tor exit node, the last Tor node in the chain, and it (the VPN server, the Tor exit node, whatever) does a DNS lookup, gets the IP address, and then goes to that IP address for you. So by using these things, we don't, uh... I mean, we still have the problems with authenticity and integrity where -- and maybe amplified now because the exit node could send you to the wrong place intentionally, maliciously, or the VPN provider could. But you get some additional privacy that way from your ISP. Your internet service provider can no longer watch which domains you're looking up via DNS, and they can't block certain domains that they don't want you to access, or whatever.

e: Interesting.

tc: I think that's all I had to say about that, but yeah, like, when you're using those kinds of things that proxy your internet traffic, a lot of the time they also proxy your DNS requests.

e: Gotcha. I feel like that's a surpr-- like, I guess I'd never really thought about it like that, but that's like, I think a surprisingly good use case for it.

tc: Yeah. [laughs] I mean, like... And it should be that way, right? 'Cause like, if you're... If you're connecting to, I don't know, some website that like, no one else uses or something, you want to be anonymous, and you're like, "Okay, I'm gonna connect to this website anonymously. Also, [said loudly from side to side] hey, does anyone around me know what this website is?" Right, like... [laughs]

e: [laughs] Yeah.

Transport Layer

tc: Anyway, wanna go up to the transport layer?

e: Uh, yeah! Let's see... One of the problems with the IP layer still is that -- I guess there's two of them. Right? Like, the IP layer, as far as implementation's concerned, is like, there's like one... I mean, there could be multiple, but largely it's not friendly to multi-user environments. Like you can have basically, you know, one... You're not gonna have like, one IP card per user on your computer. Like, you can have multiple, but you're still probably like, if you have, you know, 10 then you're probably a server who's running hundreds of people on the system. But usually you'll just have one. And that is like, directly connected to the whole machine, basically. So, that's kinda the problems that ports solve, um, is that if you have multiple users, you might, you know, you can have it so a user with unprivileged access to the machine can run on a port and not take over the whole internet card. So that's kind of one thing, and so the way that basically that's solved is pretty simple. You basically just take an IP packet and then you add a port header underneath. And that's basically what's called UDP. So, one of the protocols. UDP still has the problem where IP has, where like, it has no... it provides no guarantees about the delivery of the packet, so there's no way to like... UDP packets can just get dropped. Like, IP and UDP packets can just get dropped, and you won't know about it.

tc: You just yeet the UDP packet and hope it arrives.

e: Yeah. Exactly.

tc: That's how UDP works.

both: [laugh]

e: Exactly. And so, to solve that, you have TCP, which -- I don't remember exactly, and there's plenty of things that like -- There's a bunch of kind of technical... maybe not "hacks" per se, a little bit better than hacks. Some techniques you can use to make sure that this becomes reliable. But basically, the TCP...

tc: It has a rigorous handshaking process, right?

e: Yeah. And kind of like, it sends acknowledgements back and forth and that sort of thing to let the computers talking to each other know when those packets get dropped. So, that's just the distinction between I guess IP and then the transport layer. And the notable thing trash cat was saying earlier is that by default, like when these were created, they're plaintext. So like, if you wanted to send a message like "Hello World!" to another computer, you can send them a UDP or a TCP packet with "Hello World!" written in there, and then everybody, you know, between you and the other computer, can see exactly that message. So that's -- This is where encryption kind of comes in and basically just build off of... I don't know if UDP has like a standard encryption protocol...

tc: UDP has a thing called DTLS that's Datagram TLS...

e: Oh, okay.

tc: ...that I think is essentially -- I don't know very much about it, but I think it's essentially equivalent of TLS, but for UDP.

e: Gotcha. Yeah. So I guess yeah, then both of these protocols have some like, additions, a little bit of tweaks. Basically, at the beginning of the conversation, you explain some -- I think trash cat can probably explain it a little bit better, but you're gonna exchange some information that allows you to then, like, encrypt the channel so that only the -- only you, the person sending, and the person receiving can see the information, and then anybody in the middle is gonna kinda see garbage, basically.

tc: Yeah, um and... another thing that... I mean, yeah. That's what the encryption does. And it's important for [laughs] that reason. Um, another thing that the protocol, the encryption protocol TLS, or I assume DTLS as well, does is they require... well, I'm not sure I really want to talk about the whole certificate authority setup. But basically, they... without getting into how it works, they provide authenticity and integrity as well. So-- which is really important. So what that means is, when you go to, like, your bank's website, and it's... I mean, that's a bad example 'cause banks are just terrible about like, user-facing security. But, when you go to, say, amazon.com or whatever, like, a shopping website, and you're gonna put in your credit card number, right? It's really important that that credit card number doesn't just get overheard and copied down by whoever happens to be nearby on the same network or whatever. As all the stuff we've discussed so far, not encrypted by default. So it's really important that it's encrypted, but it's also really important that you are giving your credit card number amazon.com or ebay.com, etsy.com, whatever website that you are intending to and not to somebody else who's saying "Oh yes, I'm Amazon. I'm Etsy. I will happily take your credit card number!" and they're not. Right?

e: Right.

tc: So um, TLS also provides that authentication where you can verify that this website is actually the domain it claims to be.

e: Yeah. I guess, yeah, I think, yeah, that's like, the certificate authority stuff. And I guess more generally, right? TLS tells you that who you're talking to is the same person that you started the conversation with, basically.

tc: Yeah.

e: Because, and I think something we didn't really talk about is that at any point, I guess with the previous ones, without encryption, without TLS, or certificate authorities, any of that stuff... if you send a packet to Amazon and somebody else sends a packet to Amazon with the same information, Amazon can't tell the difference.

tc: Oh, I see where you're going with this, yeah. Yeah.

e: Yeah, so that would mean, you know, this is what IP, it's called "spoofing", right? So somebody else can send them data that -- If there was no encryption, and somebody saw... I guess, they could just take your credentials at that point, but you know, they could replicate the packet and send it. Or, even in the other way, they can send you -- they can send your computer malicious data so that you think that like, you send a packet to Amazon, and then they can send you a packet that looks like it came from Amazon. And your computer thinks that's okay.

tc: Yeah. Or like, a good example of where that matters is if you're getting -- like if you're downloading software, right? You want to make sure that it's the authentic software that you're trying to get and not [laughs] some random executable that someone's sending you.

e: Yeah, exactly.

tc: Yeah.

e: And so, I guess, this -- I think this is one of the problems, right?, with DNS that I guess we kinda skipped over. Sorry to like, kind of go back, but one of the problems with DNS is that if you send a DNS request, a UDP request and say, like, whoever you're asking them to, the DNS server, they just drop it, or they're slow enough where somebody next to you can just send you the DNS request like, right away, then they'll be able to begin to kinda hijack your session. So say you ask for, you know, you ask for Google, and then somebody else on your network just sends you the response UDP packet right away "for Google" and it's actually their own computer or their own server, then you're gonna start talking to somebody else like it's Google, but it's not actually Google.

tc: Yeah, exactly.

e: And so, yeah, TLS with certificate authorities allows you to make sure that who you're talking to actually is Google because... Yeah, I'll take your approach and not get into the because or how that's all authenticated, but...

tc: It's just a whole separate conversation. [laughs]

e: [laughs] Yeah.

tc: And it ties into all the other stuff with trust and centralization and like... it's -- we don't have time for it. [laughs]

e: Yeah. Yeah. Um... Yeah.

tc: But yeah. And that's the problem that DNSSEC tries to solve, right? But DNSSEC, whether because adoption is low or because the protocol is not well-designed or whatever, I don't know. I genuinely don't know the answer. I think mostly adoption is just low. But DNSSEC is one of those things that just... It doesn't solve-- It doesn't actually work to solve the problem that it's supposed to solve. In practice. [laughs]

e: Um, yeah. But I guess the happy part about TLS, right? Once you get the TLS, it's like, everything else can be a little bit more secure above it.

tc: Yeah, DNSSEC doesn't work, but TLS steps in and fixes it. Right?

e: Yeah. I think that might be-- I mean, I don't know anything about DNSSEC, but that might be one of the reasons why it's not adopted, right? Because most people will use -- It is, like, the problems that it solves are kind of solved with TLS, so.

tc: Maybe. I don't know enough either. I mean, I think DNSSEC is old enough that um... it just-- I think it's just one of those things that like, was a good idea that didn't really catch on. Frankly, like PGP, right? [laughs]

e: Yeah. I think one of the most interesting I guess, maybe downsides to like, things that kinda... I think about all the time is like, I have a habit of checking for the lock icon on the browser, and something that always kinda I wonder is like, so... pretty much anyone -- We can start with like, anyone can go out and get like, a certificate for their own website. And so, as long as you have like, a server and you can point -- you can put a DNS record that points to that server, you can do that. And so like, the thing that the lock icon doesn't protect against, and I think this is like, what certificate authorities are supposed to protect against, and I think -- I hope most of them do, is if you're, so for the example previous, like on amazon.com, and maybe somebody registered "amazonn" like with 2 n's or something ".com" and you go and, you know, the website looks the same, and it has a lock icon next to it, it doesn't actually... you know, you can still... you're not talking to Amazon, so they can take your things and like, this is where, like, you would trust and you trust either Mozilla or your browser provider, and I think like, some operating systems too, to be like, "Yeah, these... That website is bad. We're taking it off of the certificate authority."

tc: So, the problem with that, right?, is in that instance, if you register amazonn.com or whatever, and you get a TLS certificate for it, that's a perfectly valid TLS certificate. Right? The thing is, when you see that lock icon, when you whatever, that just says, "You are genuinely talking to the website as it appears in your URL bar."

e: Yeah.

tc: Which is important, but not always the whole thing.

e: Yeah.

tc: Um, there is a thing you can get if you're like, a company or whatever, you can get something called an Extended Verification [Editor's note: It's "Extended Validation" certificate.] (EV) certificate, and what these do is they say, "Who as an entity are you?" not just "What is the domain you run?"

e: Oh, I see.

tc: And then, you may have seen it in your URL bar where it'll sometimes appear like, you know, "This is" I don't know, "twitter.com" or whatever, like, or DuckDuckGo maybe has one where it's like, "This is DuckDuckGo Incorporated, this company based in this place" or whatever. And it'll be a little bit longer. But... So that offers sort of more of the human element of the verification in a sense. But that's not the standard. That's not the default. And some big entities -- I don't remember which ones off-hand, but like, maybe Google, maybe Amazon. I feel like one of those two at least, if not both -- they just don't do that because they have some issue with that protocol or something. I don't know. There's some, like, ideological objection to it, or maybe it's just too much of a hassle. I don't know.

e: Gotcha.

tc: So, there sort of exists a partial solution to this, but it's not widespread, and it only kind of partially solves the problem. But yeah, that's an issue with TLS. It... What it verifies is "You are authentically talking to the domain as it appears, and you have an encrypted connection to it. It doesn't mean that the site itself is trustworthy, and it doesn't mean that the site itself is the one that you think it is.

e: Yeah.

tc: Yeah.

Closing

tc: Um, do you want to provide any like, contact information for listeners? Do you wanna like, say what your Fedi handle is or anything?

e: Yeah, sure, I mean, uh... Probably like, link my Fedi handle. It's uh, @ear7h@www.librepunk.club

[Outro]

tc: You've reached the end of this episode of trash cat tech chat. Check out the show notes for links and other information. This podcast is licensed under a Creative Commons Attribution-ShareAlike 4.0 license. Music by Karl Casey @ White Bat Audio.

More info

Credits

Music by Karl Casey @ White Bat Audio