|
Introduction
Introduction to Obfuscated TCP
IntroductionTCP is a protocol between computers which is used when transmitting information across the Internet. Every time you download a file or a web page, a TCP connection is established between your computer and the server which has the file. Data on the Internet is transmitted as packets. A packet is just a number of ones and zeros. Protocols are the instructions for interpreting those packets to mean something significant like "I want to start a connection". Let's look at the packets which are sent when you make a Google search. In the figure below, each arrow is a packet and the direction of the arrow depicts the direction in which the packet travels.
You can ignore the terms like "Synchronise", but note the following:
Obfuscated TCPObfuscated TCP is a modification to the TCP protocol so that:
(There are, however, some important caveats which have been omitted that we'll get to below.) Let's see how the same Google search would work when both computers support Obfuscated TCP:
MotivationsEncryptionIn order to understand why Obfuscated TCP is useful we need to understand a little about how the Internet works. Packets crossing the Internet pass through many computers on their way to their destination. These special computers are called routers and their function is to receive packets and retransmit them towards their destination. In doing so, they have the ability to see the contents of all the packets which pass by them. Additionally, an evil router could choose to modify a packet as it passes through. Routers are blue in the following figure:
In addition to the blue routers in the above figure there is a red sniffer. Sniffers are connected to routers and receive a copy of all the packets passing through the router. Thus they can see the contents of all the packets, but cannot modify them. Sniffers installed by US government agencies in the data centers of major telecoms companies resulted in the warrantless wiretapping scandal. These sniffers were copying the contents of emails, web searches etc from all the packets which went by. However, sniffers aren't just abused by major governments. Anytime you're using a public wireless Internet connection, anyone can tune into the radio in your computer and see your packets. Obsfuscated TCP connections, because they are encrypted, cannot be sniffed. SigningIn addition to being unencrypted, normal TCP packets are unauthenticated. This means that a third computer can transmit packets to your computer which appear to be from the server that your computer was communicating with. The best known perpetrator of this is Comcast, a major US ISP. Comcast forges packets to stop computers communicating when their networks are overloaded. They selectively do this to certain programs and it's very hard to detect.
Stopping the communication is performed by forging a TCP packet which means "I'm finished". After that, legitimate packets from the real server are ignored. Obsfuscated TCP packets, because they are signed, cannot be forged (This will not be supported in initial versions) CryptographyEncryption is just a process of scrambling something in a reversible manner. If you know how something has been scrambled, you can undo it and read the original message. If your browser and a website are able to scramble and unscramble data when no one else can, that means that they must share a scrambling process which nobody else knows. A cipher is a very large collection of scrambling processes. The sizes of the collections vary, but they are all very large. The number of possible processes used by Obfuscated TCP is 78 digits long. If we could just communicate the number of the processes to be used between your browser and the website we would be all done. However, we can't just send the number because any eavesdropper would also know the number of the scrambling process used! So, imaging for the moment that both your browser and the website roll some electronic dice and generate a large random number. Let's call your browser's number b and the websites's number w. Each multiplies their number by 9 and sends the result to the other. So your browser knows b and 9w and the website knows w and 9b. If they multiply the two numbers together they both end up with 9bw. However, anyone listening only knows 9b and 9w and multiplying those together results in a different number: 81bw. Of course, using normal numbers, anyone can divide by 9 to turn 81bw into 9bw, but we can replace multiplication with certain mathematical operations which can't be undone easily. They are complex, but I hope that you can understand that, if one couldn't divide, our browser and website both know a shared number that our eavesdropper can't see. This is called a Diffie-Hellman key agreement and is the basis of Obfuscated TCP. WeaknessesObsfuscated TCP, sadly, has some major weaknesses which cloud the picture. These are not design flaws; they are inherent in anything which tries to achieve the same goals. At the end we'll see how programs that are aware of Obfuscated TCP can overcome these weaknesses. We can't upgrade every computer on the Internet at the same time. It takes decades for protocol changes to reach 95% uptake and there are now so many computers that we'll probably never reach 100%. Thus we cannot know which servers have been upgraded and which have not. So, if we find a server which doesn't support Obfuscated TCP we have to fall back to normal TCP to talk to it. Equally, servers cannot know which computers support Obfuscated TCP. They can only determine that from the presence of a special mark on the first packet. This means that any router in the path between two computers can hide the fact that Obfuscated TCP is possible: the server will think that the client doesn't support it and the client will think that the server doesn't support it: Afterwards, all the packets will be normal TCP packets and will be unencrypted like any other. However, in case disabling Obfuscated TCP altogether might be noticed; routers can put more effort in and be more subtle. Recall from the Cryptography section that each side exchanges a number with the other. A router in the middle could substitute it's own number in place of the real ones. Now, each computer has an Obfuscated TCP connection established, but they both have it established with the router, not each other. This means that the router has to decrypt and re-encrypt the packets as they pass by, which is too much work for a busy router, but a targeted attack could manage it. SalvationReading about all the weaknesses might have been a little disheartening, but they don't mean that Obfuscated TCP is useless. Firstly, we have removed sniffers from the equation. Note how the attacks above required that a router modify the packet. Core Internet routers are very large, very expensive devices. It takes lots of effort to modify them to perform these attacks. Sniffers, at the ISP level, are also large, but much less critical: if they break, no customers notice. Additionally, it appears that there might be legal recourse against an ISP altering packets. However, I'm not qualified to judge. Also, on a much smaller scale, we have removed the threat from public wireless sniffers at coffee shops and the like. But probably the most helpful result is that applications can be augmented to detect these attacks. Our weaknesses, fundamentally, come from not knowing the identity of the server that we wished to talk to: either it's identity in terms of it's support for Obfuscated TCP, or in terms of it's special public key value. Some applications do know the correct identity of the server, such as when you send credit card details over the Internet. These applications can detect shenanigans in the network and that puts us in a much better position than we are now. If you still have questions, you may wish to read HowIsThisDifferentFromX |
Sign in to add a comment
Neat, can you contrast it with existing things that sound vaguely related (like HTTPS, SSL generally, IPv6, etc).
I understand the difference, but others may not.
Thanks, wrote and linked to HowIsThisDifferentFromX
Very nice explanation of the concept. I'd feel confident forwarding this to my mother.
In the man-in-the-middle scenario (2nd) the 'false' public key and public key used are reversed in the 'Acknowledge and Push' (3rd) exchange.
"If the server doesn't understand Obfuscated TCP, the mark will be ignored and the connection will work just as before"
What happens if server responds with public-key to all requests?
rchfreytag: I might be looking at the wrong diagram, but I think that it's correct. In the 3rd exchange, the host has just received the false public key from the router and is replying with its own public key. I've used the string "public key" twice, meaning two different keys depending on where the message it coming from here. That might have been a mistake on my part.
selectedmutation:
> What happens if server responds with public-key to all requests?
That's actually not a problem. If the server chooses to include the public key in all replies, clients that cannot use it will just ignore it.
AGL
"Additionally, it appears that there might be legal recourse again an ISP altering packets. However, I'm not qualified to judge."
s/again/against/
I'm trying to learn something.. so my expertise is very low:
It looks doable with a 3rd party and if the client knows and chooses to use ObsTCP protocol to request a service. Which is pretty much the same thing as the existing protocols. Isn't it?
cjdaniel: fixed. thanks.
Couldn't we deal with the man in the middle aspect by getting the public key through a different means, like DNS? (ignoring DNS insecurity for the moment). Then if we got back a different key from the server we'd know some sort of hanky panky was happening. This still wouldn't stop the ISP from disabling the encryption but if we knew the other end supported ObsTCP and had key X, we could refuse to speak them using anything other than ObsTCP.
ObsTCP is a great idea BTW!
Also, on a much smaller scale, we have removed the threat from public wireless sniffers at coffee shops and the like.
This makes it sound like wifi spots in coffee shops are safe to use again.
A malicious person in the coffee shop can still spoof a router and run a man in the middle attack. This would be really easy, or am I missing something?
@bluntsimon28: not safe, but a little safer. The larger the attack, the easier to detect, but passive sniffing will no longer work. However, at the scale of a coffee shop, if you wished, you could spoof the DHCP replies and still easily MITM those who you managed to beat the real router too. More messy than a straight sniffer, but doable.
You say a man in the middle attack on large scale is not possible because of high computational costs, but an attacker could simply sniff the secret number and log all the encrypted traffic together with the secret for later decryption. With disk space becoming awfully cheap and data centers ready to sail the ocean obfuscated tcp do not seem too secure.
@bigonazzi: that's not actually correct, although it is non-intuitive result. As a result of Diffie-Hellman (http://en.wikipedia.org/wiki/Diffie-Hellman) you cannot log the secret value, it's never on the wire. Instead you have to pretend to each side that you are the other. That's perfectly possibly, but if a whole ISP starting doing it, it's very obvious and easy to detect.
@alangley: you are right, sorry, my network security class is not so fresh anymore. Hopefully hw crypto engines will remain expensive for a while! ;)