Skip to content
Snippets Groups Projects
Select Git revision
  • errorf-wrap
  • handshake-padding
  • encapsulation-readdata-buffer
  • remove-ipdistinct
  • sendqueue-clientid
  • ip_bind_address_no_port
  • clustercounter-scan-err
  • queuepacketconn-pool
  • 40043
  • kcp-snmp-client-log
  • client-torrc-crusty
  • server-multi-kcp
  • turbotunnel-perf
  • clientidaddrmap-98304
  • websocketconn-mem
  • server-srcaddr
  • smux-server-keepalive-4min
  • gorilla-websocket-v1.5.0
  • server-perf.1
  • multi-kcp
  • server-perf.20220923
  • server-perf.20220923.1
  • v2.3.0
  • v2.2.0
  • v2.1.0
  • v2.0.1
  • v2.0.0
  • v1.1.0
  • v1.0.0
  • webext-0.2.2
  • webext-0.2.1
  • webext-0.2.0
  • webext-0.1.0
  • webext-0.0.13
  • webext-0.0.12
  • webext-0.0.11
  • webext-0.0.10
  • webext-0.0.9
  • webext-0.0.8
  • webext-0.0.7
40 results
Compare
user avatar
Change the representation of domain fronting in HTTP rendezvous.
David Fifield authored 
Formerly, BrokerChannel represented the broker URL and possible domain
fronting as
	bc.url  *url.URL
        bc.Host string
That is, bc.url is the URL of the server which we contact directly, and
bc.Host is the Host header to use in the request. With no domain
fronting, bc.url points directly at the broker itself, and bc.Host is
blank. With domain fronting, we do the following reshuffling:
	if front != "" {
		bc.Host = bc.url.Host
		bc.url.Host = front
	}
That is, we alter bc.url to reflect that the server to which we send
requests directly is the CDN, not the broker, and store the broker's own
URL in the HTTP Host header.

The above representation was always confusing to me, because in my
mental model, we are always conceptually communicating with the broker;
but we may optionally be using a CDN proxy in the middle. The new
representation is
	bc.url   *url.URL
        bc.front string
bc.url is the URL of the broker itself, and never changes. bc.front is
the optional CDN front domain, and likewise never changes after
initialization. When domain fronting is in use, we do the swap in the
http.Request struct, not in BrokerChannel itself:
	if bc.front != "" {
		request.Host = request.URL.Host
		request.URL.Host = bc.front
	}

Compare to the representation in meek-client:

https://gitweb.torproject.org/pluggable-transports/meek.git/tree/meek-client/meek-client.go?h=v0.35.0#n94
	var options struct {
		URL       string
		Front     string
	}
https://gitweb.torproject.org/pluggable-transports/meek.git/tree/meek-client/meek-client.go?h=v0.35.0#n308
	if ok { // if front is set
		info.Host = info.URL.Host
		info.URL.Host = front
	}
55f4814d
History
user avatar 55f4814d
History
Name Last commit Last update
broker
client
common
doc
probetest
proxy
server
.gitignore
.gitlab-ci.yml
.gitmodules
.travis.yml
CONTRIBUTING.md
ChangeLog
LICENSE
README.md
go.mod
go.sum
README.md

Snowflake

Build Status

Pluggable Transport using WebRTC, inspired by Flashproxy.

Table of Contents

Structure of this Repository

  • broker/ contains code for the Snowflake broker
  • doc/ contains Snowflake documentation and manpages
  • client/ contains the Tor pluggable transport client and client library code
  • common/ contains generic libraries used by multiple pieces of Snowflake
  • proxy/ contains code for the Go standalone Snowflake proxy
  • probetest/ contains code for a NAT probetesting service
  • server/ contains the Tor pluggable transport server and server library code

Usage

Snowflake is currently deployed as a pluggable transport for Tor.

Using Snowflake with Tor

To use the Snowflake client with Tor, you will need to add the appropriate Bridge and ClientTransportPlugin lines to your torrc file. See the client README for more information on building and running the Snowflake client.

Running a Snowflake Proxy

You can contribute to Snowflake by running a Snowflake proxy. We have the option to run a proxy in your browser or as a standalone Go program. See our community documentation for more details.

Using the Snowflake Library with Other Applications

Snowflake can be used as a Go API, and adheres to the v2.1 pluggable transports specification. For more information on using the Snowflake Go library, see the Snowflake library documentation.

Test Environment

There is a Docker-based test environment at https://github.com/cohosh/snowbox.

FAQ

Q: How does it work?

In the Tor use-case:

  1. Volunteers visit websites which host the "snowflake" proxy. (just like flashproxy)
  2. Tor clients automatically find available browser proxies via the Broker (the domain fronted signaling channel).
  3. Tor client and browser proxy establish a WebRTC peer connection.
  4. Proxy connects to some relay.
  5. Tor occurs.

More detailed information about how clients, snowflake proxies, and the Broker fit together on the way...

Q: What are the benefits of this PT compared with other PTs?

Snowflake combines the advantages of flashproxy and meek. Primarily:

  • It has the convenience of Meek, but can support magnitudes more users with negligible CDN costs. (Domain fronting is only used for brief signalling / NAT-piercing to setup the P2P WebRTC DataChannels which handle the actual traffic.)

  • Arbitrarily high numbers of volunteer proxies are possible like in flashproxy, but NATs are no longer a usability barrier - no need for manual port forwarding!

Q: Why is this called Snowflake?

It utilizes the "ICE" negotiation via WebRTC, and also involves a great abundance of ephemeral and short-lived (and special!) volunteer proxies...

More info and links

We have more documentation in the Snowflake wiki and at https://snowflake.torproject.org/.