Re: [tor-talk] A multi-layer proof of work system to solve the Tor/CloudFlare problem?

[Pickfire]

On Mon, Jan 25, 2016 at 09:09:37PM +0100, Cain Ungothep wrote:

That way a normal web client, normally browsing a website, would not be
impacted from end-user experience, but any automated system (the ones causing
problems to Cloudflare)


Why can't people separate Tor from Tor Browser in their minds?  Tor is a
network transport.  Not all Tor users are lusers sitting behind Tor Browser,
clicking things.


Nice speech, I don't use Tor browser, I use Tor for almost every
application. I would like to automate a link checker for it, but the
useless Cloudflare broke my script to check broken links.


For example I have a system-wide Tor daemon, and I use it for a variety of
different non-interactive things, like news reader updates, automatic source
code fetches, web-api-related requests, and other cronjobs.  I am not the only
one.  Shitflare also affects completely reasonable automatic non-interactive
uses like that.


I do that too, I use Tor for news reader, email client, lightweight
browser, almost everything use Tor, I just don't use transparent
torification for it, I considered it problematic.


In fact the Great Firewall of Shitflare completely fucks every hope of
composability of their clients' web sites.


There is a work to get around that, I plan to do an application to solve
those captcha either by using audio captcha or the picture, there is
actually some ways to solve, I just haven't got the idea yet. (Note:
Those captcha is solve-able by machine not human, it is too hard)


At that stage Cloudflare, instead of using a Captcha, could also
implement an independent Javascript Proof of Work system,


No.  Javascript in the browsers is shit. Shit for security, shit for privacy.
I consider requiring Javascript for fundamental functionality an affront.


I have no comment for Javascript, Tor browser disable that by default,
but I use javascript most of the time.


Maybe it's a bad idea, but the key to be addressed is imho:
- reducing the automated attacks from Tor netwok by increasing it's
costs while leaving intact the end-user experience on Tor Browser


They can actually not use Tor and instead use botnets, botnets is better
and a lot faster than Tor.

--
_
< Do what you like, like what you do. >
-
   \   ^__^
\  (oo)\___
   (__)\   )\/\
   ||w |
   || ||
--
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] Warning: 37 new booby trapped onion sites

[Nurmi, Juha]

Hello Tor community,

In June I warned Tor users about the presence of hundreds of fake and booby
trapped .onion websites [1].

Someone runs a fake site on a similar address to the original one and tries
to fool people with that. The sites look like the original ones.

These sites are actually working as a transparent proxy to real sites. In
addition, the attacker works as MITM and rewrites some content. It is
possible that the attacker is gathering information, including user names
and passwords.

My search engine Ahmia.fi filtered these fake sites. As a response,
eventually, the attacker deleted old fake sites and started to generate new
ones.

See, for instance, my own search engine Ahmia and a fake new version of it:

https://ahmia.fi/static/fake_ahmia.png

I filtered them again. This way I am protecting the Tor users.

Be careful, it's hard to distinguish between the real and the fake site.
Make sure you are using the real ones!

So far I have found 37 new domains of the attacker. See the list below.

Peace,
Juha

[1] https://lists.torproject.org/pipermail/tor-talk/2015-June/038295.html

REAL: http://25cs4ammearqrw4e.onion/
FAKE: http://pythonmkwmxhozin.onion/
REAL: http://2kka4f23pcxgqkpv.onion/
FAKE: http://euroguns4c7rswkh.onion/
REAL: http://54ogum7gwxhtgiya.onion/
FAKE: http://technodowmx53kwg.onion/
REAL: http://abbujjh5vqtq77wg.onion/
FAKE: http://identityw72gv5j6.onion/
REAL: http://acropol4ti6ytzeh.onion/
FAKE: http://acropolzxeerrvsp.onion/
REAL: http://answerstedhctbek.onion/
FAKE: http://answershuhpdxtab.onion/
REAL: http://auutwvpt2zktxwng.onion/
FAKE: http://oniondirw6dno3tb.onion/
REAL: http://bm26rwk32m7u7rec.onion/
FAKE: http://majesticdbvbzbv5.onion/
REAL: http://cryptomktgxdn2zd.onion/
FAKE: http://cryptonwmifsy3ws.onion/
REAL: http://deepdot35wvmeyd5.onion/
FAKE: http://deepdot53faojvzi.onion/
REAL: http://directdal7bourmy.onion/
FAKE: http://linkdirzabianoxp.onion/
REAL: http://dirnxxdraygbifgc.onion/
FAKE: http://dirnxxdemauthipe.onion/
REAL: http://easycoinsayj7p5l.onion/
FAKE: http://easycoincdttveyq.onion/
REAL: http://en35tuzqmn4lofbk.onion/
FAKE: http://fakeidsannnxrk3h.onion/
REAL: http://escobarkz55dlmo3.onion/
FAKE: http://escobarsxo7w6huz.onion/
REAL: http://gerpla4igmngtpgw.onion/
FAKE: http://gerpla4raarp2jwe.onion/
REAL: http://grams7enufi7jmdl.onion/
FAKE: http://grams7qs7lnmmidl.onion/
REAL: http://gunsjf3dxsaf6mwg.onion/
REAL: http://gunsnbmobn7evasc.onion/
FAKE: http://gunsj3xe6iaugsgg.onion/
FAKE: http://gunsnsdlbts2jhdu.onion/
REAL: http://gunsp2oe4irjxwog.onion/
FAKE: http://guns2pqyxlcd7ge5.onion/
REAL: http://hansamkt2rr6nfg3.onion/
FAKE: http://hansamktso6yaelv.onion/
REAL: http://hwikis25cffertqe.onion/
FAKE: http://hwikis27hjxsfpho.onion/
REAL: http://lchudifyeqm4ldjj.onion/
FAKE: http://lchudispi47ay5jj.onion/
REAL: http://mobil7rab6nuf7vx.onion/
FAKE: http://mobileshpc3xcw2u.onion/
REAL: http://msydqstlz2kzerdg.onion/
FAKE: http://ahmiafibdbbagojp.onion/
REAL: http://nucleuspf3izq7o6.onion/
FAKE: http://nucleuseeiya3532.onion/
REAL: http://outfor6jwcztwbpd.onion/
FAKE: http://outfor6nwtntdgpj.onion/
REAL: http://ow24et3tetp6tvmk.onion/
FAKE: http://onionwltue7vuznr.onion/
REAL: http://pfoxkj3p65uyc5pe.onion/
FAKE: http://pfoxkj2sjkqvxgpe.onion/
REAL: http://pwoah7foa6au2pul.onion/
FAKE: http://alphabayy72eux2w.onion/
REAL: http://reloadedudjtjvxr.onion/
FAKE: http://reloadedflayygcf.onion/
REAL: http://shopsat2dotfotbs.onion/
FAKE: http://shopsat4otwvudzl.onion/
REAL: http://tfwdi3izigxllure.onion/
FAKE: http://applestr7kcsyvuf.onion/
REAL: http://tochka3evlj3sxdv.onion/
FAKE: http://tochka3doxdirurf.onion/
REAL: http://torlinkbgs6aabns.onion/
FAKE: http://torlinksb7apugxr.onion/
REAL: http://valhallaxmn3fydu.onion/
FAKE: http://valhalla4qb6qccm.onion/
REAL: http://vendor7zqdpty4oo.onion/
FAKE: http://vendor7eewu66mcc.onion/
-- 
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] Warning: 37 new booby trapped onion sites

[I]

Thank you very much for being so vigilant and proactive.


-- 
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 service discovery

[Katya Titov]

Joshua Hull:
> I've been thinking about how to get onion services transparently
> selected over non-onion services in order to drive adoption. It seems
> to me that a simple strawman proposal would be that before attempting
> to connect to a domain name, do a lookup for a specific type of TXT
> record, ensure it's being served over DNSSEC, and if both things are
> true, prefer that record.

Check out Darkweb-Everywhere, a fork of HTTPS Everywhere, and the
associated email thread:

https://github.com/chris-barry/darkweb-everywhere/releases
https://lists.torproject.org/pipermail/tor-talk/2014-February/032220.html

> However, I can't seem to find much documentation on preferred
> mechanisms for discovering onion services. Is there something similar
> to the scheme I mention above already in use that someone could point
> me to?

Hopefully someone else can answer this. I've run hidden services and
can confirm that they can be discovered, but I'm not sure on the
best/preferred discovery methods.

-- 
kat
-- 
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] onion routing MITM

[populationsteamsir]

I'm new to tor, trying to understand some stuff.

I understand the .onion TLD is not an officially recognized TLD, so it's not 
resolved by normal DNS servers. The FAQ seems to say that tor itself resolves 
these, not to an IP address, but to a hidden site somehow.

When I look at thehiddenwiki.org, I see a bunch of .onion sites, with random 
looking names. Why is this? What if someone at thehiddenwiki.org registered a 
new .onion site (for example http://somerandomletters.onion), which then 
relayed traffic to duck-duck-go (http://3g2upl4pq6kufc4m.onion)? 
Thehiddenwiki could give me the link http://somerandomletters.org, and of 
course I would never know the difference between that and 
http://3g2upl4pq6kufc4m.onion

Without trusting a CA to validate a site name, what prevents MITM attacks? Am 
I supposed to get the duckduckgo URL from a trusted friend of mine, and then 
always keep it?
-- 
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 routing MITM

[a55deaba]

A CA will not validate a '.onion' address since it's not an official TLD
approved by ICANN. The numbers aren't random. From Wikipedia:

"16-character alpha-semi-numeric hashes which are automatically generated
based on a public key  when a hidden
service
 is
configured. These 16-character hashes can be made up of any letter of the
alphabet, and decimal digits from 2 to 7, thus representing an 80-bit
number in base32 . It is possible to
set up a human-readable .onion URL (e.g. starting with an organization
name) by generating massive numbers of key pairs
 (a computational
process that can be parallelized
) until a sufficiently
desirable URL is found."[2]
[3]
"

Cheers,
yodablue

On Tue, Jan 26, 2016 at 1:32 PM lists.torproject.org [Masked]
 wrote:

>
> --Blur (formerly
> DoNotTrackMe)---
> 
> -By Abine--
>
>
> I'm new to tor, trying to understand some stuff.
>
> I understand the .onion TLD is not an officially recognized TLD, so it's
> not
> resolved by normal DNS servers. The FAQ seems to say that tor itself
> resolves
> these, not to an IP address, but to a hidden site somehow.
>
> When I look at thehiddenwiki.org, I see a bunch of .onion sites, with
> random
> looking names. Why is this? What if someone at thehiddenwiki.org
> registered a
> new .onion site (for example http://somerandomletters.onion), which then
> relayed traffic to duck-duck-go (http://3g2upl4pq6kufc4m.onion)?
> Thehiddenwiki could give me the link http://somerandomletters.org, and of
> course I would never know the difference between that and
> http://3g2upl4pq6kufc4m.onion
>
> Without trusting a CA to validate a site name, what prevents MITM attacks?
> Am
> I supposed to get the duckduckgo URL from a trusted friend of mine, and
> then
> always keep it?
> --
> 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 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 routing MITM

[Paul Syverson]

This is false. 

First of all '.onion' is an officially recognized reserved top level
domain according to IETF RFC 7686.

Second, a CA _will_ validate a .onion address, but only to provide an
EV (extended validation) Cert. EV Certs are typically only
had by big companies etc. Typical browsers represent an EV cert by
showing the lock icon in green. Facebook and a couple of other entities
do have certs for their .onion addresses. Most .onion site operators are
likely to want DV (domain validation) certs, which are currently not
permitted under the guidelines of the CA/Browser Forum.

That is the current state of things, which is different from how things
were several months ago and will probably change again at some point.

aloha,
Paul

On Tue, Jan 26, 2016 at 06:37:24PM +, a55de...@opayq.com wrote:
> A CA will not validate a '.onion' address since it's not an official TLD
> approved by ICANN. The numbers aren't random. From Wikipedia:
> 
> "16-character alpha-semi-numeric hashes which are automatically generated
> based on a public key  when a hidden
> service
>  is
> configured. These 16-character hashes can be made up of any letter of the
> alphabet, and decimal digits from 2 to 7, thus representing an 80-bit
> number in base32 . It is possible to
> set up a human-readable .onion URL (e.g. starting with an organization
> name) by generating massive numbers of key pairs
>  (a computational
> process that can be parallelized
> ) until a sufficiently
> desirable URL is found."[2]
> [3]
> "
> 
> Cheers,
> yodablue
> 
> On Tue, Jan 26, 2016 at 1:32 PM lists.torproject.org [Masked]
>  opayq.com> wrote:
> 
> >
> > --Blur (formerly
> > DoNotTrackMe)---
> > 
> > -By Abine--
> >
> >
> > I'm new to tor, trying to understand some stuff.
> >
> > I understand the .onion TLD is not an officially recognized TLD, so it's
> > not
> > resolved by normal DNS servers. The FAQ seems to say that tor itself
> > resolves
> > these, not to an IP address, but to a hidden site somehow.
> >
> > When I look at thehiddenwiki.org, I see a bunch of .onion sites, with
> > random
> > looking names. Why is this? What if someone at thehiddenwiki.org
> > registered a
> > new .onion site (for example http://somerandomletters.onion), which then
> > relayed traffic to duck-duck-go (http://3g2upl4pq6kufc4m.onion)?
> > Thehiddenwiki could give me the link http://somerandomletters.org, and of
> > course I would never know the difference between that and
> > http://3g2upl4pq6kufc4m.onion
> >
> > Without trusting a CA to validate a site name, what prevents MITM attacks?
> > Am
> > I supposed to get the duckduckgo URL from a trusted friend of mine, and
> > then
> > always keep it?
> > --
> > 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 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 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 routing MITM

[Seth David Schoen]

populationsteam...@tutanota.com writes:

> I'm new to tor, trying to understand some stuff.
> 
> I understand the .onion TLD is not an officially recognized TLD, so it's not 
> resolved by normal DNS servers. The FAQ seems to say that tor itself resolves 
> these, not to an IP address, but to a hidden site somehow.
> 
> When I look at thehiddenwiki.org, I see a bunch of .onion sites, with random 
> looking names. Why is this? What if someone at thehiddenwiki.org registered a 
> new .onion site (for example http://somerandomletters.onion), which then 
> relayed traffic to duck-duck-go (http://3g2upl4pq6kufc4m.onion)? 
> Thehiddenwiki could give me the link http://somerandomletters.org, and of 
> course I would never know the difference between that and 
> http://3g2upl4pq6kufc4m.onion

The hidden service name isn't chosen directly by the hidden service
operator and you can't just make one up and start using it.  Instead,
it's derived from the hidden service's cryptographic public key.
Tor checks that the public key matches when you're connecting to the
hidden service, so someone can't simply substitute their own service
without knowing the corresponding private key.

In effect, the crypto key is used as a name (or identifier), which
provides an intrinsic cryptographic way to know whether you're talking to
someone who has the right to use that name (or is properly referred to by
it), assuming hidden service operators can keep their private keys secret.

Somewhat confusingly, people do manage to make their hidden services
start with strings of their choice, but they do this by generating
enormous numbers of different keys over and over again until they get
one that they like.  Despite that, it takes an exponentially-increasing
number of attempts for each additional character of the onion name that
you want to control, so even if Facebook can get one that starts with
"facebook" (as they did), we don't tend to think anyone* has the time
or computational resources to be able to choose the entire onion name,
for example to choose one that matches an existing one controlled by
somebody else.  For instance, even if I had generated an onion name
beginning "3g2upl4", it would take me about 32 times as much work to get
one beginning "3g2upl4p", 1024 times as much work to get one beginning
"3g2upl4pq", 32768 times as much work to get one beginning "3g2upl4pq6",
and overall 35184372088832 times as much to get one that exactly matches
DuckDuckGo's onion name.

> Am I supposed to get the duckduckgo URL from a trusted friend of mine, and 
> then 
> always keep it?

Yes, or from DuckDuckGo's regular site.

https://duck.co/help/privacy/no-tracking


* The Bitcoin network is doing quite a bit more computation, in total,
  than this per year, so it's actually conceivable that someone with a
  very large amount of money to spend on custom hardware could do this.
  So the next generation of Tor hidden services will use a longer
  onion name.

-- 
Seth Schoen  
Senior Staff Technologist   https://www.eff.org/
Electronic Frontier Foundation  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109   +1 415 436 9333 x107
-- 
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 routing MITM

[Green Dream]

> What prevents a person from registering a new .onion site, such as
> http://laobeqkdrj7bz9pq.onion and then relaying all its traffic to
> http://3g2upl4pq6kufc4m.onion, and trying to get people to believe that
> *they* are actually the duckduckgo .onion site?


Nothing.

> When you see a link like  http://3g2upl4pq6kufc4m.onion somewhere on the
web
> (such as thehiddenwiki.org) why would you believe it's the real URL that
> duckduckgo created, and not somebody doing a MITM?

Well, I'd query duckduckgo for its hidden service URL in the clearnet
first. If you just search "duckduckgo hidden service" on their clearnet
site, there's a magic/onebox answer with a link to the official onion site.
;-)

The larger point is valid though. I feel like this is actually a huge
problem with the current state of hidden services. Try figuring out which
.onion site is the "real" Hidden Wiki for example.

I'll admit I barely use hidden services for this very reason.
-- 
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 routing MITM

[populationsteamsir]

26. Jan 2016 18:37 by a55de...@opayq.com:


> A CA will not validate a '.onion' address since it's not an official TLD
> approved by ICANN.
>




I understand that.







> The numbers aren't random. From Wikipedia: 
> "16-character alpha-semi-numeric hashes which are automatically generated
> based on a public key <> https://en.wikipedia.org/wiki/Public_key> > when a 
> hidden
> service
> <> https://en.wikipedia.org/wiki/Tor_(anonymity_network)#Hidden_services> > 
> is
> configured.




I also know what asymmetric keys and hashes are.




The question is: From a user perspective, http://3g2upl4pq6kufc4m.onion just 
looks like random characters. (And in fact, if it's a hash of a public key, 
which was originally randomly generated, then indeed these *are* random 
characters). You obviously don't want to memorize a domain name such as this, 
and as a human, you're very bad at recognizing the difference between 
http://3g2upl4pq6kufc4m.onion and http://xmh57jrzrnw6insl.onion




What prevents a person from registering a new .onion site, such as 
http://laobeqkdrj7bz9pq.onion and then relaying all its traffic to  
http://3g2upl4pq6kufc4m.onion, and trying to get people to believe that 
*they* are actually the duckduckgo .onion site?




When you see a link like  http://3g2upl4pq6kufc4m.onion somewhere on the web 
(such as thehiddenwiki.org) why would you believe it's the real URL that 
duckduckgo created, and not somebody doing a MITM?

-- 
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 routing MITM

[Paul Syverson]

Probably should also have noted wrt the original question
that for people who use PGP/GPG there are things that can be done
now and onionsites that do make use of that. Cf.

See
"Bake in .onion for Tear-free and Stronger Website Authentication"
https://github.com/saint/w2sp-2015/blob/master/SP_SPSI-2015-09-0170.R1_Syverson.pdf
for a description of both how people are using GPG now, and for
the situation and plans for certs in the future.

See also Juha Nurmi's related post to this list about booby trapped
onion sites.

aloha,
Paul


On Tue, Jan 26, 2016 at 02:04:54PM -0500, Paul Syverson wrote:
> This is false. 
> 
> First of all '.onion' is an officially recognized reserved top level
> domain according to IETF RFC 7686.
> 
> Second, a CA _will_ validate a .onion address, but only to provide an
> EV (extended validation) Cert. EV Certs are typically only
> had by big companies etc. Typical browsers represent an EV cert by
> showing the lock icon in green. Facebook and a couple of other entities
> do have certs for their .onion addresses. Most .onion site operators are
> likely to want DV (domain validation) certs, which are currently not
> permitted under the guidelines of the CA/Browser Forum.
> 
> That is the current state of things, which is different from how things
> were several months ago and will probably change again at some point.
> 
> aloha,
> Paul
> 
> On Tue, Jan 26, 2016 at 06:37:24PM +, a55de...@opayq.com wrote:
> > A CA will not validate a '.onion' address since it's not an official TLD
> > approved by ICANN. The numbers aren't random. From Wikipedia:
> > 
> > "16-character alpha-semi-numeric hashes which are automatically generated
> > based on a public key  when a 
> > hidden
> > service
> >  is
> > configured. These 16-character hashes can be made up of any letter of the
> > alphabet, and decimal digits from 2 to 7, thus representing an 80-bit
> > number in base32 . It is possible to
> > set up a human-readable .onion URL (e.g. starting with an organization
> > name) by generating massive numbers of key pairs
> >  (a computational
> > process that can be parallelized
> > ) until a sufficiently
> > desirable URL is found."[2]
> > [3]
> > "
> > 
> > Cheers,
> > yodablue
> > 
> > On Tue, Jan 26, 2016 at 1:32 PM lists.torproject.org [Masked]
> >  > opayq.com> wrote:
> > 
> > >
> > > --Blur (formerly
> > > DoNotTrackMe)---
> > > 
> > > -By Abine--
> > >
> > >
> > > I'm new to tor, trying to understand some stuff.
> > >
> > > I understand the .onion TLD is not an officially recognized TLD, so it's
> > > not
> > > resolved by normal DNS servers. The FAQ seems to say that tor itself
> > > resolves
> > > these, not to an IP address, but to a hidden site somehow.
> > >
> > > When I look at thehiddenwiki.org, I see a bunch of .onion sites, with
> > > random
> > > looking names. Why is this? What if someone at thehiddenwiki.org
> > > registered a
> > > new .onion site (for example http://somerandomletters.onion), which then
> > > relayed traffic to duck-duck-go (http://3g2upl4pq6kufc4m.onion)?
> > > Thehiddenwiki could give me the link http://somerandomletters.org, and of
> > > course I would never know the difference between that and
> > > http://3g2upl4pq6kufc4m.onion
> > >
> > > Without trusting a CA to validate a site name, what prevents MITM attacks?
> > > Am
> > > I supposed to get the duckduckgo URL from a trusted friend of mine, and
> > > then
> > > always keep it?
> > > --
> > > 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 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 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 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 routing MITM

[Seth David Schoen]

populationsteam...@tutanota.com writes:

> The question is: From a user perspective, http://3g2upl4pq6kufc4m.onion just 
> looks like random characters. (And in fact, if it's a hash of a public key, 
> which was originally randomly generated, then indeed these *are* random 
> characters). You obviously don't want to memorize a domain name such as this, 
> and as a human, you're very bad at recognizing the difference between 
> http://3g2upl4pq6kufc4m.onion and http://xmh57jrzrnw6insl.onion

In the Zooko's Triangle sense, Tor hidden service names are secure and
decentralized, but not human-meaningful (or human-memorable).

https://en.wikipedia.org/wiki/Zooko's_triangle

That is to say that Tor hasn't tried to solve the problem you mention
at all.  The answer seems to be that you're supposed to get the names
somewhere else and store them in something other than your human memory.
This is in common with a few other designs that use representations
of crypto keys directly (for example, PGP and Bitcoin) and where
someone could try to trick you into using a key that isn't really the
right one.  In the PGP example, someone has uploaded a fake key with my
name and e-mail address to the keyservers (several years ago), which has
already fooled a number of people because they couldn't or didn't readily
distinguish my real key from the fake key, both of which are just numbers
that someone on the Internet has claimed are relevant to contacting me.

If you have ideas for making this more convenient, I'm sure they would
be welcome.  Aaron Swartz proposed in 2011 that blockchains and related
systems could solve it by letting people publicly announce claims to
(human-memorable) names in an append-only log.

http://www.aaronsw.com/weblog/squarezooko

There are some implementations of related ideas, like okTurtles, but
none is extremely widely used yet.

> What prevents a person from registering a new .onion site, such as 
> http://laobeqkdrj7bz9pq.onion and then relaying all its traffic to  
> http://3g2upl4pq6kufc4m.onion, and trying to get people to believe that 
> *they* are actually the duckduckgo .onion site?

Indeed, Juha Nurmi described earlier today that people are doing exactly
that right now, probably with some success.

https://lists.torproject.org/pipermail/tor-talk/2016-January/040038.html

-- 
Seth Schoen  
Senior Staff Technologist   https://www.eff.org/
Electronic Frontier Foundation  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109   +1 415 436 9333 x107
-- 
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] Warning: 37 new booby trapped onion sites

[populationsteamsir]

Juha, thank you for identifying the real and fake sites.

This re-raises the question, when you get a URL from somewhere, how do you 
know it's the real one? Which upon further thought requires definition of 
"the real one." If two guys on the internet both claim to be John Doe, how is 
it possible to know which one is the real John Doe, or is there more than 
one, etc.

If directories such as https://thehiddenwiki.org are going to publish .onion 
URL's, it would be useful to also publish user-verifiable information on why 
they believe it's the valid one. For example, it's been pointed out here, 
that you can search duckduckgo for their hidden URL on the regular internet. 
In which case, you're placing trust in the CA. (An attacker who can 
impersonate https://duckduckgo.com could feed you a fake result in order to 
add validity to the fake URL they've published on some site like 
thehiddenwiki).

If somebody hosts a dark website, that doesn't have a verifiable external way 
to lookup their URL, then the only way you can verify them is to talk with a 
bunch of other people, web-of-trust style. Which also has a bunch of ways it 
can be undermined.

In any event, Juha, in your list, how do you know which ones are real and 
fake?
-- 
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 VPN less safe?

[juan]

On Mon, 25 Jan 2016 10:25:20 -0500
Paul Syverson  wrote:


> "20,000 In League Under the Sea: Anonymous Communication, Trust,
> MLATs, and Undersea Cables" available at
> http://www.degruyter.com/view/j/popets.2015.1.issue-1/popets-2015-0002/popets-2015-0002.xml?format=INT


As far as I can see, most if not all of the paper deals with a
way to organize information about 'network topology' but
there's no concrete data regarding which
systems/relays/cables/people/IXPs/ASs/whatever are
'compromised'.

...though the section on cables and cooperation between so
called nation states seems to suggest that virtually all the
world's infrastructure is 'compromised'?

Also, is there a more concrete analysis of what can be
achieved by monitoring traffic on those cables? Specifically,
how easy it is for your government to find users and especially
servers in the tor network or similar networks (i2p, freenet
etc)


There's also mention of 'user beliefs' and 'trust'. That
strikes me as weird. You seem to be saying that routes
can be choosen according to users' beliefs, not according to
real world facts? It doesn't matter if system X is hostile,
what matters is what the user believes about system X? Am I
missing something? 

And what's the engineering definition of trust? And the units
used to measure it? 
 

> 
> This is ongoing evolving research. This is not ready for deployment
> for everybody's Tor clients to do their own trust-aware route
> selection.  And, one of the observations of this work is that you
> should probably always use the default settings unless you have
> specific other adversaries in mind and understand how diverging from
> the pack will affect you.  What this work will do is help people who
> want to use different route selection choices to understand those
> choices, and it will eventually impact the default and alternative
> route selections built into the Tor software.  
> 
> It also focuses just on route selection.  Tor does other things to
> diversify trust.  For example, Tor's binaries have for the last few
> stable releases reflected reproducible (or determistic) builds, which
> means that people can independently verify that the officially
> distributed binaries are compiled from the officially distributed
> source programs. If they did not match, anyone could test and expose
> that.  See
> https://blog.torproject.org/category/tags/deterministic-builds
> 
> aloha,
> Paul

-- 
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 routing MITM

[Coyo Stormcaller]

On Tue, 26 Jan 2016 18:31:50 + (UTC)
 wrote:

> When I look at thehiddenwiki.org, I see a bunch of .onion sites, with
> random looking names. Why is this? What if someone at
> thehiddenwiki.org registered a new .onion site (for example
> http://somerandomletters.onion), which then relayed traffic to
> duck-duck-go (http://3g2upl4pq6kufc4m.onion)? Thehiddenwiki could
> give me the link http://somerandomletters.org, and of course I would
> never know the difference between that and
> http://3g2upl4pq6kufc4m.onion

What?
-- 
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 routing MITM

[Flipchan]

Try to put up a server n run it throw tor and the generate a key with scallion 
for example https://github.com/lachesis/scallion , or ur favorite programming 
lang

a55de...@opayq.com skrev: (26 januari 2016 19:37:24 CET)
>A CA will not validate a '.onion' address since it's not an official
>TLD
>approved by ICANN. The numbers aren't random. From Wikipedia:
>
>"16-character alpha-semi-numeric hashes which are automatically
>generated
>based on a public key  when a
>hidden
>service
>
>is
>configured. These 16-character hashes can be made up of any letter of
>the
>alphabet, and decimal digits from 2 to 7, thus representing an 80-bit
>number in base32 . It is possible
>to
>set up a human-readable .onion URL (e.g. starting with an organization
>name) by generating massive numbers of key pairs
> (a
>computational
>process that can be parallelized
>) until a sufficiently
>desirable URL is found."[2]
>[3]
>"
>
>Cheers,
>yodablue
>
>On Tue, Jan 26, 2016 at 1:32 PM lists.torproject.org [Masked]
>opayq.com> wrote:
>
>>
>> --Blur (formerly
>> DoNotTrackMe)---
>> 
>> -By Abine--
>>
>>
>> I'm new to tor, trying to understand some stuff.
>>
>> I understand the .onion TLD is not an officially recognized TLD, so
>it's
>> not
>> resolved by normal DNS servers. The FAQ seems to say that tor itself
>> resolves
>> these, not to an IP address, but to a hidden site somehow.
>>
>> When I look at thehiddenwiki.org, I see a bunch of .onion sites, with
>> random
>> looking names. Why is this? What if someone at thehiddenwiki.org
>> registered a
>> new .onion site (for example http://somerandomletters.onion), which
>then
>> relayed traffic to duck-duck-go (http://3g2upl4pq6kufc4m.onion)?
>> Thehiddenwiki could give me the link http://somerandomletters.org,
>and of
>> course I would never know the difference between that and
>> http://3g2upl4pq6kufc4m.onion
>>
>> Without trusting a CA to validate a site name, what prevents MITM
>attacks?
>> Am
>> I supposed to get the duckduckgo URL from a trusted friend of mine,
>and
>> then
>> always keep it?
>> --
>> 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 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

-- 
Sincerly Flipchan
-- 
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] Network Analysis of Overlay Networks, Capabilities, Fill Traffic [was: VPN less safe?]

[grarpamp]

On Tue, Jan 26, 2016 at 3:09 PM, juan  wrote:
> On Mon, 25 Jan 2016 10:25:20 -0500
> Paul Syverson  wrote:
>
>
>> "20,000 In League Under the Sea: Anonymous Communication, Trust,
>> MLATs, and Undersea Cables" available at
>> http://www.degruyter.com/view/j/popets.2015.1.issue-1/popets-2015-0002/popets-2015-0002.xml?format=INT
>
>
> As far as I can see, most if not all of the paper deals with a
> way to organize information about 'network topology' but
> there's no concrete data regarding which
> systems/relays/cables/people/IXPs/ASs/whatever are
> 'compromised'.
>
> ...though the section on cables and cooperation between so
> called nation states seems to suggest that virtually all the
> world's infrastructure is 'compromised'?

The USA and Soviets have decades experience tapping cables
around the globe in a cold war sense.
The USA/FVEY has top secret blackops and administrative via corp
partnership and various legal and extralegal access to extensive cable,
hardware, and organizational assets around the globe.
It is simply foolish to not assume that the world is highly
compromised by these actors.
Snowden and all the other surveillance and bigdata news and political
rhetoric have been telling you that for over a decade now.
You might be safe if you are in a locale untouchable by these actors,
conduct all your activities in that locale, and have no similar local
adversaries.

> Also, is there a more concrete analysis of what can be
> achieved by monitoring traffic on those cables?

Did you just push a bunch of packets over time into your ISP and
have google send replies back? Well, they can see both ends, so
they saw that traffic pattern in and out, and back in and out, so
they know who's talking to who and when.

> Specifically,
> how easy it is for your government to find users and especially
> servers in the tor network or similar networks (i2p, freenet
> etc)

In addition to simple taps, they can also deploy passive or
active nodes in any of these networks at will. And use all
the tools to perturb things in favor of their efforts.

Tor and other networks are good at hiding endpoints (users, servers)
from each other, keeping traffic content encrypted over the wire, letting
you anonymously publish and consume stuff among other users that
isn't really of interest to (against) such adversaries (and thus won't get
you killed or jailed or disappeared (but will still get you databased
for life)),
and getting around some censorship. That's probably about it.

However when it comes to such global (and regionally lucky) passive
adversaries, and adversaries operating the networks themselves, I
seriously doubt anyone can say with a straight face that these
networks protect against network analysis... who is talking to
who and when.

It would be harder for that analysis to succeed against networks
that filled between all the nodes with fill traffic when unused and
not needed for user traffic. (And in the sense of Tor, between clients
and some number of guards). But that's hard to design so that it
is functional. And no one in the overlay network / messaging field
really seems to be trying it. Mindset, OMG bandwidth, probably
buzzkills most research before it gets started.

Here's some recent mostly tor specific threads if anyone's interested,
plus whatever else has come up whenever I've mentioned this.

https://lists.torproject.org/pipermail/tor-dev/2016-January/010257.html
https://lists.torproject.org/pipermail/tor-dev/2016-January/010290.html


> There's also mention of 'user beliefs' and 'trust'. That
> strikes me as weird. You seem to be saying that routes
> can be choosen according to users' beliefs, not according to
> real world facts? It doesn't matter if system X is hostile,
> what matters is what the user believes about system X?

Users often have better knowledge of the laws, operations and
general feel in their countries and locales and areas of expertise
than a handful of distant project maintainers largely based
in one geopolitical exposure might have. You can download
science, but you need more than that to win a street fight.
-- 
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] Darknets: Full of onions, and eeps, and other wondrous things

[grarpamp]

> Email to tor-talk@ [0] made me wonder if (some of) these
> are run by the same people that have been trying to hijack
> Bitcoin transactions.  In the first step, they could enumerate
> services by crawling them

That would be useful to get an early start in the spamming / seeding
publication below.

> and setting up an impersonation
> site that has substituted Bitcoin addresses on it.

There's no need to 'mirror' or 'clone' or 'set up a site', the good ones
are just transparent cleartext proxies, one onion in front of another.
They can be timed, but don't fall to the dynamic content and
update differences that mirrors do.

Regardless, the last step is publication of the proxy. This is done in
wholesale on onionland services such as forums and the now tens of
wannabe 'hidden wikis', many of which are run by the same actors,
obviously adding to the attack surface. Users surf them, they and the
links looks legit, they get bookmarked and that's that till they somehow
find out. It's been going on that way for years. All onionland services
should be considered suspect, even email, syndication and storage.

> Finally, they are
> running malicious exists that rewrite onion domains to their own
> impersonation sites.

Exit rewriting is an easy way to skim another fraction of users without
needing to play with forums and wikis.

As interesting as why, is that there are so many.

Those willing to immerse themselves in the corners of onionland would
probably find some insight, at least for that which comes from there.

Topside ventures that reach down into onions would be different story.

Databasing, crime, anti-crime, covert stuff, games, research, hacking,
and even the overriding majority of everyday legitimate use by users
around the globe

The story and scaling over time of all these aspects is becoming quite
interesting.

> [0] 
-- 
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] Network Analysis of Overlay Networks, Capabilities, Fill Traffic [was: VPN less safe?]

[Cain Ungothep]

> It would be harder for that analysis to succeed against networks
> that filled between all the nodes with fill traffic when unused and
> not needed for user traffic. (And in the sense of Tor, between clients
> and some number of guards). But that's hard to design so that it
> is functional. And no one in the overlay network / messaging field
> really seems to be trying it. Mindset, OMG bandwidth, probably
> buzzkills most research before it gets started.

I'll just name-drop these two hopefully-more-correlation-resistant
communication systems, in case people want to discuss them.

1) In relation to the "noisy traffic" you mentioned:

vuvuzela (WIP):
  https://github.com/davidlazar/vuvuzela

2) In relation to mixing networks:

bitmessage (by now fairly well known):
  https://bitmessage.org/
  https://github.com/Bitmessage/PyBitmessage
-- 
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] Warning: 37 new booby trapped onion sites

[Juha Nurmi]

Hi,

> If somebody hosts a dark website, that doesn't have a verifiable external way 
> to lookup their URL, then the only way you can verify them is to talk with a 
> bunch of other people, web-of-trust style. Which also has a bunch of ways it 
> can be undermined.
> 

That's true. You have to trust the source(s) of the URL.

> In any event, Juha, in your list, how do you know which ones are real and 
> fake?
> 

I compared my real ahmia (msydqstlz2kzerdg.onion) to the fake one. I
scanned them and detected the difference. The fake ahmia changes URLs to
point to fake services.

BTW, the attacker removed the fake version of Ahmia! It seems that the
attacker didn't like my active countermeasures.

Peace,
Juha
-- 
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] crashsafari.com

[tor_talk]

Hi Tor Talkers,

are you aware of it already:
http://www.wired.com/2016/01/hack-brief-dont-be-trolled-by-this-iphone-crashing-link-meme/
"Crashsafari appears to run javascript code that overloads the victim’s address 
bar with an infinite series of numbers."

It's not only Safari who is about to crash. Social Network reads that device 
may get (too) hot before the reboot. It's not a TorBug to report, i guess.
-- 
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