So hello everyone. It is great to be here at DEF CON 19. Thank you all for being here. If you don't know me, hi, I'm Dan Kaminsky and I write code. I am not here to fix authentication or regale you with stories of DNS or DNS sec. These are still things I'm working on but not today. Today is a returned form. As a community we have sort of, was anyone here out of curiosity at my talk in like 2002 about black ops and TCP IP? Like anyone? Awesome. This is a sequel to that talk. First impression ever. Let's see how about this. Is this good? Logistics. No. How about this? Is this work? Awesome. Thank you guys. All right. So we sort of stopped looking at network security, you know, mapping networks, evading firewalls, subverting design assumptions. You know, the various arts of messing with packets kind of been abandoned and that's sort of a good thing. You know, when you actually look at how systems are broken into, it's the same game every time. SQL inject the web front end or PDF, the client back end. Take whatever credentials are on the box and move on with your life. It's not hard. Making hacking look difficult is just something we do so we look awesome to the other people. NetSec is only so relevant in such an environment. You know what? I do not care. This is what I like doing back in the day and we're going to play with the packets. So what are we going to start messing with here? We're going to start messing with all things Bitcoin. Why not? It infects everything else. It should hit my talk too. You know, what is Bitcoin? Well, it's an attempt at making a digital currency with no central bank. Yeah. It's a system with economic properties. I don't know anything about. I'm not an economist. But to be fair, neither are most economists. So it sort of works out. It's an overlay network upon the internet. It's like an internet on an internet that people think has certain properties. Now that is a toy to play with. So Bitcoin is built on doing three things. Transferring money. I, Alice, give Bob 2.1 Bitcoins. That's done with public key cryptography. You sign the message. And then there's gossip. Hey everybody, did you hear that Alice gave Bob 2.1 Bitcoins? Alice ahead and gossips that out and it just spreads throughout the network like wildfire. Look at this great new news. And then there's a pending. Once about every 10 minutes, someone on the network does enough computation to say, aha, the official record of all transactions ever should include that Alice paid Bob and Bob paid Charlie and Charlie paid David. And, you know, it's a lot of cryptographic work. How do you know if you've done enough work? Well, if the network generates answers any faster than 10 minutes, you make the problem harder and harder and harder until it takes once every 10 minutes. It's really quite elegant. In its fit, you know, if it goes too fast, itself corrects. So, talk about Bitcoin. This is not my Bitcoin talk. Go to DanKaminsky.com. If you want to see some slides on that, the good news is that Bitcoin is really impressive. Anyone who's all dismissive of it and, you know, it's got all these bugs? No. They're just like missing. Like the first five times you think you understand Bitcoin, you're not even close. I'm on major bug nine on Bitcoin that I was absolutely sure was going to work. Now, they like, like the line of code that would have made that bug work is just not there. It's the mark of a pentester is upon this software. Bitcoin is fixed almost all the flaws that aren't forced by the design. However, there are flaws forced by the design. It totally does not scale and it is absolutely not anonymous. What do I mean? If you go to the scalability page on the Bitcoin wiki, you will see the funniest document in the history of software engineering. Let me give you some quotes. I don't even need to talk about how Bitcoin doesn't scale because they say it. They're like, yeah, for bandwidth eventually we're going to acquire every machine to exchange a gigabyte a second. What? You know, CPU, you'll have to have 50 CPU cores just to participate in storage. Well, you might need a three terabyte hard drive every 21 days but it's cool because they're like only 200 bucks and that's pretty affordable. Like this is their own page. I'm not making this up. So, you know, you end up with like super nodes that do special stuff and everyone else who trusts them. We have another word for this. They're called banks. I'm not saying banks are bad. I'm just saying all of these economic properties of Bitcoin that everyone likes today are going to be gone tomorrow. Now, I'm not saying those are the properties of a posi scheme. Until we get to this point that Bitcoin completely has to shift over to the banking model. Who here knows a very interesting character by the name of Travis Goodspeed? You don't even know how ridiculous this guy is. But he asked me a great question. He said, damn, could we use Bitcoin as a Sama's dot service as a way to store information and distribute it? You know, three terabytes is an awful lot of data. There's an old challenge. I haven't thought of it in years. And it's, well, the internet is about sending data from point A to point B. At which point it just magically disappears. What if we could get away where it didn't magically disappear? Or in fact, it's stuck around forever. Well, the reason you need a three terabyte hard drive in Bitcoin is because basically all the transactions have to live forever somewhere. So, if it's going to live forever, what could we do with this? Who here, who here knew or knows Len Sassman? Len was one of our brightest lights in our community. There's a command that one can run on Bitcoin today and on Bitcoin forever on any node running Bitcoin. Strings, bytes equals 20.Bitcoin slash block 0001.dat. Strings will go ahead and extract human readable text from any blob of data. We usually use it to find hard coded passwords inside of statically linked executables. Well, if we run this on the block database of all transactions ever moved through Bitcoin on any machine in the world participating, you know what you get? Well, Len was our friend. Len was a brilliant mind, a kind soul, and a devious schemer. His husband, Tim Meredith. He was brother to Calvin who is here at his first DEF CON ever. Son to Jim and Dana Hartzorn, co-author of mine and of many others, co-founder at Schmu and so much more. We dedicate this very silly hack to Len who would have found it absolutely hilarious. And just to increase the amusement factor and Len would have loved this, Bitcoin is now dependent until the end of time on Len. Bitcoin is also dependent until the end of time on the head of the Federal Reserve, Ben Bernanke. So, so how did we do this? Uh, in Bitcoin, Alice gives money to Bob by issuing a sort of challenge. Whoever can sign a message with the public key that hashes to the following bytes that has the following fingerprints may claim this money. Well, bytes are bytes. Instead of pushing the hash of a public key, we pushed 20 characters of a testimonial 78 times. There are consequences to this. It does cost money, cost about a Bitcoin. There are minimums to transferring money. This does destroy the money forever. The Bitcoin network is thoroughly convinced that somewhere somehow there must be a public key with the hash that Len was our friend. I am totally cool with that. This is the cyber equivalent of pouring one out for your homies. So, can we get a higher bandwidth? Bitcoin does let you send money to a public key directly rather than a hash. So that gives you like a 10x increase in bandwidth. That's not good enough. Bitcoin allows for extra data in a signature. A really beautiful style too. Um, you see Bitcoin works with small programs. The receiver says, please put this signature in public key on a stack. You know, pile of data. And the program from the sender is, hey, take the signature in public key off the stack and make sure they're good. If you look at this just from a language perspective, Meredith's research is all about language theoretic security. Um, what if there is extra data that the receiver puts on? You know, I don't know, some video file or something. I don't know why someone crazy would do that. Um, well, the sender just says take the signature in public key off the stack. Doesn't say anything about making sure there's not more data. So this just works fine. Now it's funny. This bug shows up all the time in signature checking systems. Um, it's not just the sender of money who can add the extra content. See, a signature can't cover itself. When you sign a document, you don't sign the signature because the signature is not there yet. It's a chicken and egg problem.   Um, but there is time between when the transaction is sent and when that thing happens every 10 minutes to merge stuff in. And in that time, it's not just the sender of the money who can add extra data. It's like anyone can add extra data because it's unsigned. Oops. So this is some limited usefulness. If you're at some random relay that's gossiping this stuff around, you know, Bitcoin just charges you money or bitcoins per kilobyte of your message. So the random relay can't add all that much. So this limit doesn't count if you're the one adding the extra data because you can just pay the fee.  Austin does not count if you generate the block. So if you're the guy who does the work every 10 minutes, you can go ahead and make everyone in the world store 2 megabytes of data no problem. So, uh, I am Ian Travis here talking. Yes, we can totally do the Bitcoin file system. And what about anonymity? Let's look at a block explorer.com. This is the big site that tells you what's going on in Bitcoin.  All these sources are the same guy. Also, you get obvious pseudonym linking in Bitcoin. One of these two destinations is all the guys on the left. That's your sort of change when you've paid too much. You need some money back. Um, and you can build these great graphs. I was going to show you some of mine, but Reed and Harrigan actually did a much better job in that recent Bitcoin is not anonymous paper. So they got their pretty pictures. Now the problem is, is that they got lucky, right? Like, the way they got to IP addresses is some jackass shows up in a forum and is like, hi, I'm Bob Jones and my Bitcoin ID is this.  Uh, another user, you know, another system when it gives Bitcoin to tells the IP of who it gave it to. Uh, so they're, they're getting de-anonymization, they're getting pseudonym linking. Those IDs link to each other within Bitcoin. But if you want IP addresses, that's out of band. This audit trail is noisy and deniable. And, and you know, the authors of this paper know it. Is there another source of data? Well, there are two sources of transaction information in Bitcoin. There's the blocks that contain the historical record. There's also the loose transactions that are getting gossiped all over the place. So it's a relay race. Alice tells Bob and Charlie, Bob tells David and Eric, Charlie tells Frank and Gary. So what you do is you just connect to all the Bitcoin nodes in the world. You say, oh my God, that'd be like 50,000 connections. Yeah, uh, computers are powerful now, it turns out. So when you connect to every node in the world, the first node to inform you of a transaction is the source. He don't relay it because he done done it. Um, so I wrote some code which I can't demo for time constraints called Blitcoin. Does anyone here get that joke by the way? It does accelerated probing of Bitcoin. So how do you find out who to probe? We can just scan the entire internet on 8333 TCP. You can join the IRC channels. Bitcoin runs like a botnet command and control. So you just have this thing called BitBot. It connects to all the IRC channels, watches the live stream of everyone who's connecting. Or you can just add, ask every node, hey, what are the nodes do you know about? And they'll tell you, they'll give you a map of the network within 30 seconds. Now the Bitcoin devs want to be very clear they know Bitcoin is not anonymous and they wanted me to spread this out that, you know, this is just not a feature they're working on. So, um, don't think it's intentional. What about Tor? Well, Tor is interesting. Tor will go ahead and hide the IP address for all your outbound connections when the Bitcoin node talks to the rest of the world. But what if the rest of the world is scanning every IP address on the internet looking for who's listening for Bitcoin? Tor doesn't do anything about that. So there's actually a bug file now in Bitcoin to say when running through Tor, how about we not listen for incoming connections? But unreachable nodes. Well, most are just behind that and you can't connect to them, they can only connect out. We already have sort of a super node situation. There's only about 3,000 to 8,000 Bitcoin nodes, maybe, you know, 10% to 20% of the nodes in the world that you can go ahead and just arbitrarily connect to. And that's awesome. Because now I create another couple hundred incoming only Bitcoin nodes and the other 50,000 depend on me. So they come to me and they make a direct connection. And now again, the first people who connect to me and tell me of a transaction, I know who they are. So probably only need about a few hundred. It's a bit unreachable.  Now there's a protocol that most of these devices accept called UPnP. And it allows nodes inside your network to say, hey, can you let the outside world in? And there's a protocol that allows you to discover that you can ask for inbound connections. I have to sort of speed through this a little. Well, UPnP opens up firewall holes from the inside to the outside. Man, it would really be bad if that service wasn't just available on the internal network. If like, people on the internet could just say, hey, firewall, can you not be a firewall?  Hundreds of thousands to millions of these things are out there.  The Microsoft code is great. It actually requires this random identifier that you have to be on the internal network to discover. But every other vendor was just like, well, you know, we have this code, and it's the most wide, some of the most widely deployed code in the world. And you can reach it from the internet from everywhere. But our budget for this device is like $4. Maybe we are number one on the security. So I don't need to go into this because there's another speaker who found this first. So I just got to refer to him. Daniel Garcia, he's speaking in track three today at five o'clock. He found that there were open UPnP nodes on the net last year. So now we're starting to collaborate to figure out what the exact number is. Another guy, Dutch, Armin Hemel, I think I pronounced his name right. He's doing some great work too. He's at UPnPhacks.org. The one thing to realize, this was found in 2007 and it's still broken. So yeah, things, oh, by the way, the other nice thing about home routers, it's not like they patch. Yeah, it's like a worst case scenario. So what about outside the consumer space? Corporate environments. These are less about Bitcoin and UPnP and more about web services and ACLs and access controllers. It says, oh, you want to access this resource, you better be coming from this IP address. So of course we lie through our teeth. It's called IP spoofing. You just pretend to be some IP that the system trusts. You might say, but, but, but I thought networks block spoofing. It's like, yeah, they block spoofing from like your cable modem. I'm on the core of the internet.  The one thing that does care about IP spoofing though, I have finally found something that the cloud does not do well. If you are running in a virtual node and you want to spoof packets, good luck. You can't do it. The hypervisor will stop you. He'd have to say, I don't know like have a hypervisor exploit. No one has those. So is IP spoofing still effective to do interesting things? Well, there's a DNS trick that I've been sitting on for a couple of years.  You say, hey, go look up this domain. The server goes and runs around the internet and looks for the domain.  You're not going to get the reply with the answer, but that server has to go run around the internet to go satisfy the request. And they'll run around to you. So you now see, oh, okay, my spoof type request spawns another request that comes back to me through another channel. Now this only works for obscure applications like DNS, UDP. Certainly nothing built on TCP, right? Well, limits of IP spoofing. Most modern protocols run over TCP. It's a reliable communication protocol. And TCP has sequence numbers. They're kind of like passwords that are exchanged at the beginning of a session to make sure that each side is really able to hear the other side. And it's rather effective and it means when you don't get the reply, because you spoofed your address, you're not able to get to the point at TCP where data is really going to be exchanged. Now, sequence numbers didn't use to be random, which meant people could just guess them out of, you know, out of thin air. Okay, so let's go ahead and make them random. Well, you can't just go ahead and make them random. See, the problem is that sequence numbers did not start out as passwords. They started out as markers where inside a session.  Are they on page one? Or are they on page 100? Or are they on page 500? Got to know where to put the words. So the deal is, let's save a connection from 24123 on port 50,000 and 4221 on port 53. You got to make sure if there are two connections and all that stuff is recycled that random packets from the old session don't show up in the new session. It'd be like you're reading a book and, you know, suddenly a page from some other book shows up. It'd be rather confusing. So the game is to have, you know, random sequence numbers unless the idea is the same.  And that's done with the hashing function where you hash all the data with the secret. You get some absolute number and you add time. So if you have a slight difference in, you know, 2345 to 2346, the numbers become much different. But if it's absolutely identical, it becomes sequential with time. Now there's a problem. What if someone just floods us with connection requests? They don't have to remember all the passwords. They just need to like flood us with the question. We need to remember their passwords. So we run out of resources. This sin floods older and dirt. So the solution is, it came from Dan Bernstein. It's called Sin Cookies. And basically what is sent out to the the requester is a challenge. If you can read this challenge, if you can respond, all right, I'll go ahead and I'll store some memory. And there's 24 bits of security there. So, okay, 24 bits, that's, you know, 2 to the 24 is 16 million. It takes about 8 million packets to go ahead if Sin Cookies are enabled and guess what the cookie would be. And it might actually be a little less. So DJB knew this, right? It's like, no matter what you do, the attacker will succeed in the connection forgery after millions of random act packets. Well, there's something that's changed in 1999 to 2011. Networks are really fast. Sending 8 million packets, not that big a deal. When you have a spoofed acknowledgement, you can also throw a bunch of data in there. You can throw like a web services payload. So if you have like a web, like an Apache server, and it's behind an access control list that says only connections from IPI trust every 8 million packets, he's going to get a fake packet from an IPA trust, and it's going to be received and get to do whatever it wants. That's good. Now what about on Linux? What do we do on Linux? Well, so Linux has Sin cookies on by default, but even if you disable it, what are the actual sequence numbers look like? Are they RFC 1948? Are they randomized unless you have the same source port, that's port, source IP, that's port, that's IP. Totally randomized. Well, okay, not totally. 3 fourths of it are randomized. The lower 24 bits are pretty strong. The upper 8 bits, no, no, that's just like sequential. Just keeps incrementing one every five minutes. And it gives that number to everyone. So you can go ahead find out the offset being your real IP, and then you know every sequence number that everyone else is going to use. And after 8 million tries, you win. So this lets you go ahead and there are some old attacks on reset hacking, so you'd shut down a session without actually knowing the codes before, or the sequence numbers.  Now it's a one-pack kill. The other problem is that you might have a live session between two hosts. I have to skip through this quickly. I'm so sorry. You might have a live session between two hosts, and there's 64 bits of security between them. Two to the 64 is an ungodly number of packets. But there's windowing, which says kind of like a range of where the password can be. So that cuts off 16 bits in each direction. So now we're down to two to the 32. Four billion packets. Oh man, that's a lot. Now we cut off another five bits, because the windows might be really big. There's something called Windows scaling. Oh okay, now you're down from 32 bits to 22 bits. So now it's a million packets to go ahead and inject into a session. By inject into a session, let me translate this into the world's most difficult cross-site scripting attack. Now because the eight bits are known in each direction, we have a problem, because we take 22 minus eight minus eight, six bits. It takes 16 packets to have a 50% chance of the world's greatest cross-site script. Crap. Now that does get a little harder because there's port randomization, but you know the port randomization adds at most 13 bits, so it's still only 250,000 packets. That may not even happen with port randomization if you have a client that's forcibly setting its ports, which actually happens with DNS and BGP. So status, this is some very old code in Linux. It actually predates Linux Torvalds check-in history into the Linux source tree. So like this bug's been there since like the late 90s. They're figuring out right now the right fix that won't cause even more problems. There's a ton of fixes you could do that would make just things even worse. So digression. Let's check my time here, make sure I'm not going to go over. Alright. RFC 1948 is an interesting construction. It is sequential and ordered if you have secrets and it is random and unpredictable without. It's actually kind of a public and private system. There's the private component, the sequence number is mixed with like a secret and you can generate all possible secrets with that things. It's like a private key. There's like a public component. I give you one of the generated values and if you can see it on the network, you can communicate for that one session as that one IP using that one set of connection identifiers which are ports. So wow, that's like public private photography without nothing but a password. Clearly this is impossible. It's only possible here because we're at the intersection of network security and cryptography. You guys know what public private cryptography is. Just as a quick example, a photo of my face can be a public key and my actual face is a private key. It's very easy for people to identify me from a photo. It's very hard for them to you know mash their face into you know being my face. So it's all about asymmetry. Now I want to be clear here. What I'm about to tell you is a terrible idea. However, nowhere does it say on the DEF CON signup form that everything you say must be a good idea. In fact, not usually the case. But passwords are a bad idea. They're constantly being lost and forgotten and stolen. They're responsible for 50% of compromises. They increasingly look like elite speak. It's not helping. But let's ignore all that for a moment. Soon we're stuck with them. How do we use the password to log into a system without that system learning our password?  That's nice. The web app is still receiving the password in plain text. The attacker just modifies the web app to send the plain text to them. So it doesn't help. Next thing we challenge you to mix your password with this particular hash, and then we'll never have to send the plain text password on the wire. This thing called digest or ntlm. The problem is, if you're hashing the plain text password with some random value, they got to do that too. They got to store the plain text password or some password equivalent version. Um, there are things where you say we require knowledge of the password to complete this complicated asymmetric crypto magic foo. Speak does this and SRP does this. It requires the client and server to run some really obscure code and good luck getting that code deployed. What are you going to do? Is it possible, not advisable, but is it possible to build a system where the client only remembers a password? But the server stores nothing but a straight up public key and deploys no other magic code except the standard challenge to make sure the client has the matching private key derived unilaterally from the password. In other words, can we construct a cryptographic key pair using nothing but a password? So here's a question. Um, and if you can answer it, we're going to go get a drink after. What vulnerability impacted all asymmetric crypto systems be they RSA, DSA or ECC? Anyone? There you go. We'll grab some tequila. Check it out. Debbie and bug had, uh, was basically a situation where every time the cryptographic key generator went to get random numbers, got the same random numbers. So all cryptographic system, all asymmetric crypto systems use entropy as follows. They grab random bits and they permute them until those bits are roughly a private key they need a public key from. Predictable entropy means predictable key pairs no matter what the algorithm is. So what if we said it wasn't the bug? What if we turn the Debbie and bug into a feature? Cryptography is all about constructions. We have hash functions that make fingerprints of data. We have stream functions that stream ciphers that give us a stream of data. We have block ciphers that take data and a key and mix them all together. Um, you can actually turn any of those into any of the others. Well, we also know how to take a password and construct an everlasting stream of pseudo random number generators from random number, random numbers from it. This is predictable entropy. We can even make this stream of predictable entropy in such a way that is both time hard, meaning it takes a whole bunch of CPU to find out what the stream should be from the password and memory hard, which means it takes a whole bunch of memory that I don't know a GPU really can't do on a per per block basis.  Um, so this is a great algorithm called S Crypt that does this. So what if you make the output of a password seeded PRNG, the input to an asymmetric key generator, you end up with 2048 bit RSA keys that have a trapdoor in the form of a human memorable password. This is not theoretical. Actually, went ahead and wrote this. So and the way it's born is just awful, terrible idea. God, I love it. Um, so check it out. In normal key generation, if I run SSHP gen four, three times, I'm going to get three different keys.  Fidelius is saying, you know, LDP, Fidelius.so password of high grandma. My grandmother comes to my black hat talk every year. It's great. She brings cookies. And if you look, I run this twice with the high grandma password and I get 80 od five to and once again, 80 od five to. So is this happening? See, here's what the deal is with Fidelius. Harry Potter properly understood is a story about the epic consequences of losing one's password. This is how passwords fail in the Harry Potter universe. And if you don't get the reference, go find a Dumbledore. What Fidelius does is it hooks dev random and it hooks dev you random and it hooks open SSL random functions. What do I mean by hooking? I mean that the applications try to go get random numbers and my code steps in and goes, have I got some random numbers for you? So this just works like unmodified code. SSHP gen will suddenly develop standardized keys. Open SSL for certificates will generate the same certificate every time. You can get a certificate authority to sign a password. Freebird will even generate consistent DNS that keys.  It solves the login with a password without the system learning your problem thoroughly that you have to install anything anywhere. In fact, the server has no idea there's a trap door and can never find out. So it's, I wouldn't say non consensual. It's more backwards compatible. With Bitcoin, you literally could send money to like a word or even a photograph because you can actually say my private key is a picture of a pony. You can do that. We have the technology. So there's no pain server side. All time memory hard requirements are limited to the client. There are a couple of issues that are totally real. The obvious ones passwords suck. The non obvious ones. It is fragile. It is dependent on the peculiar way that SSH key gen 5.3 P1 turns random numbers into a final key. That's what you get for being an implicit scheme that, you know, tries to make function hookings useful. It's also hard to salt. What does that mean? That means everyone who uses the common password password is going to generate the same certificate every time. So that kind of that's kind of a problem. Now you can fix that but not implicitly not for free. You basically have to have a situation where a randomized salt, a thing that says five different instances of the password password are going to get five different certificates. The public side needs to contain the random information. So instead of just I have this password, I generate this private key. It's I have this password and a particular instance of a public key. I can now generate this private key. You can do that. But it takes some custom magic. Back to TCP IP. I want to get to the the last thing in this talk. The thing that God, I missed packets. What can we do with networks? That's how I started coming to Def Con. That's what I haven't played with in a while. Let me tell you something you can do if you're willing to play some games with packets. Who here knows about net neutrality?  Now it's my ISP. Really? I don't have a worry about when my ISP is obviously messing with me. You know, because, well, first of all, I can just tunnel around it using DNS. But secondly, you know, I can know to tunnel around it or I can complain to my congressman. What I'm worried about are when the biases are subtle. When I can't necessarily prove that they're there. What I'm here to tell you is that there's been a change in technology and I'm going to describe it to you and we are going to always be able to know if an ISP is manipulating your traffic. So if bias networks are affecting you, this is the proof that's going to be able to be shown up in a court of law. And if you happen to be working for an ISP doing this stuff, I'm just saying, if you don't want it on the front page of a newspaper in two weeks, you might want to stop doing it now. I don't want to embarrass everyone. I would love it if I didn't find any violations in it neutrality. Because then there'd be no violations. So let's look at the topology how we're going to do this because I'm making some big claims here and you know, extraordinary claims require extraordinary evidence. Now standard topology in the real world, you have some client, goes through a home router which has 83 million bugs, goes to an ISP. The ISP has various links to the internet through level three and whatnot, link one, link two, link three, and then you have Google and Microsoft and Yahoo that are linked through those links. So the fear is, and it's a reasonable fear because they're all over Washington saying it's going to be great when we can do this. There's a magic box deployed within the ISP network in front of all the links. The box matches packets to policies, applies different rules to different packets. Can we stateless? Do I not like this packet? Or can we stateful? This packet rolls with the bad crew of packets. It's part of a flow. Do I not like the flow? So, and the policies can be anything and they can do anything. Limit maximum, bandwidth, increase minimum latency, alter content, they can do everything. But sometimes you don't know if they're doing it or not. Let's say Bing.com was 50 milliseconds slower than Google.com. Is this because of the ISP? Or is this because Google.com is better hosting? You know, there's a lot of different servers. There's a lot of different routers. And the problem is you can't tell if Bing is slow because of the ISP or because of all the routers and servers. There are many reasons why Bing may be slower than Google. And that means there's plausible deniability. We've got to go deal with that. Deal with that with normalization. Whether the tester is accessing Bing.com or Google.com, the network path should be identical or at least the path should be uncorrelated with the particular identity being run over it. That way, any changes would be the result, not of the path but of policy at the collection point which is the ISP. So simple normalization, HTTP. Let's say all we're looking at is websites. There are absolutely policies out there today that say if you see an HTTP connection and there's a host editor that says Bing.com, go mess with it. Slow it down by 50 milliseconds why don't you? This is super easy to detect. Just put up a server at some IP address somewhere that will be, I don't know, like a proxy or something. It'll respond for all web requests, no matter if it's for Bing or Google or whatnot. Now you have a consistent server with a consistent path back to the client. If packets from the proxy, oh wait a second, you don't have to write any code because it's just a proxy server, it's just squid. If traffic from the same squid server is faster when it seems to come from Google than when it seems to come from Bing, you have just discovered a biased network. Very simple. There's a problem. Very protocol dependent. Works wonderful for HTTP. You guys know the internet is bigger than the web. And the problem is all of these other protocols bit torrent require a lot of work to implement or ambulate. And I'm a lazy guy. The other problem is that proxy server is at some IP. You know what that IP is? Not Bing's. Not Google's. And the ISP can just look in DNS to find out which IPs are actually associated with Google and Bing. So you can have the greatest test server in the world. The policy is only applied against genuine Bing or Google servers. You're blind. So we gotta do something about that. We gotta spoof the whole internet. Okay. So I've written some code. It's a neutrality router. It's called Neuter. Neuter is the network normalization engine. It's very easy to explain. Who here has ever run a VPN? All right. Here's the deal. You got a VPN. You're sitting in some Starbucks but where you really want your networking to be from is, I don't know, the home office or the home or somewhere in EC2.  You just want to, like, operate from the other network. So traffic is put in a VPN. Traffic is pushed from a client to a broker. An IP address at the broker or VPN concentrator, it goes ahead and talks to Bing. It goes ahead and talks to Google. And they respond back to the broker. Hey, now the broker's got all the packets. It's all the same source. So you have a normalized server. And then when it sends traffic back to the client, it always comes from the broker. So you got a normalized path. It happens to be because it's encrypted that the ISP doesn't see anything and so no policies are applied. Well, that's a bug and we're going to fix that with Neuter. See with Neuter, when the server talks to the client, okay, we're just going to go ahead and send that in the clear. In fact, we're going to spoof the IP addresses of the real Google or the real Bing. So it looks like Google and Bing are talking straight to the client. Why do you do that? We want the ISP to see the return traffic. We want the ISP to apply the policies that they only would normally do for Google and Bing and we want them to mess with us too. Why? Because then we bust their policies. And it works.  I am going to mess with Kaminsky stuff. I already got like the blog post half written. Oh, oh, but the rabbit hole goes so deep. See the policy engine in this scenario doesn't see traffic from the client to server. That's encrypted VPN style. What if the policy engine only worked? It saw all the traffic from the client to server and all the traffic from server to client. Otherwise it didn't go anything. Guess what, dude? You do that. So here's what we're going to do. A normal neuter. We're going to spoof the traffic from the server to the client. But in roto neuter it's doing it the other way around. In packet sample A, the client's going to talk to the real Google. No magic whatsoever. It's just going to go talk to it. Say, you know, real routes but full bi-directional flow trigger whatever policy is there. And then apparently the policy engine doesn't like half flows. Well, guess what we're going to do? We're going to go give it a half flow. We're going to take the client to server traffic and we're going to route that thing encrypted right around the ISP's policy engine. And then the first thing that's going to happen at the broker, the broker's going to send that traffic straight to Google as if it had the IP address of the client. Google's happy it sees a request from a client to respond to the client. It's only the ISP that suddenly's got a half flow and isn't triggering its policy. So you get differential behavior between full flow and half flow and I've still got you busted. So guess what? It's a catch 22. The ISP attaches, applies policies to half flows. Neuter sees it because the normalized server gets a difference in performance. If it only applies policies to full flows, when I create a half flow to the real Google, suddenly it has different performance characteristics. Either way, Neuter wins. This is the end game. Bias policies might as well be transparent because I'm going to find it. Now, I think I might go over by two, but no more than two. Suppose you really want the ISP to see bi-directional traffic. You don't want this, you know, weird catch 22 I just said. Well, you'd want to do this because it's definitely going to trigger all the policies. Also, if you've got an inconvenient NAT in the way, the NAT really needs to see client to server traffic to open up return connectivity. It might be inconvenient to get around a NAT. Now, the disadvantage is if an ISP is seeing client to server traffic, if a NAT router is seeing client to server traffic, the server sees the client to server traffic too, and it might reply, interfere, complain, etc. So what are the tricks we can do now? Well, we can play with TCP checksums, client can tunnel valid traffic to the broker, and can also send packets with invalid checksums to the server. So it'll get past the NAT, and it'll get past the ISP, and it'll arrive at the server. Servers like this thing is corrupt. I'm going to ignore it. That actually kind of works. The problem is the policy engine might actually do TCP checksum validation, and the NAT might go ahead and fix the sums. There's been a problem with that. But we got another catch 22, because we get differential behavior when the policy engine sees packets with bad checksums. So once again, it's like, oh, I see a full flow, but it's got half checksums. I'm going to change policy. Gotcha. So, you know, that's nice. Strategy two of three is low TTL. When you send traffic on a network, this is from my 2002 talk, you can control how far it goes. So you can say, I want this traffic to get past my NAT, and I want this traffic to get past my ISP, but not so much with getting to the real server. Could you like stop along the way? You can do that. We have the technique. So the advantage, it's legitimate traffic, the disadvantage, the policy can locate low TTL and alter behavior. That's great actually in the catch 22, because now not only do we identify the policy engine, but we know which hop it's at. Nice. But okay, let's talk about utter, utter packet trickery. The silence place. You see, normally according to TCP specification, if you ever get a TCP packet that doesn't look right, you are supposed to either acknowledge it or send a reset to stop that guy from talking to you. So you're always supposed to reply. Well the thing is, there's a lot of servers out there that have the right stack, but they got firewalls in front of them. The firewall is like I see something that looks even remotely bad. I'm going to hide in a little corner and not say anything. I have use for this behavior. So what I'm going to do is I'm going to have the real client do a three-way handshake with the server. So it's going to go and have a real session and then not going to see it, the ISP is going to see it, and even Google's going to see it. And you know what Google's going to see next? The broker is going to send a reset and it's going to shut that thing down hard at the server side. Clients still open. Clients expecting server to say something any minute now. Server doesn't want anything to do with client now. So now the broker shows up and says hey server, why don't you set up a connection with me? So broker sets up a connection with the server, gets it all nice and good, and then the broker just goes ahead and splices his connection into the connection that has been originally set up at the client. And now client sends server traffic, server ignores it, server spoofs or broker spoofs the server back to the client, client accepts it, packets go out, packets go in, you can't explain it. So bit of warning if you are passively monitoring network traffic, these techniques kind of sort of allow any one side of the conversation to impersonate traffic from anybody. You can detect it if someone tells you to detect it, I'm telling you to detect it. Where neuter is now and emulates half flows, it's super fast, it supports anything that runs over IP. If you want to know whether a network prefers Xbox 360 traffic to PlayStation 3 traffic, this will tell you what a court of law. So I got to end this. Here's the summary. Networks are neat, Bitcoin isn't anonymous, UPNP sometimes exposes itself to the outside world. Actors can be bypassed using interesting sequence number tricks. Passwords can be used to see asymmetric crypto even though they shouldn't and subtle net neutrality hacks are doomed. Transparency are busts. Thank you to N2K of Three Crowd and Docs of Lion Labs for the crazy things they're letting me do on their network and I'm looking for some help release engineering because we got to get this code out and about. Thank you so much.