Purchase new snowflake domain to fix "safe browsing" issue

*.bamsoftware.com is currently marked as "unsafe" by Google's "safe" browsing system, which breaks in-browser snowflake proxies. We don't know what caused this decision. It's probably a false positive because of an educational article but it may be snowflake itself. We are still waiting to hear back from Google.

We cannot transition the system to a torproject.org domain because if snowflake itself was the issue, we may end up getting torproject.org marked as unsafe too. Besides, our sysadmins may not like providing a domain for a system they don't control.

As a temporary solution, we could purchase another domain and transition to it. Examples are:

• snowflake.best
• snowflake.rocks
• snowflake.world
• snowflake.army

added component::circumvention/snowflake in Legacy / Trac points::2 in Legacy / Trac priority::high in Legacy / Trac resolution::fixed in Legacy / Trac severity::major in Legacy / Trac status::closed in Legacy / Trac type::task in Legacy / Trac labels

$ host snowflake.freehaven.net
snowflake.freehaven.net is an alias for snowflake.bamsoftware.com.
snowflake.bamsoftware.com has address 37.218.242.151
snowflake.bamsoftware.com has IPv6 address 2a00:c6c0:0:151:4:8f94:69f5:7c01

$ host snowflake-broker.freehaven.net
snowflake-broker.freehaven.net is an alias for snowflake-broker.bamsoftware.com.
snowflake-broker.bamsoftware.com has address 37.218.240.96

Feel free to give these a try. We can use them for the medium term until we learn more about whether it was the woot paper that caused the trouble, or snowflake. (And if it was snowflake, ok I guess I will now have two domains to ask the safe browsing team wtf about.)

Long term, once we've resolved the zip bomb question, I think using a cname in the torproject.net domain will be a fine choice.

I configured the hosts to recognize the freehaven.net names.

One the broker, in /etc/service/snowflake-broker/run, I changed --acme-hostnames snowflake-broker.bamsoftware.com to --acme-hostnames snowflake-broker.bamsoftware.com,snowflake-broker.freehaven.net and ran sv restart snowflake-broker.

On the bridge, in /etc/tor/torrc, I changed --acme-hostnames snowflake.bamsoftware.com to --acme-hostnames snowflake.bamsoftware.com,snowflake.freehaven.net and ran service tor restart.

So if we want to go ahead with this plan, all that's needed is changing the broker and bridge addresses in the proxy code, and redeploying.

Replying to arma:

Long term, once we've resolved the zip bomb question, I think using a cname in the torproject.net domain will be a fine choice.

*.torproject.net and *.torproject.org are both routinely blocked for residential Internet connections in the UK on the basis that they provide circumvention of the connection filtering. The snowflake extension itself doesn't provide circumvention to the user of the extension so there is a good basis for arguing it shouldn't be blocked (and I've had these arguments with 's staff, who maintain some of the block lists) but I think their stuff doesn't really work on subdomains or their staff did not configure things with subdomains when I've made complaints. It's all or nothing.

https://github.com/cohosh/snowflake/compare/freehaven

Should probably put this in needs_review. I tested it out locally. Should we go ahead and do this update?

Trac:
Status: new to needs_review

Okay apologies if I moved on this too quickly. I pushed the fix to both the chrome and mozilla webstores and it appears to be working for both legacy/trac#31231 (moved) and legacy/trac#31232 (moved).

As a side note, Mozilla must have changed their validation process a bit because they complained that the snowflake icon in the manifest wasn't square. I made this change and pushed it as well.

Alright, sorry for the messy update/versioning. I'd accidentally included the embed.html and embed.js files from a different branch. Should be fixed now.

Okay apologies if I moved on this too quickly

No problem, thanks for getting it out

it appears to be working for both legacy/trac#31231 (moved) and legacy/trac#31232 (moved).

s/#31232/legacy/trac#31230 (moved)/

Alright, sorry for the messy update/versioning. I'd accidentally included the embed.html and embed.js files from a different branch. Should be fixed now.

I opened legacy/trac#31253 (moved) to hopefully make our lives easier

it appears to be working for both legacy/trac#31231 (moved) and legacy/trac#31232 (moved). s/#31232/legacy/trac#31230 (moved)/

Note that, while those two were specific to the addon, the badge is still not updated.

Why is the update taking this much time to appear in the Chrome addon store?

Replying to cypherpunks:

Why is the update taking this much time to appear in the Chrome addon store? In our experience so far, the Chrome addon store takes at least a day (maybe longer?) to approve new versions. I'm not sure why.

Is the in-page version of the proxy hosted at https://snowflake.torproject.org/snowflake (or more specifically, the javascript proxy code in https://snowflake.torproject.org/snowflake.js) going to be maintained as well? It currently still references bamsoftware.com.

I hope so, since I prefer that over the Firefox addon because it lets me see what's actually happening, and I can run more than one tab with it instead of just the one addon proxy. But if not, it should probably be removed from the docs page at https://trac.torproject.org/projects/tor/wiki/doc/Snowflake. There should either be an explicit commitment to keep the in-page js proxy up to date with changes made to the plugin, or the docs page should stop showing it as a valid option.

Replying to cohosh:

Replying to cypherpunks:

Why is the update taking this much time to appear in the Chrome addon store? In our experience so far, the Chrome addon store takes at least a day (maybe longer?) to approve new versions. I'm not sure why.

I checked just now (2019-07-27T15:19:08+00:00) and it's now showing version 0.0.7 rather than 0.0.8

Replying to dcf:

I checked just now (2019-07-27T15:19:08+00:00) and it's now showing version 0.0.7 rather than 0.0.8 Thanks David, another shameless question when will cupcake use the new freehaven domain? (I tested it and I only saw the bamsoftware one in the addon's settings)

Replying to cypherpunks:

Thanks David, another shameless question when will cupcake use the new freehaven domain? (I tested it and I only saw the bamsoftware one in the addon's settings)

I just sent email to saint about that today, we'll see.

Trac:
Cc: cohosh, dcf, arlolra, phw to cohosh, dcf, arlolra, phw, saint

Replying to cypherpunks:

Is the in-page version of the proxy hosted at https://snowflake.torproject.org/snowflake (or more specifically, the javascript proxy code in https://snowflake.torproject.org/snowflake.js) going to be maintained as well? It currently still references bamsoftware.com.

Relax, friend, it was just a little slower to update :) I deployed from 0bded511b99a396df2172c89f0ac9a9ae21a2115 at about 2019-07-27 15:53.

I also added a deployment guide to proxy/README.md to hopefully make it smoother in the future.

Replying to dcf:

Replying to cohosh:

Replying to cypherpunks:

Why is the update taking this much time to appear in the Chrome addon store? In our experience so far, the Chrome addon store takes at least a day (maybe longer?) to approve new versions. I'm not sure why.

I checked just now (2019-07-27T15:19:08+00:00) and it's now showing version 0.0.7 rather than 0.0.8 Yeah, there's a different packaging requirement for Chrome and Firefox and I messed up the Firefox 0.0.7 upload so had to do a version bump. The Chrome one is fine (I think). In any case, the update took too long for me to just bump it right away again.

Since this discussion happened, there are also domains snowflake.torproject.net and snowflake-broker.torproject.net reserved for this purpose (legacy/trac#31232 (moved), legacy/trac#31522 (moved)).

Also saint, I think we're waiting on confirmation that Cupcake is using the newer domains (i.e. tag webext-0.0.7 or later) to close this ticket. https://chrome.google.com/webstore/detail/cupcake/dajjbehmbnbppjkcnpdkaniapgdppdnc still says "Version: 2.0; Updated: July 26, 2019", which is the same day as webext-0.0.7, so I'm not sure.

Trac:
Status: needs_review to needs_information

I'll close this now because we have the *.freehaven.net and *.torproject.net domain names, and the issue is moot anyway because bamsoftware.com is no longer on the safe browsing blacklist.

Trac:
Resolution: N/A to fixed
Status: needs_information to closed