Hippotat: IP over HTTP(diziet.dreamwidth.org)
diziet.dreamwidth.org
Hippotat: IP over HTTP
https://diziet.dreamwidth.org/12934.html
32 コメント
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.
Just connect to 1.2.3.4 and then proxy to 192.168.5.6. Boom, 48-bit address space.
I don’t understand how that’s related…aren’t you just describing NAT, but worse?
If every NAT is a proxy, you can address every address without port forwarding.
[deleted]
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?
> 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
China is doing that to their entire population
Lots of commercial and government entities are doing that and not just in china but in the west too
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.
[deleted]
Many public wifi networks here do this. No normal VPN client I've tried works.
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?"
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?"
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
[1] https://docs.python.org/3/library/2to3.html
nice, reminds of IP over DNS https://github.com/yarrick/iodine
SoftEther VPN client supports IP over both DNS and ICMP, among other things.
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
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
How is OpenVPN sort-of TLS? You can even use it behind a normal HTTPS reverse proxy.
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...
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?
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.)
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
Not enough abstraction layers
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.
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`
You can also use the normal rust build process that hasn't changed since v1.0: `cargo build --release`
[deleted]
related: chisel [1] does TCP over HTTP
[1] https://github.com/jpillora/chisel
[1] https://github.com/jpillora/chisel
This feels like a lot of additional steps and protocols when you can use something like proxytunnel.
Nice. My approach when faced with a https inspecting (mitm) proxy that did not support "http connect" requests was to do ssh over websocket.
Using websocat or similar? Do you have a link to how you set it up?
[deleted]
I run openvpn on 53 udp and 80tcp... works like charm in most cases and sometimes enough to bypass hotel portal. :)
i hate computers
https://github.com/ietf-wg-masque/draft-ietf-masque-connect-...