Hello world, it’s been a week since i “officially” contribute to the LEAP project. \o/
Here’s a raw status report of my progress so far:
Started working on leap_platform. The idea so far is to have the possibility to deploy an obfsproxy service instance either alongside the eip service or standalone.
- I wrote a puppet module that installs obfsproxy from wheezy-backports, creates the respective user and group, creates the necessary configuration files, logging files, init script and starts it as daemon.
- I wrote the aforementioned init script to daemonize obfsproxy. No such script is included in the debian package at the moment.
- A configuration file containing all the necessary parameters for obfsproxy is placed in /etc/obfsproxy.con and is then sourced by the init script. In specific, parameters contained are the pluggable transport used by obfsproxy, a special parameter for the transport, the listening port, the destination ip address and port to which the traffic will be forwarded and the log level of the daemon.
- A manifest was added to site_shorewall so as firewall permits incoming traffic to the port obfsproxy listens to.
- provider_base/services/obfsproxy.json was added. This is the base of the obfsproxy service. It’s compiled on leap platform admin’s side and outputs the shared secret of scramblesuit, the listening port and the openvpn gateway.
You can check the above commits and more in the feature/obfsproxy branch.
- Two new macros are used in obsfproxy.json, one to pick a random base32 encoded string for scramblesuit transport and one to pick a random port within a specified range.
Those macros were merged in leap_cli. feature/obfsproxy_macros branch.
Obfsproxy and Scramblesuit
- An issue was raised with the obfsproxy daemon. The pluggable transport which was chosen is scramblesuit. Scramblesuit protocol defines a shared password between a client and server, and this password is given from command line when obfsproxy is run unmanaged i.e. not managed by Tor. That way the password is visible in the system’s process list, which is considered a problem. This was actually reported some time ago, when obfs2 pluggable transport was still used.
I wrote and suggested a patch for the scramblesuit transport used in obfsproxy, so as the password can be read from a file. You can find more info on that issue, as well as the patch at the relevant ticket.
Things to be done
- As long as daemon is configured and running, obfsproxy’s connection details should be passed to web_app. Authenticated clients should then be able to fetch a new version of eip-service.json via the api, which will contain everything necessary for them to obfuscate their connection.
Many thanks to every single person that helped me with comments, reviews, advices. Thanks!