|
History
Obfuscated TCP History
Obfuscated TCP is now in its third major form. If you've looked at this project in the past you may be wondering what happened. In the beginning was the first experimental version. This consisted entirely of an in kernel implementation which tried to apply obfuscation to every connection. Support was advertised via a TCP option in the SYN and conforming servers returned their public key in the SYNACK. The client then transmitted its public key in future packets until acknowledged (implicitly) by the server. The payload of packets was encrypted with Salsa20/8 and each packet was MD5 signed. It actually worked, but the resulting kernel patch was so large and intrusive that I knew that it would never get anywhere. The changes to TCP to fit a 32-byte public key in the options were also a bit messy, although the draft spec survives. So next I pulled as much from the kernel as I could. Packet signing was put on the back burner and all key agreement etc happened in userspace. However, I still needed a single bit of option data in the SYN in order to switch protocols when both the client and server supported obfuscation. The server also used a little known aspect of TCP to send information in the second packet of the 3-way handshake. This form also reached the point of a working implementation. After a torrent of email writing, it became clear that the IETF working group on TCP was never going accept wedging an application level bit into TCP's option space (the spec still exists). Thus this form was dropped too. In the course of doing this I rewrote the kernel's TCP option handling code and MD5 packet signing code. This bit was split off from the rest and is now in 2.6.26, so not a dead loss. The third (and currently current) form moves away from modifying the kernel or TCP at all. It shares much of the design of the second form except that the magic bit and early server transmission have changed into a DNS hack and connection memory. |
Sign in to add a comment
It would be good if, to enable obstcp, a client or a server needs to make only a single change. In the case of a server, it would be only a change to the webserver.
The current form as you noted needs both a change to the server and a change to the DNS. This will reduce the rate of rollout. So I encourage standardisation of the TCP option hack :-)
Nick, you missed something. According to the video, the X-ObsTCP header lets a webserver give a hint over a cleartext connection that further connections can be obfuscated. This is how you do it with no DNS changes -- you let clients observe that they can try obfuscation later. With DNS changes you can avoid the first cleartext connection, and the bandwidth of the header.
Thanks for doing this work, Adam. It could help me with a device I'm working on that needs super-lightweight, secure transport.
Jeff R. Allen
What is wrong with IPSec? Can't you just do opportunistic IPSec encryption (i.e. without validating the server cert.)?
@B IPSec requires major changes to the underlying OS. Requires hosts OS's to support IPSec, and either requires all intervening network devices to pass IPSec unhindered (IP Protocols 50 and 51) OR requires the use of UDP encapsulation. IPSec is also computationally expensive in software, less so in hardware, but still a delay.
Not to take you back to the kernel, but occurs to me that you could add data to your SYN and ACK packets that contain the public key. This is not in line with TCP protocol, but that has never stopped other venders from implementing their ideas....
The idea would be to simply allow for the mechanism to inject a public key into a SYN- SYN/ACK packets data, and then also allow that data to be picked up on the other end.
I think you could keep the kernel changes rather small and pull all of the encryption back up to the application layer, and the only thing you would need in the kernel would be the injection of public key into either SYN or SYN/ACK packet.
With this method, I think applications and kernels with the patch would be able to perform data encryption within your parameters, and devices that did not would likely harmlessly drop the packet data.
Oops.
Let me also add that if you are at all intrigued. I would be happy to test this little idea. send me an email and I will give it a try.
@crewiscool: thanks for the suggestion! Sadly, it turns out that it doesn't work :( I did some testing and > 8% of SYNs with payloads get dropped over the public internet: http://www.imperialviolet.org/binary/ecntest.pdf