Re: [tor-talk] UseEntryGuards: 0?

[Roger Dingledine]

On Sun, Aug 15, 2021 at 04:22:53PM +0200, Fran wrote:
> I run some onion v3 services, some are also available in the "clear net", some
> only as onion services. I monitor[1] reachability of the onion services which 
> results
> in quite some false positives, although  I configured alertmanager to alert 
> after > 1 hour (!)
> of failed connection attempts.  I'd like to reduce these false positives and 
> thought
> of using "UseEntryGuards: 0" to have circuits been rebuild more often.
> I'd only do this for the onion services which are also reachable in the 
> non-tor internet
> and therefore their IP adresses are known anyway.

First question: what do you mean by false positives? That is, is the
monitor script telling you that it's down but actually every time
you try manually it works? If that's what's happening, it sounds like
there's a bug or mis-design in the monitoring approach, and that's worth
tracking down.

Whereas if the problem is that actually the onion service is unreliable
and not always reachable, then it sounds like a *true* positive from
the monitor.

If they are true positives, I think it sounds like a great idea to do an
experiment where you switch to UseEntryGuards 0 for the services where
you don't mind having their location known. Let us know if it improves
things. :)

We also spoke in the past of having an 'onion service health monitor',
which would help to pinpoint *which phase* of the connection is failing,
and I continue to think that would be really valuable but we never quite
got there. See e.g.
https://gitlab.torproject.org/tpo/network-health/metrics/analysis/-/issues/13209
https://gitlab.torproject.org/tpo/core/tor/-/issues/28841

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor browser 10.5 lost all saved passwords

[Roger Dingledine]

On Tue, Jul 06, 2021 at 10:18:54PM +0200, Jerome Lille wrote:
> I just updated to version 10.5 and all the saved logins are gone!!
> 
> Can they be recovered?

Check out
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40506

Apparently they're not gone, they're just... inaccessible. The ticket
suggests one way to recover them. Hopefully an upcoming Tor Browser will
fix this surprise.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Bad signature of tor expert bundle

[Roger Dingledine]

On Sat, May 08, 2021 at 12:44:37PM +0800, Lu Wei wrote:
> I need a most recent version of the Windows Expert Bundle that could
> run on Windows XP. Version 0.4.5.7 do not work for me.

Firefox doesn't work on Win XP anymore, and so Tor Browser doesn't
work either.

In theory the Tor program itself (i.e. the one in the expert bundle)
might still work. You might need to build it yourself though.

Win XP is long dead and is now a terrible idea to run. So the safe
recommendation is "move to a better operating system", and if you want
to stick with that one, you'll have some work to do.

> > When I download the .asc file for 0.4.4.6 from archive.org, the file is
> > empty.
> >
> > The version 0.4.4.6 package is available from Tor's archive site, and
> > the signature is valid:
> > https://archive.torproject.org/tor-package-archive/torbrowser/10.0.10/tor-win32-0.4.4.6.zip
> > https://archive.torproject.org/tor-package-archive/torbrowser/10.0.10/tor-win32-0.4.4.6.zip.asc
> >
> Yes, but my point is why there are two tor-win32-0.4.4.6.zip files. Is
> there anything wrong with the file on archive.org? That would cast a
> cloud of suspicion on archive.org's credibility.

I just fetched your archive.org version of the tor 0.4.4.6.zip file,
and it matched the one I got from archive.torproject.org. The sha1sum
in both cases is e0a17cc7d2f51dc75f6fea496c44096e32e054bf. The signature
file I got from archive.org also checks out.

I notice that your original archive.org url was an http url, not an
https url. So all sorts of things might have happened that could mean
you never made it to the real archive.org site at all.

But from Matt's mail, it looks like something was going wrong with
fetching the archive.org versions of those files a few weeks back. All
the more reason to use the real Tor archive.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] tor as Onion Service (only) Wrote about "Requested exit point" in .log

[Roger Dingledine]

On Fri, Apr 30, 2021 at 07:16:08PM -0400, d...@foundingdocuments.org wrote:
> Why would tor running as an onion service write this to its log? 
> 
> Apr 29 02:06:22.000 [warn] {APP} Requested exit point 
> ???$1FINGER-PRINT-XYZ*??? is not known. Closing.

It's just a terminology confusion. What Tor means is that it wanted to
make a circuit whose last hop was XYZ, but it couldn't.

Onion services make circuits like this when, for example, they want to
upload your onion descriptor to particular HSDir relays -- the 'exit'
is the HSDir it's trying to end its circuit at.

> Among other stuff, the torrc contains: 
> 
> SOCKSPolicy reject *
> SocksPort 0
> ExitRelay 0 
> ExitPolicy reject *:*  

All of those are fine. I wonder why you have ExitRelay and ExitPolicy
set if you don't have ORPort set though -- if there's no ORPort, you're
not a relay, so then your exit policy doesn't matter.

> In case it???s related, I see about an hour earlier there was a large number 
> of dirservers that rejected an HS descriptor as invalid. In the past I???d 
> seen a line or two or three of similar [warn] {REND} errors, but near the 
> time below, there were 40 such lines. All within the span on one minute; 32 
> rejected in one second. I don???t think I???d seen that many at once before. 
> 
> Apr 29 00:50:25.000 [warn] {REND} Uploading hidden service descriptor: http 
> status 400 ("Invalid HS descriptor. Rejected.") response from dirserver 
> [IPv4**]:9001. Malformed hidden service descriptor?

Are you sure these are v3 onion services, and not v2 onion services?

You shouldn't be getting descriptor upload failures from v3 onion
services. If you are, please make an account on gitlab.torproject.org
and file a ticket in the 'Tor' component:
https://gitlab.torproject.org/tpo/core/tor/-/issues
and provide as many details (ways to reproduce it) as you can.

Whereas if they're actually v2 onion services, failures are going
to become more and more normal as relays upgrade:
https://blog.torproject.org/v2-deprecation-timeline

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Help test the v3 onion service patch if you like

[Roger Dingledine]

Hi people-who-enjoy-building-their-Tor-from-source,

We have an experimental fix for making v3 onion services work, both
client-side and service-side, even while the network is in a degraded
state.

(More background:
https://gitlab.torproject.org/tpo/core/tor/-/issues/40237
https://lists.torproject.org/pipermail/network-health/2021-January/000659.html
)

You'll need to apply the patch to both the service side and the client
side. (But it might work just to apply it on the client side -- if the
service side still has its introduction points open and hasn't tried to
publish a new hsdesc that lists different introduction points.)

And you're in luck, the network is running in degraded mode right now,
so it is the perfect time to try the patch. :) :/

You can find it as a git branch at
https://gitlab.torproject.org/dgoulet/tor/-/tree/ticket40237_046_01

or as a Tor diff which you can apply to your git checkout:
https://www.freehaven.net/~arma/40237-patch-046.txt

or as a Tor tarball I just made, at
https://www.freehaven.net/~arma/tor-0.4.6.0-alpha-dev.tar.gz
$ sha256sum tor-0.4.6.0-alpha-dev.tar.gz
0e66ef42e048551acdabdc27ac2510bc4230be56fb4574f31a6827eb650e1c77 
tor-0.4.6.0-alpha-dev.tar.gz

If you don't like building from source, that's fine. But if you do,
please test, and help find problems! Our current plan is to get this
patch into Tor 0.4.5.3-rc, which will come out tomorrow-ish, and that
will work its way into an upcoming Tor Browser alpha at some point.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] I don't understand two things about the node 'freja'.

[Roger Dingledine]

On Thu, Jul 02, 2020 at 10:12:19AM -, sean_sulli...@danwin1210.me wrote:
> The only reason I'm interested in "freja" is because I saw it's IP was the
> last login to one of my accounts. I checked the IP with WHOIS and got
> concerned. Then I checked "torstatus" and was relived that it was a Tor
> node. Then I got confused because it wasn't an exit node.

Actually, its exit policy does allow some outgoing ports:
https://metrics.torproject.org/rs.html#details/2096BCFEBB95A1134F39FCF8CEB076FF41A2B48B

So, it is missing the Exit flag, because its exit policy doesn't include
both ports 80 and 443.

I guess the follow-up question would be: when you say "one of my
accounts", perhaps this is an account that is reachable on a port
other than 80 and 443? For example, an irc account?

(When a relay is missing the Exit flag, Tor clients (a) won't use it when
preemptively making circuits, before new connections come in, because
it's too likely that the new connection will be for a destination that
the relay can't handle, and (b) won't apply the load balancing weights
that make them avoid using exit relays in non-exit positions in the
circuit. But if a connection request comes in when there aren't any
preemptive circuits already built, then the client will pick among
any relays whose exit policies allow that destination. So yes, it is
possible to use relays for exiting even when they don't have the Exit
flag, but they will get used less often.)
destination port k
use when new connections come in

> My point is that the IP of "freja" was the last login. So, unless there's
> a scenario I haven't thought of, surely it must at some point on Tuesday
> have been an exit node? Is there a way to check this?

Exonerator is the right tool for asking historical questions like this:
https://metrics.torproject.org/exonerator.html?ip=194.88.143.66×tamp=2020-06-30&lang=en

and it looks like the Exonerator folks have opted to say "yes" on whether
it counted as an exit relay, probably because its exit policy allowed
some connections, even if it didn't allow enough that it qualified for
the Exit flag.

All of this said, there is another possible explanation for your
scenario, though I don't think it happened here: sometimes relays exit
from a different IP address than they advertise in their descriptor. And
sometimes if there are several relays run by one person or organization,
one of the exit addresses overlaps with another relay. So it is possible
to receive a connection from the Tor side from an address that is a
non-exit relay, if there is an exit relay running nearby to it. But I
don't think that happened here.

Hope this helps,
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] I don't understand two things about the node "freja".

[Roger Dingledine]

On Tue, Jun 30, 2020 at 10:13:37PM -, sean_sulli...@danwin1210.me wrote:
> I have questions about the Tor node “freja”.
> 
> First, according to https://torstatus.rueckgr.at/, the node is at
> 194.88.143.66 which is in Italy. Yet WHOIS says the addresses
> 194.88.142.0-194.88.143.255 are in Pune, India. The last IP from a
> ‘traceroute’ is 81.25.202.165 and 81.25.202.128-81.25.202.255 is in ‘IT’
> (Italy) which suggests that https://torstatus.rueckgr.at/ is correct.
> 
> Why would WHOIS inaccurately (I think) say the IP is in India?

whois, and geoip databases, are notoriously inaccurate. This is a fine
illustration that it's not good to rely on them for situations that
really matter.

In particular, there's a pattern where some European country "loans"
an address block to somewhere in Africa or Asia, and then takes it back
a few years later, but nobody bothers updating whois for a while.

This pattern is also illustrated by some of the periodic spikes we have
of hundreds of thousands of new Tor users in Uganda -- they're actually
Tor users in Germany, but the geoip is wrong.

(To make things more exciting, sometimes there *are* spikes of many Tor
users in Uganda. But it means every time you see a pattern on one of
the metrics graphs, you have to wonder what you're actually seeing.)

> Second, according to https://torstatus.rueckgr.at/, “freja” is not an exit
> node. But if you use...
> 
> StrictNodes 1
> ExitNodes freja
> 
> ...then TBB will load the purple introductory screen “Explore. Privately.”
> (I tried with other non-exit nodes and TBB typically gets stuck on
> “Requesting Relay Information” and never loads the purple screen).
> 
> However, then “freja” will not load any pages.
> 
> So if it’s not an exit node, why does the introductory screen load?

Tor Browser's "about:tor" screen is served locally -- it does not come
from any remote website.

This is one of the Tor Browser usability improvements from some years ago,
where "making users wait for their Tor to bootstrap, and then fetch a
remote page, before the browser window appears" is no fun so we fixed it.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Full storage OS doesnt give warning signal to Tor Browser thus not upgrading

[Roger Dingledine]

On Fri, Mar 27, 2020 at 10:15:54AM +, bo0od wrote:
> no matter how many time you upgrade TB it wont upgrade (which is rational
> because there is no space). But a notification telling the user that would
> be better.
> 
> (same goes for plugins upgrade, tested on FF-esr manual download and gave
> same result as TB)
> 
> Yes its FF/TB issue.

Yep! This is a bug with the Firefox updater, and they don't seem to have
any momentum at fixing it. :(

For the Tor ticket, see
https://bugs.torproject.org/18186

And for the Firefox bug, see
https://bugzilla.mozilla.org/show_bug.cgi?id=315278

Gotta love those 15 year old bugs. :(

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] How secure is a hidden service?

[Roger Dingledine]

On Thu, Feb 20, 2020 at 07:25:32AM +0100, Robin Lee wrote:
> I'm wondering how hidden a hidden service actually is? Because last
> week charges were brought against Flugsvamp, a Swedish darknet drug
> shop. In the documents made public for the court case the police states
> that is was able to trace the actual ip-addresses of the onion-
> addresses. Flugsvamp had two onion-addresses and the the police gave
> different probabilities that a certain ip-address was behind each.
> 
> Is it just a function of time and amount of traffic, i.e. the longer
> you are online and the more traffic you generate, the more probable it
> is to discover the true ip-address?

It's complicated.

I should start out with saying I'd never heard of Flugsvamp until your
email, and I have no notion of whether they used Tor or what. That said:

Services on the internet are inherently harder to make safe than clients,
(a) because they stay at the same place for long periods of time, and
(b) because the attacker can induce them to generate or receive traffic,
in a way that's harder to reliably do to clients.

Most identification problems with Tor users, and with onion services,
have turned out to be opsec mistakes, or flaws in the application
software at one end or the other. That is, nothing to do with the Tor
protocol at all. But of course in the "layers of conspiracy" world we
live in nowadays, you can never be quite sure, because maybe "they"
used a complex attack on Tor and then covered it up by pointing to an
opsec flaw. One hopefully productive way forward is to point out that
even if we don't know how every successful attack really started, we
know that opsec flaws are sufficient to explain most of them.

When I'm doing talks about Tor these days, I list these four areas
of concern, ordered by how useful or usable they are to attackers in
practice: (1) Opsec mistakes, (2) Browser metadata fingerprints / proxy
bypass bugs, (3) Browser / webserver exploits, and (4) Traffic analysis.

See e.g. the original story about Farmer's Market:
https://blog.torproject.org/trip-report-october-fbi-conference
where at first people worried about a vulnerability in Tor, but then it
turned out that the operators had been identified and located far before
they even switched to using Tor.

To make this thread more productive and more concrete: can you point us
to these "documents made public for the court case"? Even if they're in
Svenska, they would still be useful to look at. The ones talking about
probabilities of IP address I mean.

Thanks,
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor and sources.list

[Roger Dingledine]

On Tue, Feb 04, 2020 at 11:14:14PM -, mimb...@danwin1210.me wrote:
> I ran the commands from the Ubuntu section of
> https://2019.www.torproject.org/docs/debian.html.en and it updated to
> 0.4.2.6.

Yep. The Tor 0.4.2.6 debs have now arrived in Debian as well as
deb.torproject.org.

I talked to the maintainer and he said they were held up due to a bug
in the arm64 builder (arm as in the cpu architecture, not arm as in the
deprecated tor controller). The packages should be all set now.

> Also, my /etc/torrc file (for tor not for the TBB) says:
> 
> ## Configuration file for a typical Tor user
> ## Last updated 9 October 2013 for Tor 0.2.5.2-alpha.
> ## (may or may not work for much older or much newer versions of Tor.)
> 
> All entries are ##'d out. Is it outdated? Do I need to do anything?
> 
> Thanks again.

It should be fine.

We try to change /etc/tor/torrc as infrequently as possible, because
every time we make even a tiny change, every single person who upgrades
and has modified their torrc file gets presented with a "how do you want
to handle this diff" question, and it's easy to make the wrong choice
and end up confused.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor Browser without Tor

[Roger Dingledine]

On Sun, Feb 02, 2020 at 01:16:24PM +0100, Jason Evans wrote:
> A similar question that was asked recently is, "how can I connect to local
> IPs with the Tor Browser?". For example, my home SAN is on 192.168.1.X and
> it's not reachable with the Tor Browser.
>[...]
>  Firefox still has an "No proxy for"
> section on its proxy page. However Tor Browser no longer has that section. Do
> you know of any way to use that functionality or is that just gone now?

You should really avoid making exceptions to the proxy rules for Tor
Browser. If you let your browser connect to local services, that opens
the door for remote websites, which you access over Tor, to give you
instructions (e.g. via javascript, but not only via javascript) to make
local connections and then send that info back to the website.

In the most benign case, you're setting yourself up with a tracking marker
("there's that weird person who allowed connections to 192.168.1.1
again"). In worse cases, you're opening yourself up to permissions
surprises and attacks that start with the word "cross-site" or
"cross-protocol".

For an early example of a similar bug that bit Tor users, see
https://lists.torproject.org/pipermail/tor-announce/2007-September/78.html

All of that said, if you still want to shoot your feet off: in
about:config, there's a network.proxy.no_proxies_on option that you
can set.

For even more details, new in ESR68, there is now a
network.proxy.allow_hijacking_localhost option, which we needed to fix
for Tor Browser:
https://bugs.torproject.org/31065

Good luck!
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor and sources.list

[Roger Dingledine]

On Mon, Feb 03, 2020 at 02:02:54AM -, mimb...@danwin1210.me wrote:
> In my /etc/apt/sources.list I have:
> 
> deb https://deb.torproject.org/torproject.org bionic main
> deb-src https://deb.torproject.org/torproject.org bionic main
> 
> My version of tor is 0.4.2.5. Am I correct that, at some point, it will
> automatically update to 0.4.2.6 thanks to the above entries in
> sources.list?

I'm expecting it to work this way, yes. Or at least, I've been patiently
waiting for my 0.4.2.6 deb too. :)

I expect that the workflow involves the real Tor deb going through the
general Debian process, and then once it is available in the real Debian
repositories (even if it's just the unstable ones), then the packages
get mirrored onto deb.torproject.org.

So, give it a couple of days and hopefully it will appear.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Are 'StrictNodes 1' actually strict?

[Roger Dingledine]

On Mon, Feb 03, 2020 at 01:14:39AM -, mimb...@danwin1210.me wrote:
> I don't want to come across as critical but ExitNodes with one node just
> doesn't work.
> 
> Looking at the Tor Circuits, it starts with 'hands' but then moves on to
> other exit nodes.
> 
> My torrc is simply:
> 
> ExitNodes hands

Your next step is to make a series of steps that are (a) as simple as
possible, and (b) as consistently repeatable as possible, and that
still show your bug.

That is, try to remove as many variables as possible -- visit a very
boring website that has only one IP address and doesn't pull in ads
and other dynamic stuff. Definitely avoid Cloudflare-hosted sites, or
CDN-hosted sites in general. Avoid onion services, because they don't
exit. If possible, view the Tor controller events yourself (not just
relying on Tor Launcher's visualization). If possible, reproduce the bug
outside of Tor Browser entirely, with just your Tor client and making
requests to it with curl or the like. Reproduce it on a variety of exit
relays. Basically, you want to rule out as many other factors as possible,
to get the simplest possible "if I do these steps, it breaks every time"
test case. Once you have that very simple scenario, please file a ticket
on trac.

Or if it breaks on the complex scenarios, and doesn't break on the simple
scenarios, then that gives you a direction to investigate.

The "hands" exit relay is indeed an exit relay, but it is heavily rate
limited, so I would expect that requests that use it will take a long
time, time out more frequently, etc. So maybe having it as a performance
bottleneck is helping to expose some bug.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Are 'StrictNodes 1' actually strict?

[Roger Dingledine]

On Fri, Jan 31, 2020 at 11:54:40PM -, mimb...@danwin1210.me wrote:
> That said, I have used the StrictNodes / ExitNodes combination many times
> recently and it has worked.
> 
> For example:
> 
> StrictNodes 1
> ExitNodes {ro}
> 
> or:
> 
> StrictNodes 1
> ExitNodes example_one
> ExitNodes example_two

Yep. StrictNodes does nothing there, and ExitNodes by itself should do
what you ask it to do.

> So if I wanted to use a specific exitnode, how would my torrc look?

The same as above, but leaving out the StrictNodes line since it
doesn't do anything.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Are "StrictNodes 1" actually strict?

[Roger Dingledine]

On Wed, Jan 29, 2020 at 02:45:01PM -, mimb...@danwin1210.me wrote:
> I have StrictNodes 1 and ExitNodes hands in my torrc.
> 
> However, when using TBB, I discovered that I was often using other exit
> nodes. Clicking "New Circuit for this site" then placed hands back as the
> exit node.
> 
> Any ideas why? Just the one exit node in the torrc.
> 
> This suggests to me that StrictNodes are not 100% strict.

Check out the man page, where it says "StrictNodes does not apply to
ExcludeExitNodes, ExitNodes, MiddleNodes, or MapAddress."

So you shouldn't be setting StrictNodes for this case. Maybe you are
using a super old guide found somewhere on the internet? :) More info
from when we made the change back in 2011:
https://gitweb.torproject.org/tor.git/tree/ReleaseNotes?h=tor-0.4.2.5#n17216

That said, ExitNodes should work. My guess is that you're visiting a
Cloudflare site, which is giving your Tor Browser an alt-svc header,
which sends the browser to load the site via one of Cloudflare's onion
addresses. And since onion services don't have the concept of "exiting",
then your Tor feels no need to end that circuit with your specified
ExitNode.

*That* said, there are some bugs with how Tor Browser visualizes your
circuit when alt-svc is in use:
https://bugs.torproject.org/27590
and it looks like the browser might be inconsistent about whether it
actually uses the alt-svc destinations, which could explain your getting
your exit relay every so often:
https://bugs.torproject.org/27502

Best plan would be to pick a really simple non-CDN'ed single-address
domain, like freehaven.net, and try to recreate your issue there.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Ports required for Tor and hidden services

[Roger Dingledine]

On Sat, Jan 25, 2020 at 01:30:34PM +, Forst wrote:
> In that case, what would be best approach to achieve that all traffic is
> forced though Tor and direct internet connection blocked, preferably even
> if/when the system is breached?

Here are two approaches that are worth exploring:

(A) Set the iptables rules so only the tor process can get through
the firewall. This is how Tails does it, I believe. This way you're
firewalling based on what user is trying to make the connection, rather
than what destination they're trying to reach. More info at
https://tails.boum.org/contribute/design/Tor_enforcement/

(B) Pick a bridge that you know you like, and configure your Tor to
use that, and configure your firewall to only allow connections to
that bridge. More info on this approach at
https://lists.torproject.org/pipermail/tor-relays/2014-October/005541.html
https://lists.torproject.org/pipermail/tor-relays/2014-October/005544.html
("The best design we've been able to come up with is one that forces
you to be using Tor on your side, and only allows your traffic through
if it's coming from Tor.")

I guess there is also (C) do both.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor vs Tor Browser

[Roger Dingledine]

On Sat, Jan 18, 2020 at 07:01:07AM +, Jason Long wrote:
> Hello,In the Tor Browser, we have some options like "Security Level". How 
> about Tor in CLI? How can I define it?

The "security slider" in Tor Browser is about disabling pieces of browser
functionality, to reduce surface area. Another name for it that might
give a better intuition would be "functionality filter". It is entirely
about stuff inside the browser, like whether it renders certain image
formats, whether it runs scripts, etc.

There is no equivalent of that "disabling application level pieces" idea
for the program called Tor: Tor just moves bytes back and forth for you,
and aims to give you good security by default.

(You will find advice on random websites out there, to add fifty new
lines to your torrc or something. Those guides are usually bad ideas.
Tor's defaults aim to keep most people safe, and since anonymity loves
company, you are probably better off blending in with the crowds.)

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] TBird & torbirdy

[Roger Dingledine]

On Sat, Nov 16, 2019 at 04:59:50PM -0500, eliaz wrote:
> I just installed Thunderbird 68.22 on a new machine and find out that the
> torbirdy extension cannot be installed in versions above 60. I've been
> running Thunderbird with the -p flag so that when I run over the Tor Browser
> Bundle 9.01 I can use the torbirdied instance. Does TBird 68.22 no longer
> need to be torified? Thanks for any enlightenment. - eli

It is alas worse than that: somebody needs to look at the new 68esr and
evaluate it for privacy flaws, and nobody has had time + expertise to
do it. So there is no Torbirdy for recent Thunderbird because nobody
has made one:
https://bugs.torproject.org/31341

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Brave Review Mentions Tor

[Roger Dingledine]

On Sat, Nov 16, 2019 at 01:50:18PM -0700, Mirimir wrote:
> On 11/15/2019 11:57 AM, d...@foundingdocuments.org wrote:
> > A few-days-old review.
> > 
> > Since Brave is the browser for OnionBrowser on iOS, I figured I???d read 
> > the article. 

I'm going to flag that one as "citation needed". That is, I don't think
Brave is the browser for OnionBrowser on iOS.

> > https://www.pcworld.com/article/3453376/brave-10-review-this-excellent-privacy-focused-browser-can-make-you-money-too.html
> >> Not only can you open a private window, but you can open an even deeper 
> >> level of privacy and use the Tor onion-routing network as well.
> 
> Why the bloody hell does OnionBrowser on iOS not just use Firefox?

Because iOS is missing real Firefox. And that alas is why there's no
Tor Browser on iOS either.

For more details, check out
https://blog.torproject.org/tor-heart-onion-browser-and-more-ios-tor
especially the first and second comment from the comments section.

> I wonder how Brave and Tor browser compare re anonymity, privacy and
> security. It seems unlikely that Brave would do a better job.

For those reading this, check out the Tor Browser design doc for
its application-level privacy goals and fixes:
https://www.torproject.org/projects/torbrowser/design/

And yes, I believe Brave wants to do all of those things too, and it
isn't there yet. I hope it does get there, because the world needs
more safe browsers.

> Also, the idea of running clearnet and Tor-mediated tabs in the same
> browser is pretty iffy. I mean, I don't even risk doing that in the same
> VM. And indeed, using Whonix, there is no clearnet connectivity.

Agreed. Even trying to keep state isolated across time (i.e. sometimes
your whole browser is torified, sometimes it isn't) is hard. That's why
we got rid of the "toggle model" in Torbutton:
https://blog.torproject.org/toggle-or-not-toggle-end-torbutton
https://arstechnica.com/information-technology/2013/10/how-the-nsa-might-use-hotmail-or-yahoo-cookies-to-identify-tor-users/

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] TorBrowser is only showing a black windows after today's update

[Roger Dingledine]

On Wed, Oct 23, 2019 at 11:49:22AM +0200, Nirgal wrote:
> I'm using Tor Browser Bundle on Debian stable, with xfce.
> 
> After last update, tor is only showing a black windows.

My guess is that you are using torbrowser-launcher, not actual
tor browser (as obtained from torproject.org).

There appears to be a bug in torbrowser-launcher:
https://bugs.torproject.org//32215
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942901
https://github.com/micahflee/torbrowser-launcher/pull/426

The fix would be either to install tor browser the normal way
by downloading it from torproject.org, or to hope that the
torbrowser-launcher package gets a fix (or help them fix it).

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] How to hide using Tor browser?

[Roger Dingledine]

On Sat, Jun 29, 2019 at 09:21:32AM +, Jason Long wrote:
> HelloSome website blocked Tor browser and you can't open them by Tor browser. 
> Any method to hide using Tor browser?

Alas, there are no great answers here.

Here's a related FAQ answer:
https://2019.www.torproject.org/docs/faq#HideExits

You could conceivably find an open proxy or a vpn and chain that at
the end of your circuit, but (a) it is messy (hard) to do that from a
practical perspective, and (b) it probably harms your anonymity.

The better answer is to find the people who run those websites, and
help teach them about the value of users who care about privacy:
https://2019.www.torproject.org/docs/faq-abuse#Bans
But that suggestion will work better on some sites than others.

For even more to read, check out
https://blog.torproject.org/call-arms-helping-internet-services-accept-anonymous-users

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Surge in Users

[Roger Dingledine]

On Fri, Jun 07, 2019 at 01:01:38PM +, iwanle...@cock.li wrote:
> Can Directory Authorities analyze hostnames of relay users and publish them?

They could, but I don't think that would be a good idea, at least until
somebody has thought through how to do it in a safe way. As a start for
that thinking, I would point people to:
https://research.torproject.org/safetyboard/
But I think this would be a hard one to make properly safe.

> If the hostnames or organization names associated with the users are
> available, we could know what type of users are increasing, and probably we
> could guess why. In Iran and Russia, are the increases being made by
> individuals, companies, and/or governments? I want to know that.

In my experience, spot-checking these things in the distant past, the
hostnames and IP addresses don't tell me as much as I'd like. Maybe if
I were an expert in the network topology for these countries, I could
understand things better.

As another approach, learning the autonomous system (AS) number of
connecting users would be another way to measure diversity within the
country. I expect in some situations it would give too much precision
(too much granularity) for us to be comfortable publishing it though.

> https://metrics.torproject.org/reproducible-metrics.html#relay-users
> Directory Authorities (DAs) can see IP addresses of relay users and are
> reporting countries associated with the addresses for torproject.

Yep.

> So DAs may
> be under control of torproject.

No, the directory authorities are run by nine individuals who are part
of the Tor community but are not 'under the control of torproject'. They
make decisions on their own, and for most security choices a majority or
threshold of them need to decide on something before it becomes so.

> Can torproject let DAs report hostnames of
> the users?

No. We can ask, but they should push back unless the request comes with
a solid plan on how the measurements will be safe enough.

> Should rapid increases of the users be clear for Tor overall? I
> would like torproject to decide to do that!

Yeah, I would also like the world to figure out a way to do safer
measurements like this.

The Privcount approach seems like a useful building block here, because
it does network-wide aggregation and because it uses differential privacy
techniques to avoid publishing any counts that are too precise:
https://www.robgjansen.com/publications/privcount-ccs2016.pdf
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/PrivCountInTor
and if we had more developer time (aka more funding), we'd be able to
get there faster.

> But if torproject can let DAs report them, I won't be able to use Tor with
> security. Even now, can DAs collect our personal information including IP
> addresses and leak them in theory? :D

Careful there -- the Tor design doesn't try to prevent every person in
the world from learning that you're using Tor. It tries to prevent every
person in the world from being able to learn _what you do_ using Tor.

If you want to prevent the directory authorities from knowing your
location, you'll need to take some further step. But most of these
possible steps (use a bridge, use a pluggable transport, use a VPN)
just shift the ability to count you to some other point in the network.
So there is no magic answer, and it comes down to "it depends what you're
worried about more".

Hope that helps,
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Surge in Users

[Roger Dingledine]

On Thu, Jun 06, 2019 at 01:21:09PM +0300, Van Gegel wrote:
> Take into account that statistics are number of unique user's IPs
>connected to bridges per day. My cellular provider change my local GPRS
>IP exactly every hour and my external IP also changed to random value of
>provider's pool. Each time IP was changed my Tor rebuild 3 new circuits
>to introduction points of mounted HS. So one mobile app with HS can
>generate 24*3 connecting events per day.

No, this is not right. Bridges and relays collect two kinds of aggregated
statistics -- total IP addresses they've seen over the time period,
and total consensus fetches they've seen over the time period.

Clients fetch a new consensus networkstatus document every couple of
hours, so you can get a count of the number of Tor clients that are
running, no matter how many different IP addresses they have, or how
many entry guards they use.

It's still not perfect, (a) because you'll overcount users like Tails
who don't keep state, if they reboot many times per hour, and (b)
because you'll undercount users who don't stay online for the whole
day, which is potentially a huge undercounting for countries like Iran
where a good chunk of users are using dialup or internet cafes or other
transient connections.

See also
https://gitweb.torproject.org/metrics-web.git/tree/src/main/resources/doc/users-q-and-a.txt
as linked from
https://metrics.torproject.org/userstats-relay-country.html
and there's lots more at
https://research.torproject.org/techreports/

And for that second category of undercounting, see this totally different
method for estimating the total number of Tor users, which at the time
estimated a much larger 8 million daily Tor users compared to the 2
million daily users that our older metrics approach estimated:
https://www.ohmygodel.com/publications/tor-usage-imc18.pdf

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor Glitch?

[Roger Dingledine]

On Mon, May 06, 2019 at 07:43:21PM -0400, Barely Passable Name wrote:
> So Tor Browser says NoScript is not compatible I couldn't get a screenshot.
> Any Help?

You want to upgrade your Tor Browser to the new version which fixes
this Firefox bug:
https://blog.torproject.org/new-release-tor-browser-809

For the earlier discussion, see this blog post and the many comments:
https://blog.torproject.org/noscript-temporarily-disabled-tor-browser

Hope this helps,
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Mozilla Research Grants 2019H1 - "Super Private Browsing"

[Roger Dingledine]

On Sat, Apr 27, 2019 at 11:22:00PM +, nusenu wrote:
> https://mozilla-research.forms.fm/mozilla-research-grants-2019h1/forms/6510
> 
> > RQ12: Privacy & Security for Firefox 
> 
> > Mozilla has an interest in
> > potentially integrating more of Tor into Firefox, for the purposes of
> > providing a Super Private Browsing (SPB) mode for our users.

Great find, nusenu.

It looks like they want to fund university research groups with $25k of
gift money (i.e. no university overhead). This is great.

I'm going to mail Jofish and ask him how we can best help them end up
with the best proposals -- whether we should mostly help in terms of
helping research groups craft their proposals, or mostly help in terms
of advising Mozilla on which proposals will have the biggest impact, or
some combination of both (while avoiding conflict-of-interest problems).

With luck, we'll start shouting about this from the blog and the
twitters soon.

Woo,
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] What is the weirdest/creepiest thing you have found on the dark web?

[Roger Dingledine]

On Sun, Apr 07, 2019 at 09:19:11PM -0400, Seth Caldwell wrote:
> I know the dark web can be a terrible place, with content not suitable for
> anyone, basically. Like illegal drug cartel, fake passports/IDs,creepy
> websites, and generally all around messed up stuff. If you feel comfortable
> talking about your experiences. Then, please reply to this Message.

I'm increasingly realizing that when "threat intelligence" companies
talk about the dark web, they mean anything on the internet that they
think you should be scared of.

For example, I talk to a growing number of CTOs from these threat
intelligence companies, and the recurring pattern is that they explain
that their marketing people need to say " dark web" to feel like
they're being competitive, but actually almost all of their useful
material comes from watching paste sites like pastebin.

So increasingly, when I hear somebody breathlessly asking me about all
the spooky stuff on the internet, I wonder what that has to do with Tor,
that is, why they are asking Tor.

Or taking a step back: when they say dark web, are they talking about
(A) websites on the internet that are reachable via Tor onion services,
(B) websites on the internet that have bad stuff on them, or
(C) websites on the internet that you need to log in to before you can
read the content?

There was a time a while ago where I think people meant 'A', but nowadays
it seems everybody means 'B' or 'C'. There are a wide variety of websites
in Russia (i.e. that end in .ru) or Malaysia (.my) with all of those
things you mentioned plus more. And of course there is some overlap
between the three categories, but I think the overlap is a lot smaller
than people think, and certainly a lot smaller than the " dark web"
hollywood tv shows want to imply.

For my most recent discussions about the dark web, and trying to get
some actual facts around it, see minutes 36-44 of the FOSDEM 2019 video:
https://fosdem.org/2019/schedule/event/tor_project/

Hope this helps,
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] How dangerous are malicious entry guards?

[Roger Dingledine]

On Sat, Mar 30, 2019 at 08:20:18PM -0400, hi...@safe-mail.net wrote:
> I???ve got a technical question: How dangerous are malicious entry guards?

It depends what you're worried about, and what you're trying to protect.

> I???ve read undocumented claims about information/security agencies now using 
> AI 
> on super computers to aid with traffic analysis/correlation/confirmation 
> attacks at entry node level

Huh. I don't think they should need supercomputers for such a thing.
It's all about what data you can get. The known math that you do with
the data, once you have it, doesn't (shouldn't) need a supercomputer.

> Does anyone have any technical opinions, explanations or resources regarding 
> this subject?

For the traffic analysis question in general, see papers from the PETS
conference and other anonymity literature:
https://petsymposium.org/
https://freehaven.net/anonbib/

For entry guards in particular, here are some URLs to start:
https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters
https://www-users.cs.umn.edu/~hoppernj/single_guard.pdf
https://blog.torproject.org/announcing-vanguards-add-onion-services

In general, don't just think about relay-level adversaries, but also think
about network-level adversaries who can observe (encrypted) Tor traffic.

And lastly, don't fall into traps where you think "omg Tor has this
potential entry guard issue, so I'm going to use this simpler centralized
system instead" -- because then you'll end up with that issue plus more.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Data collection by Tor Browser

[Roger Dingledine]

On Fri, Mar 01, 2019 at 08:00:17PM -0800, npdflr wrote:
> Does Tor browser itself collect any data (Technical data, Web activity data, 
> Personal data etc)?
> 
> As Tor is a modified Firefox ESR, does Tor browser follow the Firefox Data 
> Collection Practice? (https://wiki.mozilla.org/Firefox/Data_Collection)

I believe the answer is no, Tor Browser shouldn't tell anybody else
any of these things about you.

You can read the Tor Browser design goals here:
https://www.torproject.org/projects/torbrowser/design/
and anything where it reveals your browsing activity would count as a
bug -- and depending on the type of information leak, could qualify for
a bug bounty: https://hackerone.com/torproject .

Three caveats to my answer though:

(1) This word 'collect' is confusing, because that word sure makes it
sound like it includes internal program data structures. The browser
needs to know something about your web activity while it's loading web
pages for you, and that by itself isn't harmful. The key question is
whether it shares that information with anybody else. For this sort of
user info, we aim to stick to the principle of "no secret databases",
that is, anything that we gather should be so sanitized, and so safe to
collect, that we share it with everybody else too. That way we're never
in the position where attackers might want to break into our systems to
learn more about our users.
https://www.freehaven.net/anonbib/#wecsr10measuring-tor
For browser activity, the obvious simple approach to only publishing
safe things is to publish nothing at all, which is what we try to do.

(2) I might not be up on the latest Tor Browser moves, so it's possible
there are some open tickets for disabling telemetry or the like which
aren't yet fixed. Keeping up with the constant changes to Firefox is tough
to do perfectly. I'll let the browser team jump in here if they want.

(3) Other places on the Internet could still keep statistics, based
on your connections to them. I'm thinking in particular of:

(3a) the addons.mozilla.org server, which ought to see just anonymized
connections over Tor, but that still lets them gather general statistics
like how many Tor users there are, what extensions they have installed,
etc. Similarly, the periodic update pings, and update fetches, happen
over Tor but can still be counted in the aggregate:
https://metrics.torproject.org/webstats-tb.html
https://blog.torproject.org/making-tor-browser-updates-stable-and-reliable-fastly

and

(3b) the Tor relays, which see connections from the Tor client that is
part of Tor Browser. Because of the decentralized Tor design, no single
relay should be able to learn both who you are and also what you do on
the Tor network. But they can still collect what they observe about who
you are. Relays collect and publish aggregate statistics about the users
they see (but not what they do, because they can't learn that). For much
more info, see https://metrics.torproject.org/about.html

and

(3c) other researchers might perform experiments using their own
internet connections to try to answer questions about Tor performance,
usage, safety, etc. The ones who are doing it right will consider how
to minimize risks while doing their experiments:
https://research.torproject.org/safetyboard.html

Hope this helps!
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Getting Involved in the Tor Project

[Roger Dingledine]

On Sun, Feb 17, 2019 at 07:49:21AM +, J.S. Evans wrote:
> how do I join the Tor Project organization as a official 
> contributor/volunteer? For example, last year I did a presentation at the 
> OpenSUSE Conference on using containers to build .onion services. This year I 
> would like to do something similar at the HCPP19 Hacker Congress. I would 
> like to be able to say that I am with the Tor Project as opposed to saying, 
> I'm just some guy who experiments with Tor on his own. I hope that makes 
> sense.

Hi Jason!

Thanks for asking. The simple answer is to start working with some of
the existing core contributors. Tor (that is, the Tor Project) does a
lot of its work online in a distributed way, but we also try to meet in
person as often as we can.

You can learn about the various teams here:
https://trac.torproject.org/projects/tor/wiki/org/teams

and see some upcoming in-person meetings on the event calendar on
the blog here:
https://blog.torproject.org/

and learn about how to become a core contributor here:
https://gitweb.torproject.org/community/policies.git/tree/membership.txt

I'd suggest, since you mentioned you don't want to get involved as a
developer, listening in on the irc team meetings for the community team
and the UX team.

Hope that provides a useful start!
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Why some optional weights of router bandwidths are set to 10000?

[Roger Dingledine]

For those of you wondering what the heck we're talking about: these are
parameters that clients read from the consensus that help clients choose
paths in a way that is globally optimal for load balancing.

The idea stems from the realization that relays that can handle exiting
are going to get a lot of load already by clients who choose those relays
as the final hop in their circuit, so clients should avoid picking them
in *other* hops of their circuits, because that would just overload them
even more.

More info here:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2434
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3045
https://gitweb.torproject.org/torspec.git/tree/proposals/265-load-balancing-with-overhead.txt

You can see the current weights in your consensus file: search for the
"bandwidth-weights" line.

Ok. With that introduction, here we go:

On Wed, Jan 02, 2019 at 09:47:14AM +0800, Lucon Yang wrote:
> As we know, some weight params are applied to router bandwidths during path
> selection. In the process of computing node weight, I find the the
> consensus' "bwweightscale" param and the exit position related
> params(eg.Weg,Wem,Wee,Wed) are all set to '1', which results in every
> node has the same weight value of 1. That means node's flag, such as
> 'Exit','Guard','V2dir', doesn't have effect on choosing the exit node.So I
> want to ask what's the reason of the design like this?


I admit I've always found the per-position weightings logic to be a bit
of a mystery, but I believe the answer here is that these weights are
applied *in addition to* the individual weights for the relays, and the
goal of these weights is to give clients a chance to avoid using relays
in circuit positions that aren't globally optimal for the network.

With the current relays in the network, exit capacity is scarce. So the
current values for the weights mean that if a client is considering a
given relay for whether it should be the exit relay in their circuit,
its chance of being used as the exit relay should not be reduced. Or
said another way, these weights mean that if a client is thinking of
picking that relay as its exit, it's fine to do.

Compare this situation to

 Wgd - Weight for Guard+Exit-flagged nodes in the guard Position

That weight means that if a client is thinking of picking a relay for
its Guard position, and the relay has both the Guard flag and the Exit
flag, then it should adjust its chance of picking that relay by that
factor. In this case, since Wgd is 0 in the current consensus, it should
adjust its chance down to 0, meaning that clients will skip over relays
with both the Guard flag and the Exit flag when they're picking a relay
for the guard position (first hop) of their circuit.

In an alternate world where the Tor network had plenty of spare exit
capacity, the "Weg,Wem,Wee,Wed" weights might be less than 1,
which would instruct clients to choose these various kinds of relays
less often for the Exit position, because the relays would presumably
already be getting other load from being chosen by other clients for
non-exit positions.

Hope this explanation helped rather than making things worse :)
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Onion v3 Services in 2019

[Roger Dingledine]

On Tue, Jan 01, 2019 at 09:15:15PM +0100, Nathaniel Suchy wrote:
> At some point in 2019 will TorProject.org get an Onion v3 Address.

I believe we, like debian and others, are waiting for onionbalance
support in the v3 design.

It turns out to be quite hard to change the v3 design to support the
original onionbalance approach. That's because the v3 design added
cross-certification between the overall onion descriptor and each
individual intro point component in the descriptor, so you can't just
take the individual intro points components and put them together into
your own custom frankendescriptor.

The ticket is here:
https://trac.torproject.org/26768
And I don't think anybody is working on it currently. :(

> Additionally at some point will Onion v3 Addresses become the default rather 
> than v2?

It already happened, starting in 0.3.5.x (which will be the next
long-term-stable).

See this changelog entry from 0.3.5.1-alpha:

  o Major features (onion services, UI change):
- For a newly created onion service, the default version is now 3.
  Tor still supports existing version 2 services, but the operator
  now needs to set "HiddenServiceVersion 2" in order to create a new
  version 2 service. For existing services, Tor now learns the
  version by reading the key file. Closes ticket 27215.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Abuse complaint 418289

[Roger Dingledine]

On Wed, Dec 26, 2018 at 06:36:52PM +, potlatch wrote:
> One of my VPS providers has requested that I block exit output to ports 22, 
> 465 and 576.  I have never received a request like this before even though I 
> have (now or in the past) operated almost 40 Tor exit relays in diverse 
> countries.  The host making this request is understanding and the service 
> excellent.  He sees these ports as generating the most abuse complaints.
> Question:  Is this a reasonable request and how much critical communications 
> would be booted if I block these ports.  I think my alternative to blocking 
> as requested would be to close these accounts and find another host.

Port 22 is ssh, so turning it off would mean your relay won't be the exit
point for helping people reach their ssh servers while protecting their
communications metadata. Exiting to port 22 is a helpful thing to do,
but web browsing is by far the most common activity over Tor (or at least
it was last time we measured). Port 465 is for secure mail delivery,
which probably doesn't work so well over Tor these days anyway. And I
wonder what they meant by 576, and if it's a transcription error and
they meant some other port (like 587).

So, should you abandon them because they asked you to reject these extra
ports? It depends on your situation and your alternatives.

Answer #1: an exit that exits to 80 and 443 is still a very useful exit
relay. So turning off those small lesser-used ports is fine and
reasonable if it means you can keep running the main ports. See this
tor-relays thread for a similar discussion:
https://lists.torproject.org/pipermail/tor-relays/2018-December/thread.html#16736

Answer #2: if you want to use this event as a reason to explore other
options, to figure out what other hosting places there are, how much
they would cost, and how friendly they would be, it is a fine excuse
for doing that. Who knows, you might even find a second great place
and now you could be running two exits. :)

Answer #3: it depends how many other relays are running at this
particular VPS hoster. If it's a huge number, then it makes more sense
to set out and find a place with fewer relays. If it's a tiny number,
then the diversity that the network gets, from having your relay there,
is a more important component.

Hope that helps! And thanks for running exits.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] "Tor Circuit" list in TBB displaying incorrect exit node and IP address

[Roger Dingledine]

On Sun, Dec 23, 2018 at 03:10:00PM -, jiggytwi...@danwin1210.me wrote:
> The odd behavior only happens with certain sites:
> https://bitcointalk.org/, https://www.cato.org/,
> https://www.whatismyip.com/ (for example - there must be many more)
> 
> It does not happen with Google, Gmail, Amazon, Alexa, Yahoo, CNN, BBC, etc.

bitcointalk is a cloudflare website. So is whatismyip.com.

> Is this a known bug? Or something problematic with certain sites? Why are
> these sites different?

Assuming the difference is "cloudflare vs not cloudflare", check out
https://trac.torproject.org/27590

You can also read
https://trac.torproject.org/27949
and
https://trac.torproject.org/28033
for related tickets that got closed as duplicates of #27590 but might
still give you more context.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor official list of new .onion addresses?

[Roger Dingledine]

On Tue, Dec 04, 2018 at 04:14:46PM +, iwanle...@cock.li wrote:
> The descriptors seem to indicate onion addresses. So if I act a relay, I
> seem to be able to get the addresses. Then how? ... Could someone skilled
> try to get the lists? :D

Please don't.

In particular, if we notice that your relay is enumerating onion addresses
that it learns about, we will kick your relay out of the network.

That's because it's a known protocol bug with the old v2 onion service
design, and so we consider exploiting the bug to be a form of attacking
the network.

For a more detailed explanation, check out minutes 30-37 of
https://media.ccc.de/v/32c3-7322-tor_onion_services_more_useful_than_you_think
and you can follow along with slide 32 of
https://freehaven.net/~arma/slides-32c3.pdf

Or from yet another angle, if you're running a relay with the goal of
learning stuff about users, rather than the goal of providing safe
relaying for users, then I wonder what else you're willing to attack
or undermine rather than protect.

And if you're not forthcoming about your goals and why they're safe
enough, I worry that you're not a positive contributor to our community:
https://research.torproject.org/safetyboard.html

Hope this helps,
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor VoIP PBX Architecture Discussion

[Roger Dingledine]

On Mon, Oct 22, 2018 at 05:13:39PM +0100, Iain Learmonth wrote:
> It might also be that half-duplex communication (even if implemented
> with humans saying "over") could bring benefits as this would allow you
> to increase the buffer sizes without having people talking over each other.

Reminds me of the early days in Guardian Project's voice support in Orbot,
where they essentially built a "push to talk" feature that encoded your
thing as an mp3 and sent it across the Tor network and played it on the
other end. I hear that, once you figured out how to use it, it was
remarkably usable.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Questions about Directory Authority Servers

[Roger Dingledine]

On Mon, Oct 15, 2018 at 08:08:03PM +, panoramix.druida wrote:
> From my understanding when a Tor proxy is started it downloads a list of 
> relays from one of the ten  Directory Authority Servers listed here:
> https://metrics.torproject.org/rs.html#search/flag:authority
> 
> Am I right?

Almost. First, it's actually only the nine v3 directory authorities.
The tenth one you see there, Serge, is a bridge authority, which is
different. And second, modern Tor clients fetch from a much larger
list, called the fallback directories, which are 100 or so relatively
stable relays.

The v3 directory authorities are responsible for collectively creating
the hourly networkstatus document, but that doesn't mean they need to
be the bottleneck for serving it.

You can learn more about the various roles here:
https://www.torproject.org/docs/faq#KeyManagement

> If so who run these servers and how the people running them are chosen? I 
> would like to know a bit on the governance on how this authority servers are 
> chosen.

The simple answer is that we choose good people from among the core
Tor participant community.

You can learn more about the community here:
https://gitweb.torproject.org/community/policies.git/tree/

And more about our selection goals here:
https://gitweb.torproject.org/torspec.git/tree/attic/authority-policy.txt

> What could go wrong if one or more of these servers are compromise?

In theory, not much happens if a minority of them are compromised. If
a majority are compromised, things start to go bad, for example because
the attacker could create their own competing networkstatus documents.

Overall the v3 directory design still seems like a win though in terms
of trust, compared to the more-complex more-decentralized approaches,
where the complexity brings in new attacks, e.g.:
https://www.freehaven.net/anonbib/#wpes09-dht-attack

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] website typos (was re: Tor 0.3.4.6-rc is released)

[Roger Dingledine]

On Sat, Sep 08, 2018 at 09:07:17AM +0100, Colin Baxter wrote:
> There's a typo in https://www.torproject.org/docs/tor-doc-unix. That
> page says "src/or/tor" runs tor directly from the git directory. The
> path should be "src/app/tor"

Thanks -- I've fixed it.

(Actually, it wasn't wrong yet: that page tells you what to do with a
stable Tor release, and no releases have been made yet of Tor 0.3.5.x,
which is where the path changed from src/or/tor to src/app/tor. So
hopefully I've changed it in a future-proof way. :)

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor 0.3.4.6-rc is released

[Roger Dingledine]

On Tue, Aug 07, 2018 at 08:09:10PM -0400, Nick Mathewson wrote:
> Changes in version 0.3.4.6-rc - 2018-08-06
>   Tor 0.3.4.6-rc fixes several small compilation, portability, and
>   correctness issues in previous versions of Tor. This version is a
>   release candidate: if no serious bugs are found, we expect that the
>   stable 0.3.4 release will be (almost) the same as this release.

Hi folks,

We screwed up and left out some changes entries in the 0.3.4.6-rc
changelog. They are now in the ChangeLog file in git:
https://gitweb.torproject.org/tor.git/commit/?h=release-0.3.4&id=7ce714e7d360416db3b5f1e1b8af7a2f4eae97b4

and I've included them below for completeness. I don't think any of them
are super important, but sorry for the surprise.

  o Minor features (compilation):
- When compiling with --enable-openbsd-malloc or --enable-tcmalloc,
  tell the compiler not to include the system malloc implementation.
  Fixes bug 20424; bugfix on 0.2.0.20-rc.
- Don't try to use a pragma to temporarily disable the
  -Wunused-const-variable warning if the compiler doesn't support
  it. Fixes bug 26785; bugfix on 0.3.2.11.

  o Minor features (controller):
- The control port now exposes the list of HTTPTunnelPorts and
  ExtOrPorts via GETINFO net/listeners/httptunnel and
  net/listeners/extor respectively. Closes ticket 26647.

  o Minor bugfixes (continuous integration):
- Skip a pair of unreliable key generation tests on Windows, until
  the underlying issue in bug 26076 is resolved. Fixes bug 26830 and
  bug 26853; bugfix on 0.2.7.3-rc and 0.3.2.1-alpha respectively.

  o Minor bugfixes (directory authority):
- When voting for recommended versions, make sure that all of the
  versions are well-formed and parsable. Fixes bug 26485; bugfix
  on 0.1.1.6-alpha.

   o Minor bugfixes (compilation):
- Update build system so that tor builds again with --disable-unittests
  after recent refactoring. Fixes bug 26789; bugfix on 0.3.4.3-alpha.

  o Minor bugfixes (logging):
- Improve the log message when connection initiators fail to
  authenticate direct connections to relays. Fixes bug 26927; bugfix
  on 0.3.0.1-alpha.

  o Minor bugfixes (portability):
- Work around two different bugs in the OS X 10.10 and later SDKs
  that would prevent us from successfully targeting earlier versions
  of OS X. Fixes bug 26876; bugfix on 0.3.3.1-alpha.

  o Minor bugfixes (single onion services, Tor2web):
- Log a protocol warning when single onion services or Tor2web
  clients fail to authenticate direct connections to relays. Fixes
  bug 26924; bugfix on 0.2.9.1-alpha.

  o Minor bugfixes (testing):
- Disable core dumps in test_bt.sh, to avoid failures in "make
  distcheck". Fixes bug 26787; bugfix on 0.2.5.2-alpha.

  o Minor bugfixes (v3 onion services):
- Stop sending ed25519 link specifiers in v3 onion service introduce
  cells and descriptors, when the rendezvous or introduction point
  doesn't support ed25519 link authentication. Fixes bug 26627;
  bugfix on 0.3.2.4-alpha.

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Firewall setting in Tor Browser not working?

[Roger Dingledine]

On Wed, Aug 01, 2018 at 04:06:27PM +0200, Cristian Consonni wrote:
> I have a couple of questions about the "Tor Network settings" in Tor
> browser.
> 
> Tor browser can be configure to use bridges and/or pluggable transport
> if needed. However it may happen that these PT are exposed on port that
> cannot be reached from behind company/university restrictive firewalls.
> 
> In the Tor Network settings (clicking on the onion icon) I see that
> there is an option that says "This computer goes through a firewall that
> only allows connections to certain ports", this option is not available
> when ou click on the "Configure" button when you want to configure a
> connection when Tor is starting up.
>[...]
> My first question is: why there is this difference?

Hm! I think this is a bug. It should probably both be like the simpler
interface.

Turns out there is this ticket open for fixing it:
https://trac.torproject.org/24452

You can find the reasoning for simplifying the interface on this ticket:
https://trac.torproject.org/11405#comment:7

And you can read a similar thread to yours here:
https://lists.torproject.org/pipermail/tor-dev/2018-July/thread.html#13270

> The second question is about how this setting work.
> Here's my scenario, born out of testing a bridge with pluggable
> transport [1]:
> * I start Tor browser normally
> * I go to "Tor Network settings" and I put in my bridge with plugglable
> transport
> * I enable the firewall setting indicating to go through ports 80,443
> (default value)
> 
> with this configuration Tor Browser does not work.

Restricting your outgoing ports to 80,443 means that your Tor won't
attempt to connect to anything that isn't on port 80 or port 443.

So if your PT bridge is listening on some other port than 80 or 443, Tor
will choose not to try connecting to it, since that's what you asked for.

And if that is indeed what happened here, I think it is a further argument
in favor of simplifying the interface rather than sticking with the
current confusing one. :)

Thanks,
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] How do tor users get past the recapacha and it's super short 2min exemption

[Roger Dingledine]

On Tue, Jul 10, 2018 at 06:44:26PM -0700, Mirimir wrote:
>  For example, how did Facebook come around to have an
> onion? Was it just that Alec Muffett championed it? Did complaints from
> excluded users play a role? Positive or negative?

They did some internal measurements and realized that the number of
people connecting to Facebook over Tor was growing and had become huge:
https://www.facebook.com/notes/facebook-over-tor/1-million-people-use-facebook-over-tor/865624066877648/

To put that into context, that means something like 1 out of every 1000
Facebook users connected to Facebook over Tor in the month of April 2016.

And see also "part one" of
https://blog.torproject.org/facebook-hidden-services-and-https-certs

So yes, they needed an internal champion to get them to do the
measurements, but after that the measurements spoke for themselves.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Cannot access tor onion sites via FF

[Roger Dingledine]

On Sun, Jul 08, 2018 at 06:35:40PM -0400, David Niklas wrote:
> 2. Where is the source code?

Building Tor Browser is ugly because of another critical feature that
it provides: reproducible, aka deterministic, builds. You can read more
about that feature here:
https://reproducible-builds.org/
and then if you want to build it yourself (it won't be easy), start at
https://gitweb.torproject.org/builders/tor-browser-build.git/tree/README

But in terms of just the source code changes (from the various Firefox
releases), check out
https://gitweb.torproject.org/tor-browser.git/
e.g.
https://gitweb.torproject.org/tor-browser.git/log/?h=tor-browser-60.1.0esr-8.0-1

> 3. Noscript is a poor man's privacy protector. I use scriptsafe. It has
> many JS fingerprinting protections. And yes, many sites do require JS. I
> block as much as possible by default.

One of the goals of Tor Browser is that Tor Browser users should blend
together as much as possible. So if you run javascript here and here
and here but not there and there and there, then this unique set of
configuration choices acts like a cookie for recognizing you. That's
why there's a security slider, to disable functionality in chunks so
that we don't splinter the anonymity sets too much.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Cannot access tor onion sites via FF

[Roger Dingledine]

On Sat, Jul 07, 2018 at 11:19:49PM -0400, David Niklas wrote:
> Hello,
> I'm running firefox 61.0.1. I am trying to access the media outlet
> defcon's onion site. https://media.defcon.org/ points me to:
> http://m6rqq6kocsyugo2laitup5nn32bwm3lh677chuodjfmggczoafzwfcad.onion/
> 
> I have network.dns.blockDotOnion false
> network.http.referer.hideOnionSource true and
> network.proxy.socks_remote_dns true.
> Tor's https://check.torproject.org/ reports that I am using tor.

You should first be aware that the right way to do what you want is to
use Tor Browser. Using any other browser with Tor is likely to not
provide the same behavior, protections, etc:
https://www.torproject.org/projects/torbrowser/design/

So if you have a great reason to not use Tor Browser, ok, but you are
in expert mode territory. :)

> This: http://www.idnxcnkne4qt76tg.onion/ is said to be the tor projects
> home page which times out. Defcon's address returns "Unable to connect"
> without any perceptible delay.

This could be explained by a lot of things. My first thought is that the
version of Tor you have is old, so it doesn't know about v3 onion service
names (the longer safer kind). And my first suggestion for fixing it is
to use Tor Browser.

Hope that helps,
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Who controls Tor's DNS Traffic?

[Roger Dingledine]

On Fri, May 11, 2018 at 03:08:54AM +0500, Roman Mamedov wrote:
> "Level 3" on the charts is most likely the notorious 4.2.2.2...4.2.2.6.
> Those absolutely should not be used, aside from all the other reasons outlined
> in the article, they also hijack NXDOMAIN results for monetization of the 
> user.

For this particular issue, Tor has a feature where it tries to resolve a
few nonsense domains, and if they work, it remembers the IP addresses that
were returned, and whenever it sees those, it treats them as NXDOMAIN.

https://gitweb.torproject.org/tor.git/tree/src/or/dns.c?h=tor-0.3.3.5-rc#n1771

So I agree that DNS resolvers that try to sell you encyclopedias are
evil, but also Tor has some rudimentary defenses against them. :)

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor 4

[Roger Dingledine]

On Sun, Mar 18, 2018 at 07:40:01AM -0400, Wanderingnet wrote:
> 'Do it yourself' is in my view one of the astounding problems with Linux and 
> the anon-sec issue.

Dear Wanderingnet,

Please consider that there are many thousands of people on this list,
and while a variety of discussion topics are in-scope, people are more
likely to view your posts positively if you limit your volume.

Mailing lists are tough ways to interact these days (they were always
difficult to use well, but the difference these days is that fewer
people have experience using them well), so we all need to do our part
to keep the signal-to-noise ratio high.

Thanks,
--Roger


-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] catastrophe: ip-api.com sees me

[Roger Dingledine]

On Mon, Jan 29, 2018 at 12:38:32PM +0200, Anon Hyde wrote:
> ip-api.com sees me, it means not only one
> Why he sees my ip in the Chrome and Opera, but under TBB does not
> What is the matter?!!

Nothing is the matter, and everything sounds like it's working as
intended?

Using any browser with Tor besides Tor Browser is usually a bad idea:
https://www.torproject.org/docs/faq#TBBOtherBrowser

You can read more about all the fixes in Tor Browser here:
https://www.torproject.org/projects/torbrowser/design/

Chrome, Opera, and others all have bugs that allow a website to route
traffic around the configured proxy -- and in some cases allow a website
to bypass VPNs too.

Stay safe out there,
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Using a public relay as a bridge?

[Roger Dingledine]

On Fri, Jan 12, 2018 at 04:25:58PM +0100, Marco Gruß wrote:
> the other day I just for the fun of it tried using a public
> relay as a non-obfuscated bridge - it actually works.

There are actually still some subtle bugs, e.g.
https://trac.torproject.org/1776
(I know it's closed, but I think that's just as because it is a
rarely used configuration, not because it's actually fixed)
https://trac.torproject.org/2998
and my most recent favorite,
https://trac.torproject.org/20531

So, it mostly works, but if you want this behavior, it is much better
to set your EntryNodes option to the relay you want to use.

> Curious: Would be using a public relay I implicitly trust
> (operated by a friend, operated by me, operated by the NSA)
> as a bridge be a good or a bad idea?

It depends! If you know they're safe to use, yes it's better to use
a trusted node as your first hop. Except, if the adversary guesses
that you think they're safe to use, then no it's worse, because what
if they run some middle relays and try to draw conclusions about the
circuits they see coming from your favorite relay. Also, even if you
totally trust the relay, you need to consider the network in between
your current location and that relay. Traffic routing can be surprising,
e.g. on the route from Bolivia to Brazil you might go through Miami.

For an entire paper on this topic (spoiler: it doesn't give you a concrete
answer either), check out
https://www.freehaven.net/anonbib/#ccs2011-trust

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] some websites are blocking me now

[Roger Dingledine]

On Mon, Jan 08, 2018 at 03:25:09PM -0800, jbclem wrote:
> Since I started using Tor browser I can't reach certain websites.  
> www.craigslist.org is a good example.  I get an error message that "this ip 
> has been automatically blocked".  
> 
> I wonder if using Tor is causing this, or if I've been assigned an ip address 
> that is unacceptable to these websites?  And how can I get Tor to change the 
> ip address so I can test with a different one...any thoughts on this problem?

Check out this blog post for a good start to the issue:

https://blog.torproject.org/call-arms-helping-internet-services-accept-anonymous-users

Craigslist's business model is basically to have a proprietary data set
that its users can interact with but that its competitors can't get. So
they're stuck being scared of the Internet and blocking connections from
anyplace that yelp, tripadvisor, etc might use to fetch their secrets.

As for getting Tor to switch circuits, Tor Browser has a "New Tor
Circuit for this Site" option (click the little green onion). But
for sites like Craiglist, moving to a new circuit will rarely help.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] CCC self-organised session - Tor research presentation

[Roger Dingledine]

On Thu, Dec 28, 2017 at 07:39:42PM +0200, Andre Wingor wrote:
> On 12/28/17, COLLIER Ben  wrote:
> > initial findings from my sociological research on Tor at a self-organised
> 
> so it is easy to recover all secret users of !
> good try, officer Ben

Hello angry person who fears science,

This is not a productive or helpful response here. It certainly doesn't
help other people think that this list is a productive or helpful space.

The research world has been critical for Tor, both in understanding
attacks and in helping to design a stronger system:
https://blog.torproject.org/tor-heart-pets-and-privacy-research-community

and while these social science approaches to studying Tor as a community
are not quite the same, they still don't deserve that response.

Please keep it not just civil but also productive,
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] What is mean "Guard context default"

[Roger Dingledine]

On Sat, Nov 04, 2017 at 04:32:48PM +0200, Andre Wingor wrote:
> I'm under harassment, always under watching. At several year I have
> accumulated a collection of bad (aggressive) tor hosts and networks.I
> append those to torrc
> https://goo.gl/XKdEoT (google docs)

You're probably not doing yourself any favors by building a huge list of
addresses that you do and don't want to use. Tor does indeed have a lot
of config knobs you can turn, but you're probably not helping yourself
by this kind of setup.

> It always worked, but today it broke. I can't change first gateway
> (5.189.164.230) despite the fact that it is explicitly prohibited by
> the ExcludeExitNodes rule (forbidden all 5.0.0.0/8).

Tor circuits typically consist of three relays. The first is your
guard (what I think you call the 'first gateway'), and the last is
your exit. The ExcludeExitNodes config option does not affect your
guard choice.

> It's a hostile host-agent. It turn up my requests through a hostile territory.

Part of the strength of Tor is the variety of possible points your traffic
might traverse, which makes it hard for an attacker to predict where on
the Internet they need to watch.

But more importantly here, it is very unlikely that your entry guard is
deciding what exit to use for you.

> https://goo.gl/sbWMTo (png image)
> Why the ExcludeExitNodes is not working and what is a simple way for
> reliably control that?

Well, first of all, the exit relays that you think are in the Ukraine
are not in the Ukraine. One is in Germany:
https://atlas.torproject.org/#details/AF8A3EE078EB81338461F178DBE5CA7E62566FCE
And another is in Sweden:
https://atlas.torproject.org/#search/193.15.16.4

Google is mistaken about where these IP addresses are:
https://lists.torproject.org/pipermail/tor-talk/2017-June/043269.html

But second of all, maybe I'm misreading it, but do I see in your gmail
history that you're logging in via Chrome? If you're at all under threat,
using Chrome rather than Tor Browser is a terrible move:
https://www.torproject.org/projects/torbrowser/design/

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] [tor-announce] Tor Browser 7.0.9 is released

[Roger Dingledine]

On Fri, Nov 03, 2017 at 08:47:51PM +0100, Nicolas Vigier wrote:
> Note: Tor Browser 7.0.9 is a security bugfix release for macOS and
> Linux users only. Users on Windows are not affected and stay on Tor
> Browser 7.0.8.
>[...]
> The bug got reported to us on Thursday, October 26, by Filippo Cavallarin.

Thanks again to Filippo Cavallarin for reporting this one to us!

I know that security researchers have a choice about where they can send
their bug reports, and some of the huge evil corporations pay pretty
well, so we should all applaud "We Are Segment" for choosing the path
that makes the world a safer place, rather than a less safe place.

Here is a link to their page about it:
https://www.wearesegment.com/research/tormoil-torbrowser-unspecified-critical-security-vulnerability/

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Ongoing client problem

[Roger Dingledine]

On Sun, Oct 29, 2017 at 06:48:00PM +, George wrote:
> The route to determining the issue probably comes down to this error:
> 
> Oct 29 12:50:06.000 [info] onion_skin_ntor_client_handshake(): Invalid
> result from curve25519 handshake: 4

Right. That message comes when you tried to do a circuit-level handshake
with a relay, but you were using the wrong onion key for it.

> ... but let me take a poke and ask if your time is synchronized?

A fine question. My first guess is that somehow your Tor client is trying
to build circuits using obsolete directory information.

Another more distant option is that you (or your platform) have hacked
together your own curve25519 implementation and it's not working right
for you.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Need a stable .onion address hosted by the Tor project.

[Roger Dingledine]

On Wed, Oct 25, 2017 at 07:22:18PM +0200, Rob van der Hoeven wrote:
> > Keep in mind the false positives caused by crappy networks that just
> > resolve _all_ domains and then serve ads, a captive portal, etc. on
> > whatever IP address. Checking the https://check.torproject.org/api/ip
> > response body seems like it would be safer.
> > 
> 
> A normal DNS server will not be able to resolve an onion address
> undetected.
> 
> My program uses the transparent proxy provided by the Tor daemon which
> resolves an onion address to an address in a non routable address
> range. 
> 
> If the DNS server returns an address outside the VirtualAddrNetworkIPv4
> range, I know that something is wrong...

This is a good example of why "testing your local Tor configuration by
making a request out to the network" is a fragile approach. In this case,
a local attacker who knows the algorithm could respond to .onion dns
requests with an IP address in a range that makes your program think
everything is correct even when it's not.

Another problem with the approach, which might not seem like a big deal
now but has historically turned into a big deal in a surprising way,
is that users of your tool will always start out doing some specific
network activity, which immediately sets them apart from other users.
For example, if your tool hits the Facebook onion on startup, and then
the user actually visits the Facebook onion soon after, will there be
ways for Facebook to link the two visits together, and draw a conclusion
about whether the user who just logged into Facebook is using your tool?

I think the more stable answer long term is not to try to have some
resource always available on the Internet, but rather to change the
design of your checks so that they are correctly checking, locally,
whether your requests are making it to the Tor client as expected.

Tor Browser went through exactly this evolution: we used to have Tor
Browser hit check.torproject.org at startup, so the user could make sure
everything is ok. That approach led to a series of small miseries, where
the website would get overloaded, or a small fraction of requests would
end up with false negatives (since tordnsel, which feeds check.tp.o, is
not perfect).

The better approach turned out to be teaching Tor Launcher about the
Tor control interface, and then it can connect and see for itself (via
controller events) that its connections are indeed arriving at the local
Tor client. No actual network traffic needs to be generated.

In fact, in the distant past we had a special-purpose domain (like .onion)
in Tor named ".noconnect", which could be used for exactly this "try it
and check that it worked" purpose:
https://spec.torproject.org/address-spec
We removed that special-purpose domain though, right around the time we
disabled the ".exit" domain by default too -- there were too many cool
tricks that websites could do to manipulate your path selection.

I believe the eventual strategy that Tor Launcher settled upon was to
arrange so it was not possible to configure Tor Browser in any other
way besides sending its traffic through Tor. That approach was better
for usability *and* (thus) better for security.

Hope that helps,
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Why Tor can't load on my Linux?

[Roger Dingledine]

On Tue, Oct 10, 2017 at 01:38:23PM -0400, grarpamp wrote:
> Seems like either unset/remove "DisableNetwork" in your torrc,

It is definitely not this.

Tor Browser uses DisableNetwork when it first starts to make sure that
your Tor doesn't try to interact with the network before you've selected
'connect directly' or 'I want to use bridges'. Otherwise your Tor goes out
and does "hello I am a Tor user!" behavior on the network when it starts,
and maybe you wanted to use a bridge to be more subtle on the network.

> or remove all tor and tor browser from your system
> and reinstall their current version, and if possible, temporarily skip
> using obfs4 to test without it, unless you need it.

It is true: "my obfs4 bridges don't work" either means that you need
fresh obfs4 bridges, or something else is firewalling you or otherwise
wrong with your network connection.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Multiplexing TCP streams within a circuit similar to EWMA

[Roger Dingledine]

On Thu, Oct 05, 2017 at 03:18:07PM +0300, Yasir Al-Agl wrote:
> I've been working for some time on Tor multiplexing and circuit scheduling
> from a security perspective. I stumbled across the great work of Tang and
> Goldberg and their implementation of EWMA (2010), and while their main
> purpose was performance enhancement, it produced a certain level of
> randomness to circuit scheduling.

Be sure to check out the KIST papers too!

https://www.freehaven.net/anonbib/#jansen14-kist
https://arxiv.org/abs/1709.01044

>  I also experimented this and concluded that Tor will push the
> GET requests to the circuit queue (encapsulated in Tor cells) as they are
> received from the browser. This indicates that the order of which streams
> appear in a circuit queue, is primary controlled by the used browser.

Makes sense.

In fact, check out the hack that Mike Perry introduced to Tor Browser
to randomize the order of fetching things, with the goal of screwing up
website fingerprinting.

https://blog.torproject.org/experimental-defense-website-traffic-fingerprinting
https://trac.torproject.org/projects/tor/ticket/3914

I think Tor Browser still includes this feature. But I also think most
of the WF researchers have concluded that, at least as currently built,
it doesn't do much.

> Any idea why the algorithm is failing when the number of resources
> increases beyond four?

There are a bunch of tickets on stream level fairness, some closed
and some still open.

https://bugs.torproject.org/1298
https://bugs.torproject.org/1937
https://bugs.torproject.org/2179
https://bugs.torproject.org/2180

Hopefully these are all useful directions to explore,
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] "the bad Tor like CP or drugs"

[Roger Dingledine]

On Sun, Sep 17, 2017 at 10:08:54PM -0400, Random User wrote:
> Take the example of a photo of a child

I also set the "moderated" bit on this person. Please take your
dog whistles elsewhere. This is not what Tor is for or about.

Sorry for the distraction everyone.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] can't connect data bases and scientific journals

[Roger Dingledine]

On Fri, Sep 15, 2017 at 04:24:45PM -0400, Benjamin Sullivan wrote:
> I have breaking news

Sorry for the disturbance everybody. This person is off-topic
for tor-talk, and I have set the person's "moderated" bit. (A good
thing too, since it caught a half dozen further emails before they
made it out to all of you.)

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] "recently-used.xbel" file in TBB directory, stores data on accessed, downloaded files

[Roger Dingledine]

On Mon, Sep 18, 2017 at 01:34:49PM -0500, Joe Btfsplk wrote:
> Why is there a *"recently-used.xbel"*, file in my Tor Browser installation
> directory - in path shown and  labeled as file TYPE: "XBEL bookmarks"
> recording ACTUAL local file names, dates, times - they were accessed AND
> some DOWNLOADED files (like *.pdf) with dates and times?
> ~/.torbrowser/torbrowser-7.0/tor-browser_en-US/Browser/.local/share/recently-used.xbel.
> *TBB is installed in home directory: ~/.torbrowser.*

I asked Georg about this, and he pointed to this ticket:
https://bugs.torproject.org/8706

So yes, it looks like it's a real issue, and people should probably
help make progress on the ticket.

Thanks,
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Advertised Bandwidth in tor atlas

[Roger Dingledine]

On Sun, Sep 17, 2017 at 06:36:12PM +0200, tor-l...@jluehr.de wrote:
> I'm running
> https://atlas.torproject.org/#details/D91F0F2683A264D8A6FDA7736D75FBC327F3F4F5
> 
> Atlas shows, that the advertised bandwidth is around 54 KiB/s.
> 
> The machine is running in a data center (hetzner) having:
> 
> RelayBandwidthRate 7000 KB  # Throttle traffic to 7000B/s (56Mbps)
> RelayBandwidthBurst 8000 KB # But allow bursts up to 8000KB/s (64Mbps).
> 
> Do you know why atlas is showing 54 KiB/s, only?

Thanks for wanting to run a bridge!

The short answer is that your bridge is not seeing much use. Bridge
addresses are given out to users who need them based on a variety of
distribution strategies, and each distribution strategy tries to pick
a different point on the "easy for users to find" vs "hard for censors
to find" spectrum. So some bridges are given out to many people, but
they end up blocked quickly in China; whereas other bridges are not
given out to many people, but also they aren't blocked as quickly.

At least, that's the theory -- in practice, unless you are offering the
obfs4 pluggable transport too (and it looks like you're not), your bridge
will get blocked quickly in China anyway, and most other countries right
now are able to reach the Tor network without needing bridges at all.

Perhaps you want to switch your bridge to being a normal public relay,
since it has quite a bit of bandwidth? See also
https://www.torproject.org/docs/faq#RelayOrBridge
and
https://www.torproject.org/docs/faq#ExitPolicies

And lastly, in the future this question will get a more consistent
response on the tor-relays list:
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Thanks!
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor users in US up by nearly 100,000 this month

[Roger Dingledine]

On Fri, Sep 01, 2017 at 08:08:30PM -0700, Seth David Schoen wrote:
> I'd be happy to ask CloudFlare if they'd be willing to share this data
> (maybe in relative rather than absolute numeric terms, like "the number
> of people successfully completing a CAPTCHA per day from a Tor exit
> node on September 1, 2017 is x% of what it was on January 1, 2016").

If you're thinking in that direction, I would suggest asking Akamai
instead. The question is "how many people are connecting from known Tor
IP addresses to your sites?"

Asking Cloudflare how many people are deciding to solve their captchas
today is measuring a different thing -- if I try to load a news article,
see a cloudflare captcha, and say "aw, fuck cloudflare, oh well" and
move on, am I a bot?

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Neal Krawetz's abcission proposal, and Tor's reputation

[Roger Dingledine]

On Wed, Aug 30, 2017 at 03:07:37PM +0100, Ben Tasker wrote:
> So his suggestion is portrayed as not sacrificing much, but actually
> sacrifices quite a lot.

This is a really important point. Thinking of onion space right now as
the sum total of all that it can be is cutting off all of the future
innovation.

My claim isn't "onion services are 3% of Tor traffic, so don't get
upset about anything you find on an onion service" -- my claim is "onion
services are still very early in terms of adoption, and as is usual for
many decentralized techologies the extra-early adopters are not great use
cases, and that means we need to help the space grow, and as it grows,
if we do it right, it will become more broad and thus more good".

One concrete example of an onion service that the proposed design would
cut off is Ricochet. Ricochet users want longterm-stable identifiers,
and they want the identifiers to be self-authenticating. And of course
making every Ricochet user register and maintain a domain, plus run a
webserver, is both silly and harmful.

This example also helps to illustrate why thinking of onion services as
only websites also artificially constrains their future. What if your
smart refridgerator registers an onion address when you first plug it
in, and it's only willing to receive secure updates via that channel,
meaning it has a hugely reduced surface area to attacks?

As Alec says, the list of "things that could benefit from having a safe
communication channel" is both enormous and open-ended. People like to
use phrases like "dark web" or "dark continent" to evoke mystery and
intrigue, but really, do you want to use the communications channel where
you know for sure that you're talking to the person you meant to talk
to, and you know that it's hard for somebody to eavesdrop on the content
or the metadata? Or do you want to use the communications channel where
you don't know who you're talking to, you don't know who is listening,
and you don't know whether somebody is modifying the traffic?

Calling onion services the "secure web" and everything else the "insecure
web" isn't very catchy, so maybe we should settle on calling everything
else (the places where you don't know who you're talking to or who's
listening) "dark". :)

For those following along who haven't watched our 32c3 onion services
talk, you might find it enlightening:
https://media.ccc.de/v/32c3-7322-tor_onion_services_more_useful_than_you_think
(The Defcon talk has a few more details about the next-generation onion
service design, but I'm told the video for it won't be up for another
couple of months.)

I think finding ways to tie onion addresses to normal ("insecure web")
domains, when a service has both, is really important too. I'd like to
live in a world where Let's Encrypt gives you an onion altname in your
https cert by default, and spins up a Tor client by default to let users
reach your webserver using whichever level of security they prefer.

And for those who made it this far down the mail, you might enjoy this
historical tor-talk mail too:
https://lists.torproject.org/pipermail/tor-talk/2015-April/037538.html
(see the paragraph towards the bottom that starts "I should also make
clear my opinion on some of the bad uses of Tor.")

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] TBB User Agent - how decided?

[Roger Dingledine]

On Sat, Aug 26, 2017 at 04:57:45PM -, blo...@openmailbox.org wrote:
> How did TBB project people decide on the user agent which is:
> 
> Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0
> 
> Panopticlick shows 1 in 30 browsers use it. I assume it's the most generic at 
> this moment?

Tor Browser aims to make all the Tor Browser users look the same. That
is, the goal is to blend in with the other Tor users.

The goal *isn't* to blend in with "everything else using the Internet",
since that's a much harder goal.

See also the discussions in
https://tor.stackexchange.com/questions/11701/most-common-tor-browser-configuration-panopticlick

And see item 5 in the list under
https://www.torproject.org/projects/torbrowser/design/#fingerprinting-linkability

This question comes up every time there's a new Tor Browser release,
because somebody rushes to Panopticlick, finds that nobody else is using
the new Tor Browser version yet, and becomes concerned.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] MTor (multicast tor), is it going to be released?

[Roger Dingledine]

On Mon, Aug 21, 2017 at 11:49:22PM -0700, Yuri wrote:
> Here is the white paper with MTor design: 
> https://www.degruyter.com/downloadpdf/j/popets.2015.2016.issue-2/popets-2016-0003/popets-2016-0003.pdf
> 
> And here is an implementation based on tor-0.2.3.25:
> https://github.com/multicastTor/multicastTor/tree/master/shadow/build/tor
> 
> But ChangeLog doesn't mention it, and there are no mentions of it on
> torproject.org.
> 
> So, what is MTor's status?

It's the standard story -- it's a research paper written by a research
group to show a concept, and then they moved on.

There is some code, but it was enough to do performance graphs, not
anything that they intended actual users to (be able to) use.

I don't remember the design in detail, but I remember based on the talk
at PETS thinking that they had really changed the threat model for Tor
to something much weaker, in exchange for better scalability in some
situations.

So, it is a fine idea to read about, and maybe it will spark some new
ideas when you read it, but it is not an obvious improvement for Tor in
terms of security, and also it was never intended to be an actual patch
that users could use.

All of that said, don't misunderstand me: yay research! If you haven't
read this blog post, check it out:
https://blog.torproject.org/blog/tor-heart-pets-and-privacy-research-community

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Is DNS required to connect to an entry node?

[Roger Dingledine]

On Thu, Aug 17, 2017 at 11:02:54PM +0200, Aeris wrote:
> > Every time you enter a URL in the browser address line, your browser
> > requests the IP address of that URL from the DNS server.  You can
> > instead enter the IP address yourself along with the webpage requested.
> > You could also just make your own entry in a HOSTS file if you know how
> > to do it.  Caveat, do not mess with HOSTS unless you know what you are
> > doing!
> 
> But for Tor nodes, Tor client doesn't use hostname but IP directly.
> There is no need of DNS, consensus is only IP-based.

Correct -- Tor clients don't do DNS requests of any sort.

For reaching the Tor relays that they want to reach, they just use the
IP address directly.

And when asking the Tor network to connect to, say, indymedia.org for
them, they write "indymedia.org port 443" in a "begin" cell and send it
down the circuit to the exit relay, and it's the exit relay that resolves
it (using its own DNS) and then connects.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Motivations for certificate issues for onion services

[Roger Dingledine]

On Wed, Aug 09, 2017 at 03:53:59PM -0700, Seth David Schoen wrote:
>   There was also
> a long-standard concern about cryptographic strength mismatch in the
> sense that the cryptography used by onion services was weaker than the
> cryptography that's now used in TLS.  (I think this concern was misplaced,
> but I believe it's served as one of the main rationales for distinguishing
> EV from DV.)

Right -- I used to buy their reasoning, thinking "you're right, 1024-bit
RSA is indeed not as good as modern TLS, let's wait for the newer onion
design", but then I realized that they're comparing the *authentication
about whether you control the domain* step. That is, they are saying that
1024-bit RSA is not as strong as unauthenticated DNS and unauthenticated
BGP. Which is just nonsense.

At HotPETS this year we had a live demonstration, right there while
we all watched, of a BGP hijack on the real Internet, which obtained
a Let's Encrypt certificate for the hijacked domain. Piece of cake.
I'd say needing to factor a 1024-bit RSA, or needing to generate 2^80
keys to find one that matches the onion address you're trying to attack,
is still a much much higher bar.

> So, there has been a suggestion that this issue might be revisted with
> the next generation onion services because they have stronger
> cryptographic primitives.

Can you help me understand why this is not just more of the same poor
reasoning? One of the reasons we want to use modern TLS, i.e. get real
HTTPS certs, is to use those stronger cryptographic primitives. Waiting
for the stronger onion names is like saying you shouldn't be able to get
an HTTPS cert because we can't trust the DNS system -- and I don't hear
any of the CA vendors saying that.

>  Apparently these have now been not only
> implemented but actually demonstrated:
> 
> https://blog.torproject.org/blog/new-and-improved-onion-services-will-premiere-def-con-25
> 
> I'd like to prepare to raise this issue with the CA/Browser forum in
> anticipation of a ballot there to have it be possible for DV certificates
> to be issued to onion services.  So I wanted to ask two things here:
> 
> (1) What's the status of onion services looking like now?

The v3 onion service code is in the code review stage. The relay
side and HSDir side have been in place since Tor 0.3.0, and Nick just
merged the service-side code into master last night. There is a branch
("dgoulet/ticket17242_032_02") that implements the client side.

If you grab that branch, build it, and stick the resulting tor binary
into Browser/TorBrowser/Tor/tor in your tor browser, then you'll have
a tor browser which can successfully visit
http://7fa6xlti5joarlmkuhjaifa47ukgcwz6tfndgax45ocyn4rixm632jid.onion/

>  I haven't seen Roger's DEF CON talk.  (Was it recorded?)

It was recorded, and the Defcon people tell me that the video will be
appearing sometime in October or November.

> (2) What reasons do people have for wanting certificates that cover
> onion names?  I think I know of at least three or four reasons, but I'm
> interested in creating a list that's as thorough as possible.

I like Alec's list. Here's the subset of his list I find most compelling:

* We've taught users that https is what they should see in their browser
tab. Browsers are heading towards not letting you do stuff unless the
url says https. We can't, and shouldn't, fight that trend.

* Admins should be able to run their Tor onion service at a different
location than their webserver. "End to end" in onion encryption means
"Tor client to Tor client", but "end to end" in web encryption means
"Browser to Webserver". You should be able to have both. Never forget
the phrase "SSL added and removed here"!

* People who write complicated web services should be able to have very
simple "if it's not https, don't allow it" rules, and asking them to
create an onion-sized hole in their security rules is foolish and harmful.

It seems to me that an onion address, where you actually have a private
key that proves that you "are" the onion address, is a slam dunk for
a Domain Validated (DV) situation. It's exactly what everybody should
have wanted for DV certs from the beginning.

(In fact, technically speaking, there's no particular need to have a
trusted central third party do the validation, since onion domains are
*self* validating. If we made a tool to generate a cert chain using the
onion private key to certify the traditional TLS key, and we taught Tor
Browser how to verify those cert chains... we wouldn't need the sham
that is a DV certificate authority. But that is a different discussion. :)

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] tor 0.3.0.9 release notes

[Roger Dingledine]

On Sat, Jul 22, 2017 at 05:34:49PM +0200, Udo van den Heuvel wrote:
> On 22-07-17 17:25, krishna e bera wrote:
> > On 22/07/17 08:14 AM, Udo van den Heuvel wrote:
> >> Where can I find the tor ReleaseNotes for 0.3.0.9 that actually mention
> >> details about changes in 0.3.0.9?
> > 
> > These?
> > 
> > https://lists.torproject.org/pipermail/tor-announce/2017-June/000133.html
> 
> Thanks!
> These details were not in the ReleaseNotes in my 0.3.0.9 source download.

Good find. It looks like there is an entry in the ChangeLog file in the
tarball, but not a corresponding entry in the ReleaseNotes file.

I've opened a ticket to see if there's some useful way to automate the
check in the future:
https://bugs.torproject.org/23013

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] My ISP, university, etc. just sent me a DMCA notice. What should I do?

[Roger Dingledine]

On Thu, Jul 20, 2017 at 11:19:06PM +, Paul Templeton wrote:
> I got a cold caller email for the TOR mirror I have... 
> 
> >> Hi Paul,
> 
> >>I appreciate you're busy but I just wanted to follow up on the email I sent 
> >>you the other day. I've included a copy below for reference.

It's a standard seo spammer, trying to get you to link to their thing
to boost its pagerank. Nothing to worry about.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Beware of insecure mobile Tor apps such as Orion/Torion

[Roger Dingledine]

On Tue, Jul 18, 2017 at 11:30:44AM -0400, InterN0T wrote:
> The developer basically took Mike Tigas' iOS app and introduced several 
> vulnerabilities to it that could be used to track users

To be clear, right now there are no ios apps that are on par with the
protections that Tor Browser provides.

You can read more about the general issue at
https://blog.torproject.org/blog/tor-heart-onion-browser-and-more-ios-tor

tl;dr you should assume that there are proxy bypass flaws in every
single ios app that aims to be a Tor Browser replacement.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Is the recent growth in Ukrainian users confusing google's geoip?

[Roger Dingledine]

Motivated by a blog post comment:
https://blog.torproject.org/comment/269237#comment-269237

It looks like a growing number of connections from Tor exits are being
treated by Google as being Ukrainian.

Anecdotally, I've experienced it too -- Google news keeps wanting to
give me Ukrainian news.

For those who haven't been paying attention, we got a jump in some
hundreds of thousands of .ua users recently:
https://metrics.torproject.org/userstats-relay-country.html?start=2017-05-01&end=2017-06-18&country=ua&events=off
and it looks like they're really users:
https://bugs.torproject.org/22369

Here's my speculation:

You know how Google's proprietary geoip system is typically better
than Maxmind's, because they data mine the heck out of their traffic,
for example by deciding that the google maps address you ask about most
is probably your home address?

I wonder if a lot of ordinary people doing ordinary things via Tor,
and acting like people in the Ukraine, has tipped Google's sekrit-sauce
machine learning decision trees into labeling those IP addresses as
being in .ua.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Use of TBB behind a physically isolated Tor router?

[Roger Dingledine]

On Sun, May 21, 2017 at 09:50:14PM +, CANNON wrote:
>  Tor browser bundle is generally recommended for privacy due to
> its ability to blend in more with other people by having a
> commonly shared browser fingerprint.

Right. For more on what Tor Browser does (and doesn't do) at the
application layer, see
https://www.torproject.org/projects/torbrowser/design/

>  The issue is however if one wishes to use tor browser bundle
> behind a transparent Tor proxy in which the Tor process is
> running on the router between the computer and LAN for better
> security.

That's one of the reasons why transparent tor proxies are bad
news. For other reasons, check out this thread from long ago:
https://lists.torproject.org/pipermail/tor-relays/2014-October/005541.html
https://lists.torproject.org/pipermail/tor-relays/2014-October/005544.html

>  What is the best way to use Tor browser behind a physically 
> isolated Tor router so to prevent Tor browser running on the 
> computer from creating a Tor circuit inside another circuit?

The best way is to use that router as a firewall, to *prevent* any
communications that you didn't want coming out of the main computer,
rather than to scoop it all up and shove it through Tor and hope that
somehow that makes you safe.

The above posts have more details on how to do that well, and also
on why it's the better model.

(Projects like Whonix offer a variety of configurations for doing this
isolation, rather than building it yourself.)

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Stipends available for the Privacy Enhancing Technologies Symposium

[Roger Dingledine]

Hi tor-talk!

The PETS conference is where all of the academic privacy / anonymity
experts gather each year:
https://petsymposium.org/

This year it's in Minneapolis, July 18-21. Please consider joining us --
and if you do, be sure to stay for the hike on July 22, which is where
many interactions and collaborations move forward.

The list of accepted papers is up (and of course it is open access):
https://petsymposium.org/2017/paperlist.php

Thanks to the generosity of the National Science Foundation and
(hopefully) Ford Foundation, we have stipends available again this year,
to help get people to the symposium:
https://petsymposium.org/2017/stipends.php

The deadline for stipend application is May 31.

We especially want to use the stipends to attract perspectives
and motivations that are different from the usual academic
research-and-publishing crowd. In the past we've had great participation
from people who care about building and deploying the tools (aka hackers
and activists), and from people who care about the societal implications
of the research (aka artists and politicians).

Thanks!
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] A Pluggable Transport based on i2p?

[Roger Dingledine]

On Thu, Mar 16, 2017 at 01:44:06AM +0100, m.aj...@tuta.io wrote:
> I was playing with the SAM protocol of I2Pd. When I typed some control 
> characters by pressing some Ctrl+Alphabet keys in telnet window, the I2Pd on 
> the other side crashed with a seg fault. It really freaked me out.

This concern reminds me of the "criteria for prioritizing pluggable
transports", which started out as this email:
https://lists.torproject.org/pipermail/tor-dev/2013-September/005528.html
and then worked its way into the methodology that Yawning used for
evaluating pluggable transports:
https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/list

There's lots of good reading there!

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] A Pluggable Transport based on i2p?

[Roger Dingledine]

On Wed, Mar 15, 2017 at 06:20:53AM -0400, Lolint wrote:
> Hi,
> 
> Could it be possible to implement a pluggable transport using i2p? The way 
> this could work
> is that a server would function as a bridge node, and will also have the i2p 
> router installed,
> and the client will connect to this bridge via I2P Tunnels,
> 
> <=><=><=><=> onion>
> 
> What do you think?

If somebody wants to build this, that sounds great to me! More options
are always good.

I agree that it could give you somewhat crummy performance, but hey,
that's a tradeoff that users can decide whether to make. Some bandwidth
is a lot better than no bandwidth in some situations.

Jonathan responded with:
> You want to hide the fact that you are using an anonymization network
> by using an anonymization network. This idea seems pretty stupid to me.

But I think that's taking a very narrow view of pluggable transports.
Many people want to use Tor and/or pluggable transports to get around
censorship that otherwise prevents them from reaching the sites they
want to reach.

(Getting around censorship with no security at all is probably a bad
idea -- we keep learning that lesson as people from Iran, Egypt, etc say
"my government is stupid, they don't know how to surveil the Internet,
just let me get to Facebook" and then they realize once it's too late that
maybe they should have had some more security. So the Tor perspective is
that we should give them as many ways to get around censorship, while
getting most of Tor's security properties, as we can, but we shouldn't
help people with insecure approaches.)

That said, one of the side effects of making a successful i2p pluggable
transport would be that censors would have more incentive to censor
i2p connections. Speaking of which, I have no idea if i2p connections
right now are hard or easy to DPI for. But attracting the attention of
Tor's adversaries could speed up the arms race there, which could be a
sad result.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] What is preventing Bridge Enumeration?

[Roger Dingledine]

On Wed, Feb 15, 2017 at 12:10:05PM -0500, Philipp Winter wrote:
> On Wed, Feb 15, 2017 at 02:32:32PM +0100, BVpTuvb AVMV wrote:
> > What is preventing an attacker to start up a few mid-nodes and
> > enumerating all IPs and substracting those from the list of publicly
> > known entry-nodes to get a list of (all) unlisted bridges?
> 
> That is indeed a problem.  Section III.D of the following paper talks
> about the issue in greater detail:
> 

Yep! Another resource to look at is
https://blog.torproject.org/blog/research-problems-ten-ways-discover-tor-bridges

There's plenty of work to be done, both in terms of research and in
terms of engineering, on making the bridge idea better.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Published bridge?

[Roger Dingledine]

On Sun, Feb 05, 2017 at 08:15:07PM +0100, Maxxer wrote:
> A couple of days ago I've set up a new bridge. I've tested it in my config
> and works fine

Great! Thanks for setting up a bridge. :)

>, but I've doubts it's getting published on the bridge
> database.
> 
> I've configured it on both IPv4 and IPv6, I've remotely tested IPv6 and the
> connection is established, but when I query the bridgedb for ipv6 only
> bridges it returns nothing.

Yes, bridgedb divides bridges up into different distribution
strategies, and one of those strategies is to give them out by
https://bridges.torproject.org/. For those bridges, it further divides
them up by where on the Internet you're coming from (for ipv4, it
divides by /16. For ipv6, I don't know what bitmask it picks).

So it is not surprising that you wouldn't find your own bridge on
https://bridges.torproject.org/ -- you are very likely not on an IP
address that would map to your bridge.

> How can I know if the bridge is published correctly?

You can search for your nickname or identity fingerprint on
https://atlas.torproject.org/

If you allow javascript, atlas even sends your browser some javascript
that hashes the fingerprint before your browser sends it to atlas, so
atlas never learns the fingerprint (onionoo only stores a hashed version
of bridge identity fingerprints, since if you know the fingerprint,
you can ask the bridge authority for the bridge descriptor and learn
everything else about it).

(If you don't allow javascript, that's fine too -- you send your actual
bridge identity fingerprint to atlas, which hashes it and then discards
the original.)

> This is the node's torrc:
> ExitPolicy reject *:*
> RunAsDaemon 1
> ORPort 9123
> BridgeRelay 1
> ServerTransportPlugin obfs3,obfs4 exec /usr/local/bin/obfs4proxy
> ServerTransportListenAddr obfs3 [::]:443
> ServerTransportListenAddr obfs4 [::]:80
> ExtORPort auto
> PublishServerDescriptor bridge
> 
> Is everything correct?

It looks promising!

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] TAILS people

[Roger Dingledine]

On Tue, Jan 24, 2017 at 03:44:15PM -0800, I wrote:
> The requested URL /torrents/files/tails-i386-2.10~rc1.torrent was not found 
> on this server.

Probably because you don't want the release candidate.

https://blog.torproject.org/blog/tails-210-out

https://tails.boum.org/install/download/

https://tails.boum.org/torrents/files/tails-i386-2.10.torrent

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Tor 0.3.0.2-alpha is out!

[Roger Dingledine]

(Also, Tor 0.2.9.9 is out. If you didn't know, you should subscribe to
the tor-announce list and/or read the Tor blog!)

Tor 0.3.0.2-alpha fixes a denial-of-service bug where an attacker could
cause relays and clients to crash, even if they were not built with
the --enable-expensive-hardening option. This bug affects all 0.2.9.x
versions, and also affects 0.3.0.1-alpha: all relays running an affected
version should upgrade.

Tor 0.3.0.2-alpha also improves how exit relays and clients handle DNS
time-to-live values, makes directory authorities enforce the 1-to-1
mapping of relay RSA identity keys to ED25519 identity keys, fixes a
client-side onion service reachability bug, does better at selecting
the set of fallback directories, and more.

You can download the source code from https://dist.torproject.org/ but
most users should wait for the upcoming 7.0a Tor Browser alpha release,
or for their upcoming system package updates.

Changes in version 0.3.0.2-alpha - 2017-01-23
  o Major bugfixes (security, also in 0.2.9.9):
- Downgrade the "-ftrapv" option from "always on" to "only on when
  --enable-expensive-hardening is provided." This hardening option,
  like others, can turn survivable bugs into crashes--and having it
  on by default made a (relatively harmless) integer overflow bug
  into a denial-of-service bug. Fixes bug 21278 (TROVE-2017-001);
  bugfix on 0.2.9.1-alpha.

  o Major features (security):
- Change the algorithm used to decide DNS TTLs on client and server
  side, to better resist DNS-based correlation attacks like the
  DefecTor attack of Greschbach, Pulls, Roberts, Winter, and
  Feamster. Now relays only return one of two possible DNS TTL
  values, and clients are willing to believe DNS TTL values up to 3
  hours long. Closes ticket 19769.

  o Major features (directory authority, security):
- The default for AuthDirPinKeys is now 1: directory authorities
  will reject relays where the RSA identity key matches a previously
  seen value, but the Ed25519 key has changed. Closes ticket 18319.

  o Major bugfixes (client, guard, crash):
- In circuit_get_global_origin_list(), return the actual list of
  origin circuits. The previous version of this code returned the
  list of all the circuits, and could have caused strange bugs,
  including possible crashes. Fixes bug 21118; bugfix
  on 0.3.0.1-alpha.

  o Major bugfixes (client, onion service, also in 0.2.9.9):
- Fix a client-side onion service reachability bug, where multiple
  socks requests to an onion service (or a single slow request)
  could cause us to mistakenly mark some of the service's
  introduction points as failed, and we cache that failure so
  eventually we run out and can't reach the service. Also resolves a
  mysterious "Remote server sent bogus reason code 65021" log
  warning. The bug was introduced in ticket 17218, where we tried to
  remember the circuit end reason as a uint16_t, which mangled
  negative values. Partially fixes bug 21056 and fixes bug 20307;
  bugfix on 0.2.8.1-alpha.

  o Major bugfixes (DNS):
- Fix a bug that prevented exit nodes from caching DNS records for
  more than 60 seconds. Fixes bug 19025; bugfix on 0.2.4.7-alpha.

  o Minor features (controller):
- Add "GETINFO sr/current" and "GETINFO sr/previous" keys, to expose
  shared-random values to the controller. Closes ticket 19925.

  o Minor features (entry guards):
- Add UseEntryGuards to TEST_OPTIONS_DEFAULT_VALUES in order to not
  break regression tests.
- Require UseEntryGuards when UseBridges is set, in order to make
  sure bridges aren't bypassed. Resolves ticket 20502.

  o Minor features (fallback directories):
- Select 200 fallback directories for each release. Closes
  ticket 20881.
- Allow 3 fallback relays per operator, which is safe now that we
  are choosing 200 fallback relays. Closes ticket 20912.
- Exclude relays affected by bug 20499 from the fallback list.
  Exclude relays from the fallback list if they are running versions
  known to be affected by bug 20499, or if in our tests they deliver
  a stale consensus (i.e. one that expired more than 24 hours ago).
  Closes ticket 20539.
- Reduce the minimum fallback bandwidth to 1 MByte/s. Part of
  ticket 18828.
- Require fallback directories to have the same address and port for
  7 days (now that we have enough relays with this stability).
  Relays whose OnionOO stability timer is reset on restart by bug
  18050 should upgrade to Tor 0.2.8.7 or later, which has a fix for
  this issue. Closes ticket 20880; maintains short-term fix
  in 0.2.8.2-alpha.
- Require fallbacks to have flags for 90% of the time (weighted
  decaying average), rather than 95%. This allows at least 73% of
  clients to bootstrap in the first 5 seconds without contacting an
  auth

Re: [tor-talk] [GetTor] Simple way of getting Tor countering TorProject.org and its mirrors censorship using the Internet Archive's Wayback Machine

[Roger Dingledine]

On Fri, Jan 06, 2017 at 03:58:53PM -0300, ilv wrote:
> We also trust other providers like 
> Google and Dropbox, so I don't see why we couldn't trust archive.org.

Sounds like a great addition!

I wouldn't want to use that logic to add *any* website, but I think we
like archive.org at least as much as we like Google and Dropbox.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] List of ways to attack Tor

[Roger Dingledine]

On Thu, Jan 05, 2017 at 12:25:20PM +1030, windows95@national.shitposting.agency 
wrote:
> I'm tasked with doing a short report on the ways in which Tor can be
> attacked.
> I've brainstormed and done research for few hours and this is the
> list I've come up with.
> Is there anything big that I've missed?
> I feel I might be a bit light on more technical attacks.

Your list is pretty good, though it could do with some sorting and
some categories. :)

For another interesting set of attacks, see
https://media.torproject.org/video/Defcon16-Roger_Dingledine-Sec_Anonymity_Vulns_in_Tor.m4v
and
https://media.torproject.org/video/2008-12-29-25c3-2977-en-security_and_anonymity_vulnerabilities_in_tor.mp4

These talks are some years old now, but many of the issues the talks
describe are hard to fix well so they remain an issue in some form.

If I were doing your 'short report', I would try to prioritize the various
attacks in terms of how hard they are to perform, and how damaging they
are if performed. You could imagine a two-dimensional graph where various
attacks correspond to a point on the graph.

I would also want to include a short section on how having a big list of
possible attacks does not indicate that it's a weaker system or weaker
design compared to a system or design that has a shorter but scarier list
of attacks. For example, centralized architectures don't need to think
about the more esoteric attacks, because they have the whole dataset of
what users went to which website right in front of them:
https://svn.torproject.org/svn/projects/articles/circumvention-features.html#5

Let us know what you come up with,
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] 33c3 and tor?

[Roger Dingledine]

On Tue, Dec 27, 2016 at 08:35:55PM +0100, x333 x333 wrote:
> > Julius reserved a workshop room for us on day 2, from 21:30 to 23:00,
> > in Hall B:
> >
> > https://events.ccc.de/congress/2016/wiki/Session:Tor
> 
> Why did you choose to make it at the same time as phw's censorship talk takes 
> place?
> 
> https://fahrplan.events.ccc.de/congress/2016/Fahrplan/events/8068.html

We didn't: their talk is 20:30 to 21:30.

(We actually first scheduled it for 21:00 to 23:00, because the Fahrplan
wasn't out yet. When the Fahrplan came out, we noticed the conflict and
cut off the first 30 minutes of the workshop.)

So, go to the censorship talk, and then come to the workshop!

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] 33c3 and tor?

[Roger Dingledine]

On Tue, Dec 20, 2016 at 02:37:19PM +0100, fatal wrote:
> And will there be a tor relay operators meetup?

Julius reserved a workshop room for us on day 2, from 21:30 to 23:00,
in Hall B:

https://events.ccc.de/congress/2016/wiki/Session:Tor

So you should feel free to come by and we'll talk about whatever you
want to talk about. Depending on how many people there are, we might
break into groups based on interests.

I think there is no separate relay operators meeting, so relay
operators are welcome in this workshop space too.

Many Tor people will be hanging out in the tea room at other times
as well.

I hope to see many of you there! :)

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Mirai Botnet Relocates To Onions

[Roger Dingledine]

On Sat, Dec 17, 2016 at 10:59:37PM -0700, Mirimir wrote:
> > "Try to shut down .onion 'domains' over Tor," he boasted, knowing that
> > nobody can.
> 
> OK. However, it's not hard to scan for connections to Tor servers. And
> you don't expect them for random devices. But maybe Mirai is setup to
> use bridges.

Yuck. The 2013 botnet operator from Ukraine apparently stopped using Tor
for controlling his bots (they were doing ad click fraud), because he
attracted way more attention signing them all up to Tor than they had
attracted before, and in the end he decided it wasn't worth it.

For a while I've been trying to figure out how to share his lesson with
other botnet operators around the world. The western journalists are alas
super excited to talk about how amazing and brilliant and insightful the
idea is to move your botnet over to Tor, and if some new botnet operator
only reads those stories, they won't get an accurate impression. :(

(Keep an eye on the user graph on the metrics page, because there's a good
chance that this story is nonsense and the graph won't change at all.)

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] How to unsubscribe (was Re: confusion over verification instructions for build verification on Mac OS X)

[Roger Dingledine]

On Tue, Dec 13, 2016 at 04:33:16AM +, Jedd Casella wrote:
> unsubscribe
>[...]
> tor-talk mailing list - tor-talk@lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

These instructions are at the bottom of every post to the list.

They are the right way to unsubscribe from the list.

(See close to the bottom where it says "To unsubscribe from tor-talk, ...")

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Ahmia search engine works normally again

[Roger Dingledine]

On Thu, Dec 08, 2016 at 02:06:30PM -0500, scfith riseup wrote:
> First, not sure why you want to list .onion domains. The key here is that 
> they are HIDDEN services. But I am sure you have reasons.

Actually, that's part of the reason for the shift into calling them
"onion services" -- many people offer onion addresses for their website
or service because of the many other security properties they offer,
and not because they want to hide the existence or location of the Tor
client offering it.

If you're in the "wait, they're supposed to be hidden, I don't understand"
camp, I encourage you to watch our CCC talk from last year:
https://media.ccc.de/v/32c3-7322-tor_onion_services_more_useful_than_you_think

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Javascript exploit

[Roger Dingledine]

On Wed, Nov 30, 2016 at 02:28:52PM -0500, Roger Dingledine wrote:
> * The blog post about the 6.0.7 Tor Browser update will go up any
> moment. I see that the Tor Browser team has already put the packages in
> https://dist.torproject.org/torbrowser/6.0.7/

And there it is:
https://blog.torproject.org/blog/tor-browser-607-released

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Javascript exploit

[Roger Dingledine]

On Wed, Nov 30, 2016 at 12:08:00PM +, Georg Koppen wrote:
> FWIW: We plan to release 6.0.7 with the patch Mozilla developed in a
> couple of hours. Updates to the alpha and hardened series will we
> provided as well thereafter.

Update:

* The blog post about the 6.0.7 Tor Browser update will go up any
moment. I see that the Tor Browser team has already put the packages in
https://dist.torproject.org/torbrowser/6.0.7/

* It looks like the vulnerability was in Firefox's SVG animation, so the
exploit does not work unless you have both svg and javascript enabled.
The "high" setting of Tor Browser's security slider disables both of
these pieces of the browser.

* It looks like the exploit code went up on pastebin on Monday morning,
and Mozilla worked on a patch yesterday, and updates to Firefox and
Tor Browser and Tails are coming out today. The exploit only worked on
Windows, but the vulnerability exists for Windows, OS X, and Linux.

In the meantime, if you slide your security slider to high, you won't
be vulnerable to this issue.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Javascript exploit

[Roger Dingledine]

On Tue, Nov 29, 2016 at 09:55:23PM -, firstwa...@sigaint.org wrote:
> This is an Javascript exploit

Thanks. I pointed some folks on irc to this mail, and Daniel Veditz
(Mozilla Security Team) said "the Firefox team was sent a copy of that
this morning. We've found the bug being used and are working on a patch."

So it sounds like the immediate next step is that Mozilla finishes their
patch for it; then the step after that is a quick Tor Browser update. And
somewhere in there people will look at the bug and see whether they
think it really does apply to Tor Browser.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Will Quantum computing be the end of Tor and all Privacy?

[Roger Dingledine]

On Mon, Nov 28, 2016 at 05:44:15PM +0100, Flipchan wrote:
> I dont think so, quantum 4times at fast so we just need to generate 4times as 
> strong keys the entropy will just be bigger, But as Long as we are not useing 
> like 56 bit des keys its okey

No, it's way more complicated than this.

The main area where we want to become quantum-resistant is in the circuit
level handshake. Once we've got that one sorted out, the rest of the
places we use crypto are not as important.

See
https://gitweb.torproject.org/torspec.git/tree/proposals/269-hybrid-handshake.txt
and
https://gitweb.torproject.org/torspec.git/tree/proposals/270-newhope-hybrid-handshake.txt
to get up to speed on this topic.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Orbot control port

[Roger Dingledine]

On Sun, Nov 13, 2016 at 08:05:06PM +0100, arrase wrote:
> Orbot control port is randomized every run, is there a way to know the port
> by other app? I would like to write an app who manages his own hidden
> service.

Check out the ControlPortWriteToFile torrc option. You can instruct
Tor to write out what control port it picked, to a file, and then your
other program can read the file and find out how to connect.

We built it for the case where there's an external app that launches
Tor, and it wants to let Tor pick its ports, but it still wants to be
able to connect.

But it should work fine for totally separate apps too.

Be sure to notice the ControlPortFileGroupReadable option too if that
matters to you.

In the glorious future, maybe Tor packages will default to using
an abstract unix ControlSocket:
https://trac.torproject.org/projects/tor/ticket/20337
and then they wouldn't be tempted to using ControlPorts at all.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] TorChat for Android

[Roger Dingledine]

On Sun, Nov 13, 2016 at 02:57:15AM +0100, arrase wrote:
> Is there an app like TorChat for Android? The idea of ??TorChat is
> interesting but the current implementation is very basic for normal use

Careful! You should be aware that "TorChat" is not made or endorsed
or anything by the Tor people, despite its confusing name. :( I would
suggest staying away from it on all platforms.

A better choice, for the platforms where it's available, would be
Ricochet.

But you're right that there isn't a good one on Android, to my knowledge.
And I think it would be hard to get Ricochet going on Android, since
it's tied to the Qt library.

A worthwhile next step would be asking the Guardian folks if they know
of anything good on the horizon.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] ShellCode-Exploit deleivery over TOR

[Roger Dingledine]

On Sat, Nov 12, 2016 at 11:54:35PM +0100, John Doe wrote:
> Maybe it is also a false positive. Have to check this.

Right -- my assumption whenever I hear of strange antivirus behavior
is that the antivirus program is mis-tuned. After all, one of their
main techniques is to look in every file and see if they find a certain
sequence of characters. An "artist website" could easily produce graphics
files or the like that happen to have one of the sequences of characters
in them.

And that's if you're lucky -- another common antivirus technique is to
report a summary of every file that you download, back to the mothership,
and then if you download a file that not enough other customers have
already reported, they call it a virus. :/

I guess the short-term fix is indeed to get a copy of the files that
it's upset about, and send them to your antivirus vendor so they can
fix their program.

That said, if you find that something is maliciously modifying your files,
please do let us know!

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor and macOS Sierra

[Roger Dingledine]

On Fri, Oct 28, 2016 at 06:39:03PM +0200, tort...@nym.hush.com wrote:
> Thanks, Flipchan! Nope, as far as I can see, I am not running
> anything else on that port...
> 
> http://tinypic.com/r/212d2xc/9
> 
> Still "could not connect to Tor control port"...
> 
> Any idea?

It is possible you are hitting
https://trac.torproject.org/projects/tor/ticket/20327
which is an underlying Tor bug:
https://trac.torproject.org/projects/tor/ticket/18753

I think that bug would bite users of the experimental Tor Browser 6.5a3
on Sierra, but should not bite users of the stable Tor Browser 6.0.5.

(I fear the tor-talk mailing list is a poor forum for back-and-forth
debugging of your particular software set-up though. So if "try the
stable" doesn't help, asking on irc is probably more effective than a
big thread here.)

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Authority Search and 4th Amendment

[Roger Dingledine]

On Sun, Oct 09, 2016 at 03:10:06PM +0200, tort...@arcor.de wrote:
> Second, some readers argued that a Tor user loses a reasonable expectation of 
> privacy in IP addresses because the user must disclose his true IP address to 
> Tor.

I think this reasoning represents a deep misunderstanding of how the
Internet works.

Shari and I wrote up this response back in February when the idea
first came out:
https://blog.torproject.org/blog/statement-tor-project-re-courts-february-23-order-us-v-farrell

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Wily repository

[Roger Dingledine]

On Wed, Sep 21, 2016 at 05:21:10AM -0400, 128Ko wrote:
> Some month ago, i have installed tor on Ubuntu Wily with the methode 
> described here :
> https://www.torproject.org/docs/debian.html.en

It looks like your Ubuntu version is end-of-life:
https://en.wikipedia.org/wiki/Ubuntu_version_history#Table_of_versions

> It's works fine but since a few weeks, every update attempt on the repository 
> return a 404. And indeed, if i check the repository i only find Xenial 
> repository

It looks like our volunteer deb maintainer removed the wily repository
some time after it went end-of-life.

I found this related ticket:
https://trac.torproject.org/projects/tor/ticket/18021
and took the opportunity to resolve it (I hope).

Thanks!
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] How do i check the archives?

[Roger Dingledine]

On Tue, Sep 20, 2016 at 05:51:50PM -0400, grarpamp wrote:
> It would *greatly* help readers if the full raw maildir
> or mbox archives could be provided for download.
> Thus seeding their MUA's and search tools and indexes.

Here's a tarball I just made from the seul.org archives:
http://seul.org/~arma/tor-talk-20160920.tar.gz
(It's 61MB compressed.)

People are welcome to do what they want with it to make it more
usable by whatever the cool kids use these days.

I wonder if longer-term the answer is that one of those more thoroughly
maintained mail archive websites should be doing this.

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor Browser 6.0.5 Released Early

[Roger Dingledine]

On Mon, Sep 19, 2016 at 12:27:52PM -0400, Random User wrote:
> I'm just wondering what accounts for TB 6.0.5 being released at least
> several days ahead of the date announced (20 Sept.)

https://blog.torproject.org/blog/tor-browser-605-released
has your answer (and is also the page that Tor Browser pointed
you to after the update, I hope).

Thanks!
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] benefits of onion services (was Re: getting Tor to be default browser)

[Roger Dingledine]

On Sun, Sep 18, 2016 at 10:34:45PM -0400, Random User wrote:
> What is your basis for saying that HS .onion sites are "likely harder to
> attack" than "public HTTPS" sites?

Well, one feature is that the onion service design limits the surface area
to only that service. So you can't break in by e.g. sending malformed IP
packets that surprise the kernel. This feature isn't so helpful for huge
complicated websites that use php, since in that case the webserver is
the main vulnerability anyway, but it is pretty cool in the context of
an ssh server that is firewalled from all other access.

> And, concerning your assertion that, "staying within the tor network has
> benefits.", can you name some of these benefits?

One benefit is that you're reducing load on the exit relays, so in theory
things can scale a lot better (you need folks to volunteer more non-exit
relays, but those are easier to get).

Another benefit is that you're no longer at the mercy of the Certificate
Authority mafia, and the mess which is the current CA model. (Alas when
it comes to site authentication we don't really replace the mess with
anything, so let's not get too carried away with how cool this benefit
is quite yet. :)

And there's actually lots more where that came from. Can I recommend our
32c3 talk for more info:
https://media.ccc.de/v/32c3-7322-tor_onion_services_more_useful_than_you_think

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Running a relay for some months

[Roger Dingledine]

On Sat, Sep 17, 2016 at 09:46:48PM +0200, Tor Dev wrote:
> I see now. My apologies! I pressed the button indeed multiple times, but the 
> window with the mail didn???t close after pressing the button. Even disabling 
> GPG signatures made no difference. After a few minutes I force quitted my 
> mail client and went to other things. 
> 
> Now I???m also surprised that not a single spam filter across the 
> infrastructure noticed this.

I, on the human side, noticed part-way into the mails and set the
'moderated' bit on you in case it turned into a habit. :) I've removed
the moderated bit from you.

Also, to add some useful content and answer the original question
a bit more, check out https://consensus-health.torproject.org/
especially the link at the bottom to
https://consensus-health.torproject.org/consensus-health.html
(warning, it is a huge page that your browser might find no fun to load)

Thanks,
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor Bridge vs Tor Exit?

[Roger Dingledine]

On Sat, Aug 20, 2016 at 12:58:55AM -0700, George Grantham wrote:
> I've heard that Tor Bridges and Tor exits are both within serious demand.
> 
> At this point in time within the Tor Network, are Tor Bridges with obfs4
> pluggable transports at a greater need, or are Tor exit nodes?

I think exit relays is the right answer here, if all else is equal on
your side.

In favor of exit relays:
1) Not everybody is in a position to run an exit relay, so if you can
you should.
2) More exit relays can make Tor faster for everybody.
3) More exit relays (in more diverse locations) can make Tor more
anonymous for everybody, since it increases the variety of places that
adversaries have to watch.

Whereas on the obfs4 bridge side, right now our bridge address
distribution strategies are not very robust against the steps China takes
to discover the bridge addresses, and bridges are overkill basically
every other place besides China. So running a few more obfs4 bridges,
without also improving the distribution strategies, might not end up
benefiting as many people as you hope. Really we ought to do a push to
distribute bridges better, in parallel to asking people to run a lot
more of them, in parallel to making it super easy for people to run
them (apt-get install ..., done). For the first piece, see the "Salmon"
paper from this year's PETS for some ideas:
https://censorbib.nymity.ch/pdf/Douglas2016a.pdf
but that's really a whole separate topic, and historically it also
turns out to be more complicated than it sounds. :)

And see also
https://www.torproject.org/docs/faq#RelayOrBridge

Thanks for wanting to help users!
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] tor 0.2.8.5-rc connecting to 18.0.0.1

[Roger Dingledine]

On Fri, Aug 19, 2016 at 04:05:07AM +0100, land...@tutanota.com wrote:
> I'd like to ask why is tor-win32-0.2.8.5-rc.zip and 
> torbrowser-install-6.5a2_en-US.exe connecting to 18.0.0.1 ?
>[...]
> is tor 0.2.8.5-rc binding a socket to 18.0.0.1 ? or is it something else?  if 
> so why is this not on the changelog?
> 
> 
> this was a bug 4 or 5 years ago for mac users, had a ticket and its been 
> solved.
> https://trac.torproject.org/projects/tor/ticket/1827 

Neat! It looks like that behavior is back.

> the simple notion that tor connects to an ip with 18.0.0.1 seems unsettling 
> specially when a old ticket solved the issue
> although it was for mac users, i have never encounter this behavior before 
> when using previous versions of TBB or tor packages in windows.
> 
> the other recent version "torbrowser-install-6.0.3_en-US.exe" 
> (e8ca44a4d73bc0183973e3e7abbbaf546c2a1d2cae3df58b76e929332e02a277) simply
> connects to 127.0.0.1 no other behavior is shown.

Sounds like a regression. A search in the code for "18.0.0.1" led me to
get_interface_address6_via_udp_socket_hack(). Looking at the recent
commits that mention that function we have:
https://trac.torproject.org/projects/tor/ticket/17950
and
https://trac.torproject.org/projects/tor/ticket/17951

The ChangeLog entries are:

  o Minor features (relay, address discovery):
- Add a family argument to get_interface_addresses_raw() and
  subfunctions to make network interface address interogation more
  efficient. Now Tor can specifically ask for IPv4, IPv6 or both
  types of interfaces from the operating system. Resolves
  ticket 17950.
- When get_interface_address6_list(.,AF_UNSPEC,.) is called and
  fails to enumerate interface addresses using the platform-specific
  API, have it rely on the UDP socket fallback technique to try and
  find out what IP addresses (both IPv4 and IPv6) our machine has.
  Resolves ticket 17951.

That second one looks very related.

Can you open a new ticket on https://bugs.torproject.org/ pointing to
the original issue (#1827) plus these two new ones? Hopefully teor and
rl1987 will notice and work on a fix.

Thanks,
--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] A community concern that needs to be addressed,

[Roger Dingledine]

On Thu, Aug 18, 2016 at 08:49:04PM -0400, myz...@openmailbox.org wrote:
>  I feel like Tor has become increasingly user-friendly
> and the Tor Browser Bundle is by far less 'intimidating' to perform
> first time configuration than it was a few years ago.

Yay! Sign me up. There are many millions of people around the world
who can benefit from the things that Tor Browser can do for them,
but there's still a lot of work to be done.

In fact, wait a minute, I already wrote this text before. :) Here is the
middle chunk of my blog post from last December 1st -- I still believe
it all now, and I think it gives us some good ideas for a future roadmap
of Tor's priorities.

"We have much more work ahead of us in the coming years. First and
foremost, we care about our users and the usability of our tools. We
want to accelerate user growth: The Tor network sees millions of users
each day, but there are tens of millions more who are waiting for it to
be just a little bit faster, more accessible, or easier to install. We
want to get the word out that Tor is for everyone on the planet.

We also need to focus on outreach and education, and on helping our
allies who focus on public policy to succeed. Tor is still the best
system in the world against large adversaries like governments, but
these days the attackers are vastly outspending the defenders across the
board. So in addition to keeping Tor both strong and usable, we need to
provide technical advice and support to groups like EFF and ACLU while
they work to rein in the parts of our governments that have gone beyond
the permissions and limits that our laws meant to give them.

From an organization and community angle, we need to improve our stability
by continued work on transparency and communication, strengthening our
leadership, choosing our priorities well, and becoming more agile and
adapting to the most important issues as they arise.

Taller mountains await after these: We need to tackle the big open
anonymity problems like correlation attacks, we need to help websites
learn how to engage with users who care about privacy, and we need to
demonstrate to governments around the world that we don't have to choose
between security and privacy."

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk