John C. Welch
Aug 23, 2017 · 2 min read

Nice idea but some serious issues:

  1. As Jere said, since you’re relying on specific method to tag requests, even if non-tapdance devices can’t specifically read your modifications, the modifications are usable by their existence. You can’t hide the change. It’s like when the truecrypt people would say that by using truecrypt, you’d be “immune” to border searches because customs agents/border patrol couldn’t see your data. While that’s true, they could trivially tell there was an encrypted partition and demand the passwords. “not usable” and “invisible” are two very different things. It’s why things like radar and sonar avoidance rely so heavily on passive avoidance rather than active jamming. Once you’re actively jamming, the other person knows you’re there.
  2. Why would china or saudi or any other government heavily censoring internet access even allow your client to be used? If you’re relying on specific clients, you’ve already failed. if it’s not going to work with bog-standard web browsers, then it’s not going to work.
  3. The Tapdance appliance is literally the NSA’s/every other covert INFOSEC agency’s wet dream. Ponder it: it’s a device that monitors 100% of traffic at any given ISP, looking for your specific header modifications. How are you going to seal that box and prevent extra hardware being inserted that will take advantage of this to route additional copies of that traffic elsewhere? They wouldn’t even have to use their usual “you can’t tell anyone about our fiber tap” tricks. Just intercept your hardware en route, modify it, and send it on its way. This is a solved problem for the modifiers, they’ve been doing it for some time now. How do you prevent that?

There are serious issues when you start to ponder implementation. Everything works in theory, and most everything works in a lab. The real world however, actively seeks to kill ideas.

)

    John C. Welch

    Written by