A draft research paper about Snowflake – comments welcome

[wkrp]

Cecylia Bocovich, Arlo Breault, Serene, Xiaokang Wang, and I are writing a research paper about Snowflake. We have an almost completed draft that we are asking for input on. This is not a published paper yet—we’re asking for comments in advance of submitting it for peer review.

snowflake.20231003.e6e1c30d.pdf

Comments are welcome. If you are a Snowflake user or proxy operator, and something we wrote does not match your experience, please let us know. It doesn't yet cover some very recent events like #291.

[IrradiatedKiwi]

Thank you for sharing.This paper doesn't have those jargons and the technical aspects are well explained,so it is quiet easy to understand even for a non professional like me.I also learned something new and become a bit more understanding with snowflake.

[wallpunch]

This was a very accessible introduction to Snowflake for someone who has a foundation in network programming but isn't familiar with the technical details of Tor or Snowflake in particular. I had a couple questions after reading:

1) For domain fronting, it sounds like a single front domain (and eventually a second alternate) were used for all Snowflake clients, but there aren't any details about how that domain was chosen or why it was so resistant to blocking by censors.

2) The decision to not add multiplexing now that you have Turbo Tunnel sessions is quite surprising. Intuitively it seems the ability to have redundant fallback connections available for immediate use would significantly improve usability. I would love to hear more information about the relevant experiments mentioned in the paper that led to this decision. In particular, is there a clear benefit of adding multiplexing but it is outweighed by the technical difficulties of adding multiplexing, or do the experiments indicate that even were multiplexing added it would not have a noticeable effect?

[wkrp]

1. For domain fronting, it sounds like a single front domain (and eventually a second alternate) were used for all Snowflake clients, but there aren't any details about how that domain was chosen or why it was so resistant to blocking by censors.

I don't think there's a lot of documentation about this. Unfortunately the options for domain fronting these days are few and getting fewer—nothing is really ideal.

You can see some considerations here:

• Is there a better moat/snowflake SNI than cdn.sstatic.net?
• Anti-censorship team meeting notes, 2023-09-21
  • http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-09-21-15.57.log.html#l-77
  • http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-10-05-15.57.log.html#l-14

Some past changes:

• Change Snowflake rendezvous to use Azure
• Update domain front for Snowflake
• https://forum.torproject.org/t/problems-with-snowflake-since-2023-09-20-broker-failure-unexpected-error-no-answer/9346 (#291)

2. The decision to not add multiplexing now that you have Turbo Tunnel sessions is quite surprising. Intuitively it seems the ability to have redundant fallback connections available for immediate use would significantly improve usability. I would love to hear more information about the relevant experiments mentioned in the paper that led to this decision. In particular, is there a clear benefit of adding multiplexing but it is outweighed by the technical difficulties of adding multiplexing, or do the experiments indicate that even were multiplexing added it would not have a noticeable effect?

The overall issue for the topic is https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/25723. A first try at implementation turned out experimentally not to do much for performance.

[wkrp]

The Snowflake paper has been conditionally accepted to USENIX Security 2024, which means that it will be part of the conference as long as we satisfy the reviewers with some revisions. We are working on final revisions now. Here is a current snapshot. If you have any more comments, we can try to take them into account up until about 2024-02-26.

snowflake.20240210.7181a5cd.pdf

[wkrp]

The paper was accepted to USENIX Security 2024. Here are HTML and PDF versions with all the final revisions.

Snowflake, a censorship circumvention system using temporary WebRTC proxies (online HTML) PDF version Local copy of PDF Paper source code and data

It will also eventually be up somewhere at https://www.usenix.org/conference/usenixsecurity24, along with a presentation video and slides.

[Tw-C]

I came across this state funded research after suspecting if Snowflake has been a lost cause, and guess what I found! https://www.mdpi.com/2076-3417/13/1/622