Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:57:31Zhttps://gitlab.torproject.org/legacy/trac/-/issues/393hidden services resolve hosts only once2020-06-13T13:57:31Zweasel (Peter Palfrader)hidden services resolve hosts only onceI have a hidden service, configured with
HiddenServicePort 6666 irc.oftc.net:6666
Now irc.oftc.net is a rotation that changes quite frequently and for that
reason the TTL of the A records it returns is only 60.
The problem is that Tor ...I have a hidden service, configured with
HiddenServicePort 6666 irc.oftc.net:6666
Now irc.oftc.net is a rotation that changes quite frequently and for that
reason the TTL of the A records it returns is only 60.
The problem is that Tor resolves the hostname only once, when it configures
the hidden service, not everytime a user establishes a new connection. This
causes problems since by the time a client request comes the information Tor
has often is long obsolete.
Please resolve it on connects, and don't cache it in a broken way (caching it
for TTL is fine).
Thanks
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedRobert RansomRobert Ransomhttps://gitlab.torproject.org/legacy/trac/-/issues/697Wrong DNS configuration could break navigation2020-06-13T14:00:00ZTracWrong DNS configuration could break navigationOn 0.2.0.26rc (add new version on reported version please),
Hello,
i've received one email who alert me.
One user have received OpenDNS pages when he is using tor.
OpenDNS is a company who resolve DNS for the others giving them filt...On 0.2.0.26rc (add new version on reported version please),
Hello,
i've received one email who alert me.
One user have received OpenDNS pages when he is using tor.
OpenDNS is a company who resolve DNS for the others giving them filtering, security, ads, but no privacy.
It appears that some nodes resolving DNS seems to have wrong DNS configured, blocking navigation.
If one router making dns resolution is misconfigured it could break navigation of others.
I think a DNS control need probably to be added making theses routers down.
Perhaps using a downloadable list for phishing.
---------- Forwarded message ----------
From: d
Date: 2008/6/10 04:22
Subject: Tor exit node policy
Hello,
I was browsing a phishing site using Tor recently and instead of the phish I saw an OpenDNS warning page (and apparently no way to bypass it). Yours was one of the exit nodes that was part of my Tor connection at the time.
I wasn't able to identify exactly which exit node it was.
Do you have Phish Filtering set up on your exit node, and if so is this a deliberate policy? I work in antiphishing and use Tor for some phish sites.
Thank you,
d
----------------------
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: amisTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/1991Recognize poor guard performance and switch?2020-06-13T17:46:35ZRoger DingledineRecognize poor guard performance and switch?Ticket #1919 showed that the expected performance when using guards is comparable to the expected performance when picking the fastest guards. The penalty from using the slowest guards is especially noticeable in the 1MB and 5MB torperf ...Ticket #1919 showed that the expected performance when using guards is comparable to the expected performance when picking the fastest guards. The penalty from using the slowest guards is especially noticeable in the 1MB and 5MB torperf runs.
What property is it about the guards that lets us guess when we have the slow ones? Can we sum the bandwidth of our top three guards and realize that it's significantly below the average?
Ultimately I expect we'll want the Tor client to be able to recognize that it's chosen a poor set of guards and swap in a faster one so it's not in the bottom, say, 20%.https://gitlab.torproject.org/legacy/trac/-/issues/2544Report potential addon conflicts in a standard, observable way2018-03-27T13:44:43ZTracReport potential addon conflicts in a standard, observable wayi have installed foxyproxy recently in order to access i2p sites from firefox. by default foxyproxy provides a proxy configuration called 'Default' (no proxying) that's used when a given url doesn't match any patterns. this means that by...i have installed foxyproxy recently in order to access i2p sites from firefox. by default foxyproxy provides a proxy configuration called 'Default' (no proxying) that's used when a given url doesn't match any patterns. this means that by default all urls will be fetched directly without going through the tor network. at first it wasn't clear to me that proxy settings applied by foxyproxy override those specified in torbutton options. so i just added a proxy for the i2p network and some time later when i visited check.torproject.org i noticed that i'm not using tor anymore;) i think torbutton could somehow detect the presense of foxyproxy and at least warn user.
**Trac**:
**Username**: wooTorbutton: 1.2.5Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/2681brainstorm ways to let Tor clients use yesterday's consensus more safely2022-03-22T13:28:40ZRoger Dingledinebrainstorm ways to let Tor clients use yesterday's consensus more safelyRight now Tor clients won't use a consensus that's 25 hours old. But if the directory authorities don't agree on a consensus for a day, things can go bad. We need to investigate other tradeoffs in this space than the one we've currently ...Right now Tor clients won't use a consensus that's 25 hours old. But if the directory authorities don't agree on a consensus for a day, things can go bad. We need to investigate other tradeoffs in this space than the one we've currently picked.
For instance: if you got your directory consensus info when it was valid, but you haven't been able to get any new consensus, perhaps you should be more forgiving about the timestamp on the consensus you have. That's a slightly different scenario than believing a new consensus that's 48 hours old.
Another option is just to change 24 to 48, which probably doesn't put clients at much greater harm, but gives us a lot more breathing room for mistakes.
The implementation side of this will be tricky, because we'll need to make sure that clients can handle descriptors that are 36 hours out of date too. We started implementing that feature several times, but I think we've never finished it.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/2743safelogging should cover hidden service name and intro-points too2020-06-13T14:09:26ZRoger Dingledinesafelogging should cover hidden service name and intro-points tooIn log messages about a hidden service we operate, we don't replace the hidden service name with [scrubbed].
Historically, this was considered fine, because you have your hostname and private_key files on disk already.
But if the user ...In log messages about a hidden service we operate, we don't replace the hidden service name with [scrubbed].
Historically, this was considered fine, because you have your hostname and private_key files on disk already.
But if the user puts his $datadir on encrypted storage, and the logs aren't on encrypted storage, then the logs could be the weak link.Tor: unspecifiedRobert RansomRobert Ransomhttps://gitlab.torproject.org/legacy/trac/-/issues/3060Review JonDos Design + Profile2011-05-31T00:55:06ZMike PerryReview JonDos Design + ProfileWe need to review the JonDos Firefox profile and work with them towards a shared web fingerprint.We need to review the JonDos Firefox profile and work with them towards a shared web fingerprint.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/3098Review other W3C-Identity Workshop submissions2011-05-15T05:49:38ZMike PerryReview other W3C-Identity Workshop submissionsI need to review 5 papers by Sunday as part of participation in the W3C-Identity workshop.I need to review 5 papers by Sunday as part of participation in the W3C-Identity workshop.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/3324Mike Perry's Iteration Report 201106122011-06-16T15:23:15ZMike PerryMike Perry's Iteration Report 20110612# Goals
[[TicketQuery(keywords=~MikePerryIteration20110612,format=table,col=component|summary|points|actualpoints,order=component)]]
Interviews, emails, etc: 6 pts, Actual: 10 pts
# Fires
[[TicketQuery(keywords=~MikePerryIterationFires2...# Goals
[[TicketQuery(keywords=~MikePerryIteration20110612,format=table,col=component|summary|points|actualpoints,order=component)]]
Interviews, emails, etc: 6 pts, Actual: 10 pts
# Fires
[[TicketQuery(keywords=~MikePerryIterationFires20110612,format=table,col=component|summary|points|actualpoints,order=component)]]
# Metrics
Goal Points: 23
Goal Points Done: 5
Actual Goal Points Done: 35
Fires Done: 1
Actual Points Done: 36Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/3330Evangelize private browsing improvements2011-06-16T02:10:21ZMike PerryEvangelize private browsing improvementsWe should write a blog post describing our ideal private browsing mode. Along the way, I should add my thoughts about the ThirdParty cookie policy to the Mozilla bugzilla, and also review and comment on their Privacy Roadmap.We should write a blog post describing our ideal private browsing mode. Along the way, I should add my thoughts about the ThirdParty cookie policy to the Mozilla bugzilla, and also review and comment on their Privacy Roadmap.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/3501Teach Tor to run the Control Port over TLS2020-06-13T14:11:33ZJacob AppelbaumTeach Tor to run the Control Port over TLSI've been discussing how we can use Vidalia with chiiph as a Tor controller over a network - this would be useful for the Torouter for example.
I think that a TOFU (Trust On First Use) model is probably best and that would mean we'd sim...I've been discussing how we can use Vidalia with chiiph as a Tor controller over a network - this would be useful for the Torouter for example.
I think that a TOFU (Trust On First Use) model is probably best and that would mean we'd simply need a Tor Control Port that uses a static TLS cert/key combo. I guess we could do a bare key or we could do the full x509 nightmare. I don't really have a preference.
This would allow us to control Tor safely as the control port data exported by Vidalia doesn't seem safe to expose to an attacker.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/3566Should controller events respect SafeLogging 1 torrc option?2020-06-13T14:11:51ZTracShould controller events respect SafeLogging 1 torrc option?Vidalia seems not to scrub addresses ignoring SafeLogging directive set in the torrc config file : the first one is the event logged by Vidalia , the second one is the same event logged by Tor while pulling tor git tree with tsocks ( 'us...Vidalia seems not to scrub addresses ignoring SafeLogging directive set in the torrc config file : the first one is the event logged by Vidalia , the second one is the same event logged by Tor while pulling tor git tree with tsocks ( 'usewithtor git pull' on the command line )
[...same time...] Potentially Dangerous Connection! - One of your applications established a connection through Tor to "38.229.70.11:9418" using a protocol that may leak information about your destination. Please ensure you configure your applications to use only SOCKS4a or SOCKS5 with remote hostname resolution.
...same time... [warn] Your application (using socks5 to port 9418) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider using Socks4A (e.g. via privoxy or socat) instead. For more information, please see https://wiki.torproject.org/TheOnionRouter/TorFAQ#SOCKSAndDNS.
**Trac**:
**Username**: tornewbieTor: unspecifiedTomas ToucedaTomas Toucedahttps://gitlab.torproject.org/legacy/trac/-/issues/3587Accounting should work with pluggable transports2020-06-13T14:11:55ZGeorge KadianakisAccounting should work with pluggable transportsA bridge operator supporting pluggable transports should still be able to enforce accounting policies.
(This is also related to #3586)A bridge operator supporting pluggable transports should still be able to enforce accounting policies.
(This is also related to #3586)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/3666SafeCache key is only 32bit2020-06-13T00:26:54ZMike PerrySafeCache key is only 32bitWe need to extend the key that safecache uses either to a 64bit int, or just add an additional string key. 32bits is too small: the birthday paradox says that 1 in every 64k domains will collide to the same id, allowing identifier sharing.We need to extend the key that safecache uses either to a 64bit int, or just add an additional string key. 32bits is too small: the birthday paradox says that 1 in every 64k domains will collide to the same id, allowing identifier sharing.TorBrowserBundle 2.2.x-stableMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/3733Tor should abandon rendezvous circuits that cause a client request to time out2020-06-13T14:12:26ZRobert RansomTor should abandon rendezvous circuits that cause a client request to time out```
Aug 14 05:59:04.639 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 05:59:09.631 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:08.637 [Notice...```
Aug 14 05:59:04.639 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 05:59:09.631 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:08.637 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:10.634 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:30.680 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
```
All of these streams had been attached to the same rendezvous circuit.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/3846Recruit build test/signoff volunteers2020-06-13T01:07:49ZMike PerryRecruit build test/signoff volunteersI still think it is a good idea to get tor-talk volunteers to commit to testing builds for us. We created this table for them to fill in but then forgot about it: https://trac.torproject.org/projects/tor/wiki/doc/build/BuildSignoff
Ther...I still think it is a good idea to get tor-talk volunteers to commit to testing builds for us. We created this table for them to fill in but then forgot about it: https://trac.torproject.org/projects/tor/wiki/doc/build/BuildSignoff
There also used to be a pastebin or google doc with a testing checklist + instructions in it? Is that lost forever?Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/4113Clean up and post Tor Browser Design Doc2011-10-07T23:53:09ZMike PerryClean up and post Tor Browser Design DocThe design doc needs to be merged and cleaned up a little before posting. More will still need to be done to get it out of draft status, but let's just post it first.The design doc needs to be merged and cleaned up a little before posting. More will still need to be done to get it out of draft status, but let's just post it first.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/4565Enable relays to talk to other relays via IPv62020-06-13T14:21:11ZKarsten LoesingEnable relays to talk to other relays via IPv6We need to extend Tor for relays to talk to other relays via IPv6. This task depends on #4564. The exact steps will be described in the roadmap that comes out of #4556.
This ticket is an _optional_ deliverable for June 30, 2012 for sp...We need to extend Tor for relays to talk to other relays via IPv6. This task depends on #4564. The exact steps will be described in the roadmap that comes out of #4556.
This ticket is an _optional_ deliverable for June 30, 2012 for sponsor G.Tor: unspecifiedLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/4696add OutboundBindInterface option to torrc2020-06-13T14:15:56ZTracadd OutboundBindInterface option to torrcFirst, I am well-aware that there is OutboundBindAddress option in tor.
I am also aware that tor "automatically" chooses an IP address/interface to bind to (if OutboundBindAddress is not specified) based on the current routing table.
...First, I am well-aware that there is OutboundBindAddress option in tor.
I am also aware that tor "automatically" chooses an IP address/interface to bind to (if OutboundBindAddress is not specified) based on the current routing table.
There are quite a few instances where OutboundBindAddress option is not suitable, particularly where the IP address changes frequently (vpn as well as most dhcp-dependant interfaces).
Whether I use OutboundBindAddress or just leave tor to make a decision which address to bind to is not suitable (at least) in the following two cases:
1. When I temporarily loose my IP address which tor has used up until now due to dhcp client renewing its lease (and receive a new IP address) and that doesn't happen - for whatever reason - instantly.
This results in one of two possible - wrong - outcomes: a) in case of absence of OutboundBindAddress option, Tor decides that my IP address "has changed" and tries to bind to the default interface, which may not be the one I have used previously; or b) when OutboundBindAddress is specified, tor just sits there trying to use the "old" address specified, resulting in a stall.
2. When I temporarily loose my current IP address due to vpn connection becoming (temporarily) unstable and it takes a bit of time for my machine to renew its IP address (this may take from a minute to up to 20+ minutes depending on the status of the vpn server at the other end) the outcome is exactly the same as I listed above - tor either tries to use the default interface (wrong!) or tries to bind to the IP address I specified with OutboundBindAddress (wrong again).
With the introduction of this new (OutboundBindInterface) option, tor can follow the IP address on the specified *interface* (regardless of what that might be) and the above - erroneous - outcome could be avoided.
**Trac**:
**Username**: mr-4Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/4712Review and update any existing patches for proposal 182 ("credit buckets")2020-06-13T17:47:22ZKarsten LoesingReview and update any existing patches for proposal 182 ("credit buckets")We should review any existing patches for proposal 182 and update them for merging them into master. This is part of #4682.We should review any existing patches for proposal 182 and update them for merging them into master. This is part of #4682.Tor: unspecified