-2

I'm trying to develop something that can get around Deep Packet Inspection so that rather than looking like OpenVPN traffic etc, I could put all that into HTTP packets as extra information or some other protocol. I would control the client and the server machines and could communicate securely as I'd be in OpenVPN but the packets would be disguised as legit HTTP traffic hiding the extra OpenVPN traffic in there.

I understand there would be issues with integrity of the packets if someone knew this was happening and that security through obscurity isn't best practise.

My questions are really to ask what your thoughts are on the implementation. How would you go about this?

I believe that it would work something like:

  1. Force NIC through iptables or static route through my own virtual interface.
  2. Sniff my interface and modify so that packets can be changed and the relevant other traffic (voip, SSL) etc be added in the traffic of HTTP, then pump through eth0 to the internet.
  3. When it reaches the destination server, it does the opposite to decrypt the traffic.
  4. Process the traffic through the server and report back.

I've found stunnel and obfsproxy so far but I don't believe that's the same concept.

This is very much an idea in progress. Can you please advise of your thoughts? Any feedback welcome.

Thanks, truex0r

Kim Ly
  • 11
  • 1
  • This is an interesting question, but not really suitable for [SF]. I don't know which site to migrate to though, none of the standard migration targets fit. I hope a moderator can find a suitable site to migrate it to. – kasperd Mar 27 '16 at 16:33
  • I [asked](http://meta.security.stackexchange.com/q/2280/47143) whether it would be suitable for migration to [security.se]. – kasperd Mar 27 '16 at 16:53
  • 1
    @kasperd: I don't think this is a type of question that can work on any SE site with its focus of Q&A pairs. However, the closest fit I would think of might be [programmers.se]. I won't shop around to see who might want to have an OT question though. – Sven Mar 27 '16 at 16:54
  • @pete I am not sure about that. The question appears to be about a scenario in which the OP is the legitimate administrator of both ends of the connection. And he appears to want to protect himself against intermediate nodes on the communication path snooping on the traffic in ways not authorized by the administrator of either endpoint. – kasperd Mar 27 '16 at 17:11
  • 1
    @kasperd I had deleted my comment prior to seeing you had read/replied; I see your point now – pete Mar 27 '16 at 17:20
  • 1
    as it stands, the question would not be suitable on Sec.SE. The current structure has multiple questions, some unrelated and confusing information, and a title that muddies the water further. If you could clarify it down to one question, it may be appropriate there. – Rory Alsop Mar 27 '16 at 18:48
  • 2
    I assume you mean "steganography", and not "shorthand"? – AviD Mar 27 '16 at 20:09

1 Answers1

0

Running IP on top of TCP is a bad idea for reliability and performance reasons. That doesn't mean you cannot disguise VPN traffic as TCP traffic, it does however mean you need to mess around with the TCP layer in innovative ways.

You are better off disguising VPN traffic as some already encrypted protocol such as HTTPS. First setup a real HTTPS connection and have the client authenticate with the server. Once authenticated your VPN layer takes over the communication at the IP layer just beneath TCP and starts sending VPN packets utilizing what would have been an encrypted HTTPS payload.

The main problem with running VPN over TCP is that when a packet is lost the receiving end will queue all later packets until the lost packet has been retransmitted. The simplest way to work around that is to send packets using ordinary unmodified TCP, but have each end of the connection receive raw encrypted packets at the IP layer and hand them off to the VPN layer. Simultaneously the received packets will also be delivered to the TCP layer, so you'll also need an ordinary TCP receiver to sink the traffic. That way you will have addressed the main problem in running IP over TCP while still preserving traffic that looks like real TCP traffic to any man-in-the-middle, because it would be generated by a real TCP stack.

This approach will not entirely avoid the problem in running IP over TCP. If the sending end will stall traffic due to receive window or congestion window filling up, the VPN layer will no longer be able to transfer traffic in that direction. However any approach which would allow you to bypass this limitation would change characteristics of the TCP connection in ways that would be detectable to a man-in-the-middle, so at that point you would have to weigh the reliability of your VPN against the detectability.

kasperd
  • 29,894
  • 16
  • 72
  • 122