Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Snowflake Mobile
Snowflake Mobile
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 4
    • Issues 4
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 1
    • Merge Requests 1
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • The Tor Project
    • A
      Anti-censorship
  • Pluggable Transports
  • Snowflake MobileSnowflake Mobile
  • Wiki
  • Home

Last edited by HashikD Aug 20, 2020
Page history

Home

Snowflake Proxy on Mobile

The Snowflake proxy is one of the pluggable transport circumvention tools used by the Tor Project. There is an existing Web-extension version of the Snowflake proxy. The goal is to leverage the ubiquitous nature of Android phones; A proxy relays the data to Tor in the background on mobile phones.

Project Implementation ❄️

Overall_connection Shown above is the general working of the Snowflake bridge. In this project, the Android device is the Snowflake proxy. Implementation of the project divided into two parts:

Part A: Snowflake Peers Connection ​- Involves the process of WebRTC connection establishment between Snowflake peers, i.e., the Snowflake proxy and client, using ​the Broker​ as a ​Signaling server​.

Part B: Relaying Traffic to Tor - After connection establishment is finished, the data is relayed to a Tor using a WebSocket.

Snowflake

Part A: Snowflake Peers Connection: ​Establishing a WebRTC connection involves multiple steps

Getting Client SDP Offer: ​Proxy sends POST requests to the server as a long-poll, we will run this task as a ​service​. Everything should happen in the background, including connection establishment, relaying the data; hence a background service is used. The broker endpoint for the offer is at "/proxy" read more about Broker's endpoint specifications ​here.

Since it's long-poll, we can set a custom time-out for the connection in OkHttpClient and pass it to Retrofit.

final ​OkHttpClient​ okHttp = ​new​ OkHttpClient.Builder()
.readTimeout(​60​, ​TimeUnit​.​SECONDS​)
.connectTimeout(​60​, ​TimeUnit​.​SECONDS​)
.build();

In the future, If we want to connect multiple snowflake clients, launch a thread for every client. The bottom image illustrates the process of service and threads to serve multiple clients. RxJava(RxAndroid), which is already included in the project, can be used to make the launch the threads.

Service_threads

Part B: Relaying Traffic to Tor: Now that the WebRTC connection is established, this data should be sent to the relay using a WebSocket​. For Snowflake Proxy Web, the following address is used. The latest Endpoint used can be found in the configuration of web-extension ​here.

Config​.​prototype​.relayAddr = {
host: 'snowflake.freehaven.net',
port: '443'
};

The same address can be used for Android. Snowflake supports both TLS and non-TLS WebSocket, i.e., WSS and WS; by default, the server uses WSS (TLS WebSocket).​There are many libraries to work with WebSockets. Libraries like, ​Scarlet​, nv-websocket-client, ​OkHttp, etc. Since the project is using OkHttp for Retrofit anyway, OkHttp will be used to handle WebSockets as well, and its functionality is good enough for the project's use case.

Roadmap 🛣️

  • Part A
    • Setting up the project
    • Setting up the libraries
    • Designing a workable UI
    • Setting up the Service to handle the persistent notification
    • Setting up the Service to establish a connection
    • HTTP Call to the broker in a long polling fashion to get the offer
    • SDP De-serialization
    • SDP Serialization
    • HTTP Call to send the answer to the broker
    • Establish a WebRTC connection
    • Handling connection termination
  • Part B
    • Setting the Tor relay (WebSocket) endpoints
    • Setting up WebSockets
    • Setting up WebSocketListener
    • Serialization between WebSocket and WebRTC bytes
    • Establishing the connection to Tor relay using WebSocket
    • Testing the connection to the relay
    • Relaying the data back and forth to and from WebSocket and WebRTC
  • Settings
    • User custom STUN servers to use
    • User custom broker URL
    • User custom relay URL
  • Changing project to MVP
  • UI
    • Making the designs.
    • Implementing the design for MainActivity (main user screen)
    • Implementing the design for Notification UI
    • Testing the new UI
  • Reachability tests
  • CI for the project

Contribution

  • For ideas, bug reports, etc. contributions, please use the issues tab in this project.
  • For code contribution, kindly refer to the README.md in the project.

Development and People

This project is developed under Google Summer of Code Program
I (HashikD) built this project with the help of my mentors Cecylia (cohosh) and Philipp (phw)
feel free to ask questions and join the team! 😃
Anti-censorship Team

Contact 📪

You can use Tor OFTC IRC to contact the people at Tor and get to know the dev team.
If you want to contact me exclusively you can email me at HashikDonthineni(@)Gmail(dot)com

Clone repository
  • GSoC 2020 Wrap Up Documentation
  • Home