Hippotat: IP over HTTP

https://diziet.dreamwidth.org/12934.html

by AndrewDucker • 4 years ago

74 28 4 years ago

diziet.dreamwidth.org

fsiefken• 4 years ago

nice, reminds of IP over DNS https://github.com/yarrick/iodine

ranger_danger3• 4 years ago

SoftEther VPN client supports IP over both DNS and ICMP, among other things.

bragr2• 4 years ago

If port 443 is open and you can connect to SSH, why not just use an SSH SOCKS proxy? This is neat in principle, I'm just not sure who it helps or why it's better. I suppose this helps if someone is doing deep inspection on their portal traffic, but is anyone doing that?

tailspin2019• 4 years ago

I suppose this helps if someone is doing deep inspection on their portal traffic, but is anyone doing that?

China is doing that to their entire population

dilyevsky• 4 years ago

Lots of commercial and government entities are doing that and not just in china but in the west too

iudqnolq• 4 years ago

Sure, but one of the things they use it for is to impede this sort of thing. They don't care about perfect accuracy, just inject random faults and increase latency if they suspect this sort of tunneling.

ranger_danger3• 4 years ago

Many public wifi networks here do this. No normal VPN client I've tried works.

amaccuish2• 4 years ago

Why not use the openconnect vpn server, ocserv? [0]

It opportunistically uses DTLS over UDP where it can, but falls back to plain TLS over TCP where not. And I mean real TLS, not the sort-of-TLS that OpenVPN uses.

[0] https://ocserv.gitlab.io/www/index.html

ranger_danger3• 4 years ago

How is OpenVPN sort-of TLS? You can even use it behind a normal HTTPS reverse proxy.

amaccuish2• 4 years ago

It does some things differently than what a normal browser-based TLS connection does. There's some background here: https://subscription.packtpub.com/book/networking-and-server...

hackernudes• 4 years ago

Nice. My approach when faced with a https inspecting (mitm) proxy that did not support "http connect" requests was to do ssh over websocket.

computerfriend• 4 years ago

Using websocat or similar? Do you have a link to how you set it up?

barathr• 4 years ago

Soonish there's going to be a standardized way to do this, via CONNECT-IP:

https://github.com/ietf-wg-masque/draft-ietf-masque-connect-...

immibis3• 4 years ago

The solution to IPv4 exhaustion that we definitely didn't need or want but will be adopted universally.

Just connect to 1.2.3.4 and then proxy to 192.168.5.6. Boom, 48-bit address space.

justusthane• 4 years ago

I don’t understand how that’s related…aren’t you just describing NAT, but worse?

derhuerst• 4 years ago

related: chisel [1] does TCP over HTTP

[1] https://github.com/jpillora/chisel

evulhotdog• 4 years ago

This feels like a lot of additional steps and protocols when you can use something like proxytunnel.

andrew-ld2• 4 years ago

if traffic passes under tls shouldn't it be possible to figure out the content or type of content transmitted/received, shouldn't just an ip over tls be enough?

immibis3• 4 years ago

Not enough abstraction layers

xorcist• 4 years ago

There are some things related to the size and timing of packets that you can use to infer the likeliness of a given handshake inside the TLS stream. The great firewall does similar things to detect Tor. (Not related to the IP-over-HTTP presented above however.)

andrew-ld2• 4 years ago

with this intermediate protocol within tls you're just adding a fixed (or almost fixed) size to the data being transferred and the timing I think is indifferent

superkuh• 4 years ago

re: The package build instructions are rather strange. I've given up trying to compile anything written in rust since what "Rust" is changes every 3 months. Unless you're using a rolling distro, and even then, you're gonna have a hard time compiling $randomrustproject using repo compilers. There's no useful efforts for forwards compatibility and right now the dev userbase is still the type of people in love with bleeding edge.

danhor• 4 years ago

It's strange because it's written to generate a debian package.

You can also use the normal rust build process that hasn't changed since v1.0: `cargo build --release`

ebfe1• 4 years ago

I run openvpn on 53 udp and 80tcp... works like charm in most cases and sometimes enough to bypass hotel portal. :)

lamp987• 4 years ago

i hate computers

blincoln• 4 years ago

I wrote this for pen testing purposes, but it worked so well that I've used it to get around public WiFi limitations like the author of TFA:

https://github.com/nccgroup/ABPTTS

(Still need to port it to Python 3 someday)

I was very surprised at how finicky some TCP software is. SSH/SCP in particular was not at all tolerant of seemingly minor delays that every other client/server combination ignored. My gold standard for testing became "can you perform an arbitrary number of tunneling layers, where the layers alternate between SSH and the HTTP tunnel, and still behave as reliably as a direct connection?"

bragr2• 4 years ago

Any particular reason you haven't? I just skimmed the code, and while 2=>3 string differences might give you some pains since you are doing a lot of works with strings and encryption, you seem to only be using standard packages so this should be an easy port. 2to3 [1] might get you all the way there with no manual changes.

[1] https://docs.python.org/3/library/2to3.html

Hippotat: IP over HTTP

Related Stories