########################################################################################## DNSCHAT-4: List alternate transport mechanisms ########################################################################################## Issue Type: Task ----------------------------------------------------------------------------------------- Issue Information ==================== Priority: Major Status: Closed Resolution: Informational Only (2015-01-27 07:10:34) Project: DNS Chat (DNSCHAT) Reported By: btasker Assigned To: btasker Time Estimate: 0 minutes Time Logged: 0 minutes ----------------------------------------------------------------------------------------- Issue Description ================== Although there's no intention to build them, be interesting to think about other obscure transport mechanisms ----------------------------------------------------------------------------------------- Activity ========== ----------------------------------------------------------------------------------------- 2015-01-15 19:52:42 btasker ----------------------------------------------------------------------------------------- *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 ----------------------------------------------------------------------------------------- 2015-01-16 16:59:52 btasker ----------------------------------------------------------------------------------------- *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. ----------------------------------------------------------------------------------------- 2015-01-26 14:10:34 btasker ----------------------------------------------------------------------------------------- *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'). ----------------------------------------------------------------------------------------- 2015-01-27 07:10:35 ----------------------------------------------------------------------------------------- btasker changed status from 'Open' to 'Resolved' ----------------------------------------------------------------------------------------- 2015-01-27 07:10:35 ----------------------------------------------------------------------------------------- btasker added 'Informational Only' to resolution ----------------------------------------------------------------------------------------- 2015-01-27 07:10:38 ----------------------------------------------------------------------------------------- btasker changed status from 'Resolved' to 'Closed'