New SQS rendezvous method for Snowflake

This post is about a new feature that will be released in Tor Browser Alpha 13.5a5 and was released in Stable 13.0.10.

Before Snowflake can establish a peer-to-peer WebRTC connection, it needs to do a step called rendezvous, where the client connects to the broker and indicates its need for a proxy connection. The rendezvous method is modular and any kind of blocking-resistant request–response protocol can work. The two existing methods Snowflake uses for rendezvous is a domain-fronted HTTPS request and an AMP cache rendezvous. We have just deployed another rendezvous method that utilizes the Amazon SQS service from Amazon Web Services. Now, if any of these three rendezvous methods are blocked, we can switch over to one of the other methods.

To use this new rendezvous method, you will have to add the following bridge line to your Tor Browser:

snowflake 2B280B23E1107BB62ABFC40DDCC8824814F80A72 fingerprint=2B280B23E1107BB62ABFC40DDCC8824814F80A72,,,,,,,, utls-imitate=hellorandomizedalpn sqsakid=AKIA5AIF4WJJXS7YHEG3 sqsqueue= sqsskey=7SDMsJA4s5F+Webu/zL8vk0QWWIlkW6cWNfUlCKQ

Background for Amazon SQS rendezvous:

This feature was implemented by five Software Engineering students from the University of Waterloo: Andrew Wang, Anthony Chang, Kieran Quan, Michael Pu, Yi Wei Zhou with the help of Cecylia Bocovich from the Tor anti-censorship team.


This seems awesome! Would this be directly implemented into TBB/Orbot in the future without having to put in a separate bridge line?


That depends on a few things:

  • where it is unblocked/remains unblocked
  • how much it costs as we ramp up usage

The next step will be to add in SQS bridge lines to the circumvention settings API responses for regions we know it works.