Flexi-chains: multi-protocol tunnel-chaining app for Qubes to annoy GPAs

I have given it a star to look at later, thanks for the info.

Should I be looking at this as an alternative to glide?

@Plexus

EDIT:
Can you clarify, is the v2ray link you posted deprecated for v2fly/v2ray? I’m confused :frowning:

v2ray/v2fly/Project V confused me

it 404 now
Edit:the link is GitHub - nadoo/glider: glider is a forward proxy with multiple protocols support, and also a dns/dhcp server with ipset management features(like dnsmasq).

1 Like

Typo, sorry.

1 Like

Important UPDATE:

Flexi-chains is set to be adopted by a super-duper awesome new company I am launching very soon.

I will keep everyone posted.

And also, thanks everyone for your feedback & support - I really appreciate it all!

1 Like

@Quser59
Any update ?

1 Like

You might need to take an introductory course to Information Security (@newbie might be interested too). Privacy (Confidentiality) is only one of the pillars of security. Also, hoping that your adversary won’t understand what you are doing, and hoping that will protect you, is called “security by obscurity” and doesn’t last for very long, if at all.

1 Like

@Quser59 any update?

I’ll try to get involved as best I can. I’ll be studying up on how to use v2ray and glider. Anything else I should look into?

Also are you familiar with any proven systems for streaming “cover traffic”, see my response about this thesis to fix the flaws of TOR https://www.csrc.link/download/defending-end-to-end-confirmation-attacks-against-the-tor-network/defending-end-to-end-confirmation-attacks-against-the-tor-network.pdf I posted about here:

https://forum.qubes-os.org/t/cover-traffic-garbage-generator/5469/5?u=gateofranre

I see Stunnel mentioned but it doesn’t too seem to be to fit as a obfuscation / plausible deniability layer?

This also mentioned seems to be closer to meeting the requirement: https://github.com/ReconInfoSec/web-traffic-generator

If you would like maybe this is where I can fit in to your project, but I’m a novice programmer, so if I could bounce questions off you hopefully you could help me if I find myself stuck at a certain point.

Also you mentioned passive logging, that’s my current focus with the Qubes IDS we talked about in other threads previously. So if you think it’s beneficial, maybe that could be my second effort to get working within your flexi-chain system.

I have a 5-day contract for the foreseeable future.

However, as per another post on here, this will enable me to pay for dev time.

My level of knowledge is much more:
Let’s use Qubes APIs to launch VMs with v2ray and import configs via command line.
(As opposed to writing each line of code).

If you would like to work on the project, please feel free to PM me or find my details via github.

Your ‘novice’ ability most likely far exceeds my programming speed.
(Honestly, I just haven’t got the commitment/time to program a project. I need to stick to the management/abstract spec else it will never get done). I can help much better by raising 6 figures in a couple of months, then spending those 2 months programming.

I foresee that I will have 6 figures of liquidity - much of which I would like to allocate to dev/Qubes work - in the next 12 months.

The current corporate structure is planned as follows:
Development Corporation/Conglomorate

  • Sub-projects/assets (i.e. flexi-chains).

All assets with fair-use licences.
Business model is from premium support/consulting/plugins, (which are also planned to be open-source&free after lag-time of approx 12-24 months max).

As my current contract business is using MS Windows, and QWT is chugging slowly - I also plan the following:
(Within dev. corporation):
‘QBusiness Company’
(This will be a fork of qubes, contributing directly to this fork - leaving it upto the Qubes core team if they want to adopt anything upstream).

Disclaimer

I need to double-check that this is ok with Qubes licencing and core team

Proclaimer:
There are many reasons the QBusiness company will be setup like this to start with:

  1. Qubes Core Team is small - forking the project reduces burden in many ways
  2. Forking the project removes liability/branding issues etc.
  3. It means Qubes remains non-commercial and nobody can claim that they are being influenced by the company, as we contribute directly to the fork.

Also, I wish to make it very very clear that we will adopt an open-source & free licence for the fork.

Long-term a non-profit corp or a ‘charity’ would probably be ideal for this venture, however I must make the following Disclaimer:
Charity law where I am is some of the most complex in the world, and you would need 5-6 figures/year. (in admin/management overheads), to maintain charity status for such a project.
It would require further admin overheads and disagregration of the project (i.e. separate charity/nonprofit from consulting company), which is simply pointless until the project grows that big.

Also, for anyone wondering, am I really comitted to Qubes?
The answer is Yes. Thankfully, Joanna laid out quite clearly why OpenXT is not all it’s cracked up to be.
Further, I do not ever see SecureView, (OpenXT-based), being open-sourced/free-licenced - the only reason I can see this would be done is if Qubes became a commercial competitor.
In addition to all that: From what I’ve learnt of SecureView, the only really major headstart they have rightnow is the apps builtupon the admin API(s) - which Qubes 4.1 now has (the admin API).

Apologies for leaving everyone without an update - and for the very long post.
I am working hard on building a trustworthy core team, and generating revenue - bare with me please.

If anybody is interested in joining this team or contributing - please get in touch.

1 Like

I don’t think there’s that many options (that can be easily integrated) - and I think many are commercial. @adw knows more than myself on this matter.

Keep It Simple.

I already envisage a ‘standardisation’/‘steganography’ etc layer.
This is ‘easy’ to design at abstract level.
All you need to do is add an extra layer - no redesign is needed.
Look at TOR obfsproxies.

There’s so many really simply ways to create a custom steganography protocol that’s realtively high bandwidth (mb/s) - i.e. making it look like traffic to mainstream sites (sites.google.com, etc etc). Video streaming or livestreaming upload - where you have your traffic and then use a clever algorithm to make it look like you are streaming a genuine video. (And you just do this ‘after’ you’ve forwarded it your VPN, so unless anybody is really looking carefully, it just looks like you’re streaming whinnie the poo).

The advantage of flexi-chains, is it is built atop Qubes - with ‘Guard’ and ‘Tunnel’ Nodes.
So even if something is so poorly coded in flexi-chains that it ebnaled a 2-exploit compromise of a VM, you can just put a unikernel guard node in-front and behind it - and it has the protection that Qubes offers atop the Xen hypervisor (which, suffice to say: is reasonably secure).

EDIT/UPDATE:
See the very basic example setup I just wrote: