Hoi hoi, I'm Dr. Sumerian, not a real doctor, and today we are going to answer a question. Is the SCP Wiki safe for kids? You might be wondering why I didn't even ask such a question. Ah, you sweet summer child. But for those of you tuned into the SCP Wiki, you might even be asking, oh god, which person got banned now? And a ban did happen, it did sort of inspire this, but that's not the real point of this. Let's look at some data. The SCP Wiki runs a yearly survey, and one of the questions on there is related to age. Now, putting aside from the stupendous problems with asking kids for their ages, in the age of the Child Online Privacy Protection Act, and ultimately hoping that volunteers with no legal degree are getting all the requirements of that right, we do have hard data from 2022 that we can examine to understand the site's demographics a little bit better. This is the survey results. It should be noted, by the way, that joining the site itself requires you to be 18. This survey includes results from people who are not registered with the Wiki, but just read articles. Now, as you can see, 4.86% claimed to be under the age of 13, which is actually a stupendously high number of people, because I'm sure there are more that just either didn't interact with the survey or didn't answer honestly. 29.5% claimed to be between 14 and 16, and 20.68 claimed to be between 17 and 18. Now, it's a little hard to get an exact determination of how many are under the age of 18, since 17 and 18 are included together, but 55% of the respondents claim to be of high school age or younger, and I guarantee you that the number is actually higher, because, again, in order to register for the site, you have to be 18, and the people who register for the site are more likely to answer this survey. Now, is this whole thing of, say, 55%? Just pretend like that number isn't lower than it should be. Is 55% of the people on the Wiki being high school age or younger a problem? Yes. And no, I guess. The problem arises from the fact that the site's average age is below 18, but the content creators and staff are all above 18, because of the rule of registration I mentioned before. It's likely that some staff and creators are just lying about their age too, but that's not really a point here. The problem isn't the kids, see, it's the adults. There have been many scandals throughout the years involving sexual misconduct relating to staff and users on the SCP Wiki. Bright is one of the most recent ones, and most of you have probably seen my video on Bright's misconduct already. Rest assured, though, this is not the only person who was involved with this kind of behavior, and I will say I've known several of these folks personally, as they were other high-profile users, and as each one of them turned out to be a creep, I had to ask myself, why I never saw it coming? You feel like that's the kind of thing you would inherently know about someone, but I didn't for quite a lot of these people. Part of that's probably just aloofness on my part. I don't get to know anybody very well, but I can't help but think I screwed up and missed something from time to time, or excused something that I shouldn't have.  I've had this conversation with people on Discord before, and it always comes down to this. There are certainly valid avenues for adult content, should you want to write that, but there's nothing saying you have a natural right to post it to the wiki, and if you do so knowing that about half the people who read it will be below the age of 18, then you've made a decision. We can talk about the appropriateness of that decision, but you can't pretend that you didn't exercise free will on the subject. It's not just the content on the site, by the way, but also behaviors of people, but the content is reflective of the acceptance of people to put adult content or adult behaviors in front of children. One way a lot of authors relieve themselves with the burden of responsibility here is to throw an adult splash page up on their work. It's a little sort of like entry landing page that warns the user that the work is for adults only. It forces them to click to confirm before they read it, but this just circles back to making a choice. You know that kids will read this. So why are you leaving it in a place that kids can pick it up? I mean, it's an inexact metaphor, which absolutely wouldn't leave a book containing adult content on a park bench just because it has a clear warning label on the cover.  But of course, there's another hitch here, too. It's hard to argue to someone that they should write what they know to an author when those authors are mostly young adults and teenagers themselves and then to admonish them after they do so because they wrote smut. This is the stuff that's occupying their minds a lot of the time. But I think just don't post it here would be a pretty good way to go about it. But we, and what we I mean, those of us who are adults and not just young adults, but like older adults. I'm 37, 38. I'm so old, I don't remember how old I am. Have an additional responsibility to keep an eye out for creepy behavior. I'd argue that you shouldn't be engaging in any adult behaviors with folk you know online, but they also know arguing that would be a lost cause. Just keep it nontransactional. Keep consent in mind to be goddamn sure kids aren't seeing this stuff is going on. Remember that behaviors you treat as normal then become normalized for everyone else. The Internet is kind of a great equalizer in many respects. Kids don't look at you doing a thing and think, oh, that's only for adults. They think that's for everybody. It's hard for a lot of people who are young to draw distinctions between what behaviors are OK or for adults and what are OK for kids. As an example, if kids see you setting up a secret adults only chat room, they'll do the same thing. But with other kids and sometimes not kids will sneak in. Does that mean you should never do it in this community? I'd argue that the answer is yes. I've evolved a bit on this topic over the last 10 years or so, but I definitely think we can do more to protect kids on the wiki by just straight up keeping adult content out of the community as a whole. Creeps exist. There's a lot of them in the world. And because of that, it's probably easy to just go, meh, not my problem. Where are their parents? Let them handle it. But that's abrogating your responsibility.  And if you're an adult and you've chosen to remain part of a community where over half of the users are kids, be vigilant and be careful. That's it. Thank you very much for watching. If you enjoyed the video, hit the subscribe button, then hit the notification bell next to that. So you're notified when I upload new videos. If you'd like to support the channel, head on over to patreon.com forward slash decimarian and pledge at any level like everybody here on the screen already has, including Cingeriki, who's pledged to the hundred dollars. It is nice to know that I'm not alone out here and I will see you all again soon.


All right, so here we are. I'm a little bit surprised too. It takes me about five minutes to realize, to go from, wow, I'm really tired to, I guess, we're giving a presentation. So we're going to talk about building a session layer. And as usual with these types of things, it's good to start at the beginning so you can end at the end. And we need to talk about what a session layer actually is. It all goes back to the seven-layer ISO model, which was designed by committee sometime back and has been more or less replaced with a four-layer TCP-IP model. But let's go through it anyways, because it's important. First layer, physical layer, the actual wire, the air, the everything that actually makes up the physical networking. Then you have your data link layer, your ethernet, your 802.11, your FDDI, that kind of crazy stuff. And then pretty much on layer three, you just have IP. On layer four, TCP, UDP, all those. And then we come to the session layer. Pretty much no one uses the session layer. Some people describe TLS and SSL as the session layer. Not really, but it's the closest we have. The session, or excuse me, the layer six is the one probably that everyone makes fun of, because it's character encodings and problems that we solved 20 years ago. And if you actually are discussing the ISO seven layer model with someone and they're not a fan of it, they're usually going to point at layer six as the one that's pretty much useless. And then everything else goes into layer seven. And we've been seeing more and more and more of everything going into layer seven. And that's what we need to, or what I'm trying to reverse here. So if the session layer isn't here anymore, where did it go? It really went everywhere. It's all over the place. You have SSL, SSH, IPSEC, all some forms of session layer in their own different ways. The idea that an individual application should be authenticating users, why would you do that?  My typical example is I want to use SSH keys to log into everything. The fact that I can't log into my web server with an SSH key infuriates me. So basically, a bunch of stuff got pushed from the session layer into layer seven, because we never got around to implementing it. This was about 20 years ago. Maybe we can change that today. So this causes more code. When every application is writing authentication functions, their own encryption layers, their own stuff to describe what a session is, it's just wasteful. More importantly, it's more buggy code. Most of the security vulnerabilities that really matter, security vulnerabilities in the authentication code and the encryption code, actual problems. Session layer code that shouldn't be in the application in the first place. And while we're getting rid of things from the application, let's go ahead and, you know, we've got application multiplexing in layer four. What I'm talking about here is port numbers. Your TCP and UDP layers are actually doing multiplexing. They're not just providing a reliable byte stream, but they're telling you which application to talk to you on your computer. Why should we have that there? I don't know. So we're gonna yank it and layer five it. By the way, the software itself that I'm presenting here is five short for layer five, damn it. Currently, don't run it. It's very much a piece of software that is used for demos. A good portion of the development cycle may have happened in my car yesterday. There was quite a lot that's changed, even over the last few days. And certainly if you run it on your computer as root, which you need to for the port number, you know, capabilities, et cetera. But still, you need some level of privilege. A two-year-old can hack your box. So really, don't run it. I'm not having my wireless card in my computer right now for a very good reason because when I demo the software, it would get owned.  So, here's what's going in. Application multiplexing, authentication, encryption. All in the session layer, all out of layer seven, pushing it into layer five, and we're gonna have software to do it. Things that go away. Port knocking. This was an idea that I just loved a long time ago when someone first said, you know what, we should be able to establish authentication by sending random packets of the specifically described sequence of ports.  I thought that was really clever. But, you know what's more clever? Doing it right. So, we're gonna try and do it right here. Host-based firewalls. You know, everyone loves firewalls. So rarely do they actually improve anything, especially when it's on the host. Your applications are just gonna punch holes through in many ways. Let's try and actually make it so that if you don't have services you wanna expose to the world, you don't expose the services to the world. V-hosts. This was a thing put in web servers a long time ago because we couldn't figure out how to actually multiplex anything on top of anything. And so, instead of getting 17 different IP addresses to determine what website your web server shows when you go to the web server, you use this thing where you stick in the host in the header and now the web server knows what it's supposed to show you and it shows you something completely different. Now, of course, when DNS breaks, which, when Dan Kaminsky's around, it seems to do pretty often, this all goes pretty chaotic.  So, it would be nice to try and see if we can get, can't get rid of this, too. You know, the typical setup on a nice, on a nice lightweight server these days is you've got a front-end web server that's doing proxying to back-end web servers and you've got load balancers and all kinds of things that are really doing this type of thing. And in really, they just really wanna be a session layer. They really wanna be a session layer. So, we're gonna try and help them. And we're gonna try and get rid of authentication as much as possible. Obviously, you can't do everything. But, you know, a lot of it, you just don't need it. You can authenticate yourself to a machine and you can get all your services one central place. I mean, we have Pam. That was a great start. But it doesn't work so well on the network. Port numbers, yeah. Really, I'm trying to get rid of port numbers. I think they're terrible and I think they need to go. Yeah. So, if TCP and UDP hadn't done them, we'd have had a real session layer. We'd have had it 20 years ago. Instead, here we are, no session layer. Port numbers. So, kind of a big deal. Just a little small change here. So, please quickly, you know, if you're on the same page here, please shout an expletive. Or, excuse me, if you're not on the same page, please shout an expletive. There we go. And if you are on the same page, which none of you should be, hmm, interesting. You know, not a whole lot of audience participation from you folks.  Thank you. I appreciate that. If we can have a little bit more shouting of expletives now and again, accusing people of hating freedom. There we go. You know, I'm awkward when it's just me up here and I haven't slept. So, a little shouted expletive really helps break the mood. So let's take this slowly in the order of most surprising to least surprising. No port numbers. Probably the most surprising thing that I'm going to tell you that I'm trying to get rid of today. There's some precedents. Port mapper, common RPC service. RPC services generally didn't run on the same port twice. So you needed a port mapper to map an RPC service to an actual port. Very similar. It used ports, but it's kind of the same idea. So really, it's doing the same thing DNS does with IP addresses, except it's doing it with ports. Those of you who really love DNS are gonna quietly mutter to yourself, well, what about SRV records? And the answer is you don't use them, so why are you telling me about SRV records? You know, yeah, and there's a reason none of your software uses them because not every machine runs its own DNS server. The sysadmin doesn't control the DNS most of the time. Someone else controls the DNS most of the time, so it's not really smoothly integrated to expose those services via DNS. It's just not a good mechanism for port numbers. It's a decent mechanism for IP addresses when Dan Kaminski's not around, but for port numbers, it's just not very good.  Well, RFC 1078, it's one probably no one has heard of. Has anyone in the room heard of this RFC before? Thank you. It's a very little known protocol called TCPmux, and if you can't guess, multiplexing is gonna be a theme in this talk that kind of underlies, but isn't terribly well exposed because I made these slides when I was way too tired. And it celebrates its 20th birthday in November, which means it's almost as old as I am. It is, in fact, one year older.  Yeah, as it turns out, the fix was way to wild. So TCPmux is actually a very simple protocol. Its entire specification consists of one paragraph. If you read the RFC, you know how they're laid out, they've got a lot of standard sections and it's less than two pages long. Maybe it's three. I can't remember. Anyways, the actual protocol specification is a paragraph. Help provides a list of service names. That's help, H, E, L, P, all caps, CR, L, F. Yep, type of service name, followed by CR, L, F. Server responds with plus or minus, the characters, followed by an optional message, and yes, CR, L, F. And then it says simply, the selected protocol starts. Not sure what that means always, but the selected protocol starts and that gives us a little bit of room to do things that are a little bit, not entirely what they envisioned. The RFC is completely silent on what happens after the selected protocol ends. It doesn't make any mention whatsoever. In fact, it just ends the protocol specification right here with the selected protocol starting. So we've taken some liberty with that. That and the idea of services, we added some, oh, sorry. The main point that we really need to use this RFC is it provides a very, very sexy port number. Again, I'm getting rid of ports.  You might as well choose an arbitrary and sexy one, right? Run the command and you get, there we are. Port number one. Did anyone pay close attention in their et cetera services file and actually ever see this service? I didn't know this was the one that claimed the first port until I got annoyed one day and said I wanna run something on port number one. What would I have to do? And then I submitted a talk for DEF CON and read software a couple days before and here I am. So since that port number is too good to pass up, we're complying with the RFC to the letter, all couple hundred of them. And our protocol is extended via services that are built into the daemon we wrote and enable additional features. Contrary to the Microsoft embrace extend extinguish approach, this is going to be the embrace make awesome and make awesomer approach. So our built ins, as of today and I'm not joking as of today, obviously we have help. This is required by the RFC. It lists your service names. We have off, a demonstration of which looks like this.  And then you can enter a username and you can enter a password and it tells you you've authenticated. Now for those of you who are picky, you'll notice that when I demo this, this is the same username and the same password and if you were to try anything else, it would probably fail unless I have a bug in which case it might succeed. So yes, it's hard coded in at the moment. Host, this one is what we're gonna use to get rid of vhosts and as you can see, here's our service, host and it asks you which vhost and you go to vhost and then it knows your vhost and it goes on about its day. This one is the one that actually probably matters from a security perspective for most of you. It's the one that actually allows you to make this thing secure so that when you're typing in user names and passwords, they're not going in plain text. This is the protocol that does exactly what you think. You type in SSL, it waits for you to start an SSL handshake. You start an SSL handshake and it presents you a certificate signed by a 512 bit RSA key, self-signed by the way, yeah. So obviously some room for improvement. Multiplex, which does all the really cool things. In fact, when I was first thinking about this software, this service didn't exactly come to mind. It's why it doesn't show up in the description of the talk. You'll notice in the description of the talk I listed several things like wouldn't it be nice if we could do X, Y and Z? And I never said run 17 TCP connections over one actual TCP connection. This one does that. So it basically, you take as many layer seven pieces of data and you shove them on one layer four connection or one layer five connection, if you wanna get specific now that we bothered to reopen the layer. And so this changes networking a little bit. The traditional model is your application connects to another application. I mean, this is standard. You have your application. It makes this call. It tells you what port it wants to connect. It goes off to another computer and says, I wanna talk to the application on that port. It's application to application. With this software, your computer connects to another computer. And your applications use that session to communicate very similarly to what happens today. In fact, we're gonna use several existing applications. And by existing, I mean net cap. So maybe it's running a couple of shell scripts too. So in general, it looks like this. You've got your actual app and it connects to your computer's session client. And that connects to the actual session daemon, which connects to the actual service. So the arrow between the session client and five is the one that's supposed to be long and they're supposed to be an internet in between there. I don't have a little cloudy symbol, so I didn't put the internet there. But that's where the internet would go. But as a matter of fact, if you really wanted to, you could put the internet in between any of these. So five could act as a load balancer. It could act as whatever you needed. It can be the example that comes to mind since I'm a student at UCSD is, we could have one session server and it would be ucsd.edu. And then everything could go through that and you could just have one sweet sign-on system and I would only have to identify myself once. I could get my mail. I could change my grades. Wait, not change my grades. I could do all the things that I would expect to do as a student. Drop classes actually I think more often than changing grades. So we're gonna go ahead and demo it now and we're gonna try and ignore the fact that I don't actually have four different computers and that really my computer is just pretending to be rampantly multi-personality here. And let's see. First off, Book of Mozilla. I don't know if you ever noticed this but if you type in about Mozilla and Mozilla, it comes up with a different one that they change every now and again. Anyways, so let's pop this thing into presentation mode. That didn't work. Can you see that? Yes? Yeah, see it. Awesome. See it. So here we have our demo client. It is in fact named demo and our usage is you can pass an S switch or an M switch. The S switch does SSL and the M switch does multiplexing. The reason we have a demo client instead of me just showing you with NetCat is because I really tried but I can't do an SSL handshake in my head. I wish I could but it's just tricky. The exponential encryption, it's tricky to get right. Okay, so starting the daemon, we've got the services running and we're doing pretty well on time. Um, too well. I'm going too fast. Oh well. So we're going to use our demo client. Oops. And here it is. Help. And there we are. So as you can see, we have a perfectly RFC compliant, very simple server here. It's offering, really? Hold on. It's gonna be a little bit tricky. Oops. And... Is that good? Excellent. All right, so help is listing the following service, the multiplex one that we saw earlier, the SSL service, the auth service, the host service and a web service. Everyone loves the web except me. I'm a communist. But we actually don't want the, we, yeah, I know. We don't want the plain text one because that's just, you know, it's so much more satisfying when you use a useful scriptographic layer that, you know, is blatantly men in the middle attackable because of bad certificates. So we're gonna enable SSL and now we go ahead and the demo client goes to the server, it goes ahead and does the SSL service and does a handshake. And as we can see, the SSL service is no longer available because we've used it. And we're gonna go ahead and switch hosts.  I don't know why, but you know, everyone used to have an echo daemon running and then of course someone put the character generation daemon and told the echo daemon to go find the character generation daemon and the box proceeded to do as itself. Anyways, we have an echo daemon here but we're gonna use the hello one because it's nice and courteous and it says hello and then there we go. The protocol's over, the selected protocol began and the selected protocol ended and our connection is done. Simple, right? I'm done, no. So the idea though is that we want our sessions to be just a teeny bit more persistent here but before I go there, let's show the, let's show the rest of the off here. Oh, with SSL, there we go. Man, okay. So it would be wonderful if, when I'm looking for a service, it's almost always that I'm looking for a shell. Oh, well, I guess I'm not gonna find one or at least not until I tell it who I am and now I have a shell. See, it's a shell. There's a shell. Projects, five, oh, it helps if you can type and there's the entire source code for the program. I hope you caught that, was it a little fast? Better? So, so I think at the moment that this now qualifies as self-hosting which is a milestone in the development of every source code management system except this isn't a self-source code management system but if it was, it would be self-hosting and we've got a shell that we're now gonna exit from. Okay, so now we need to stop getting our things actually where the protocol ends and everything goes to help. So let's use this multiplexing thing that we're so excited about or, well, I'm excited about it.  So now we're, you know, the S switch enables SSL, the M switch enables multiplexing and here we are. We've got a multiplex connection. We can do our things before. Let's go ahead and get ourselves authenticated, demo, demo pass and here we are. We're authenticated. Let's throw ourselves, ah, you know what? Let's go, you know, let's throw ourselves into the other V host, can't type and here we are. We've got our list of services, auth, host, shell, echo, hello, web. So web, so now instead of actually starting the selected protocol, the server starts the selected protocol but this is the client and the client noticed that the server started a separate protocol and noticed that it got embedded, slip streamed if you will, into the existing session that was open. So now the client, our little demo client has gone and opened a port on local host that allows us to access this separate service so that any communication that happens on this port in the future can be slip streamed back through this one connection because, you know, Firefox doesn't yet really know how to interact with my software. They're very slow. I mean, I made it yesterday. Anyways, not with the laughing these days. All right, local host and here we are. We have a fun web page because it's the fun host or the toys host and here we are but you know what? Now that I think about it, I don't want a web page with red in it so let's go back to the main host which is more of a business friendly web page.  So now we have three different layer seven connections going. We have the main one that's interacting with the help menu. Notice how we can still use this one. This is still giving us data and we had the old web connection which we shot in the face a while back and now we have this web connection. They're all running over one physical TCP connection, only one and we're not taking layer two packets and throwing them in layer four. We're actually legitimately taking the layer seven data and putting headers on it and not headers on each packets but actually headers within the reliable byte streams because the software knows nothing about packets and frankly shouldn't know anything about packets. So now we have our web. You know what? Let's get away from the web. So here's our help. What do you think? I'm taking suggestions on what the next service to multiplex over this connection is gonna be. Telnet. I've got a shell. Do you want a shell? So here's a shell and we can connect to it through Telnet but Telnet sucks so let's use Netcat instead. And so oh wait, we switched out a presentation mode here. Darn it. Here we are. Now you can see it. So Netcat, we're going to the socket that our client opened up for us and lo and behold we have ourselves a fully functional shell as long as you don't want to prompt or anything else that might resemble a shell. Notice the reset commands absolutely do nothing because you're not running on a real terminal and this is not a terminal in the later. Which from what I understand is about as functional as the SSH functionality on the iPhone these days. Yeah, we went there. Yeah, so now let's start an Echo server. Oh, what do you mean no such service? Well, let's go to the one where don't have spaces at the end of your service names. It's not the service you thought it was. Now let's go back to the host that did have the service, help. There's our Echo service. Gotta love the Echo service. You know, it's always boring when someone's sitting there typing commands in a computer. I wish there was something that I could do but it's hard to show you it any other way. I don't have a nice 3D visualization for networking traffic, I'm very sorry. Okay, so here we are. And...  Yeah, so as it turns out, no spell check here. The computer is happily repeating everything back to us and of course we still have our shell running over here. Perfectly functional. So let me just recap this again because it's a very subtle point and it's very important. This connection, connection, is running on the same connection that this connection is running on. They're both on the same TCP connection.  Dead, completely gone. They're not separate, it's all in the same thing. Where we're using our session, we were known to the computer at the same time, we were completely authenticated and they all went away. So since I'm running faster than I thought I would, let's go ahead and explain exactly how this works from a little bit more of a technical perspective. So I said that it was multiplexing layer seven connections down onto the layer five service. So the way you would think that this would be done is you would add a header in the packet and it would tell you which application it is and if you think about it for a moment you would have realized that you would have just implemented port numbers because that's exactly what TCP does. It takes each packet with an actual number that tells you which application it's coming from and which application it's going to. So we're doing something slightly different. We're actually treating TCP properly as an in-order byte stream and we go ahead and we throw a header in as soon as multiplex mode is enabled, we throw a header in that says high basically and a header consists of 16 octets for different fields. The first is a version number because if you don't have a version number when your protocol changes everything breaks. The second one is a application ID. You can pretend it's a port number if you really want. The third one is a series of flags out of which two are defined and the rest are reserved and the last one is a length and the length dictates when you'll see the next header. So that's how it works. You know in advance when you put a chunk onto the network you take it with the header and then you tell it where to find the next header. And so it's constantly picking up these headers and then taking the next piece of data and then taking that data and throwing it at an application and then looking at the next header and then slurping up however much data it says to slurp up and then taking that one and throwing it at a completely different application or the same application if the same application has done something twice. There's some optimization tricks you can do here that we didn't but you know it's very much possible. So let's see. We finished the demos. We bored the audience. We talked about communism. Okay so what? More about communism? Soviet Russia.  You know IPv6 is sweet. You should all use it. We're running it at home. Automatic configuration.  You grab a tunnel. Suddenly all your computers have IPv6. I joke that it's given me back the internet again because I have a public IP address. You know it's a useless public IP address because no one can contact it but it's a public IP address nonetheless and I'm very happy with that because I had public IP addresses way up until 2000 actually way through all the way down until I moved into college and then I was in a metropolis and cable modem. Anyways, other random parting thoughts. Intel provides micro-cut updates. Most Linux machines don't run them. Almost all Windows machines do. This is the one place where Linux is really just far behind in security. For those of you who are wondering why I'm not talking about anything related to my topic, it's because I'm near the end of the presentation. He should know because he has to actually deal with X86 all day. Poor man. Yeah, he tells himself that every night as he weeps himself to sleep.  The last one aren't just philosophical points. Anyways, also for those of you with conference CDs, the slides on them are not the same as the slides I've just presented. They're not quite as terribly atrocious as I said, but there will be updates on the Defcon website and my own website and you can grab the current copy of the slides if for some reason you wanna see the slides that had so much information on it like demos, demos, demos. This is really an informative slide and you should take it back to your workplace and share it with your coworkers. What's your website? I'm getting there. Just hold on. Would anyone like to accuse me of hitting freedom or ask me a question? This will continue in room 104 later. I'm sorry, can you? Yeah, so the question was, how does it know when to close a session? So the session client manages completely the session with the session server. So the session client can close a session whenever it wants. If you're asking how the individual applications that are multiplexed on top of the TCP stream know when to close, the header has, again, I said the header had two flags that were implemented. One is this ID is new and that symbolizes to the actual session client that it needs to open up a new stream. And so whenever one of those headers came in, that's what caused this thing to spawn off a port here. So you see this where it says listening on port. That was directly because a header was sent to it that said we have a new ID. And for closing, there's a corresponding one that's the delete flag and it does much the same thing. Yeah, I can't even hear you. I'm very sorry. It identifies itself to a web server but it's only made to identify itself to a web server. It's not made to identify itself to a telnet server. That needs to happen on a completely different layer. Someone else? I saw a hand back there. I'm sorry. Can you stand up and scream a little bit louder? Is it gonna be a nightmare for network monitoring people? So I'm really wondering where you got the impression that things weren't already a nightmare for network monitoring people. I understand the concern and I gave a talk at... Well, hold on. I understand the concern and I was actually with you last year. I gave a talk last year about how virtualization is gonna ruin the world because your hardware firewalls basically don't work anymore. People have come to similar ideas recently and the answer is, is it gonna make it worse? Well, yes and no. It's not going to make it substantially worse because it can decode the layer five traffic just as easily. It can decode anything else unless you encrypt it. So the question you need to ask yourself is, are you against encryption because you wanna be able to monitor your network better? And if the answer is yes, then yes, this is going to make your network a little bit more of a nightmare because it's actually going to make people encrypt most of their stuff. I don't know if that's a trade-off you wanna make. You know, you can put as much logging into this thing as you want. What? What was the last bit? Yeah, I get that a lot. You know what? I have another car drive down. So power inverters are great things and maybe I'll get some more coding done. But at the end of the day, I'm just not convinced that network monitoring actually gives us nearly as much as it thinks it does because your attackers are very rarely being so nice.  And that's not gonna change. I think there's nothing fundamentally different about this. Yeah. I'm not advocating SSL here. It happened to be the one that I implemented. I actually really dislike SSL. I don't like the CA model. I don't like the certificate model. And I think overall, it's a fairly poor protocol. You know, not to rake on the SSL guys too much, but you know, there's been breaks because of it and I feel much more comfortable with a model like PGP or SSH or even IBSEC to some degree. And there's nothing that would stop you from applying the same cryptographic properties of IBSEC into this. And there's nothing that would stop you from running sessions over IBSEC. It's a different layer. Would it decrease the necessity for IBSEC? Yes. Yeah. Tell them to report. Yeah. Yeah, and in fact, if you notice, I actually had it running as a user here. So I wasn't using the new capabilities of the kernel. So I wasn't running it under port one either. So there's nothing that says you have to run it under port one. It's just that you can and it'll actually be RFC compliant for the purpose of the port. Which, you know, makes me happy. Anyone else? Yeah. Not even a little bit because Oh, okay. Yes, to some extent, because at the end of the day, your client see your actual SSH, excuse me, your actual session daemon sees an in order byte stream, a drop in one packet will cause a drop in the other, which is no different than using TCP elsewhere. The other thing that, you know, people run to UDP a lot just to implement low latency things. And I wonder if they've seen the urgent pointer because there's nothing stopping you from applying it everywhere. Now you would need to change how the headers are doing, how the headers are working and how the multiplexing would have to happen to use this. And you would need to give it a little bit more concept of what a packet is. But there's no reason why you can't use the out of band data mechanism to provide a highly, or excuse me, a very low latency response time over TCP. Yeah. Yeah, not terribly familiar with the protocol, to be honest. How do I feel that it competes with SCTP? Which is a, if I remember right, it tries to be a replacement for layer four. Yeah? So by the description that I've seen of it, it's doing things a little bit differently. It's not actually, you know, a lot of things can be compared to this. How do I feel that it compares with a VPN? How do I feel that it compares with Stunnel? And the answer is, well, they're kind of similar. But this one was made with a very specific purpose that so far I haven't seen fulfilled. And it's kind of subtle, and I'm not sure I did a terribly good job of explaining it, but if you'd like to send me an email, I'd be happy to go on and on for pages about it. Yeah? Yeah, absolutely nothing at the moment. But sorry, the question was, when this happens here and your client says, you know, I'm opening a port to whoever wants to grab it, the question was basically, can someone else grab it than who was supposed to? And the answer is yes, absolutely. But obviously this solution that we used here in this particular one about opening a port and making it a free for all for everyone is not the one that we would want to see eventually. If this were to actually go anywhere, you would want to see it integrated at the low level syscall level where it would actually be able to appropriately identify which applications the user intended to use, if that makes any sense. It would need some knowledge to be properly functional, yes. Instead of asking for a port number, you'd ask for a, you know, right now you go ahead and you give it an IP address and a port number and the operating system runs off and starts a TCP connection for you. So instead you give the operating system a IP address and a service name and the operating system runs off and starts a session for you if one doesn't already exist and if one does exist, uses that. Now you're gonna go, what about different users? And the answer is different users should have different sessions. So it would actually look at your UID and it would give you an appropriate session for your UID. So your apps would all be authenticated, but someone else's apps on the machine wouldn't get your authentication. Any other questions? In that case, please get drunk. Oh, what? Well, the reason SIP is negotiation, yeah, right. The question was SIP goes through an auto negotiation process to find a port number when it actually connects between one person and another. Part of the reason it does this is to avoid firewalls. And this goes back to the networking monitoring question and his question was basically what happens to network monitoring? And the answer is, well, it gets a little bit different. You won't have firewall ports anymore if no one's using ports. So the answer to the question about what does SIP need to do, it's straightforward, it uses the name for SIP and it says I wanna start a SIP connection. And if there's a firewall that happens to be around that sees that, it can block it just as if it can block ports today. And in fact, from one perspective, it makes the network monitoring side easier. From the other perspective, if you enable SSL, it all goes away and it can't see a thing. So if you enable SSL, radically easier, if you wanna monitor your network, radically harder. Yeah, you're going to be going deeper into the packet in the sense that, yeah, you'll be going through another layer. Conceptually, you'll be going deeper into the packet but whether that actually translates into a hardware performance problem, I'm not sure I'm convinced. Yeah, you have to process it differently but you're not necessarily processing more data. You're processing port numbers now anyways. So it's not fundamentally different. The exact construction may make it so that it's less computationally efficient. Anyways, it's about that time. So I'm gonna go ahead and wrap it up and if anyone has any questions, room 104. Thanks.