Skip to content
GitLab
Menu
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
leap
bitmask-vpn
Commits
f7954bc1
Unverified
Commit
f7954bc1
authored
Jun 17, 2021
by
Kali Kaneko
Browse files
[docs] add working document about snowflake
just a dump from a working pad, comments are welcome
parent
1fafe7b3
Changes
1
Hide whitespace changes
Inline
Side-by-side
docs/research/snowflake.txt
0 → 100644
View file @
f7954bc1
Initial brainstorm
==================
Date: 16 Jun 2021
Authors: cyberta, kali
Goal
====
Using snowflake to help circumvent blocks on leap VPN.
Assumptions
===========
* 1. Not all the gateways (or obfs4 endpoints, or tls proxies etc) are blocked.
Phases
======
* 1. Use snowflake ONLY in the bootstrap of the VPN connection <- we're here now.
* 2. Use snowflake as a pluggable transport to tunnel an openvpn connection - aka "mutual aid" scenario.
Comparison of approaches
========================
Approach A: depend on Tor binary
--------------------------------
- Pros:
+ no complexity on the backend side
+ probably more snowflake proxies available
+ we might even depend on a preinstalled tor binary instead of shipping it -> no negative effect on app size
- Cons:
+ Not valid for PHASE 2 (actually moving traffic)
+ Shipping Tor binary (how big is it, static?) - but we can just assume that an user that needs to use this is sufficiently motivated to install Tor
+ Need to control failures, probably more difficult than with a better integrated solution
+ SLOW - need to stablish the circuit, bootstrap can get interrupted, either by censorship or other reasons.
- BUT: Is it possible to build a single-hop circuit?
+ This whole approach for this phase might be a good PoC, but stupid -
under censorship, we should expect DNS blocking, so if we're going to rely
on domain fronting, we could just domain-front the api (plus the certs,
there can be some complexities there). - However Domain fronting is
probably going to die sooner or later
QUESTION: what's the status of azure df? what's the status of the
alternatives to domain fronting for snowflake? (cecylia was working on
this, should look for the issue)
Approach B: no dependency on Tor
--------------------------------------------------------
This is a bit fuzzy, because we could still improve over the previous approach
by using Tor as a library.
- Pros:
+ no Tor binary dependencies, only go code.
+ might be a solution to route vpn traffic: a censorship resistant approach
that might not require sysadmins to regularly change ips for the PT bridges
+ less boring :), explorative work that might get further funding
+ little bit faster (no establishment of the circuit, no additional 3 tor hops) to fetch data from the api
- Cons:
+ We need to fork or modify snowflake :(
+ We need to change the webrt connection proxy <-> tor relay by something else.
+ Either maintain the fork ourselves, or convince Tor of making
modification s that allow a more generic "snowflake-not-as-a-Tor-transport"
codebase -> this is a key point that we should explore with tor
anticensorship team, I think. agreed
+ We *will* always have a much lesser pool of volunteers than what Tor is
able to nurture (Tor is orders of magnitude better funded/governed than
leap is).
See https://snowflake-broker.torproject.net/debug - we don't have traction
to have some 100s of volunteers, even with the expected churning rates.
+ wrt. routing VPN traffic: how well does the ephemerality of the proxies
play with the users expectation of a uninterrupted internet connection -
really good point. is it preferrable bad internet or no internet at all? we
need to start asking people.
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment