DNSCHAT-4: List alternate transport mechanisms

TCP Morse

Would be highly inefficient but as the ciphertext is hex encoded, could essentially use SYN packets to send morse code:

Send a SYN to a specified port on the end point;

- if the source port is even, it's a dot, if odd a dash.
- An unexpected RST (or maybe an ACK) would indicate moving onto the next letter

You'd need to wait for the ACK to come back to ensure the SYN had actually been received - ordering being somewhat important in morse.

If implemented correctly, it could feasibly look (at first glance) like two machines were simply trying to SYN flood each other - a more advanced implementation could also look at actually transferring abritrary data over each of the connections.

Transfer would be slow though as you'd have to send up to 4 SYN's per character - but analysis/detection of the traffic would likely require examining every SYN to cross the monitored network path.

You could, theoretically, also do something similar with ICMP echo requests - the payload size would dictate whether it was a dot or a dash

Ping Payload

Slightly less inefficient than above, but if broken down into suitable chunks, the ciphertext could conceivably be added to the payload of ICMP Echo requests.

HTTP(S)

Further along the lines of hiding in plain sight, you could also hide the data amongst some otherwise innocuous HTTP requests.

The ciphertext could be provided as a cookie value in the request, and the response could then either set a cookie with the reply, or embed it into the ETag. Would be reliant on either end sending a response quickly, unless your HTTP request appeared to be something like an XMLRPC call (giving reasonable justification for the 'server' then establishing a HTTP session back to the 'client').