Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2024-02-15T16:41:17Zhttps://gitlab.torproject.org/tpo/anti-censorship/bridge-port-scan/-/issues/8Create a debian package2024-02-15T16:41:17ZKezCreate a debian packageThe deploy process would be greatly simplified with a debian package. No more having to go through a manual build and deploy process, we could just build the package, and install it. Unfortunately, several of the go dependencies aren't p...The deploy process would be greatly simplified with a debian package. No more having to go through a manual build and deploy process, we could just build the package, and install it. Unfortunately, several of the go dependencies aren't packaged. Specifically, we're missing golang-github-pion-sdp-dev, golang-github-pion-stun-dev, golang-github-pion-webrtc.v3-dev, and golang-snowflake-dev.
I tried a custom build script instead of `dh-golang`, but it didn't go very well. I ended up getting the build working right, but not the install. I'm documenting my efforts here in case someone wants to try to pick it up in the future.
Here's the rules file I came up with. I had to install dart-sass and go manually. That's because dart-sass is not packaged, and debian's version of go is too old (1.15, needs 1.17 for the net.IP.IsPrivate method).
```makefile
#!/usr/bin/make -f
%:
#dh $@ --builddirectory=_build --buildsystem=golang --with=golang
python3 -m venv /tmp/venv
. /tmp/venv/bin/activate
curl -fsSL -o /tmp/dart-sass.tar.gz https://github.com/sass/dart-sass/releases/download/1.70.0/dart-sass-1.70.0-linux-x64.tar.gz
tar xC /tmp -f dart-sass.tar.gz
curl -fsSL -o /tmp/go.tar.gz https://go.dev/dl/go1.21.6.linux-amd64.tar.gz
tar xC /tmp -f go.tar.gz
pip install lektor pybabel
pip install -r frontend/lego/lektor-requirements.txt
env PATH="/tmp/dart-sass:/tmp/go/bin:$$PATH" bash build.sh
override_dh_auto_install:
dh_auto_install -- --no-source
```https://gitlab.torproject.org/tpo/anti-censorship/bridge-port-scan/-/issues/7Build process needs updating2024-02-07T13:11:37ZKezBuild process needs updatingThe web team's lektor site build process has changed a bit since this repo was last updated, and the repo no longer builds with the instructions provided (the build instructions seem a bit incomplete even without these build changes). So...The web team's lektor site build process has changed a bit since this repo was last updated, and the repo no longer builds with the instructions provided (the build instructions seem a bit incomplete even without these build changes). So the build process needs to be updated, and more thoroughly documented.https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/53Lock down the open invite endpoint on the distrubutor2024-02-21T13:58:13ZCecylia BocovichLock down the open invite endpoint on the distrubutorWe only want open invites to be requested by the telegram bot, so we should have that endpoint take an API key of some sort and only respond to requests if it matches one we know about.We only want open invites to be requested by the telegram bot, so we should have that endpoint take an API key of some sort and only respond to requests if it matches one we know about.Lox Ready for Open Testing Callonyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40324Snowflake git clone requires username?2024-01-26T16:58:45ZcypherpunksSnowflake git clone requires username?Hello,
I want to install Snowflake in my Debian PC, for that I tried to follow this instructions (Compiling and running from source):
https://community.torproject.org/relay/setup/snowflake/standalone/
To install golang was much more com...Hello,
I want to install Snowflake in my Debian PC, for that I tried to follow this instructions (Compiling and running from source):
https://community.torproject.org/relay/setup/snowflake/standalone/
To install golang was much more complicated that it says there as if you use apt you get an older and not supported version. Then I am asked for a username and password when I reach the git clone command. This is a surprise for me as I really didn't expect it and I cannot understand why you require this. Anyway I went to gitlab.com and I signed up for an account but it looks like that user is not good to download this package!. So I also clicked on https://gitlab.onionize.space/ and filled that form and I am waiting to get approved. Do you know how long does it normally takes? Why people cannot download it without all that registration process?
I am not an expert with Linux, sorry if I am asking something silly.
Thanks, Regards
Mhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40323Deploy new SQS rendezvous method2024-03-02T02:39:52ZCecylia BocovichDeploy new SQS rendezvous methodNow that !214 is merged, we can deploy this feature at the broker so that users with updated clients can start using it.
There are a few necessary steps:
- the broker deployment
- creation of public credentials
- set up alerts/precautio...Now that !214 is merged, we can deploy this feature at the broker so that users with updated clients can start using it.
There are a few necessary steps:
- the broker deployment
- creation of public credentials
- set up alerts/precautions against overchargesCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40012Domain fronting requests don't work on some older Android versions2024-03-12T00:09:26ZPier Angelo VendrameDomain fronting requests don't work on some older Android versionsTor Browser for Android supports old versions of Android (API21, i.e., Android Lollipop).
While 13.5a3 doesn't work there because I used some NIO API that requires API26+, I've opened a MR to fix this (tpo/applications/tor-browser!894)....Tor Browser for Android supports old versions of Android (API21, i.e., Android Lollipop).
While 13.5a3 doesn't work there because I used some NIO API that requires API26+, I've opened a MR to fix this (tpo/applications/tor-browser!894).
While checking if things worked, I noticed that domain fronting requests don't (I don't get the special countries list).
As written in that MR, I tried to enable logging (I added `"-enableLogging", "-logLevel", "DEBUG", "-unsafeLogging"` as arguments), but I could get only these messages:
```
2024/01/22 10:20:23 [NOTICE]: obfs4proxy-0.0.14 - launched
2024/01/22 10:20:23 [INFO]: libObfs4proxy.so - initializing client transport listeners
2024/01/22 10:20:23 [INFO]: meek_lite - registered listener: 127.0.0.1:55852
2024/01/22 10:20:23 [INFO]: libObfs4proxy.so - accepting connections
2024/01/22 10:20:23 [WARN]: meek_lite(bridges.torproject.org:443) - closed connection: readfrom tcp 127.0.0.1:55852->127.0.0.1:48836: io: read/write on closed pipe
```
I think there might be some problems with some HTTPS certificate (at least letsencrypt had this problem a few years ago, indeed cohosh mentioned snowflake#40087. Fastly isn't using letsencrypt, but maybe they have a similar problem).
I can open bridges.torproject.org both in TBA and in the system browser, but I can't open https://moat.torproject.org.global.prod.fastly.net/ because it has a wrong certificate.
I don't think I'm using the latest version of Lyrebird, because in the last one the log file should be called lyrebird.log (I submitted a patch for that, unless I missed the log filename), but I can try to build one from a nightly build.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/52Error in handling returned lox open invite credential2024-01-17T18:23:21ZCecylia BocovichError in handling returned lox open invite credentialThis error occurs even in the provided [index.js](https://gitlab.torproject.org/tpo/anti-censorship/lox/-/blob/1702027cb9d14f71df72e9d85cdfe77399b4fff8/crates/lox-wasm/index.js) testing file. When run against a local distributor and the ...This error occurs even in the provided [index.js](https://gitlab.torproject.org/tpo/anti-censorship/lox/-/blob/1702027cb9d14f71df72e9d85cdfe77399b4fff8/crates/lox-wasm/index.js) testing file. When run against a local distributor and the deployed one I get the following exception:
```
Got new Level 0 Lox Credential: {"P":[12,129,59,157,121,225,6,150,194,200,72,26,188,195,15,229,139,204,49,36,179,141,0,150,72,241,136,219,170,206,231,50],"EncQ":[[98,9,15,8,54,81,218,22,82,70,239,212,101,12,243,129,165,184,97,205,179,38,12,178,98,15,23,232,17,50,71,13],[80,202,142,91,230,150,9,187,208,240,238,169,26,222,64,120,238,164,35,142,217,192,10,235,0,126,191,163,255,65,178,80]],"id_server":[54,156,121,253,251,100,19,232,112,83,236,136,43,26,112,175,177,230,53,45,25,43,3,177,242,162,220,123,113,235,179,14],"TId":[72,44,140,114,216,192,186,180,125,101,94,61,134,10,93,29,95,251,160,50,201,174,38,169,160,206,88,236,107,182,234,124],"bucket":[163,125,100,109,48,31,232,75,243,29,174,45,46,128,1,87,3,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"level_since":[167,138,37,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"piBlindIssue":{"challenge":[171,251,205,97,209,196,140,133,221,211,120,119,192,152,55,185,168,79,86,137,171,158,64,156,27,47,206,177,62,25,151,5],"responses":[[235,38,47,107,237,22,154,128,245,29,86,173,17,122,45,28,153,170,186,224,24,101,123,62,137,221,81,130,222,113,172,3],[184,245,74,211,243,74,41,219,151,78,12,150,97,98,6,31,210,155,72,114,153,207,27,94,55,153,182,202,104,129,183,2],[19,6,1,194,22,128,239,61,135,67,246,55,72,95,36,218,170,243,157,127,240,29,4,192,196,133,213,109,94,54,225,6],[127,165,27,223,27,137,239,8,44,185,181,209,17,220,4,34,133,16,159,238,112,20,161,124,11,225,30,26,182,25,222,14],[254,18,160,132,137,176,117,103,138,146,49,254,200,1,50,139,27,226,23,204,95,3,52,189,228,8,116,85,71,241,221,15],[186,221,129,15,169,254,252,66,73,152,157,125,11,99,58,46,3,152,125,201,83,123,21,238,118,61,120,166,184,8,251,13],[17,183,56,176,75,141,205,193,209,98,112,70,226,161,117,170,67,43,183,76,167,22,198,216,226,1,242,143,81,5,174,3],[244,166,99,0,166,175,168,162,206,146,245,156,0,40,133,212,154,251,206,28,228,207,127,197,107,65,229,239,60,38,126,8]]},"bridge_line":{"addr":[54,56,46,49,56,51,46,50,48,53,46,49,56,0,0,0],"port":8444,"uid_fingerprint":13430605359072130000,"info":[116,121,112,101,61,111,98,102,115,52,32,102,105,110,103,101,114,112,114,105,110,116,61,34,52,53,50,48,48,67,48,68,49,53,67,48,51,66,54,57,54,52,53,57,57,66,66,51,50,51,54,50,54,69,57,53,56,48,50,51,55,55,68,57,34,32,112,97,114,97,109,115,61,83,111,109,101,40,123,34,105,97,116,45,109,111,100,101,34,58,32,34,48,34,44,32,34,99,101,114,116,34,58,32,34,122,86,117,113,114,97,88,97,51,76,109,122,102,79,113,100,110,65,111,106,53,88,83,49,120,48,111,82,101,78,51,112,78,56,97,75,70,86,116,87,121,100,104,70,107,83,76,120,97,75,78,70,111,69,119,77,78,48,49,88,47,83,89,81,43,117,57,106,99,103,34,125,41,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}} index.js:38:13
Uncaught trailing characters at line 1 column 2586
```https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/51get_invites_remaining should return 0 if the credential is untrusted2024-01-17T23:49:52ZCecylia Bocovichget_invites_remaining should return 0 if the credential is untrustedAt the moment, `get_invites_remaining` returns an error if the supplied credential is untrusted. This is caused by a failure to properly deserialize it into a trusted `lox_utils::LoxCredential` struct. Instead of returning the details `s...At the moment, `get_invites_remaining` returns an error if the supplied credential is untrusted. This is caused by a failure to properly deserialize it into a trusted `lox_utils::LoxCredential` struct. Instead of returning the details `serde_json` error in this case, we should check to see whether the credential is untrusted first (requires #49) and in this case return 0.https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/50Add function to determine when a credential can be upgraded2024-02-14T17:33:31ZCecylia BocovichAdd function to determine when a credential can be upgradedThe UX team has requested a `getNextUnlock()` function that returns the following:
- when a credential can increase in trust level
- when a credential receives new invitations
- when a credential can request new bridges (if theirs have b...The UX team has requested a `getNextUnlock()` function that returns the following:
- when a credential can increase in trust level
- when a credential receives new invitations
- when a credential can request new bridges (if theirs have been blocked)
We do not currently offer this functionality. We should figure out which of these are possible and then implement them.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/49Create a function to distinguish between an untrusted and a trusted credential2024-01-17T16:30:08ZCecylia BocovichCreate a function to distinguish between an untrusted and a trusted credentialIn order to level up their lox credential, a client has to make a specific request to the distributor to check that their bridges have not been blocked and retrieve the updated credential. The endpoint used varies depending on if a user ...In order to level up their lox credential, a client has to make a specific request to the distributor to check that their bridges have not been blocked and retrieve the updated credential. The endpoint used varies depending on if a user is trust level 0 (untrusted), or trust levels >= 1 (trusted).
To ease the process of deciding which endpoint to contact, it would be useful to have a function somewhat similar to `invitation_is_trusted` but for the credentials themselves.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/48Lox distributor hangs and does not respond to requests2024-02-27T11:28:53ZCecylia BocovichLox distributor hangs and does not respond to requestsWhile testing the Lox distributor functions today, I noticed it sometimes gets into a bad state where it hangs indefinitely and does not respond to requests. When trying to curl the open invitation endpoint I got a 504 response:
```
$ cu...While testing the Lox distributor functions today, I noticed it sometimes gets into a bad state where it hangs indefinitely and does not respond to requests. When trying to curl the open invitation endpoint I got a 504 response:
```
$ curl -I -X POST https://rdsys-frontend-01.torproject.org/lox/invite
HTTP/2 504
server: nginx
date: Wed, 17 Jan 2024 01:21:18 GMT
content-type: text/html
content-length: 160
```
Looking at the logs, I don't see anything unusual:
```
Jan 16 23:39:16 rdsys-frontend-01 lox-distributor[1209121]: Writing context to the db with key: "context_2024-01-16_23:39:16"
Jan 16 23:41:16 rdsys-frontend-01 lox-distributor[1209121]: BridgeLine [scrubbed] no longer in bridge table.
Jan 16 23:41:16 rdsys-frontend-01 lox-distributor[1209121]: BridgeLine [scrubbed] no longer in bridge table.
Jan 16 23:41:16 rdsys-frontend-01 lox-distributor[1209121]: BridgeLine [scrubbed] NOT replaced, saved for next update!
```
The distributor responds again after restarting it.Lox Ready for Open Testing Callonyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/47invitation_is_trusted doesn't properly validate open invitations2024-01-17T22:50:54ZCecylia Bocovichinvitation_is_trusted doesn't properly validate open invitationsI was testing this out today and it returns an error for a valid open invitation. Looking at the code, I think I found the issue:
```rust
let invite = unspecified_invitation_str.as_bytes();
match lox_utils::validate(invite) {
Ok(_) ...I was testing this out today and it returns an error for a valid open invitation. Looking at the code, I think I found the issue:
```rust
let invite = unspecified_invitation_str.as_bytes();
match lox_utils::validate(invite) {
Ok(_) => Ok(false),
Err(e) => Err(JsValue::from(e.to_string())),
}
```
The invitation string will look something like `[0,1,2,...,X]` and calling `as_bytes` is going to place the integer values of `[`, `,`, and `]` into the array as well which is not what we want. We want to turn it into an array with just the values of the invitation.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40322Local LAN access through snowflake2024-02-27T11:30:44Zdreamboat301Local LAN access through snowflakeHi
I'm a little bit late to the party. I've read a report from the 37C3 about the success helping people from Iran and other countries avoiding traffic blocks.
So I installed a snowflake instance in proxmox and I was overwhelmed with t...Hi
I'm a little bit late to the party. I've read a report from the 37C3 about the success helping people from Iran and other countries avoiding traffic blocks.
So I installed a snowflake instance in proxmox and I was overwhelmed with traffic. Mostly from Iran and roughly 25 GB a day. I love it that I could be of help!
But I believe there is an issue with it.
I put the instance in its own VLAN and configured the firewall to block any VLAN traffic to and from this network.
A few times a day I get an alert in my firewall claiming that this machine wants to connect to other VLANs. First I thought it might answer broadcast messages. But the IPs it requests don't exist. E.g. 192.168.1.5 is nowhere to be seen. But these are only the visable connections. Because of the nature of Unifi I can't block access to 192.168.1.1 because it is the same as 192.168.x.1 of any VLAN. So I shut down the instance to avoid people of maybe hacking my network. There were also connections to 10.x.x.x networks.
How can this be possible, that people can access my local LAN? I thought that I'm just a bridge to the Tor network and forwarding any traffic to it. Including local LAN addresses (or blocking it).
I've done a few tests. If I access in Tor Browser the IP 192.168.1.1 it gets blocked right away. Thats fine. I created a subdomain of a domain I own and added 192.168.1.1 as an A record. Suddendly I'm able to get through. Somewhere it is blocked anyway but it looks like that it is not fully blocked.
I'm just a home user. Please have patience with me when you direct me to do something.https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/46Have Lox credential return to the client a formated bridge line2024-02-27T11:33:17ZCecylia BocovichHave Lox credential return to the client a formated bridge lineI see in my open invitation bridge line the following:
```
'{"addr":[byte array],"port":YYYY,"uid_fingerprint":XXXXXXXXXXXXXXXXXXXX,"info":[byte array]}'
```
IIRC, the info field is the PT-specific params. It might also be nice for the ...I see in my open invitation bridge line the following:
```
'{"addr":[byte array],"port":YYYY,"uid_fingerprint":XXXXXXXXXXXXXXXXXXXX,"info":[byte array]}'
```
IIRC, the info field is the PT-specific params. It might also be nice for the byte array values to be easier to be converted into strings before we're dealing with it in javascript so that it's easier to turn into a bridge line that Tor Browser will understand.
This isn't urgent, because we are only requesting obfs4 bridge from rdsys for now, but in the future we may want to distribute other transports over lox.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40321Add probetest commandline option to specify STUN URL2024-01-10T17:32:59ZCecylia BocovichAdd probetest commandline option to specify STUN URLWe have a hardcoded default value for the STUN URL `stun:stun.l.google.com:19302`, which is fine for our deployment purposes, but does not work for simulations.
Needed for #40288We have a hardcoded default value for the STUN URL `stun:stun.l.google.com:19302`, which is fine for our deployment purposes, but does not work for simulations.
Needed for #40288Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/45Document the Lox Distributor API for client requests and server responses2024-01-22T15:04:26ZonyinyangDocument the Lox Distributor API for client requests and server responsesonyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/44Send lox distributor error response as json2024-01-09T20:02:04ZCecylia BocovichSend lox distributor error response as jsonAt the moment, the Lox distributor returns a [Bad Request HTTP status code if there was an error](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/common/messages/client.go?ref_type=heads#L127)...At the moment, the Lox distributor returns a [Bad Request HTTP status code if there was an error](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/common/messages/client.go?ref_type=heads#L127) with the request, along with the error string in the response body.
Many of the reasons for error are not due to bad client requests. Additionally, the json format will be easier to check and parse at the client. We can do something similar to the [Snowflake broker messages](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/54a47287ee58550e267ee8d42bb0d0eed60e470f/common/messages/client.go#L127-L130) where we return an error element only if it's present in the response.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/30Best practices for update webtunnel in production2024-02-23T14:58:41ZJacobo NájeraBest practices for update webtunnel in productionHi,
What do you recommend to update Webtunnel when you use docker-compose setup?
From my side, it doesn't work
- docker compose pull
- docker compose up --force-recreate --build -d
I'm using "force-recreate" because the latest webt...Hi,
What do you recommend to update Webtunnel when you use docker-compose setup?
From my side, it doesn't work
- docker compose pull
- docker compose up --force-recreate --build -d
I'm using "force-recreate" because the latest webtunnel image is unchanged. But there is a new version of Tor. But it maintains Tor 0.4.7.13 version.
I also tried with it, but it doesn't work to update Tor version:
- docker compose down --volumes
- docker compose pull
- docker compose build
- docker compose up -d
Thanks, Jacoboshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40320Let broker/bridge/probetest acme/autocert use ALPN-01 challenge2024-02-27T11:19:22ZDavid Fifielddcf@torproject.orgLet broker/bridge/probetest acme/autocert use ALPN-01 challengeAs far back as October 2022, we have messages like this in the snowflake-server logs:
```
2022/10/15 08:58:35 http: TLS handshake error from [scrubbed]: tls: client requested unsupported application protocols ([acme-tls/1])
```
The ALPN...As far back as October 2022, we have messages like this in the snowflake-server logs:
```
2022/10/15 08:58:35 http: TLS handshake error from [scrubbed]: tls: client requested unsupported application protocols ([acme-tls/1])
```
The ALPN-01 challenge is an alternative to the HTTP-01 challenge
we currently use
([broker](tpo/anti-censorship/pluggable-transports/snowflake#25345),
[bridge](tpo/anti-censorship/pluggable-transports/snowflake#25346)).
To use it, we need to:
https://pkg.go.dev/golang.org/x/crypto@v0.17.0/acme/autocert#Manager.GetCertificate
> If GetCertificate is used directly, instead of via Manager.TLSConfig, package users will also have to add acme.ALPNProto to NextProtos for tls-alpn-01, or use HTTPHandler for http-01.
Probably the easiest way to do it is to call
[Manager.TLSConfig](https://pkg.go.dev/golang.org/x/crypto@v0.17.0/acme/autocert#Manager.TLSConfig),
which "creates a new TLS config suitable for net/http.Server servers, supporting HTTP/2 and the tls-alpn-01 ACME challenge type".
Currently, we use a manually created &tls.Config in
the [broker](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/98db63ad01d9d78b8cd8aad77219a3d900bfdfef/broker/broker.go#L324)
and in [probetest](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/98db63ad01d9d78b8cd8aad77219a3d900bfdfef/probetest/probetest.go#L225),
and we use the tls.Config
created by http2.ConfigureServer in the
[server](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/98db63ad01d9d78b8cd8aad77219a3d900bfdfef/server/lib/snowflake.go#L104)
(which configures HTTP/2 but not the necessary ALPN string).https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40319Figure out why acme/autocert has not renewed bridge TLS certificates since Oc...2024-01-11T06:27:48ZDavid Fifielddcf@torproject.orgFigure out why acme/autocert has not renewed bridge TLS certificates since OctoberI got emails from Let's Encrypt on 2023-12-28 and 2024-01-05 saying that the certificates for 02.snowflake.torproject.net and snowflake.torproject.net respectively would soon expire.
<details>
<summary>Subject: Let's Encrypt certificate...I got emails from Let's Encrypt on 2023-12-28 and 2024-01-05 saying that the certificates for 02.snowflake.torproject.net and snowflake.torproject.net respectively would soon expire.
<details>
<summary>Subject: Let's Encrypt certificate expiration notice for domain "02.snowflake.torproject.net"</summary>
Date: Thu, 28 Dec 2023 09:46:04 +0000<br>
From: Let's Encrypt Expiry Bot <expiry@letsencrypt.org><br>
To: dcf@torproject.org<br>
Subject: Let's Encrypt certificate expiration notice for domain "02.snowflake.torproject.net"
Hello,
Your certificate (or certificates) for the names listed below will expire in 19 days (on 2024-01-17). Please make sure to renew your certificate before then, or visitors to your web site will encounter errors.
We recommend renewing certificates automatically when they have a third of their total lifetime left. For Let's Encrypt's current 90-day certificates, that means renewing 30 days before expiration. See https://letsencrypt.org/docs/integration-guide/ for details.
02.snowflake.torproject.net
For details about when we send these emails, please visit: https://letsencrypt.org/docs/expiration-emails/ In particular, note that this reminder email is still sent if you've obtained a slightly different certificate by adding or removing names. If you've replaced this certificate with a newer one that covers more or fewer names than the list above, you may be able to ignore this message.
</details>
<details>
<summary>Subject: Let's Encrypt certificate expiration notice for domain "snowflake.torproject.net"</summary>
Date: Fri, 05 Jan 2024 17:19:27 +0000<br>
From: Let's Encrypt Expiry Bot <expiry@letsencrypt.org><br>
To: dcf@torproject.org<br>
Subject: Let's Encrypt certificate expiration notice for domain "snowflake.torproject.net"
Hello,
Your certificate (or certificates) for the names listed below will expire in 19 days (on 2024-01-25). Please make sure to renew your certificate before then, or visitors to your web site will encounter errors.
We recommend renewing certificates automatically when they have a third of their total lifetime left. For Let's Encrypt's current 90-day certificates, that means renewing 30 days before expiration. See https://letsencrypt.org/docs/integration-guide/ for details.
snowflake.torproject.net
For details about when we send these emails, please visit: https://letsencrypt.org/docs/expiration-emails/ In particular, note that this reminder email is still sent if you've obtained a slightly different certificate by adding or removing names. If you've replaced this certificate with a newer one that covers more or fewer names than the list above, you may be able to ignore this message.
</details>
Certificate renewal is supposed to happen automatically using the
[acme/autocert package](https://pkg.go.dev/golang.org/x/crypto@v0.17.0/acme/autocert).
But the current certificates are both from last October:
<details>
<summary>
<pre>
Validity
Not Before: Oct 15 14:03:54 2023 GMT
Not After : Jan 13 14:03:53 2024 GMT
Subject: CN = 02.snowflake.torproject.net
</pre>
</summary>
```
-----BEGIN CERTIFICATE-----
MIIEODCCAyCgAwIBAgISBILJIV5T+hp2SFg3D2z5RGrDMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMzEwMTUxNDAzNTRaFw0yNDAxMTMxNDAzNTNaMCYxJDAiBgNVBAMT
GzAyLnNub3dmbGFrZS50b3Jwcm9qZWN0Lm5ldDBZMBMGByqGSM49AgEGCCqGSM49
AwEHA0IABH5DrT87QcJxDEhNFZ15YHUR16BQAwNQpQ52qWKV1Y4oA8elZvE/XKHY
op2p6JEO3Sz/kjbcNH6dWXWIkRXz0CmjggIdMIICGTAOBgNVHQ8BAf8EBAMCB4Aw
HQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYD
VR0OBBYEFIetn19sSDfKBLDyYT7PfpQELn08MB8GA1UdIwQYMBaAFBQusxe3WFbL
rlAJQOYfr52LFMLGMFUGCCsGAQUFBwEBBEkwRzAhBggrBgEFBQcwAYYVaHR0cDov
L3IzLm8ubGVuY3Iub3JnMCIGCCsGAQUFBzAChhZodHRwOi8vcjMuaS5sZW5jci5v
cmcvMCYGA1UdEQQfMB2CGzAyLnNub3dmbGFrZS50b3Jwcm9qZWN0Lm5ldDATBgNV
HSAEDDAKMAgGBmeBDAECATCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB3ADtTd3U+
LbmAToswWwb+QDtn2E/D9Me9AA0tcm/h+tQXAAABizPdegsAAAQDAEgwRgIhAPgR
OZAl/LXlhK8XIqa6MWEct6xODHoT4/pVBMRqsV0mAiEA7fO6V1+Gdc6rzViQBRTk
xJjsHzd5qHhf/ahbpZ/rJUMAdQDatr9rP7W2Ip+bwrtca+hwkXFsu1GEhTS9pD0w
SNf7qwAAAYsz3XogAAAEAwBGMEQCIHV/7jyPSrJe9bjMa2HMvwdu+FWChjvaPnY7
XYM55exqAiA8cdIDAZJymwt6PX/eWtyLhswbBD7iLbhlIRO6kfpcUTANBgkqhkiG
9w0BAQsFAAOCAQEASXh2o1Gh5nhhwKYEeU+wZWpqhIkvf+zbO7PEd/X1IMGRheRJ
UnobWUwzIn8Rrks6y3ktjSRtY2wY5QQgfXClYCMeleZLlp7IY1RDgG4oiqiXQ1Xr
ZJMQ+2cGnDGbdW+Jy2ISo3Mlc6H/TlfC7w6Ef+4NeTgVGbyuGKhHD0szASWfWsdO
jPtKVdxOYAyENAr0Xk/slNfgHubnKz5m1qHl0Lm8IEDgW56PjpLahQNkJM+7XUgz
52ANjQaToIzuafxGTCM2Ik0xry1/P7skI6KenuLfvxevS90qZ6GRTI6aAw/8PMR3
dWAv4LRds9DRL/NBRWTCNRNHwki9fNHciOiGzw==
-----END CERTIFICATE-----
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
04:82:c9:21:5e:53:fa:1a:76:48:58:37:0f:6c:f9:44:6a:c3
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = Let's Encrypt, CN = R3
Validity
Not Before: Oct 15 14:03:54 2023 GMT
Not After : Jan 13 14:03:53 2024 GMT
Subject: CN = 02.snowflake.torproject.net
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:7e:43:ad:3f:3b:41:c2:71:0c:48:4d:15:9d:79:
60:75:11:d7:a0:50:03:03:50:a5:0e:76:a9:62:95:
d5:8e:28:03:c7:a5:66:f1:3f:5c:a1:d8:a2:9d:a9:
e8:91:0e:dd:2c:ff:92:36:dc:34:7e:9d:59:75:88:
91:15:f3:d0:29
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
87:AD:9F:5F:6C:48:37:CA:04:B0:F2:61:3E:CF:7E:94:04:2E:7D:3C
X509v3 Authority Key Identifier:
14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6
Authority Information Access:
OCSP - URI:http://r3.o.lencr.org
CA Issuers - URI:http://r3.i.lencr.org/
X509v3 Subject Alternative Name:
DNS:02.snowflake.torproject.net
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 3B:53:77:75:3E:2D:B9:80:4E:8B:30:5B:06:FE:40:3B:
67:D8:4F:C3:F4:C7:BD:00:0D:2D:72:6F:E1:FA:D4:17
Timestamp : Oct 15 15:03:54.635 2023 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:46:02:21:00:F8:11:39:90:25:FC:B5:E5:84:AF:17:
22:A6:BA:31:61:1C:B7:AC:4E:0C:7A:13:E3:FA:55:04:
C4:6A:B1:5D:26:02:21:00:ED:F3:BA:57:5F:86:75:CE:
AB:CD:58:90:05:14:E4:C4:98:EC:1F:37:79:A8:78:5F:
FD:A8:5B:A5:9F:EB:25:43
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : DA:B6:BF:6B:3F:B5:B6:22:9F:9B:C2:BB:5C:6B:E8:70:
91:71:6C:BB:51:84:85:34:BD:A4:3D:30:48:D7:FB:AB
Timestamp : Oct 15 15:03:54.656 2023 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:44:02:20:75:7F:EE:3C:8F:4A:B2:5E:F5:B8:CC:6B:
61:CC:BF:07:6E:F8:55:82:86:3B:DA:3E:76:3B:5D:83:
39:E5:EC:6A:02:20:3C:71:D2:03:01:92:72:9B:0B:7A:
3D:7F:DE:5A:DC:8B:86:CC:1B:04:3E:E2:2D:B8:65:21:
13:BA:91:FA:5C:51
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
49:78:76:a3:51:a1:e6:78:61:c0:a6:04:79:4f:b0:65:6a:6a:
84:89:2f:7f:ec:db:3b:b3:c4:77:f5:f5:20:c1:91:85:e4:49:
52:7a:1b:59:4c:33:22:7f:11:ae:4b:3a:cb:79:2d:8d:24:6d:
63:6c:18:e5:04:20:7d:70:a5:60:23:1e:95:e6:4b:96:9e:c8:
63:54:43:80:6e:28:8a:a8:97:43:55:eb:64:93:10:fb:67:06:
9c:31:9b:75:6f:89:cb:62:12:a3:73:25:73:a1:ff:4e:57:c2:
ef:0e:84:7f:ee:0d:79:38:15:19:bc:ae:18:a8:47:0f:4b:33:
01:25:9f:5a:c7:4e:8c:fb:4a:55:dc:4e:60:0c:84:34:0a:f4:
5e:4f:ec:94:d7:e0:1e:e6:e7:2b:3e:66:d6:a1:e5:d0:b9:bc:
20:40:e0:5b:9e:8f:8e:92:da:85:03:64:24:cf:bb:5d:48:33:
e7:60:0d:8d:06:93:a0:8c:ee:69:fc:46:4c:23:36:22:4d:31:
af:2d:7f:3f:bb:24:23:a2:9e:9e:e2:df:bf:17:af:4b:dd:2a:
67:a1:91:4c:8e:9a:03:0f:fc:3c:c4:77:75:60:2f:e0:b4:5d:
b3:d0:d1:2f:f3:41:45:64:c2:35:13:47:c2:48:bd:7c:d1:dc:
88:e8:86:cf
```
</details>
<details>
<summary>
<pre>
Validity
Not Before: Oct 22 11:23:44 2023 GMT
Not After : Jan 20 11:23:43 2024 GMT
Subject: CN = snowflake.torproject.net
</pre>
</summary>
```
-----BEGIN CERTIFICATE-----
MIIEMjCCAxqgAwIBAgISBMnl0UqZyd2Ds/DcWpQdF13aMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMzEwMjIxMTIzNDRaFw0yNDAxMjAxMTIzNDNaMCMxITAfBgNVBAMT
GHNub3dmbGFrZS50b3Jwcm9qZWN0Lm5ldDBZMBMGByqGSM49AgEGCCqGSM49AwEH
A0IABDGdN4mjaNp0o+146WrLD5iuzDBpd4DrR9FmYbISj9KNQOVbty07VIWtdhel
KO95Phbj8Gmo8OlU2GCsRFuVczOjggIaMIICFjAOBgNVHQ8BAf8EBAMCB4AwHQYD
VR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0O
BBYEFMGfwy1PcMQaSDTB+69POTFrNxHRMB8GA1UdIwQYMBaAFBQusxe3WFbLrlAJ
QOYfr52LFMLGMFUGCCsGAQUFBwEBBEkwRzAhBggrBgEFBQcwAYYVaHR0cDovL3Iz
Lm8ubGVuY3Iub3JnMCIGCCsGAQUFBzAChhZodHRwOi8vcjMuaS5sZW5jci5vcmcv
MCMGA1UdEQQcMBqCGHNub3dmbGFrZS50b3Jwcm9qZWN0Lm5ldDATBgNVHSAEDDAK
MAgGBmeBDAECATCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB2ANq2v2s/tbYin5vC
u1xr6HCRcWy7UYSFNL2kPTBI1/urAAABi1dXW9IAAAQDAEcwRQIgVx42UBDJsH1f
R48qhQrRUqGHF5Xn0W16ONOiTDf3m0gCIQCoUlDJjucW8suM+ZZll1IJrT2by9eM
ik+dLfJfeEIfAwB2ADtTd3U+LbmAToswWwb+QDtn2E/D9Me9AA0tcm/h+tQXAAAB
i1dXW8IAAAQDAEcwRQIhAJgErCNbhsx8+wrpmWJ3NO04EpRrw1qTMyecCM/viUL4
AiAMGXmerZwFANih+eRqPNfPpGYollCcCRsRYVgf9XHcbzANBgkqhkiG9w0BAQsF
AAOCAQEAccSUiBqi7/D7HZSLw6Ji1t3Dvy50wB13QAAJJY1juv8Izxgltcqd2Hvb
NHVI2GQ0gQ0DxHmbRX77t9CmjCYnhFQrVvzPguYECqDfBpxjjezr8T9axfGm2CIU
n2PnUP65p/E49D9PAidUkmz2NW5IkWhvm3tfdbkdbJNpHfnM1rPmcIA3Q2FGE+jj
bGTmBsngUL/XV38crKTssOny5Lcp8W7iYlWTpWKw1r3Ja/yW2aG89oF5RvgPLf1z
Q9bqG7Y7uYtSz1hGNiy4wGypiGD6Oj14cAKOKiPL2MH9j1NYosvi2LbFMN2cIByW
cV8VCezuZbnVpvubv5HTxDyW0gLtuw==
-----END CERTIFICATE-----
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
04:c9:e5:d1:4a:99:c9:dd:83:b3:f0:dc:5a:94:1d:17:5d:da
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = Let's Encrypt, CN = R3
Validity
Not Before: Oct 22 11:23:44 2023 GMT
Not After : Jan 20 11:23:43 2024 GMT
Subject: CN = snowflake.torproject.net
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:31:9d:37:89:a3:68:da:74:a3:ed:78:e9:6a:cb:
0f:98:ae:cc:30:69:77:80:eb:47:d1:66:61:b2:12:
8f:d2:8d:40:e5:5b:b7:2d:3b:54:85:ad:76:17:a5:
28:ef:79:3e:16:e3:f0:69:a8:f0:e9:54:d8:60:ac:
44:5b:95:73:33
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
C1:9F:C3:2D:4F:70:C4:1A:48:34:C1:FB:AF:4F:39:31:6B:37:11:D1
X509v3 Authority Key Identifier:
14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6
Authority Information Access:
OCSP - URI:http://r3.o.lencr.org
CA Issuers - URI:http://r3.i.lencr.org/
X509v3 Subject Alternative Name:
DNS:snowflake.torproject.net
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : DA:B6:BF:6B:3F:B5:B6:22:9F:9B:C2:BB:5C:6B:E8:70:
91:71:6C:BB:51:84:85:34:BD:A4:3D:30:48:D7:FB:AB
Timestamp : Oct 22 12:23:44.850 2023 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:20:57:1E:36:50:10:C9:B0:7D:5F:47:8F:2A:
85:0A:D1:52:A1:87:17:95:E7:D1:6D:7A:38:D3:A2:4C:
37:F7:9B:48:02:21:00:A8:52:50:C9:8E:E7:16:F2:CB:
8C:F9:96:65:97:52:09:AD:3D:9B:CB:D7:8C:8A:4F:9D:
2D:F2:5F:78:42:1F:03
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 3B:53:77:75:3E:2D:B9:80:4E:8B:30:5B:06:FE:40:3B:
67:D8:4F:C3:F4:C7:BD:00:0D:2D:72:6F:E1:FA:D4:17
Timestamp : Oct 22 12:23:44.834 2023 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:21:00:98:04:AC:23:5B:86:CC:7C:FB:0A:E9:
99:62:77:34:ED:38:12:94:6B:C3:5A:93:33:27:9C:08:
CF:EF:89:42:F8:02:20:0C:19:79:9E:AD:9C:05:00:D8:
A1:F9:E4:6A:3C:D7:CF:A4:66:28:96:50:9C:09:1B:11:
61:58:1F:F5:71:DC:6F
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
71:c4:94:88:1a:a2:ef:f0:fb:1d:94:8b:c3:a2:62:d6:dd:c3:
bf:2e:74:c0:1d:77:40:00:09:25:8d:63:ba:ff:08:cf:18:25:
b5:ca:9d:d8:7b:db:34:75:48:d8:64:34:81:0d:03:c4:79:9b:
45:7e:fb:b7:d0:a6:8c:26:27:84:54:2b:56:fc:cf:82:e6:04:
0a:a0:df:06:9c:63:8d:ec:eb:f1:3f:5a:c5:f1:a6:d8:22:14:
9f:63:e7:50:fe:b9:a7:f1:38:f4:3f:4f:02:27:54:92:6c:f6:
35:6e:48:91:68:6f:9b:7b:5f:75:b9:1d:6c:93:69:1d:f9:cc:
d6:b3:e6:70:80:37:43:61:46:13:e8:e3:6c:64:e6:06:c9:e0:
50:bf:d7:57:7f:1c:ac:a4:ec:b0:e9:f2:e4:b7:29:f1:6e:e2:
62:55:93:a5:62:b0:d6:bd:c9:6b:fc:96:d9:a1:bc:f6:81:79:
46:f8:0f:2d:fd:73:43:d6:ea:1b:b6:3b:b9:8b:52:cf:58:46:
36:2c:b8:c0:6c:a9:88:60:fa:3a:3d:78:70:02:8e:2a:23:cb:
d8:c1:fd:8f:53:58:a2:cb:e2:d8:b6:c5:30:dd:9c:20:1c:96:
71:5f:15:09:ec:ee:65:b9:d5:a6:fb:9b:bf:91:d3:c4:3c:96:
d2:02:ed:bb
```
</details>
Note also that the "Not After" dates in the certificates are 4–5 days earlier than
the dates in the emails.
I started thinking about what might have changed at
[the most recent deployment](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/154#note_2967886),
which was on 2023-11-21.
[This is the diff](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/compare/58c3121c...aa06e7be?from_project_id=43&straight=false)
with the [next most recent deployment](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40277#note_2918780)
on 2023-07-01.
What's weird is that certificates for the snowflake-01 bridge's alternative domain names
snowflake.freehaven.net and snowflake.bamsoftware.com have been renewed as recently
as a week ago:
```
2023-10-03 05:45 snowflake.bamsoftware.com+rsa
2023-10-22 12:23 snowflake.torproject.net
2023-10-27 18:12 snowflake.torproject.net+rsa
2023-12-08 22:50 snowflake.freehaven.net+rsa
2023-12-10 04:39 snowflake.bamsoftware.com
2023-12-30 05:16 snowflake.freehaven.net
```
About every 20–30 minutes I can see a file being created in the pt_state
directory like:
```
-rw------- 1 snowflake-server nogroup 903 Jan 7 21:04 snowflake.torproject.net+token
```
So it seems like the HTTP-01 proof renewal machinery is getting invoked,
but it's not getting completed for some reason.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2024-01-12