Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2021-07-29T15:06:00Zhttps://gitlab.torproject.org/legacy/trac/-/issues/7349Obfsbridges should be able to "disable" their ORPort2021-07-29T15:06:00ZGeorge KadianakisObfsbridges should be able to "disable" their ORPortIn the future, we will want obfsbridges to only expose their obfsports and not their ORPort, otherwise an adversary can launch an active-scanning attack against the ORPort.
We should spec and implement a torrc option that hides the ORPo...In the future, we will want obfsbridges to only expose their obfsports and not their ORPort, otherwise an adversary can launch an active-scanning attack against the ORPort.
We should spec and implement a torrc option that hides the ORPort of obfsbridges.
Maybe it should make the ORPort bind on localhost. But what happens if the transport proxy is not on the same host as the ORPort?Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28803Integrate building pluggable transports for Android into tor-browser-build2020-06-16T01:25:56ZGeorg KoppenIntegrate building pluggable transports for Android into tor-browser-buildWe want to support Pluggable Transports in Tor Browser for Android. We should integrate those we support into our tor-browser-build process.We want to support Pluggable Transports in Tor Browser for Android. We should integrate those we support into our tor-browser-build process.https://gitlab.torproject.org/legacy/trac/-/issues/26920Deploy Marionette as a Pluggable Transport2020-06-16T00:48:40ZTracDeploy Marionette as a Pluggable TransportThis is a ticket to organize the deployment of Marionette as a new pluggable transport integrated into Tor. The original code is currently located at https://github.com/redjack/marionette. It has already been shown to be compatible wit...This is a ticket to organize the deployment of Marionette as a new pluggable transport integrated into Tor. The original code is currently located at https://github.com/redjack/marionette. It has already been shown to be compatible with Tor in March in its Python encumbered form. Currently, it can be compiled as a completely standalone binary, and therefore should be easy to integrate. We would like it to be integrated before the end of September.
To run it as a bridge, currently, use the torcc files in the etc/tor directory in the github repository above.
**Trac**:
**Username**: Marionettehttps://gitlab.torproject.org/legacy/trac/-/issues/29267CI for pluggable transports2020-06-13T18:36:14ZCecylia BocovichCI for pluggable transports(This will have several subtasks)
Get continuous integration into the workflow of pluggable trasport projects
This is related to #29024(This will have several subtasks)
Get continuous integration into the workflow of pluggable trasport projects
This is related to #29024https://gitlab.torproject.org/legacy/trac/-/issues/29287Have backup PT in pipeline2020-06-13T18:35:36ZCecylia BocovichHave backup PT in pipelineGet a new pluggable transport assessed and ready for deployment for if/when our current PTs become obsolete.
Possible candidates are:
- Marionette (#29272, #26920)
- HttpProxy (#29278)
- maybe a new one in Oakland 2019??Get a new pluggable transport assessed and ready for deployment for if/when our current PTs become obsolete.
Possible candidates are:
- Marionette (#29272, #26920)
- HttpProxy (#29278)
- maybe a new one in Oakland 2019??https://gitlab.torproject.org/legacy/trac/-/issues/26923Intent to create Pluggable Transport: HTTPS proxy2020-06-13T18:35:26ZTracIntent to create Pluggable Transport: HTTPS proxy# httpsproxy
HTTP CONNECT method is one of the standard ways to proxy internet traffic, which is used both in [HTTP/1.1](https://tools.ietf.org/html/rfc2616#section-9.9) and [HTTP/2](https://http2.github.io/http2-spec/#CONNECT). HTTPS tr...# httpsproxy
HTTP CONNECT method is one of the standard ways to proxy internet traffic, which is used both in [HTTP/1.1](https://tools.ietf.org/html/rfc2616#section-9.9) and [HTTP/2](https://http2.github.io/http2-spec/#CONNECT). HTTPS traffic is very popular on the web, and pluggable transports could benefit from this fact. There's very high collateral damage that would result from full HTTPS blocking, and it adds diversity to PTs’ shapes because most current PTs do not resemble HTTPS.
Usage of HTTPS proxies also helps with active probing: a proxy can be an actual web server that serves content, as opposed to circumvention technologies, that don't show any apparent collateral damage nor respond in any way, when probed. To a prober that doesn't have correct credentials, httpsproxy server can look like a real web server, if it is a real web server.
## Way to use it HTTPS proxies with Tor
### Naive proxy
Given correct credentials, user can request any standard forwardproxy on the web to connect to Tor. Client establishes TLS connection to the web proxy, and sends request in a form of
```
CONNECT 0.1.2.3:9001 HTTP/1.1
Host: 0.1.2.3
Proxy-Authorization: Basic dXNlcjpwYXNz
```
where 0.1.2.3:9001 is address of arbitrary vanilla Tor entry node. Web Server would establish tcp connection to this address and relay subsequent traffic to it.
Such an approach allows us to use a diverse set of standard proxies: a webproxy is easy to set up and does not need to speak Tor. However, the web proxy operator will likely want to whitelist Tor entrance nodes in order to prevent abuse. As such, they would benefit from talking to some sort of https-proxy-authority, which would provide an entrance node(s) to whitelist, and allow proxies to let Tor Project know that their servers could be used as a proxy.
While lack of server-side PT makes it easier to deploy, it also means we cannot collect metrics.
### Full Bridge
A full bridge runs a Tor entry node, a pluggable transport and an upstreaming frontend webserver. The upstreaming webserver would check credentials, and, instead of consuming CONNECT requests, it would upstream them into the pluggable transport ExtORPort, while also stapling client’s IP to it in a header. The PT would parse the IP from the HTTP request header, and pass it to ExtORPort, thus enabling metrics collection.
## Registering with BridgeDB
As it currently stands, bridges have to have an ORPort open to be registered with BridgeDB #7349
This leads to easy identification and blocking of bridges. However, we can still register bridge lines with BridgeDB, if we add an additional hop to an intermediate proxy before entering a bridge. A censor would only be able to observe the address of the intermediate proxy.
Having such a 2-hop setup is a natural property of Naive Proxy, as described above. Bridge line example:
```
httpsproxy [vanilla entry addr] [entry fingerprint] url=https://username:password@naiveproxy.org
```
We can use 2-hop approach with full bridges as well: the intermediate proxy would forward HTTP request (preferably with client IP in “Forwarded: for=IP:port” header). In this case, intermediate proxy just redirects all requests (as long as credentials are correct) to the chosen full bridge(s), which is essentially a reverse proxy -- a widely supported technology.
While the second hop adds overhead, there's a benefit in not requiring would-be proxy operators to run a full bridge, since configuration of a proxy now becomes substantially easier, and, ideally, would amount to adding a few lines to a web server config file and registering themselves w/ bridgeDB via some script. Not requiring them to install, configure and run both PT and Tor daemons may allow us to attract a bigger amount of volunteers for the entrance servers.
However it’s unclear which party and how would actually register the bridge line. Perhaps, a separate https-proxy-authority could do that (and provide web proxies with entries to use)
## Current prototype
Works with standard HTTP/1.1 and HTTP/2.0 proxies with both naive proxies and full bridges. If there's an interest in seeing current prototype, I would gladly share it, @dcf already created ticket for the repo creation #26793.
### Language
Both client and server are implemented in Golang. Relatively safe, cross-platform language.
### Overhead
Bandwidth overhead depends on aggressiveness of padding, but I would not expect goodput to drop below 80%, especially for high-bandwidth workloads, which should mostly consist of MTU-sized packets. Detailed evaluation would be done after padding is implemented.
Computational overhead amounts to TLS handshake per flow plus the usual connection management.
## Fingerprinting
Running a real web server helps, however there are multiple potential fingerprintabilities. Those include:
### Probing web server with proxy requests without a secret
By default, web servers with this sort of forward proxying enabled will respond to unauthenticated proxy requests with “407 Proxy Authentication Required”, whereas a web server without forwardproxying enabled will respond differently, stating that it's not a proxy and doesn't want your CONNECT requests.
It would be beneficial to hide the fact of proxying (although note that this doesn't give out proxy as a Tor proxy, just that forward proxying is enabled). This feature is already supported by [Caddy web server](https://github.com/caddyserver/forwardproxy/blob/master/README.md#caddyfile-syntax-server-configuration) (see "probe_resistance" option), which is used for the current implementation.
### TLS ClientHello fingerprinting
meek has been blocked before based on its TLS ClientHello at least twice. There is a library called [utls](https://github.com/refraction-networking/utls) that provides the ability to mimic arbitrary ClientHello messages. It uses real world data from https://tlsfingerprint.io/ to learn what it should mimic based on provided collateral damage, and allows developers to confirm the correctness of their mimicking. In the event of any particular "fingerprint" being blocked or incorrectly mimicked, this transport would use multiple "fingerprints" and cycle through them until an unblocked one is found.
### Other TLS fingerprinting
Evaluation of other TLS handshake messages and TLS records, and how they may differ from mimicked implementations remains a TODO.
### Traffic Size Patterns
The current prototype doesn't use padding yet, and traces generated by it look extremely fingerprintable by constantly generating packets of size CELL_SIZE * N + constant overhead.
We intend to address this problem shortly by splitting and padding http/2 frames to resemble common web traffic.
There is no standard way to pad http/1.1 that will work with standard web proxies, but we can probably split the cells.
### Connection establishment traffic patterns
This is especially relevant to 2-hop approaches: the client might have to wait for the first response for a long time, while the proxy establishes connection. This is an issue for many proxies, which is also possible to solve, just noting it requires attention and solution.
### Connection lifetime
Being connected to the same server for prolonged periods of time (HTTPS tunnel may work fine for hours, if not days) could be a distinguishing feature. Client should redial at least once an hour. TODO
**Trac**:
**Username**: sfhttps://gitlab.torproject.org/legacy/trac/-/issues/32095Analyse the "Carbon Reductor DPI X" DPI system2020-06-13T18:31:27ZPhilipp Winterphw@torproject.orgAnalyse the "Carbon Reductor DPI X" DPI systemSee https://github.com/net4people/bbs/issues/15
Let's take a look at the DPI system and see what we can learn from it. Hopefully, it will help us refine our threat models.See https://github.com/net4people/bbs/issues/15
Let's take a look at the DPI system and see what we can learn from it. Hopefully, it will help us refine our threat models.https://gitlab.torproject.org/legacy/trac/-/issues/21315publish some realtime stats from the broker?2020-06-13T18:20:25ZRoger Dingledinepublish some realtime stats from the broker?How many snowflakes are there registered right now and happy to serve censored users?
Right now there's a big difference between 0 and 1, and it's not easy to figure out which it is.
Knowing this number would help me as a snowflake vol...How many snowflakes are there registered right now and happy to serve censored users?
Right now there's a big difference between 0 and 1, and it's not easy to figure out which it is.
Knowing this number would help me as a snowflake volunteer decide whether I am needed, and whether to do advocacy at this moment to get other people to be snowflakes.
Knowing this number would help the censored users too, because it would give them a sense of the health of the snowflake population, and also it can help them debug their "it's not working, I wonder if I can narrow down some possible problems" situations.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/legacy/trac/-/issues/30368Run some tests to check reachability of snowflake proxies2020-06-13T18:20:01ZCecylia BocovichRun some tests to check reachability of snowflake proxiesOur standalone proxies were recently blocked in China: #30350
We should start running some probe tests like we are for obfs4 to see whether this blocking was a one-off event and detect blocking of new proxy instances.Our standalone proxies were recently blocked in China: #30350
We should start running some probe tests like we are for obfs4 to see whether this blocking was a one-off event and detect blocking of new proxy instances.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/legacy/trac/-/issues/30310Snowflake localization2020-06-13T18:19:55ZCecylia BocovichSnowflake localizationWe should start localizing the user-facing parts of snowflake. Right now that is just the browser-based proxy, but eventually it will include the WebExtension version.We should start localizing the user-facing parts of snowflake. Right now that is just the browser-based proxy, but eventually it will include the WebExtension version.Arlo BreaultArlo Breaulthttps://gitlab.torproject.org/legacy/trac/-/issues/29260Should Snowflake proxies have a way to identify themselves to the broker2020-06-13T18:19:36ZAlexander Færøyahf@torproject.orgShould Snowflake proxies have a way to identify themselves to the brokerWould it make sense for us to have an identity key (or something similar) for Snowflake proxies to allow them to identify themselves to the broker service.
This would allow us to later build reputation systems for the proxies and distri...Would it make sense for us to have an identity key (or something similar) for Snowflake proxies to allow them to identify themselves to the broker service.
This would allow us to later build reputation systems for the proxies and distribute snowflake proxies in a smart way based of stability/uptime. The downside from a privacy perspective is that the broker can follow the Snowflake proxies' movements on the internet, which means we might want to make it optional.https://gitlab.torproject.org/legacy/trac/-/issues/29205Look into using Firefox for the WebRTC implementation2020-06-13T18:19:29ZCecylia BocovichLook into using Firefox for the WebRTC implementationReduce fingerprintability and solve Windows reproducible builds problem by replacing the current Chome-based C++ WebRTC implementation with Firefox's built-in WebRTC implementation.
Update: After discussions with dcf, it looks like fing...Reduce fingerprintability and solve Windows reproducible builds problem by replacing the current Chome-based C++ WebRTC implementation with Firefox's built-in WebRTC implementation.
Update: After discussions with dcf, it looks like fingerprintability is not much of a concern and in any case would be no different with Firefox vs Chrome. Also, since meek is moving to uTLS instead of Firefox this isn't necessarily more convenient.
Leaving this ticket open just as another alternative for looking at different WebRTC implementations (related: #28942)https://gitlab.torproject.org/legacy/trac/-/issues/25681Defend against flooding of the broker by low bandwidth snowflakes2020-06-13T18:18:59ZcypherpunksDefend against flooding of the broker by low bandwidth snowflakesAn adversary may attempt to flood the broker by thousands of low bandwidth snowflakes, as a result users will have a higher chance of happening on them thereby deteriorating their experience.
Maybe there should be some way to ensure tha...An adversary may attempt to flood the broker by thousands of low bandwidth snowflakes, as a result users will have a higher chance of happening on them thereby deteriorating their experience.
Maybe there should be some way to ensure that their bandwidth is higher than some level before they can be distributed by the broker.https://gitlab.torproject.org/legacy/trac/-/issues/25601Multiplex - one snowflake proxy should be able to support multiple clients2020-06-13T18:18:58ZArlo BreaultMultiplex - one snowflake proxy should be able to support multiple clientsMigrated from https://github.com/keroserene/snowflake/issues/11
This seems to exist for the `proxy-go` but the JavaScript side has things like,
```
MAX_NUM_CLIENTS = 1
CONNECTIONS_PER_CLIENT = 1
```
so I'm guessing it wasn't finished.Migrated from https://github.com/keroserene/snowflake/issues/11
This seems to exist for the `proxy-go` but the JavaScript side has things like,
```
MAX_NUM_CLIENTS = 1
CONNECTIONS_PER_CLIENT = 1
```
so I'm guessing it wasn't finished.https://gitlab.torproject.org/legacy/trac/-/issues/25595Test suite for Snowflake on various NAT topologies2020-06-13T18:18:54ZArlo BreaultTest suite for Snowflake on various NAT topologiesMigrated from https://github.com/keroserene/snowflake/issues/20Migrated from https://github.com/keroserene/snowflake/issues/20https://gitlab.torproject.org/legacy/trac/-/issues/25593Broker needs better resilience against DoS2020-06-13T18:18:53ZArlo BreaultBroker needs better resilience against DoSMigrated from https://github.com/keroserene/snowflake/issues/25Migrated from https://github.com/keroserene/snowflake/issues/25https://gitlab.torproject.org/legacy/trac/-/issues/31245Coverity: multiple defects in btrack tests2020-06-13T15:43:51ZTaylor YuCoverity: multiple defects in btrack testsFix the following CIDs in the bootstrap tracker tests: 1446052, 1446050, 1446049, 1446047. These are inconsequential uninitialized structure members in tests.Fix the following CIDs in the bootstrap tracker tests: 1446052, 1446050, 1446049, 1446047. These are inconsequential uninitialized structure members in tests.Tor: unspecifiedTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/31011Make the bridge authority reject private PT addresses when DirAllowPrivateAdd...2020-06-13T15:43:11ZteorMake the bridge authority reject private PT addresses when DirAllowPrivateAddresses is 0When DirAllowPrivateAddresses is 0, the bridge authority should reject extra info descriptors with private addresses in their PT lines.
We should add some text asking operators to upgrade, and deploy this change after #31009 is backport...When DirAllowPrivateAddresses is 0, the bridge authority should reject extra info descriptors with private addresses in their PT lines.
We should add some text asking operators to upgrade, and deploy this change after #31009 is backported,
Gaba, this ticket should go in the PT sponsor with #31009.Tor: 0.4.4.x-finalcjbcjbhttps://gitlab.torproject.org/legacy/trac/-/issues/31009Tor lets transports advertise private IP addresses in descriptor2020-06-13T15:43:09ZPhilipp Winterphw@torproject.orgTor lets transports advertise private IP addresses in descriptorWhile dealing with broken obfs4 bridges, I realised that our bridge authority has several obfs4 bridges in its cached-extrainfo document that have private IP addresses, e.g.:
```
transport obfs4 10.0.254.17:[redacted]
```
The PT spec [e...While dealing with broken obfs4 bridges, I realised that our bridge authority has several obfs4 bridges in its cached-extrainfo document that have private IP addresses, e.g.:
```
transport obfs4 10.0.254.17:[redacted]
```
The PT spec [explicitly allows private addresses](https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt?id=4707f3604cd06e3a627980c6863cca556f9f21a4#n305) in `TOR_PT_SERVER_BINDADDR`:
> The <address> MAY be a locally scoped address as long as port forwarding is done externally.
BridgeDB however ignores bridges with private IP addresses, so these obfs4 bridges are effectively useless. We could address this issue in BridgeDB by replacing an obfs4 bridge's private IP address with the address in its ORPort but I think that tor shouldn't be writing private addresses to a descriptor in the first place.Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30885Add pluggable transports to Tor's chutney CI job2020-06-13T15:42:35ZteorAdd pluggable transports to Tor's chutney CI jobWe added PT support to chutney in #29024, now we need to make sure tor changes don't break PTs.
We should probably get chutney CI merged into Tor first, see #29280.We added PT support to chutney in #29024, now we need to make sure tor changes don't break PTs.
We should probably get chutney CI merged into Tor first, see #29280.Tor: unspecified