Open syphyr opened 1 year ago
The latest version of lyrebird just added webtunnel support. It would not be that much work to support this now in orbot. @n8fr8 @bitmold
I've created an OrbotLib that supports webtunnel here: https://github.com/guardianproject/orbot/pull/1115
I have tested webtunnel support on Orbot 16 and is working well with the following changes: https://github.com/syphyr/orbot/commit/0ba3f7cdb37c53aab5f2db7ca525076ebbbd8795
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
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
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. https://github.com/syphyr/orbot/commit/0be3ddf2c43719b918647b4c5349f718328990df
@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
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:
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
That sounds good. I am assuming moat does not yet support webtunnel as well.
I support. Obsf4 does not always work.
There is a new transport plugin for tor that supersedes obfs4.
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel