Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2021-10-29T17:55:46Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/11562meek browser stops working after many idle hours2021-10-29T17:55:46ZDavid Fifielddcf@torproject.orgmeek browser stops working after many idle hoursI left a copy of [3.5.4-meek-1](https://lists.torproject.org/pipermail/tor-dev/2014-April/006718.html) running idle for a few days. When I came back and tried to browse somewhere, the browser said "connection timed out." I will attach lo...I left a copy of [3.5.4-meek-1](https://lists.torproject.org/pipermail/tor-dev/2014-April/006718.html) running idle for a few days. When I came back and tried to browse somewhere, the browser said "connection timed out." I will attach log files in a comment. Sending a HUP to tor caused it to reload its configuration but didn't help things. Neither did "New Identity." Closing the browser and starting it again worked.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/11580Make meek man pages2020-06-27T13:44:21ZDavid Fifielddcf@torproject.orgMake meek man pagesFor:
* meek-client
* meek-server
Maybe also (only used in the bundle):
* meek-client-torbrowser
* terminateprocess-buffer
Join us for our next exciting episode, _Make `man meek` manifest meek manual_, or, _Three billy goats groff_.For:
* meek-client
* meek-server
Maybe also (only used in the bundle):
* meek-client-torbrowser
* terminateprocess-buffer
Join us for our next exciting episode, _Make `man meek` manifest meek manual_, or, _Three billy goats groff_.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/11612tbb bundle with meek takes (literally) hours to connect2020-06-27T13:44:21Zcypherpunkstbb bundle with meek takes (literally) hours to connectI tried out the experimental Tor Browser bundle with meek (version 3.5.4-meek-1-Linux, 32 bit).
When first launching the bundle, it took literally hours to make the first connection to the tor network. The progress bar was hung at ~50%, ...I tried out the experimental Tor Browser bundle with meek (version 3.5.4-meek-1-Linux, 32 bit).
When first launching the bundle, it took literally hours to make the first connection to the tor network. The progress bar was hung at ~50%, the console showed error messages like:
[notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 883/4458, and can only build 0% of likely paths. (We have 20% of guards bw, 21% of midpoint bw, and 21% of exit bw.)
[notice] Bootstrapped 72%: Loading relay descriptors.
[warn] Problem bootstrapping. Stuck at 72%: Loading relay descriptors. (DONE; DONE; count 1; recommendation warn)
I quit & restarted it several times, the bootstrapping progress seemed to restart from where it had left off, but it literally took hours before I had a tor browser window.
After that, TBB with meek worked reasonably well, albeit slower than normal Tor BrowserDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/11664BridgeDB's email server is currently not responding2020-06-27T13:43:13ZIsis LovecruftBridgeDB's email server is currently not respondingLikely because I missed another occurrence (during legacy/trac#5232 and related tickets) of the builtin buffer() type having either the new or old interface style. From the server.log:
```
Unhandled Error
Traceback (most recent call las...Likely because I missed another occurrence (during legacy/trac#5232 and related tickets) of the builtin buffer() type having either the new or old interface style. From the server.log:
```
Unhandled Error
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line 88, in callWithLogger
return callWithContext({"system": lp}, func, *args, **kw)
File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line 73, in callWithContext
return context.call({ILogContext: newCtx}, func, *args, **kw)
File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 118, in callWithContext
return self.currentContext().callWithContext(ctx, func, *args, **kw)
File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 81, in callWithContext
return func(*args,**kw)
--- <exception caught here> ---
File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py", line 614, in _doReadOrWrite
why = selectable.doRead()
File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 215, in doRead
return self._dataReceived(data)
File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 221, in _dataReceived
rval = self.protocol.dataReceived(data)
File "/usr/lib/python2.7/dist-packages/twisted/protocols/basic.py", line 454, in dataReceived
self.lineReceived(line)
File "/usr/lib/python2.7/dist-packages/twisted/mail/smtp.py", line 568, in lineReceived
return getattr(self, 'state_' + self.mode)(line)
File "/usr/lib/python2.7/dist-packages/twisted/mail/smtp.py", line 795, in dataLineReceived
m.eomReceived() for m in self.__messages
File "/srv/bridges.torproject.org/local/lib/python2.7/site-packages/bridgedb-0.2.0_dirty-py2.7.egg/bridgedb/EmailServer.py", line 394, in eomReceived
replyToMail(self.lines, self.ctx)
File "/srv/bridges.torproject.org/local/lib/python2.7/site-packages/bridgedb-0.2.0_dirty-py2.7.egg/bridgedb/EmailServer.py", line 284, in replyToMail
sendToUser, response = getMailResponse(lines, ctx)
File "/srv/bridges.torproject.org/local/lib/python2.7/site-packages/bridgedb-0.2.0_dirty-py2.7.egg/bridgedb/EmailServer.py", line 229, in getMailResponse
gpgContext=ctx.gpgContext)
File "/srv/bridges.torproject.org/local/lib/python2.7/site-packages/bridgedb-0.2.0_dirty-py2.7.egg/bridgedb/EmailServer.py", line 323, in composeEmail
mail.write(buffer(body))
exceptions.TypeError: 'buffer' does not have the buffer interface
```Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/11753BridgeDB's email responses are not translated2020-06-27T13:43:13ZIsis LovecruftBridgeDB's email responses are not translatedIn order to do this, we'll need to move the strings from the `templates/` directory that `bridgedb.HTTPServer` uses into a common file, and add methods for formatting them into HTML and plaintext emails.In order to do this, we'll need to move the strings from the `templates/` directory that `bridgedb.HTTPServer` uses into a common file, and add methods for formatting them into HTML and plaintext emails.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12029Redesign BridgeDB's class inheritance to make designing new distributors easier2020-06-27T13:43:12ZIsis LovecruftRedesign BridgeDB's class inheritance to make designing new distributors easierEverything is piled in `lib/bridgedb/Dist.py` right now, with a lack of organisation and documentation, making it rather overwhelming for others to design new distributors.
Here are some of the things which should be revised:
1. **Dis...Everything is piled in `lib/bridgedb/Dist.py` right now, with a lack of organisation and documentation, making it rather overwhelming for others to design new distributors.
Here are some of the things which should be revised:
1. **Distributor Class Interface** The class inheritance design of current distributors is all within one file and doesn't have any clear indication of what methods/attributes are necessary to create a new distributor. There should probably be a `zope.interface.Interface` class so that implementations of new distributors can be easily checked to see that they meet the specification.
2. **Distributor Class Inheritance** The current `Distributor` "base class" in `lib/bridgedb/Dist.py` inherits from `bridgedb.Bridges.BridgeHolder` which is one of the hashring classes. I've never looked into why this is done, but these should likely be distinct and separate classes. Either way the code in `lib/bridgedb/Bridges.py` is a complete mess as well, and will likely need some cleanup.
3. **Hide Database Transactions** There should probably be some sort of `getBridgesFromDBManager()` method for distributors, so that they can send a `bridgedb.bridgerequest.BridgeRequest` (or subclass) to a database manager.
- This method should expect to interact with a system, called the `DatabaseManager`, that doesn't exist yet because I'm currently building it, and also expect to receive some JSON in return which contains appropriate bridges for the client's request.
- This is so that the `DatabaseManager` can handle `BridgeRequest` queuing and database transactions, and the distributor can continue going about its business without having to worry about interacting with hashrings or databases or any of the complicated backend stuff.
- This should permit the distributors to be run in separate processes (or on separate systems), so that they can interact with the `DatabaseManager` remotely, which will help later when/if we wish to run future distributors with a larger potential attack surface (such as an OTR/XMPP distributor).
There might be more things which will be necessary to change which will be discovered either while hacking on the revision, or while a new distributor is being created through subclassing and working with the new API; these things should be added to this ticket (or a new ticket, then mentioned here).
We might want some sort of `DistributorTests` mixin class for creating `twisted.trial.unittest.TestCase`s from, so that they have some default checks.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12030Create a DatabaseManager for interacting with BridgeDB's database backends2021-09-09T14:22:37ZIsis LovecruftCreate a DatabaseManager for interacting with BridgeDB's database backendsWe need a `DatabaseManager` which will handle receiving `BridgeRequest`s from BridgeDB's distributors, and will [queue these requests](https://twitter.com/BigDataBorat/status/360850476150956032) as transactions with the backend databases...We need a `DatabaseManager` which will handle receiving `BridgeRequest`s from BridgeDB's distributors, and will [queue these requests](https://twitter.com/BigDataBorat/status/360850476150956032) as transactions with the backend databases.
The distributors are going to use a common method (just call it `getBridgesFromDBManager()` for now) to request `Bridge`s from the `DatabaseManager`, and they will expect to receive some relatively well-supported, simple, serialised format (probably JSON) in return.
1. **The Easy Way** The _easier_ way to do this would be to not really actually truly make a for-reals ORM, and simply expect to be interacting with a NOSQLly CouchDB backend [as described in proposal #226](https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/226-bridgedb-database-improvements.txt#l82). CouchDB documents are JSON anyway, so this is super easy. If we go this route, we'll need some code to convert the old SQLly stuff to the new NOSQLly format.
2. **The Masochistic Way** The harder, but possibly better in the long run (should we ever decide to stop using NOSQL/OODBMSs), way to do this would be to write a true ORM/RDBMS which can work with either system.
This databases which this system will interact with will be used for storing complex/referential/self-referential/recursive datatypes, such as `bridgedb.Bridges.Bridge`s and structures for storing data about blocking events for bridges (including timestamps, discovery method, and country code of the block, etc.) as defined [in Section 1.b. of proposal #226](https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/226-bridgedb-database-improvements.txt#l112).https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12031Create a Key-Value database system for simple/flat datatypes in BridgeDB2021-09-09T14:22:51ZIsis LovecruftCreate a Key-Value database system for simple/flat datatypes in BridgeDBBridgeDB will likely need some rather high-level code for interacting with Redis through Twisted in order to complete [Section 2 of proposal #226](https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/226-bridgedb-database-impro...BridgeDB will likely need some rather high-level code for interacting with Redis through Twisted in order to complete [Section 2 of proposal #226](https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/226-bridgedb-database-improvements.txt#l143).
We'll probably want to start with storing the `(emailAddress,timestamp)` pairs for the `bridgedb.Storage.getEmailTime` and `bridgedb.Storage.getWarnedEmail` inside Redis. Other simple datatypes which can be stored in Redis should eventually get listed here (and eventually in [bridgedb-spec.txt](https://gitweb.torproject.org/torspec.git/blob/HEAD:/bridgedb-spec.txt).https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12086BridgeDB accepts incoming emails sent to 'givemebridges@serious.ly'2020-06-27T13:43:12ZIsis LovecruftBridgeDB accepts incoming emails sent to 'givemebridges@serious.ly'From [this commit message](https://gitweb.torproject.org/user/isis/bridgedb.git/commitdiff/4c18a4e2b89872c5731d4301665642065980086e) for [this unittest which reproduces the issue](https://gitweb.torproject.org/user/isis/bridgedb.git/blob...From [this commit message](https://gitweb.torproject.org/user/isis/bridgedb.git/commitdiff/4c18a4e2b89872c5731d4301665642065980086e) for [this unittest which reproduces the issue](https://gitweb.torproject.org/user/isis/bridgedb.git/blob/4c18a4e2b89872c5731d4301665642065980086e:/lib/bridgedb/test/test_email_server.py#l326) and which is [currently failing with this error](https://travis-ci.org/isislovecruft/bridgedb/jobs/25714425#L1679):
> BridgeDB's current code will accept an incoming email with a `To: givemebridges@serious.ly` header. However, BridgeDB's reply will still contain: `From: bridges@torproject.org`.
>
> Obviously, it _shouldn't_ be possible for any email whose SMTP `RCPT TO` domain is `'serious.ly'` to actually end up in BridgeDB's mail queue. Though, if the outside SMTP layer is sent to `'[bridges|ponticum].torproject.org'` (with `MAIL FROM:` a gmail/yahoo address), these messages still end up in BridgeDB's mail queue.
>
> The following netcat session demonstrates that this is possible:
>
> {{{
> ∃!isisⒶwintermute:(master *$=)~ ∴ torsocks nc bridges.torproject.org 25
> 220 ponticum.torproject.org ESMTP Postfix (Debian/GNU)
> HELO ponticum.torproject.org
> 250 ponticum.torproject.org
> MAIL FROM: isisgrimalkin@gmail.com
> 250 2.1.0 Ok
> RCPT TO: bridges@bridges.torproject.org
> 250 2.1.5 Ok
> DATA
> 354 End data with <CR><LF>.<CR><LF>
> From: isislovecruft@gmail.com
> To: givemebridgesrightnow@serious.ly
> Subject: mwhahaha
>
> get transport obfs3
> .
> 250 2.0.0 Ok: queued as F03972834F
> QUIT
> 221 2.0.0 Bye
> }}}
>
> This request resulted in the following...
Although these logs _were_ taken from the currently live server, they are "sanitised".¹
¹ Where "sanitised" means "all bridge info, including IP addresses and hashes, are faked" and "all email addresses are mine".
> ...debug logs:
>
> {{{
> 15:30:31 DEBUG L690:server.validateFrom() ORIGIN: "'<bridgedb@ponticum>'"
> 15:30:31 DEBUG L699:server.validateFrom() Got canonical domain: 'ponticum'
> 15:30:31 DEBUG L495:server.lineReceived() > Received: from ponticum (ponticum [127.0.0.1]) for <bridges@bridgedb>; Wed, 21 May 2014 15:30:31 +0000
> 15:30:31 DEBUG L495:server.lineReceived() > From isisgrimalkin@gmail.com Wed May 21 15:30:31 2014
> 15:30:31 DEBUG L495:server.lineReceived() > X-Original-To: bridges@bridges.torproject.org
> 15:30:31 DEBUG L495:server.lineReceived() > Delivered-To: bridgedb@ponticum.torproject.org
> 15:30:31 DEBUG L495:server.lineReceived() > Received: from ponticum.torproject.org (kpebetka.net [95.79.25.182])
> 15:30:31 DEBUG L495:server.lineReceived() > by ponticum.torproject.org (Postfix) with SMTP id F03972834F
> 15:30:31 DEBUG L495:server.lineReceived() > for <bridges@bridges.torproject.org>; Wed, 21 May 2014 15:29:18 +0000 (UTC)
> 15:30:31 DEBUG L495:server.lineReceived() > From: isislovecruft@gmail.com
> 15:30:31 DEBUG L495:server.lineReceived() > To: givemebridgesrightnow@serious.ly
> 15:30:31 DEBUG L495:server.lineReceived() > Subject: mwhahaha
> 15:30:31 DEBUG L495:server.lineReceived() > X-DKIM-Authentication-Results: dunno
> 15:30:31 DEBUG L495:server.lineReceived() > Date: Wed, 21 May 2014 15:30:31 -0000
> 15:30:31 DEBUG L495:server.lineReceived() > Message-Id: <1400686231.135135.6548@ponticum>
> 15:30:31 DEBUG L495:server.lineReceived() >
> 15:30:31 DEBUG L495:server.lineReceived() > get transport obfs3
> 15:30:31 DEBUG L495:server.lineReceived() >
> 15:30:31 INFO L611:server.reply() Got an email; deciding whether to reply.
> 15:30:31 INFO L646:server.reply() Client requested email translation: en
> 15:30:31 DEBUG L70:request.determineBridg() Email request was valid.
> 15:30:31 DEBUG L160:request.withPluggableT() Parsing 'transport' line: 'get transport obfs3'
> 15:30:31 INFO L169:request.withPluggableT() Email requested transport type: 'obfs3'
> 15:30:31 DEBUG L81:request.determineBridg() Generating hashring filters for request.
> 15:30:31 INFO L420:Dist.getBridgesForEmai() Attempting to return for 3 bridges for isislovecruft@gmail.com...
> 15:30:31 DEBUG L445:Dist.getBridgesForEmai() Cache hit frozenset([<function filterBridgesByTransport(obfs3,<class 'ipaddr.IPv4Address'>)>])
> 15:30:31 DEBUG L75:Dist.getNumBridgesPerA() Returning 3 bridges from ring of len: 492
> 15:30:31 DEBUG L1034:Bridges.getBridges() Got duplicate bridge 'edfa2fd66533da52f40424bbe917bd03c8378c2d' in main hashring for position 'eda7f69f7c08bd80861c3afa2921168a007d9ae5'.
> 15:30:31 DEBUG L1034:Bridges.getBridges() Got duplicate bridge 'ed0b2fd66f398afbf10424bb911790faca9ddb8e' in main hashring for position 'eda7f69f7c08bd80861c3afa2921168a007d9ae5'.
> 15:30:31 DEBUG L183:server.generateRespons() Email contents:
> From: bridges@torproject.org
> To: isislovecruft@gmail.com
> Message-ID: <20140521153031.21456.73227139.10726@ponticum.torproject.org>
> In-Reply-To: <1400686231.135135.6548@ponticum>
> Content-Type: text/plain; charset="utf-8"
> Date: Wed, 21 May 2014 15:30:31 +0000
> Subject: Re: mwhahaha
>
>
> Hey, isislovecruft!
>
> [This is an automated message; please do not reply.]
>
> Here are your bridges:
>
> obfs3 10.1.1.1:1111 d14133856abbba8a65607baebf692162c567bf41
> obfs3 10.2.2.2:2222 86f45ab5dcef80a4b1abfcc43579e76f1d0b25a4
> obfs3 10.3.3.3:3333 5d55daabd91e041e74f62dcfab1a29c8bb32f0b2
>
>
> To enter bridges into Tor Browser, follow the instructions on the Tor
> Browser download page [0] to start Tor Browser.
>
> When the 'Tor Network Settings' dialogue pops up, click 'Configure' and follow
> the wizard until it asks:
>
> > Does your Internet Service Provider (ISP) block or otherwise censor connections
> > to the Tor network?
>
> Select 'Yes' and then click 'Next'. To configure your new bridges, copy and
> paste the bridge lines into the text input box. Finally, click 'Connect', and
> you should be good to go! If you experience trouble, try clicking the 'Help'
> button in the 'Tor Network Settings' wizard for further assistance.
>
> [0]: https://www.torproject.org/projects/torbrowser.html.en#downloads-beta
>
>
>
> COMMANDs: (combine COMMANDs to specify multiple options simultaneously)
> get bridges Request vanilla bridges.
> get transport [TYPE] Request a Pluggable Transport by TYPE.
> get help Displays this message.
> get key Get a copy of BridgeDB's public GnuPG key.
> get ipv6 Request IPv6 bridges.
>
> Currently supported transport TYPEs:
> obfs2
> obfs3
> scramblesuit
>
>
> --
> <3 BridgeDB
>
> ----------------------------------------------------------------------
> Public Keys: https://bridges.torproject.org/keys
> This email was generated with rainbows, unicorns, and sparkles
> for isislovecruft@gmail.com on Wednesday, 21 May, 2014 at 15:30:31.
>
>
> 15:30:31 INFO L655:server.reply() Sending reply to isislovecruft@gmail.com
> }}}
>
The other two bugs detailed in the above commit message are tickets legacy/trac#12089 and legacy/trac#12091 respectively.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/12087goptlib could provide IsClient()/IsServer().2020-06-27T13:43:59ZYawning Angelgoptlib could provide IsClient()/IsServer().Currently goptlib only provides ClientSetup()/ServerSetup() that will break the pt config protocol if the desired mode happens to not be a client or server.
This makes it somewhat annoying to write obfsproxy style apps with goptlib as t...Currently goptlib only provides ClientSetup()/ServerSetup() that will break the pt config protocol if the desired mode happens to not be a client or server.
This makes it somewhat annoying to write obfsproxy style apps with goptlib as the application must peek at `TOR_PT_[CLIENT,SERVER]_TRANSPORTS` themselves.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/12088goptlib should provide a method for querying the state location.2020-06-27T13:43:59ZYawning Angelgoptlib should provide a method for querying the state location.The only place pluggable transports are allowed to write to is the `TOR_PT_STATE_LOCATION`. goptlib should support querying (and maybe optionally) creating the directory.The only place pluggable transports are allowed to write to is the `TOR_PT_STATE_LOCATION`. goptlib should support querying (and maybe optionally) creating the directory.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12090BridgeDB replies with an empty email.2020-06-27T13:43:12ZMatt PaganBridgeDB replies with an empty email.Users are reporting that when they request bridges from bridges(a)torproject.org or bridges(a)bridges.torproject.org from a gmail account they receive in reply only an empty email. It appears this happens even when the request is made co...Users are reporting that when they request bridges from bridges(a)torproject.org or bridges(a)bridges.torproject.org from a gmail account they receive in reply only an empty email. It appears this happens even when the request is made correctly, (i.e. with a 'get bridges' or 'transport=obfs3' in the body).
It's unclear for me right now if these are accounts that have ever received bridges over email before or not.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12091BridgeDB still isn't checking DKIM verification results properly2020-06-27T13:43:12ZIsis LovecruftBridgeDB still isn't checking DKIM verification results properlyFrom [this commit message](https://gitweb.torproject.org/user/isis/bridgedb.git/commitdiff/4c18a4e2b89872c5731d4301665642065980086e) for [this unittest](https://gitweb.torproject.org/user/isis/bridgedb.git/blob/4c18a4e2b89872c5731d430166...From [this commit message](https://gitweb.torproject.org/user/isis/bridgedb.git/commitdiff/4c18a4e2b89872c5731d4301665642065980086e) for [this unittest](https://gitweb.torproject.org/user/isis/bridgedb.git/blob/4c18a4e2b89872c5731d4301665642065980086e:/lib/bridgedb/test/test_email_server.py#l326):
> Also, "dunno" certainly isn't a valid DKIM signature.
See the ticket description for legacy/trac#12086 for how
```
15:30:31 DEBUG L495:server.lineReceived() > X-DKIM-Authentication-Results: dunno
```
ended up in the headers on an incoming email in the first place.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12120Enable Firefox meek-http-helper to use an upstream proxy2020-06-27T13:44:20ZDavid Fifielddcf@torproject.orgEnable Firefox meek-http-helper to use an upstream proxyThe helper should be able to use an upsteam proxy, so that it can be used to implement TOR_PT_PROXY as in legacy/trac#8402/[proposal 232](https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/232-pluggable-transports-through-pro...The helper should be able to use an upsteam proxy, so that it can be used to implement TOR_PT_PROXY as in legacy/trac#8402/[proposal 232](https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/232-pluggable-transports-through-proxy.txt).
[Commit cf81b598](https://gitweb.torproject.org/pluggable-transports/meek.git/commitdiff/cf81b598defd537ed65c015cbf79c322dad26b89) (the removed part) shows how to create a per-request proxy setting.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12122Untranslatable strings in bridgedb.pot2020-06-27T13:43:12ZColin ChildsUntranslatable strings in bridgedb.potThe phrase "Uh oh, spaghettios!" appears in https://gitweb.torproject.org/bridgedb.git/blob_plain/HEAD:/lib/bridgedb/i18n/templates/bridgedb.pot. This is not translatable, and is causing confusion for a number of our translators.The phrase "Uh oh, spaghettios!" appears in https://gitweb.torproject.org/bridgedb.git/blob_plain/HEAD:/lib/bridgedb/i18n/templates/bridgedb.pot. This is not translatable, and is causing confusion for a number of our translators.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/12125Proposal 232 (TOR_PT_PROXY) support for goptlib2020-06-27T13:43:59ZDavid Fifielddcf@torproject.orgProposal 232 (TOR_PT_PROXY) support for goptlibWe should support [proposal 232](https://gitweb.torproject.org/torspec.git/blob/23b94e24f3089ba1a4bcafcc5c92c3753df0f17d:/proposals/232-pluggable-transports-through-proxy.txt)/legacy/trac#8402 (TOR_PT_PROXY) in goptlib.We should support [proposal 232](https://gitweb.torproject.org/torspec.git/blob/23b94e24f3089ba1a4bcafcc5c92c3753df0f17d:/proposals/232-pluggable-transports-through-proxy.txt)/legacy/trac#8402 (TOR_PT_PROXY) in goptlib.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/12130Figure out deployment strategy for obfs42020-06-27T13:43:59ZGeorge KadianakisFigure out deployment strategy for obfs4While we were busy doing other things, Yawning created his own PT which supercedes scramblesuit. obfs4 (this is a temporary name), aims to have all the features of scramblesuit and a bit more (for example, it has better performance becau...While we were busy doing other things, Yawning created his own PT which supercedes scramblesuit. obfs4 (this is a temporary name), aims to have all the features of scramblesuit and a bit more (for example, it has better performance because of Elligator instead of UniformDH).
The code can be found at `https://github.com/Yawning/obfs4` and apparently it already has feature parity with scramblesuit.
We should decide whether we should deploy obfs4 and when.
Some possible avenues:
- Deploy **both** scramblesuit and obfs4. This is a bit pointless since obfs4 does not have any real threat model differences over scramblesuit. And deploying another transport means that we have to ask bridge operators to upgrade, and users to learn another transport name (crying wolf paradigm applies here too). Also, maintaining two similar codebases is a bit stupid.
- Deploy obfs4 **instead of** scramblesuit. This makes more sense since obfs4 is supposedly _strictly better_ than scramblesuit. However:
1. scramblesuit is already a bit deployed. We have a few bridges already running it, and it was also recently added in the TBB `https://gitweb.torproject.org/builders/tor-browser-bundle.git/commitdiff/ef80bcdfd15ba873de6c7a88382176b893770638`.
2. obfs4 is untested and will probably need some time to pass quality control and review.
3. obfs4 is a go application, so it needs an extra patch to the TBB build process.
- Continue scramblesuit deployment, and hold on to obfs4. Maybe we can use obfs4 as an emergency transport in the future. Unfortunately, this is suboptimal. since it means that we will have to write TBB build patches to deploy the emergency transport. It would make more sense to hold on scramblesuit as the emergency transport (since it's already in obfsproxy).George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12146Firefox meek-http-helper leaks Host header in CONNECT requests2020-06-27T13:44:20ZDavid Fifielddcf@torproject.orgFirefox meek-http-helper leaks Host header in CONNECT requestslegacy/trac#12120 enabled the browser extension helper to use an upstream HTTP or SOCKS proxy. I'm watching the requests that go to the proxy, and Firefox is leaking the Host header in the proxy request:
```
CONNECT www.google.com:443 HT...legacy/trac#12120 enabled the browser extension helper to use an upstream HTTP or SOCKS proxy. I'm watching the requests that go to the proxy, and Firefox is leaking the Host header in the proxy request:
```
CONNECT www.google.com:443 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0
Proxy-Connection: keep-alive
Connection: keep-alive
Host: meek-reflect.appspot.com
```
The `Host: meek-reflect.appspot.com` is not supposed to be visible on the wire. It's encrypted inside of HTTPS. But Firefox leaks it when configured to use an HTTP proxy.
The Host header must be getting special treatment, because the extension also sets X-Session-ID, and that's not showing up in the proxy request.
We have to turn off the HTTP proxy feature if we can't find a way to prevent the Host from leaking.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12147BridgeDB distributors do not handle time intervals correctly2020-06-27T13:43:12ZIsis LovecruftBridgeDB distributors do not handle time intervals correctlyReported via arma on tor-assistants@lists.torproject.org, via a report from Francisco on IRC. Thank you to both of you!
Fix is done. Details forthcoming. I wanted a ticket to reference in the branch name, and to keep track of which vers...Reported via arma on tor-assistants@lists.torproject.org, via a report from Francisco on IRC. Thank you to both of you!
Fix is done. Details forthcoming. I wanted a ticket to reference in the branch name, and to keep track of which version(s) it needs to get backported to.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12148Leekspin is reporting its version as "unknown"2020-06-27T13:43:11ZIsis LovecruftLeekspin is reporting its version as "unknown"The current version (0.1.3) of [Leekspin](https://pypi.python.org/pypi/leekspin/0.1.3) on PyPI (and also the one in the repo) is reporting its version number as "unknown" when it's installed, which is causing some install scripts to emit...The current version (0.1.3) of [Leekspin](https://pypi.python.org/pypi/leekspin/0.1.3) on PyPI (and also the one in the repo) is reporting its version number as "unknown" when it's installed, which is causing some install scripts to emit warning messages. It seems that Leekspin's copy of versioneer probably did something weird during the last build, it likely just needs to be tagged again, rebuilt, and re-uploaded to the package distros.Isis LovecruftIsis Lovecruft