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.
So as part of integrating obfsproxy to leap platform, a relevant .json file is needed. Since obfsproxy works closely with the eip service, obfsproxy details will be included as part of the eip service json.
A couple of decisions were made on that issue:
-
Do not change existing eip-service.json
-
Add obfsproxy values in a new version, eip-service-2.json
-
Serve eip-service-2.json from the url path used at the moment,
-
Make .json files available only to authenticated users
-
Eventually move service definition files to /config/provider/
The relevant tickets are #5703, #5704, #5705, #5706.
You can find the relevant feature branches here. They will be merged in feature/obfsproxy where a couple of others commits were made lately.
Locking down json files only to authenticated users still needs care.
Obfsproxy deployment strategy
Obfsproxy service is tied to the vpn service. Essentially obfsproxy is used to obfuscate the underlying vpn traffic. As discusses so far, obfsproxy service will be deployed along with the eip service in a node, but a provider will have the option to deploy standalone obfsproxy nodes too. Figuring out the best deployment strategy for an obfuscation service is generally a hard problem and depends on the adversary’s capabilities. You can read more in the relevant ticket.
What’s next?
Start looking client side!