LEAP GSOC progress report, no5

Here goes another report from my ‘obfsproxy in LEAP’ project.

I mainly spent time in this ticket #5841.

In branch you can find the relevant commits. This branch is rebased so as to contain commits from features 5785 and 5788.

In short, we assume features 5785 and 5788 are in place, meaning bitmask is downloading the eip-service.json file that contains connection details for obfsproxy.

After that, bitmask should make various checks before attempting to launch obfsproxy in localhost.

Since in platform deploying a vpn service will deploy an obfsproxy server too, we assume that as long as a provider provides EIP service, obfsproxy is also available. That said, user should still have the option obfuscate EIP traffic or not. Checks include whether obfsproxy binary is available for use, whether user wants to obfuscate the traffic, whether obfsproxies list is not empty in eip-service.json. These checks can and should be improved/get more detailed.

I tried to implement this staying as close as possible to the way EIP functionality is implemented.

Apart from the above i’ve been wondering what is the best way to ship the obfsproxy executable and its dependencies in bitmask. In case obfsproxy is already available in the client’s system then things are fine. We can just import obfsproxy from system. (I guess obfsproxy could be added as dependency in the bitmask deb packages too?) But, this won’t be always the case. So obfsproxy should be included in standalone mode in some way.

Mind that i work with a modified version of bootstrap_develop.sh that makes obfsproxy binary available in the virtualenv. So ‘import obfsproxy’ does work even if it’s not installed system wide.

If someone could give a direction on how to make obfsproxy also available in the standalone bitmask bundle would be great! I checked how obfsproxy and pluggable transports are built (gitian) and shipped in Tor Browser bundle but, as chiiph commented, that’s not exactly what we need here.

Next step is to actually launch the obfsproxy listener with the appropriate parameters.

LEAP GSOC Progress report, no4

I mostly spent time debugging problems i introduced while implementing #5785 and #5788 in bitmask client. I think the two last commits in pull 668 finally get things working in client for these two tickets. Also i rebased feature/5788 branch against feature/5785, so the request contains commits for both features.

The new macro ‘pick_node’ introduced by elijah in leap_platform:develop, is finally used in obfsproxy.json service definition to pick a vpn gateway address. See last commit.

At the moment, i’m working on #5841. Assumptions made in leap_platform affect decisions on the client side, although things can still be changed. For example, obfsproxy service will always be deployed along with openvpn, so as long as provider provides ‘openvpn’ and client has enabled it, we can assume the same goes for obfsproxy. On the other hand, user should still have a (gui) option to have eip over obfsproxy or not. I expect to push some commits soon on that issue.

LEAP GSOC progress report, no3

I made some progress on the client side the past week.

I use bootstrap_develop.sh script to get a working development environment and it seems to work nice.

I made a simple addition to the script to get obfsproxy binary in the environment, so as to use it later. However what’s the best way to to have this binary in the bitmask bundle is stil an open question to me, please advise.

So, given that most part of the obfsproxy work on the server side is done, client has to be adapted accordingly.

configs.json was introduced in platform and is a file that contains service definition file names, listed by version. Client should download that file in order to pick a specific version of each service definition from the provider.

This is the relevant ticket and this is the pull request. I spent some time to get familiar with how things are done in bitmask, i’m really happy i came to understand a lot while making changes in it. Still i definitely need comments and reviews and some guidance on the client side.

eip-service-2.json is a new service definition file introduced in platform so as to add values for obfsproxy service without modifying eip-service.json

As long as client downloads configs.json and sees that the provider supports multiple version of a service-definition file should favor the latest e.g. eip-service-2.json instead of eip-service.json.

Ticket and pull request. Again please comment on this. I need to be sure i’m not the entirely wrong direction before going further.

There is an issue here. Since a section for obfsproxy is added in eip-service-2.json eipspec.py has to be modified accordingly. What is more gateways in eip-service-2.json are a hash instead of list. Changing eipspec will break compatibility with eip-service.json

As long as all the above are addressed, client will have all the necessary details to make a remote connection to provider’s obfsproxy server. obfsproxy client should listen to localhost and forward traffic to remote obfsproxy server. VPN should be pointed to obfsproxy listening to localhost. Ideas and directions on that are more than welcome.

LEAP GSOC progress report, no2

Here goes another report of a low intensity week: WebApp API and json service definition files When clients bootstrap with a LEAP provider they fetch .json files which contain the service definitions of the provider. For example the eip-service.json contains details the client to use the VPN service of the provider, such as vpn gateway’s hostname, available ports, protocols, location etc. These files are exposed to clients via the WebApp API. [Read More]