api.distributed.press VS iodine

I think the obvious match here is how IPFS can use a dnslink TXT file to point to the content-addressable top of an IPFS-distributed static web https://docs.ipfs.tech/concepts/dnslink/ . This is how a lot of dweb/web3 websites maintain and advertise a non-http mirror. It works out of the box for sites served using https://distributed.press/ (non-commercial, open source) or https://fleek.co/ (hosted).

If you use Brave, or have the IPFS browser extension, you can access sites like https://ffdweb.org/ as an option, or preferentially.

This should be a link to https://distributed.press/

There are several new and exciting decentralized web protocols. I am working on a tool to publish to all of them. Right now it publishes to IPFS and Hypercore, and will eventually serve signed plaintext so content can be shared to Scuttlebutt and Aether networks.

For example, this site is published using https://github.com/hyphacoop/api.distributed.press and it can be accessed over HTTP, IPFS, and Hypercore.

https://staging.compost.digital

Reminds me of using https://code.kryo.se/iodine/ ( DNS tunnel ) and a empty prepaid card...

Obligatory dns tunnel software for exfil. It is super noisy if you do dns querylogging, so I'd not use it for anything major, but it is a fun research tool.

https://github.com/yarrick/iodine

It's worth noting that you (re) invented what iodine does: https://code.kryo.se/iodine/

(https://github.com/yarrick/iodine)

It’s slow, but it works and is a handy “last resort” tool.

While working in an environment where VPN connections were pretty much all blocked⁰ a friend of mine had success using https://guacamole.apache.org/ to access a remote machine¹. Not quite the same as a direct VPN connection but worth a try if nothing else functions, it looks enough like normal HTTPS traffic that he got away with it.

To keep your wireguard setup more as-is, you could try https://kirill888.github.io/notes/wireguard-via-websocket/ to tunnel that via a web server. In fact https://github.com/erebe/wstunnel which that uses could be used just as well with any other UDP based VPN.

I once tinkered with https://github.com/yarrick/iodine and successfully connected to resources over the wireless on a train, bypassing its traffic capture and sign-up requirement, so that might be an option, though I think fully blocking external DNS is more common now so this is less likely to work²³.

--

[0] practically only HTTP(S) permitted, not even SSH, DPI in use that detected just using SSH or OpenVPN over port 443

[1] NOTE: be careful breaching restrictions like this, you are at risk of an insta-sacking if discovered, or worse if operating in some securiry environments!

[2] and the latency when it does work is significant!

[3] and that much traffic over port 53 might get noticed by the heuristics of data exfiltration scanner, encouraging sysadmins to notice and implement a way to block it

There's also iodine, a C program that tunnels IPv4 packets over DNS. Useful for bypassing captive portals on wifi, since DNS usually isn't restricted.

https://github.com/yarrick/iodine

Regarding cloudflare DNS over HTTPS: It could be that it tries to server data encoded as JSON, which is impossible in JSON. Some control characters and bytes 128-255 cannot be represented as JSON strings.

A regular proxy on port 53 might work? Is it necessary to actually use DNS?

Otherwise there's https://github.com/yarrick/iodine

Well, you're really exhausting your options here (and possibly your IT department's patience). Iodine would still be an option, it creates a tunnel through DNS traffic. Nearly impossible to block/filter out but you shouldn't expect a lot of bandwidth. Try it out! Although if you're only going to use low-bandwidth applications through the tunnel anyway you might as well use your own mobile data plan instead of your school's WLAN.