Use TLS WebSockets (wss://) for proxy-to-server communication

We might as well use secure WebSockets (wss://) instead of plain WebSockets (ws://).

For this, the server plugin needs TLS support. It can probably be cribbed from meek-server, which defaults to TLS.

I started a thread asking for brainstorming on how to easily used Let's Encrypt with a specialized HTTP server like out server plugins.

added component::circumvention/snowflake cupcake priority::high resolution::fixed severity::normal snowflake status::closed type::enhancement labels

Been updating a few things on my end -- when I visit keroserene.net/snowflake with https, snowflake doesn't work due to the lack of wss from proxy to server. While it's trivial to set the proxy javascript to use wss, we still also need to get the server plugin to accept that. How much time would it take to get TLS support on the server plugin?

Trac:
Cc: N/A to serene

Replying to serene:

Been updating a few things on my end -- when I visit keroserene.net/snowflake with https, snowflake doesn't work due to the lack of wss from proxy to server. While it's trivial to set the proxy javascript to use wss, we still also need to get the server plugin to accept that. How much time would it take to get TLS support on the server plugin?

It's probably not too bad. This is the source file: https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/server/server.go

You can probably copy the startListenerTLS and listenTLS functions from meek-server: https://gitweb.torproject.org/pluggable-transports/meek.git/tree/meek-server/meek-server.go?id=edc089e5af06eebf6a5b1d84d278082746a22c48#n306

And then of course we'll have to get a certificate and put a domain name for the bridge in the proxy rather than an IP address.

Increasing priority on this now because of imminent snowflake alpha -- we need to increase the capacity of the snowflake network, and this would have a huge impact on distribution of snowflake proxies. We should definitely not be limited to plain http sites, especially once cupcake+snowflake is happening. Will try to find more time and/or help on this soon.

Trac:
Keywords: N/A deleted, snowflake, cupcake added
Priority: Low to High

I pushed https://gitweb.torproject.org/pluggable-transports/snowflake.git/commit/?id=5cd2a226aae41a9fe834f19dee15a851b115e7bb which gets us part of the way there.

Trac:
snowflake-letsencrypt.0.patch

I have some code for automatic TLS on the websocket server. I just asked for a personal repo to host it in #21276 (moved), but in the meantime here's a patch: snowflake-letsencrypt.0.patch​

It's using the acme/autocert package. This integrates with the Config.GetCertificate callback to fetch a new certificate on demand. The basic idea comes from a patch gtank made for meek-server in comment:8:ticket:18655. Basically, now, instead of using --tls-cert and --tls-key options, you use --acme-hostnames specifying the hostnames that can appear on the certificate. One surprise is that if you are not already listening on port 443, the program will open an additional listener on 443, because that's the only port the ACME spec allows.

I have the code as of 138d2b5391 running at wss://snowflake.bamsoftware.com:443. It is a dedicated machine I just set up for the purpose. I made the necessary changes to the proxy code to use this wss bridge. We can add additional hostnames, too, to avoid relying solely on bamsoftware.com DNS: you just have to make a new DNS name (e.g. snowflake.keroserene.net), point it at the same server, and then add an additional --acme-hostname option to the ServerTransportPlugin command in torrc.

Trac:
Status: new to needs_review

Here is a repo: https://gitweb.torproject.org/user/dcf/snowflake.git/?h=letsencrypt Here is the diff: https://gitweb.torproject.org/user/dcf/snowflake.git/diff/?h=letsencrypt&id=138d2b5391&id2=af70d49e96

I merged the letsencrypt branch in 61b604fc46df7e43d8a6069e7c6c00204d46665d.

I think all the necessary TLS parts are in place now, and the badge is now using TLS websockets by default.

serene, could you change the badge code at https://keroserene.net/snowflake/ to use an https link for keroserene.net/snowflake/embed.html? I think that's the last thing required.

Replying to dcf:

I think all the necessary TLS parts are in place now, and the badge is now using TLS websockets by default.

serene, could you change the badge code at https://keroserene.net/snowflake/ to use an https link for keroserene.net/snowflake/embed.html? I think that's the last thing required.

Serene updated the links to use https.

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

closed

mentioned in issue #18655 (moved)

moved to tpo/anti-censorship/pluggable-transports/snowflake#18654 (closed)