Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2023-10-24T08:17:20Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/17improve descriptor arguments published2023-10-24T08:17:20Zmeskiomeskio@torproject.orgimprove descriptor arguments publishedThis is the extra-info line I see for the bridge documented in the README:
```
transport webtunnel 127.0.0.1:11000 domainname=n97jlbvjwy3iotetc0axrtu3mm7gq1gajqv7-80-78-24-44.sslip.io,path=939e42a2-8f3f-4645-9d7b-8b9be28b157e,port=443,pu...This is the extra-info line I see for the bridge documented in the README:
```
transport webtunnel 127.0.0.1:11000 domainname=n97jlbvjwy3iotetc0axrtu3mm7gq1gajqv7-80-78-24-44.sslip.io,path=939e42a2-8f3f-4645-9d7b-8b9be28b157e,port=443,publicVersion=0.0.1
```
Currently webtunnel is publishing the localhost IP and port where is listening for connections from the http proxy, we might want to publish a different IP address and port there as they will be used to build the bridgeline. The README uses 192.0.3.2:1, but AFAIK we can't use the same IP-port combination for several bridges as tor will consider is the same bridge and ignore the others. We could generate a random IP address from a private range, but maybe is better to put there the public IP address of the domain we are using as front. Any ideas?
I see in the extra-info line `domainname` and `path`, where AFAIK the client expects `url`. I think this is not coming from the code itself, but from `ServerTransportOptions` in torrc. Isn't it? Maybe we can improve the README to document how that is configured to include the `url` option (and fix our public tunnel).
I have some doubts about `publicVersion`, I think is weird to keep that in the bridgeline. rdsys could strip it out, but is pretty hacky. I would love to see https://gitlab.torproject.org/tpo/core/tor/-/issues/11101 solving that problem instead andSponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/122Update x/net and x/crypto to latest version in Obfs4proxy and Snowflake2023-04-20T08:36:45ZtlaUpdate x/net and x/crypto to latest version in Obfs4proxy and SnowflakeSomebody sent me an issue about this:
https://github.com/tladesignz/IPtProxy/issues/45
> For security purposes, golang.org/x/crypto and golang.org/x/net should be updated to latest versions. This also requires the obfs4 and snowflake s...Somebody sent me an issue about this:
https://github.com/tladesignz/IPtProxy/issues/45
> For security purposes, golang.org/x/crypto and golang.org/x/net should be updated to latest versions. This also requires the obfs4 and snowflake submodules to do the same thing, so there needs to be some coordination between all three projects for this to happen.
Please let me know, if this is valid, and if there's any problems with that request! Thank you!meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/121migrate our images outside docker hub2024-03-04T09:50:16Zmeskiomeskio@torproject.orgmigrate our images outside docker hubWe got an email saying that April 14th our [thetorproject](https://hub.docker.com/u/thetorproject) organization will be close. There is a [FAQ](https://web.docker.com/rs/790-SSB-375/images/privatereposfaq.pdf) hidden in their website wit...We got an email saying that April 14th our [thetorproject](https://hub.docker.com/u/thetorproject) organization will be close. There is a [FAQ](https://web.docker.com/rs/790-SSB-375/images/privatereposfaq.pdf) hidden in their website with some information about it.
If we don't do anything our images will deleted April 14th, making our 900k+ unable to update them or to install them. But docker promises that *your organization’s namespace will not be released, so other users can’t “squat” your images*.
We can ask to be included in the [Docker-Sponsored Open Source Program](https://www.docker.com/community/open-source/application/), in that case they will *defer any organization suspension or deletion while DSOS application is under review, and give organizations at least 30 days before we suspend the organization if the application is ultimately rejected*. We should qualify for it, but there are many stories in internet of people being rejected from it.
We can move to another registry, there are few options:
* TPA plans to add a registry (https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/89)
* [quay.io](https://quay.io/)
* [github](https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry)
* An individual docker hub account, will require changing the namemeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40265Standalone proxy - error polling probe - 'certificate is not standards compli...2023-03-16T17:40:24ZMarkCStandalone proxy - error polling probe - 'certificate is not standards compliant'@meskio As requested.
Yesterday I updated one of my proxies after !136 completed. When I run the proxy it starts, then begins probetest, then immediately (and repeatedly) returns an error:
2023/03/16 00:45:47 error polling probe: x509:...@meskio As requested.
Yesterday I updated one of my proxies after !136 completed. When I run the proxy it starts, then begins probetest, then immediately (and repeatedly) returns an error:
2023/03/16 00:45:47 error polling probe: x509: “snowflake-broker.torproject.net” certificate is not standards compliant
2023/03/16 00:45:47 NAT type: unknown
2023/03/16 00:45:48 error polling broker: x509: “snowflake-broker.torproject.net” certificate is not standards compliant
2023/03/16 00:45:48 Error reading broker response: unexpected end of JSON input
2023/03/16 00:45:48 body:
2023/03/16 00:45:48 bad offer from broker
Here’s the log of the start up (note that the git pull in this sequence says 'already up to date' because I ran it a second time as a double check).
[proxy_error_polling_broker_-_03_15_23.txt](/uploads/e8d343dc26e784d66e59880530374774/proxy_error_polling_broker_-_03_15_23.txt)
On the previous build everything was functioning properly.
@itchyonion Might this result be caused by the bug you mentioned in #40108 yesterday?itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40264Add option to configure private snowflake proxy2023-03-28T18:36:08ZRendezvousPointAdd option to configure private snowflake proxyJust like obfs4 private bridges.Just like obfs4 private bridges.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40262Deploy snowflake-server for QueuePacketConn buffer reuse fix (#40260)2023-07-18T00:47:30ZDavid Fifielddcf@torproject.orgDeploy snowflake-server for QueuePacketConn buffer reuse fix (#40260)#40260 describes a buffer reuse error in `QueuePacketConn` resulting from #40199.
!140 promises to fix it.
After merging !140, deploy to the bridges and restart.
- [x] snowflake-01
- [x] snowflake-02
/cc @cohosh @linus#40260 describes a buffer reuse error in `QueuePacketConn` resulting from #40199.
!140 promises to fix it.
After merging !140, deploy to the bridges and restart.
- [x] snowflake-01
- [x] snowflake-02
/cc @cohosh @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/156Missing Authentication at Resource Registration2023-10-12T14:26:44Zmeskiomeskio@torproject.orgMissing Authentication at Resource RegistrationWhile auditing the source code of the Rdsys, it is noticed that the Rdsys backend has missing authentication for the resource registration endpoint. This allows an adversary to register arbitrary malicious resources which will be distrib...While auditing the source code of the Rdsys, it is noticed that the Rdsys backend has missing authentication for the resource registration endpoint. This allows an adversary to register arbitrary malicious resources which will be distributed to the users.
The following snippet of code shows the affected code where the resource registration endpoint does not have any kind of authentication checks as compared to the other endpoints.
Affected file:
rdsys/internal/backend.go
Affected code:
```go
func (b *BackendContext) resourcesHandler(w http.ResponseWriter, r *http.Request) {
switch r.Method {
[...]
case http.MethodPost:
if r.URL.Path == b.Config.Backend.ResourcesEndpoint {
b.postResourcesHandler(w, r)
[...]
}
func (b *BackendContext) postResourcesHandler(w http.ResponseWriter, req *http.Request) {
body, err := ioutil.ReadAll(req.Body)
[...]
rTypes := map[string]struct{}{}
for _, r := range rs {
b.Resources.Add(r)
rTypes[r.Type()] = struct{}{}
log.Printf("Added %s's %q resource to collection.", req.RemoteAddr, r.Type())
}
for rType := range rTypes {
b.rStore.Save(rType)
}
[...]
}
```
The aforementioned issue can be reproduced by executing the following cURL request.
PoC:
```
curl http://localhost:7100/resources -i --data '[{"type": "obfs2", "address": "1.2.3.2", "port": 1235, "fingerprint":"10282810115283F99ADE5CFE42D49644F45D715D"}]' -XPOST
# Other endpoints which are missing authentication
curl -i -s -k -X $'GET' \
-H $'Host: localhost:7100' \
$'http://localhost:7100/status?id=10282810115283F99ADE5CFE42D49644F45D715D'
curl -i -s -k -X $'GET' \
-H $'Host: localhost:7100' \
$'http://localhost:7100/rdsys-backend-metrics'
```
To address the issue, it is strongly advised to implement robust authentication mechanisms for all endpoints, with particular attention paid to the registration of resources. This will help to ensure that only authorized users are able to register resources, thereby reducing the risk of unauthorized access.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40260Weird KCP packets received by the client2023-09-25T19:36:14ZCecylia BocovichWeird KCP packets received by the clientWe were notified by @hazae41 of some suspicious looking kcp traffic traffic arriving at the client. This traffic looks like it belongs to KCP sessions that do not correspond to the client's own KCP sessions.
I'm in the process of trying...We were notified by @hazae41 of some suspicious looking kcp traffic traffic arriving at the client. This traffic looks like it belongs to KCP sessions that do not correspond to the client's own KCP sessions.
I'm in the process of trying to reproduce this. Here is the patch they used to see the contents of the KCP packets:
<details>
<summary> kcp library logging patch </summary>
```diff
diff --git a/readloop.go b/readloop.go
index 697395a..1d8e17b 100644
--- a/readloop.go
+++ b/readloop.go
@@ -1,6 +1,7 @@
package kcp
import (
+ "log"
"sync/atomic"
"github.com/pkg/errors"
@@ -11,6 +12,7 @@ func (s *UDPSession) defaultReadLoop() {
var src string
for {
if n, addr, err := s.conn.ReadFrom(buf); err == nil {
+ log.Println("kcp <- ", buf)
// make sure the packet is from the same source
if src == "" { // set source address
src = addr.String()
```
</details>
and the following smux patch:
<details>
<summary> smux library logging patch </summary>
```diff
diff --git a/session.go b/session.go
index bc56066..1fe1122 100644
--- a/session.go
+++ b/session.go
@@ -96,7 +96,7 @@ func newSession(config *Config, conn io.ReadWriteCloser, client bool) *Session {
s.chProtoError = make(chan struct{})
if client {
- s.nextStreamID = 1
+ s.nextStreamID = 5
} else {
s.nextStreamID = 0
}
```
</details>
They report seeing smux headers that have a streamid of 3 regardless of the above change that starts stream ids at 5, and seeing kcp headers that do not contain recognizable kcp conv ids followed by a stream id of 3 and a TLS application packet (despite the fact that new KCP sessions should always contain a TLS handshake first since they represent a new OR conn).Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/154can we distribute bridges with unrechable ORPort?2023-08-23T18:59:04Zmeskiomeskio@torproject.orgcan we distribute bridges with unrechable ORPort?AFAIK if a bridge doesn't have the ORPort public the bridge authority will don't add the 'Running' flag, but will still add the bridge to the bridge descriptors. Is that correct?
rdsys currently doesn't distribute bridges that don't hav...AFAIK if a bridge doesn't have the ORPort public the bridge authority will don't add the 'Running' flag, but will still add the bridge to the bridge descriptors. Is that correct?
rdsys currently doesn't distribute bridges that don't have the 'Running' flag. Maybe if we start ignoring the 'Running' flag, and just use bridgestrap to check if a bridge is working, we can allow bridge operators to publish bridges with only the PT port accessible.
If so we could close https://gitlab.torproject.org/tpo/core/tor/-/issues/7349meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40065HTTPS CAPTCHA challenge doesn't work with new frontend2023-03-07T21:27:09ZCecylia BocovichHTTPS CAPTCHA challenge doesn't work with new frontendWhile debugging #40064, I noticed that the new `captcha.html` template is missing two necessary fields to pass the CAPTCHA challenge to the BridgeDB backend (see https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40064#n...While debugging #40064, I noticed that the new `captcha.html` template is missing two necessary fields to pass the CAPTCHA challenge to the BridgeDB backend (see https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40064#note_2884130)
Without the right input names in the captcha challenge submission form, BridgeDB doesn't know where to look to verify the challenge and solution.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40064BridgeDB https and moat distributors down after upgrade2023-03-07T21:27:00ZCecylia BocovichBridgeDB https and moat distributors down after upgradeAfter the bridgedb upgrade this morning, both the https and moat distributors appear to have stopped working.After the bridgedb upgrade this morning, both the https and moat distributors appear to have stopped working.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40259Make nf_conntrack changes persistent2023-04-25T15:13:40ZDavid Fifielddcf@torproject.orgMake nf_conntrack changes persistentInvestigating the [loss of users from Iran](https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115#note_2883298)
and the [increase of users from Russia that only affected snowflake-02](https://gitlab.torproject.org/tpo/anti-...Investigating the [loss of users from Iran](https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115#note_2883298)
and the [increase of users from Russia that only affected snowflake-02](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/131#note_2883300)
that happened in the second half of February 2023,
I discovered that the [increased nf_conntrack table size](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide?version_id=a7bcf0502102bd8d820f590bc9856a0a738a2225#general-system-setup)
from #40239 had not taken effect since
the bridges were rebooted on 2023-02-16 for #40253.
```
root@snowflake-01:~# date -u --iso=sec
2023-03-04T07:13:32+00:00
root@snowflake-01:~# cat /proc/sys/net/netfilter/nf_conntrack_{count,max,buckets}
186671
262144
65536
```
```
root@snowflake-02:~# date -u --iso=sec
2023-03-04T07:36:45+00:00
root@snowflake-02:~# cat /proc/sys/net/netfilter/nf_conntrack_{count,max,buckets}
21155
262144
65536
```
The default settings were supposed to be overridden
by /etc/sysctl.d/nf_conntrack.conf, which is loaded during boot by sysctl:
```
root@snowflake-01:~# cat /etc/sysctl.d/nf_conntrack.conf
net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_buckets = 524288
```
I think the problem is that the sysctl settings are made
before the nf_conntrack module is first loaded, so they have no effect,
as the [sysctl.d(5)](https://manpages.debian.org/bullseye/systemd/sysctl.d.5.en.html#CONFIGURATION_FORMAT)
man page cautions:
> Many sysctl parameters only become available when certain kernel modules are loaded. Modules are usually loaded on demand, e.g. when certain hardware is plugged in or network brought up. This means that [systemd-sysctl.service(8)](https://manpages.debian.org/bullseye/systemd/systemd-sysctl.service.8.en.html) which runs during early boot will not configure such parameters if they become available after it has run. To set such parameters, it is recommended to add an [udev(7)](https://manpages.debian.org/bullseye/udev/udev.7.en.html) rule to set those parameters when they become available. Alternatively, a slightly simpler and less efficient option is to add the module to [modules-load.d(5)](https://manpages.debian.org/bullseye/systemd/modules-load.d.5.en.html), causing it to be loaded statically before sysctl settings are applied (see example below).
The workaround, as the man page suggests,
is to add `nf_conntrack` to /etc/modules to make it be loaded earlier in the boot sequence,
or add a udev rule to re-load the `net.netfilter` sysctl settings
when nf_conntrack is loaded.
* https://github.com/systemd/systemd/issues/1113#issuecomment-138051408
* https://serverfault.com/a/676721
* https://github.com/coreos/bugs/issues/785
I've re-started the [conntrack.sh script](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40239#note_2864515)
to track `nf_conntrack_count` over time.
I will let it run for a couple of days to get a baseline,
then I will increase the nf_conntrack limits again
to see if it has an effect on usership.
Then, I will try one of the above workarounds to make the change actually persistent this time.
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/123Drop in Iranian snowflake users2023-05-29T22:07:57ZHackerNCoderhackerncoder@encryptionin.spaceDrop in Iranian snowflake usershttps://metrics.torproject.org/userstats-bridge-combined.html?start=2022-12-02&end=2023-03-03&country=ir
Recently snowflake usage in Iran has been dropping
A similar graph can be seen in US, https://metrics.torproject.org/userstats-bri...https://metrics.torproject.org/userstats-bridge-combined.html?start=2022-12-02&end=2023-03-03&country=ir
Recently snowflake usage in Iran has been dropping
A similar graph can be seen in US, https://metrics.torproject.org/userstats-bridge-combined.html?start=2022-12-02&end=2023-03-03&country=usSponsor 139: Rapid Response Iranshelikhooshelikhoo2023-05-26https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40258Resynchronization with Upsteamed Remove HelloVerify countermeasure2023-04-06T13:05:39ZshelikhooResynchronization with Upsteamed Remove HelloVerify countermeasureAs of https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40249, we have finished upstreaming Remove HelloVerify countermeasure changes to upstream.
We should try to resynchronize our dependency wit...As of https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40249, we have finished upstreaming Remove HelloVerify countermeasure changes to upstream.
We should try to resynchronize our dependency with upstream.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/153give only obfs4 bridges to onbasca2023-03-14T14:34:22Zmeskiomeskio@torproject.orggive only obfs4 bridges to onbascaOnbasca is unable to test vanilla bridges, let's give only obfs4 bridges to onbasca.Onbasca is unable to test vanilla bridges, let's give only obfs4 bridges to onbasca.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40255snowflake-02: increase number of tor instances from 4 to 122023-02-17T03:15:20ZDavid Fifielddcf@torproject.orgsnowflake-02: increase number of tor instances from 4 to 12The idea is that snowflake-02 will soon be handling a roughly equal amount of traffic as snowflake-01, which currently runs 12 instances.The idea is that snowflake-02 will soon be handling a roughly equal amount of traffic as snowflake-01, which currently runs 12 instances.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40253Restart snowflake bridges for haproxy CVE-2023-0056, CVE-2023-257252023-05-25T15:04:32ZDavid Fifielddcf@torproject.orgRestart snowflake bridges for haproxy CVE-2023-0056, CVE-2023-25725https://security-tracker.debian.org/tracker/DSA-5348-1
https://lists.debian.org/debian-security-announce/2023/msg00037.html
> Two vulnerabilities were discovered in HAProxy, a fast and reliable load
> balancing reverse proxy, which may ...https://security-tracker.debian.org/tracker/DSA-5348-1
https://lists.debian.org/debian-security-announce/2023/msg00037.html
> Two vulnerabilities were discovered in HAProxy, a fast and reliable load
> balancing reverse proxy, which may result in denial of service, or
> bypass of access controls and routing rules via specially crafted
> requests.
>
> For the stable distribution (bullseye), these problems have been fixed in
> version 2.2.9-2+deb11u4.
>
> We recommend that you upgrade your haproxy packages.
https://ubuntu.com/security/notices/USN-5869-1
> HAProxy could allow unintended access to network services.
>
> The problem can be corrected by updating your system to the following package versions:
>
> Ubuntu 20.04
>
> [haproxy - 2.0.29-0ubuntu1.3](https://launchpad.net/ubuntu/+source/haproxy/2.0.29-0ubuntu1.3)
- [x] snowflake-01
- [x] snowflake-02
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40252Standalone proxy probetest Wiki inconsistency and implementation details2023-03-07T18:13:49ZitchyonionStandalone proxy probetest Wiki inconsistency and implementation details1. Our [Wiki](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/wikis/NAT-matching#determining-nat-behaviour) states that:
> We determine the NAT behaviour of clients by using the tricks in [RFC 5780](ht...1. Our [Wiki](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/wikis/NAT-matching#determining-nat-behaviour) states that:
> We determine the NAT behaviour of clients by using the tricks in [RFC 5780](https://tools.ietf.org/html/rfc5780) ... For standalone proxies written in Go, we use the same method.
Which is not true since we switched to probetest https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/commit/00f8f85f412878c2066fcb5d3f4739e50912a925
Cecylia linked the issue for the change: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40013. I will update the Wiki.
2. Right now we are [logging the SDP offer](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L676) used for probetest, which might be misleading because before looking into this in detail I always thought we were logging the SDP candidates used for WebRTC connection. Does this help the user in any way or is simplying logging the resultant NAT type enough? Some options to consider:
- keep the same logging, but made it extra clear that this is only used for probetest, not peer connection
- log SDP candidates for WebRTC. I think this would be helpful for debugging, but could produce much more logs
- log both
- [x] Update Wiki with reason to use probetest
- [x] Research on whether we should respect proxy options in probetest
- [x] Decide what to logitchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/80security: tighten CSP (`connect-src`)2023-04-17T19:06:22ZWofWcawofwca@protonmail.comsecurity: tighten CSP (`connect-src`)Besides WebRTC, currently we only connect to the broker and the server, so only allowing the extension to connect to those servers should improve security.
Later, if/when we allow to connect to any address (e.g. https://gitlab.torproject...Besides WebRTC, currently we only connect to the broker and the server, so only allowing the extension to connect to those servers should improve security.
Later, if/when we allow to connect to any address (e.g. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40166), we may keep the CSP to only allow `ws:`/`wss:` connections, and `https://broker...`.
I need to remind that currently the `connect-src` directive doesn't affect WebRTC. See [1](https://github.com/sandstormports/community-project/issues/12), [2](https://github.com/w3c/webappsec-csp/issues/92).
Also need to keep configurability in mind, i.e. if users want to switch to a custom broker/relay.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/25Feedback: successful conjure test on tbb nightly2023-03-07T21:15:24ZMarkCFeedback: successful conjure test on tbb nightly@cohosh At wkrp’s suggestion on net4people I tested conjure on tbb nightly. It bootstraped successfully. I’ll confess that I didn’t follow all the instructions, just downloaded the nightly on my macos test machine, pasted in the bridgeli...@cohosh At wkrp’s suggestion on net4people I tested conjure on tbb nightly. It bootstraped successfully. I’ll confess that I didn’t follow all the instructions, just downloaded the nightly on my macos test machine, pasted in the bridgeline and connected. Tor log attached. Thx.[Conjure_test_success.rtf](/uploads/4c9501d3e6000275bc2850ccf4d3665c/Conjure_test_success.rtf)