Feature Request: webtunnel support

[syphyr]

There is a new transport plugin for tor that supersedes obfs4.

https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel

[syphyr]

The latest version of lyrebird just added webtunnel support. It would not be that much work to support this now in orbot. @n8fr8 @bitmold

https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/commit/a571773a10d8ae6cb71c0ba473d1bfb7bf2871e1

[syphyr]

I've created an OrbotLib that supports webtunnel here:
#1115

I have tested webtunnel support on Orbot 16 and is working well with the following changes:
syphyr@0ba3f7c

Although, getting it to work on Orbot 17 requires more work due to the additional circumvention api updates, which I could use some help with. If anyone can help with that, I would appreciate it.

Edit: link to commit updated to fix custom bridge support

[bitmold]

This is something I am planning on integrating right now with respects to that API and welcome if you feel like providing input with that along the way that's always very appreciated

[syphyr]

This is something I am planning on integrating right now with respects to that API and welcome if you feel like providing input with that along the way that's always very appreciated

Thank you for working on that. I can push what I did so far on master branch if you would like.. It may speed things up.
syphyr@0be3ddf

[syphyr]

@bitmold IPtProxy 3.7.0 still does not include lyrebird 0.2.0, so it will not support webtunnel yet. I have created all the necessary changes here to support webtunnel in IPtProxy.
https://github.com/syphyr/IPtProxy

[bitmold]

i understand this, we need IPtProxy to support lyrebird 2.0.0 and I submitted an issue in that repository. once it does we can bump orbot lib to that version. of course in the meantime it's possible to locally dev against v2.0.0 instead of adding our own unique binaries to the repository. like i said above, i'm not satisfied with how this go code is added to orbot, but still i think even as unideal as things are right now it makes a lot of sense to commit changes in the following order:

1. get code into IPtProxy properly
2. update OrbotIPtProxy to reference the official IPtProxy releases
3. update the binary in orbot such that it's built from what's published in these two publically available git repos

I'll definitely be referencing your work, but there are things that need to be implemented for the circumvention API that go beyond just adding web tunnel support. In the meantime, It may require refactoring/reworking a good chunk of what's there so for the time being I don't see much utility in putting that code on the main branch

[syphyr]

That sounds good. I am assuming moat does not yet support webtunnel as well.

[qua-rus]

I support. Obsf4 does not always work.

[AlexAglT2]

I absolutely support

[tladesignz]

Webtunnel support is finally almost there.

Progress is tracked in #1193, hence closing this.