Ridhwan Ikhwanto (43d520ce) at 27 Aug 17:14
Switch to Alpine for builder
Ridhwan Ikhwanto (80e0174a) at 27 Aug 15:51
Add documentations
Ridhwan Ikhwanto (0f52f0ea) at 27 Aug 15:36
Do multistage
Sorry for not pointing it out before, but the Dockerfile for binfmt
is available here under permissive license so maybe we can fork it and build it ourselves so we can truly have control over it?
Otherwise, someone on the same issue said that compiling qemu from source will also do it, but I haven't checked it out further.
Oh yea I just found it out today, I'll try it out later and put it here when I succeeds. Thank you so much for the info!
Okay I ran this in an AWS EC2 instance and it uses 3.5 GB outbound in about 3 hours so I guess it just works. And it will also blow my Free Tier's outbound bandwidth limit in less than a day.
I will add extra documentation about how to run this image later and then mark it as ready.
The current Docker image for Snowflake proxy is gigantic at 319.83 MB compressed and 905 MB on disk. As most of this is space usage are Golang package (installing golang-go
on Debian itself takes nearly 700 MB on disk) and build dependencies, I think we need to do different approach at making this image. It also helps that binaries compiled by Go on default settings don't need any runtime dependencies, so we can just strip everything down.
So I rearchitectured the Dockerfile to do an entirely different way of building the image: instead of using golang as base image, I started with the lightweight Alpine Linux. Then I installed golang and every other build dependencies, then download Snowflake's tarball, extract and compile it and put it in /usr/local/bin
. Finally, I just removed the tarball, extracted tarball and every build dependencies.
This resulted in a massively smaller image at only 13 MB compressed and about 30 MB on disk. You can check out my Docker Hub to see my build results.
I also removed the hardcoded addresses from ENTRYPOINT so proxy operators can provide the settings themselves by adding a command:
line in docker-compose.yml or when running docker run
or just use the default settings. So this will also close #1
If using Alpine Linux is not something we are fond of, I also created a similar one but using Debian as the base image. But Debian creates a significantly larger image at about 50 MB compressed and about 130 MB on disk.
Hey @meskio
I have added additional necessary instructions for cross-building and I hope you can review this soon
Ridhwan Ikhwanto (377c1408) at 26 Aug 13:01
Add additional necessary instructions
... and 1 more commit
Ridhwan Ikhwanto (148effcf) at 25 Aug 17:50
Separate optional command from entrypoint
Ridhwan Ikhwanto (edc724d0) at 25 Aug 16:32
Bump dist from stable to bullseye
At first I was confused because it worked perfectly on Docker on Windows run from WSL but when I tried building on a real Linux machine it gave the same exact problem, then I did further research and it turned out that buildx doesn't really work out-of-the-box on Linux machines for building "foreign" archs because it need qemu packages and the qemu packages distro maintainer provides doesn't support containers.
Thankfully there's an easy fix for these qemu packages from here. So basically we need to run this first on the build machine
docker run --privileged --rm tonistiigi/binfmt --install arm64
It now builds perfectly in my Ubuntu 21.04 machine, and I'm going to add it to the README and commit it later.
Ridhwan Ikhwanto (66efbe11) at 24 Aug 12:47
Remove relay and broker settings
Ridhwan Ikhwanto (f8415113) at 24 Aug 12:45
Change to bz2
Ridhwan Ikhwanto (588f49fc) at 24 Aug 12:41
Try debian
Thank you so much for making everything clearer!
But somehow when I tried to verify this by compiling proxy from source at v1.1.0 and running both ./proxy https://snowflake-broker.torproject.net/
and ./proxy
multiple time on a machine in the router's DMZ, somehow both of them often gave NAT type: unknown
.
The weird thing is, somehow ./proxy
sometimes gave NAT type: unrestricted
while ./proxy https://snowflake-broker.torproject.net/
never at all.
In case it is relevant, the output from stun-nat-behaviour
is NAT mapping behavior: endpoint-independent
and NAT filtering behavior: endpoint-independent
.
One of the simplest and arguably better tool to use for signatures is signify
from OpenBSD. It is available in many Linux distros as signify-openbsd
and in macOS as signify-osx
on Homebrew so I think it will be easy to add this method for verifying signatures.
It doesn't have the concept of keyring and just uses a plaintext file as its public key. The public key itself is so short we can either show in on the website and tell users to put it in a file themselves or make it available for download. Here's how the public key looks like:
untrusted comment: signify public key
RWRN/oBIs7NJVn2TjjWFg/n/X5RKW5z9qMWeLRB42ilN9N8xi2ZhgLQ7
The command for signing and verifying are also simple. Here's the man page.
The only problem left is that signify
isn't available on Windows, but there's a similar package with a one-way compatibility called minisign
. signify
can verify signatures made by minisign
but not vice versa, so maybe we can create the signatures using minisign
and guide Linux users to verify using signify
while Windows users uses minisign
and macOS has the option to use both.
I tried to analyze this problem by doing packet capture on Tor Browser Alpha on Android and it seems like when it showed Bootstrap 10%
all it did was doing STUN requests trying to get direct DTLS connection to a proxy. When a direct DTLS connection was finally made, it progressed until Tor finished bootstrapping.
I did the test multiple times and looking at the IP addresses that I did make DTLS connection to, one belonged to Vultr (probably it was a public IP address for an instance) and another one was my own IP where I run a Snowflake proxy in a laptop put in a DMZ. Note that this connection was made in my phone which used mobile data so it had a different IP address from a different ISP than my aforementioned laptop.
So I suspect this has something to do with how restrictive the NAT are. Further raising my suspicion on NAT is that my aforementioned laptop-in-a-DMZ always succeeds when bootstrapping Tor Browser using Snowflake, and it does it quickly compared to my phone.