Re: Why NOT send UDP over tor?

2010-12-28 Thread Bjoern A. Zeeb

On Mon, 27 Dec 2010, Praedor Atrebates wrote:


Subject says it all.  Why is only TCP sent over tor and not UDP?  Why not 
simply suck up and send ALL net traffic, regardless of type, through tor so 
there can be no anonymity violations?


You want DNS, UDPENCAP, ... go through Tor as well?

Despite the other people replied, I think you are asking about a SOCKS
limitiation here.

/bz

--
Bjoern A. Zeeb You have to have visions!
ks Going to jail sucks -- bz All my daemons like it!
  http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/


Re: Help with JanusVM?

2010-12-28 Thread zzretro999

 

 


 

 

-Original Message-
From: and...@torproject.org
To: or-talk@freehaven.net
Sent: Mon, Dec 27, 2010 11:06 pm
Subject: Re: Help with JanusVM?


On Sun, Dec 26, 2010 at 08:22:03PM -0500, zzretro...@email2me.net wrote 9.3K 

bytes in 548 lines about:

: anyone have this happen? suddenly I get no more mail from or-talk and any 

emails I send or post don't go to or-talk nor are they sent back to me as 

undeliverable?



You could send a mail to or-talk-admin with your old email address to

find out what happened.



-- 

Andrew

pgp key: 0x74ED336B

***
Thanks. I will.

To unsubscribe, send an e-mail to majord...@torproject.org with

unsubscribe or-talkin the body. http://archives.seul.org/or/talk/


 


27C3 on Tor

2010-12-28 Thread Eugen Leitl

(via arsetechnica)

http://arstechnica.com/tech-policy/news/2010/12/flaws-in-tor-anonymity-network-spotlighted.ars

Flaws in Tor anonymity network spotlighted

By John Borland, wired.com | Last updated about 4 hours ago

At the Chaos Computer Club Congress in Berlin, Germany on Monday, researchers
from the University of Regensburg delivered a new warning about the Tor
anonymizer network, a system aimed at hiding details of a computer user’s
online activity from spying eyes.

The attack doesn’t quite make a surfer’s activity an open book, but offers
the ability for someone on the same local network—a Wi-Fi network provider,
or an ISP working at law enforcement (or a regime’s) request, for example—to
gain a potentially good idea of sites an anonymous surfer is viewing.

“Developers have to be aware of this kind of attack, and develop
countermeasures,” said Dominik Herrmann, a Regensburg PhD student studying
profiling and fingerprinting attacks. “But that proves to be very difficult.”

The research, performed by a variety of collaborators in Germany working on
anonymity measures, represents a warning for privacy-conscious users wary of
spying eyes, whether behind Net-unfriendly borders or simply corporate
firewalls.

Tor is essentially an online mask, rather than a tool that hides the fact or
content of communication itself. The project’s developers are addressing the
problem of traffic analysis—essentially the threat that an attacker or
observer might be able to tease out a person’s identity, location,
profession, social network or other information about the message content by
analyzing a message’s unencrypted headers.

To hide this information, the Tor system routes messages around a winding
path of volunteer servers across the Net, with each relay point knowing only
the address of the previous and next step in the pathway.

Once this circuit has been established, neither an eavesdropper nor a
compromised relay will theoretically have the ability to determine both the
source and destination of a given piece of communication. According to the
Tor project’s latest metrics, the network has drawn between 100,000 and
300,000 users per day over the last several months.

Herrmann and his fellow researchers say there’s a partial flaw in this
arrangement, however. A potential eavesdropper on the end user’s own network
still has the ability to analyze the patterns of data being returned, and in
many cases will be able to develop a reasonable guess about the source of the
communication.

An attacker—perhaps an ISP instructed by law enforcement or a government to
engage in such surveillance—would first have to develop a list of potential
sites that the target might be visiting, or that it was interested in
monitoring. It would then run the Tor system itself, testing the way these
sites appeared when accessed through Tor, developing a database of
“fingerprints” associated with the sites of interest.

Once the target of the surveillance went online, the eavesdropper would
capture the packet stream as it crossed the local network and compare the
source data with its fingerprint database with the help of pattern
recognition software. Any match would be only statistical, giving somewhere
between 55 percent and 60 percent certainty, Herrmann said—not enough to
provide hard evidence in court, but likely more certainty than many people
seeking privacy might be comfortable with.

Different online destinations will carry different susceptibility to
fingerprinting, of course. Unusual sites, with characteristics such as very
heavy or large graphic use, can be more easily identified, Herrmann said. By
the same token, the easiest way for a website to fool such an eavesdropper
would be to make its site look as closely as possible like another popular
site—mimicking the look of the Google site, for example, one of the most
commonly accessed pages on the Web.

Users themselves can guard against this type of fingerprint-based
eavesdropping relatively easily, Herrmann noted. Downloading or requesting
more than one site at a time through the network will muddy the pattern
enough that certainty will be very difficult for the eavesdropper to
establish.

The research many not dissuade many from using Tor, which remains one of the
most promising approaches for individuals seeking to hide aspects of their
identity or online activity. But it may well make them work harder.

***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/


forum hacks

2010-12-28 Thread Olaf Selke
Hi,
are folks from 27c3 trying to break into web forums today? Never got so many 
abuse complaints within a few hours in the last three years.
regards Olaf
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/


Re: forum hacks

2010-12-28 Thread Jens Kubieziel
* Olaf Selke schrieb am 2010-12-28 um 21:04 Uhr:
 are folks from 27c3 trying to break into web forums today? Never got
 so many abuse complaints within a few hours in the last three years.

Have a look at URL:http://events.ccc.de/congress/2010/wiki/Hacked.
Usually this is the time were lots of script kiddies try their tools.

-- 
Jens Kubieziel   http://www.kubieziel.de
FdI#6: Globale Variable
Parameterübergabemechanismus in 4GLs (Marit Köhntopp)


signature.asc
Description: Digital signature


Re: 27C3 on Tor

2010-12-28 Thread Roc Admin
This doesn't seem like much of a flaw as it is a design decision. See
https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#Youshouldsendpaddingsoitsmoresecure.
I'm not trying to dismiss the researcher but maybe someone can give
some insight into how critical this is to the Tor project and what
avenues for remediation there are if any. Anyone have a video of the
presentation?

--
Onionroutor


On Tue, Dec 28, 2010 at 2:07 PM, Eugen Leitl eu...@leitl.org wrote:

 (via arsetechnica)

 http://arstechnica.com/tech-policy/news/2010/12/flaws-in-tor-anonymity-network-spotlighted.ars

 Flaws in Tor anonymity network spotlighted

 By John Borland, wired.com | Last updated about 4 hours ago

 At the Chaos Computer Club Congress in Berlin, Germany on Monday, researchers
 from the University of Regensburg delivered a new warning about the Tor
 anonymizer network, a system aimed at hiding details of a computer user’s
 online activity from spying eyes.

 The attack doesn’t quite make a surfer’s activity an open book, but offers
 the ability for someone on the same local network—a Wi-Fi network provider,
 or an ISP working at law enforcement (or a regime’s) request, for example—to
 gain a potentially good idea of sites an anonymous surfer is viewing.

 “Developers have to be aware of this kind of attack, and develop
 countermeasures,” said Dominik Herrmann, a Regensburg PhD student studying
 profiling and fingerprinting attacks. “But that proves to be very difficult.”

 The research, performed by a variety of collaborators in Germany working on
 anonymity measures, represents a warning for privacy-conscious users wary of
 spying eyes, whether behind Net-unfriendly borders or simply corporate
 firewalls.

 Tor is essentially an online mask, rather than a tool that hides the fact or
 content of communication itself. The project’s developers are addressing the
 problem of traffic analysis—essentially the threat that an attacker or
 observer might be able to tease out a person’s identity, location,
 profession, social network or other information about the message content by
 analyzing a message’s unencrypted headers.

 To hide this information, the Tor system routes messages around a winding
 path of volunteer servers across the Net, with each relay point knowing only
 the address of the previous and next step in the pathway.

 Once this circuit has been established, neither an eavesdropper nor a
 compromised relay will theoretically have the ability to determine both the
 source and destination of a given piece of communication. According to the
 Tor project’s latest metrics, the network has drawn between 100,000 and
 300,000 users per day over the last several months.

 Herrmann and his fellow researchers say there’s a partial flaw in this
 arrangement, however. A potential eavesdropper on the end user’s own network
 still has the ability to analyze the patterns of data being returned, and in
 many cases will be able to develop a reasonable guess about the source of the
 communication.

 An attacker—perhaps an ISP instructed by law enforcement or a government to
 engage in such surveillance—would first have to develop a list of potential
 sites that the target might be visiting, or that it was interested in
 monitoring. It would then run the Tor system itself, testing the way these
 sites appeared when accessed through Tor, developing a database of
 “fingerprints” associated with the sites of interest.

 Once the target of the surveillance went online, the eavesdropper would
 capture the packet stream as it crossed the local network and compare the
 source data with its fingerprint database with the help of pattern
 recognition software. Any match would be only statistical, giving somewhere
 between 55 percent and 60 percent certainty, Herrmann said—not enough to
 provide hard evidence in court, but likely more certainty than many people
 seeking privacy might be comfortable with.

 Different online destinations will carry different susceptibility to
 fingerprinting, of course. Unusual sites, with characteristics such as very
 heavy or large graphic use, can be more easily identified, Herrmann said. By
 the same token, the easiest way for a website to fool such an eavesdropper
 would be to make its site look as closely as possible like another popular
 site—mimicking the look of the Google site, for example, one of the most
 commonly accessed pages on the Web.

 Users themselves can guard against this type of fingerprint-based
 eavesdropping relatively easily, Herrmann noted. Downloading or requesting
 more than one site at a time through the network will muddy the pattern
 enough that certainty will be very difficult for the eavesdropper to
 establish.

 The research many not dissuade many from using Tor, which remains one of the
 most promising approaches for individuals seeking to hide aspects of their
 identity or online activity. But it may well make them work harder.

 

Re: 27C3 on Tor

2010-12-28 Thread Nick Mathewson
On Tue, Dec 28, 2010 at 8:27 PM, Roc Admin onionrou...@gmail.com wrote:
 This doesn't seem like much of a flaw as it is a design decision. See
 https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#Youshouldsendpaddingsoitsmoresecure.
 I'm not trying to dismiss the researcher but maybe someone can give
 some insight into how critical this is to the Tor project and what
 avenues for remediation there are if any. Anyone have a video of the
 presentation?

From the wired.com article, this sounds _exactly_ like the old website
fingerprinting attack, which has been known since 2002:
http://freehaven.net/anonbib/#hintz02

It would be neat if somebody could send a pointer to the authors'
actual results.

-- 
Nick
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/


Re: 27C3 on Tor

2010-12-28 Thread Roger Dingledine
On Tue, Dec 28, 2010 at 08:51:30PM -0500, Nick Mathewson wrote:
 From the wired.com article, this sounds _exactly_ like the old website
 fingerprinting attack, which has been known since 2002:
 http://freehaven.net/anonbib/#hintz02
 
 It would be neat if somebody could send a pointer to the authors'
 actual results.

See also point 3 at
https://www.torproject.org/getinvolved/research.html.en#Ideas
It's been sitting on our this is important to learn more about
research list for years.

It's also listed in the talk I did at 25c3:
http://events.ccc.de/congress/2008/Fahrplan/events/2977.en.html
http://freehaven.net/~arma/slides-25c3.pdf (slide 30)

So I'm glad to see more attention to the attack, but a bit frustrated that
we (the research community) are not farther along at understanding it.

Two other things to note:

The website fingerprinting attack works against other anonymity systems
too, in most cases even more straightforwardly than against Tor. We've
got 8+ years in the literature of applying it to other systems (most
thoroughly just attacking SSL streams to learn what web page is being
fetched despite the encryption), and in the past few years people have
improved the attack to get it to work against Tor also. As I understand
it, even now it only works consistently when they assume laboratory
conditions. That isn't to say that it won't work in real-world conditions
-- just that it's a real hassle to get all the details right so most
researchers don't put in the required engineering work.

What I'm really looking forward to is learning what modifications to Tor
might slow down the attack. For example, what happens if we move to a 1024
byte cell by default, or if we randomly add some extra cells periodically,
or if we ask the entry node to add padding cells so the responses we get
are multiples of 10KB? It would seem that there is a tradeoff between
bandwidth overhead (wasted bytes) and protection against this attack,
but I hope there are smart points in the tradeoff space. Alas, we're
still not really to that point yet -- we don't know how well it actually
works in practice against vanilla Tor, so it doesn't make sense to ask
how well it would work in practice against a modified Tor design.

--Roger

***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/


Re: 27C3 on Tor

2010-12-28 Thread Roger Dingledine
On Tue, Dec 28, 2010 at 08:51:30PM -0500, Nick Mathewson wrote:
 It would be neat if somebody could send a pointer to the authors'
 actual results.

Based on
http://www-wiwi.uni-regensburg.de/Forschung/Publikationen/Dominik-Herrmann.html.en
I'm guessing they're basing the talk on their CCSW 2009 paper:
http://epub.uni-regensburg.de/11919/

I was a reviewer on that paper. But alas I was in Hong Kong doing a Tor
training so I couldn't attend their presentation last November. It's the
best paper there is on the topic currently, but I feel that the attack
could become much much stronger against Tor than it was in the paper --
that paper's focus on size and frequency of IP packets was what made me
write on the Tor research page:

The problem with all the previous attack papers is that they look at
timing and counting of IP packets on the wire. But OpenSSL's TLS records,
plus Tor's use of TCP pushback to do rate limiting, means that tracing by
IP packets produces very poor results. The right approach is to realize
that Tor uses OpenSSL, look inside the TLS record at the TLS headers,
and figure out how many 512-byte cells are being sent or received.

As a final note, on my reading list (which alas is growing rather than
shrinking) is
http://freehaven.net/anonbib/#morphing09

--Roger

***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/


Re: 27C3 on Tor

2010-12-28 Thread Mike Perry
Thus spake Roc Admin (onionrou...@gmail.com):

 Found the presentation at least and watching it now.  You have to skip
 to 3:30 for the actual presentation.
 
 http://www.youtube.com/watch?v=crMInOosdBkfeature=related

Here's a direct link to the relevant section:
http://www.youtube.com/watch?v=crMInOosdBk#t=31m38s

The work seems to be pretty thorough, but it would be nice to have a
paper and/or the source to their classifier. The 27c3 website doesn't
seem to list much:
http://events.ccc.de/congress/2010/Fahrplan/events/4140.en.html

The results aren't very specific in the video. It looks like they
covered the major pitfall of timing attack research (the Base Rate
Fallacy) with their presentation of the True Positive rate and the
False Positive rate, but it's not 100% clear, because there's only a
single slide with the results:
http://www.youtube.com/watch?v=crMInOosdBk#t=46m20s

The other detail that's not clear is if you train your detector for 5
interesting websites, and 2000 uninteresting ones, what happens if the
target is browsing sites outside of those 2000 uninteresting ones?

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs


pgpYtE1yggSIT.pgp
Description: PGP signature


Re: Tor Email?

2010-12-28 Thread Roger Dingledine
On Tue, Dec 28, 2010 at 08:57:24PM -0500, Alek wrote:
 I'm curious- in what way can Tor be used for emailing?  When someone is
 connected to the Tor network is there email routed along the Tor network
 too?  Or, does it go through their the normal connection with their ISP?

The only recommended way to use email with Tor is to use web mail,
e.g. https connections to gmail.

Periodically people ask about using Thunderbird or the like. The problem
is that client-side applications that compose and deliver email could
leave identifying features in the mail headers they generate, or in the
application-level data while interacting with remote mail servers. Nobody
has investigated what would be needed to write a Torbutton equivalent
for Thunderbird.

To answer what might be your more immediate question, you may be
confused about Tor when you say when someone is connected to the Tor
network. Only applications that have been specifically configured
to use Tor will send their traffic over Tor. See point 'a' at
https://www.torproject.org/download/download.html.en#warning

--Roger

***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/


Re: Tor Email?

2010-12-28 Thread .
On 12/29/2010 12:38 AM, Roger Dingledine wrote:
 On Tue, Dec 28, 2010 at 08:57:24PM -0500, Alek wrote:
 I'm curious- in what way can Tor be used for emailing?  When someone is
 connected to the Tor network is there email routed along the Tor network
 too?  Or, does it go through their the normal connection with their ISP?
 The only recommended way to use email with Tor is to use web mail,
 e.g. https connections to gmail.

 Periodically people ask about using Thunderbird or the like. The problem
 is that client-side applications that compose and deliver email could
 leave identifying features in the mail headers they generate, or in the
 application-level data while interacting with remote mail servers. Nobody
 has investigated what would be needed to write a Torbutton equivalent
 for Thunderbird.

 To answer what might be your more immediate question, you may be
 confused about Tor when you say when someone is connected to the Tor
 network. Only applications that have been specifically configured
 to use Tor will send their traffic over Tor. See point 'a' at
 https://www.torproject.org/download/download.html.en#warning

 --Roger

 ***
 To unsubscribe, send an e-mail to majord...@torproject.org with
 unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Thank youyou answered my question.



signature.asc
Description: OpenPGP digital signature


Re: 27C3 on Tor

2010-12-28 Thread Gregory Maxwell
On Tue, Dec 28, 2010 at 11:29 PM, Roger Dingledine a...@mit.edu wrote:
[snip]
 What I'm really looking forward to is learning what modifications to Tor
 might slow down the attack. For example, what happens if we move to a 1024
 byte cell by default, or if we randomly add some extra cells periodically,
 or if we ask the entry node to add padding cells so the responses we get
 are multiples of 10KB? It would seem that there is a tradeoff between
 bandwidth overhead (wasted bytes) and protection against this attack,
 but I hope there are smart points in the tradeoff space. Alas, we're
 still not really to that point yet -- we don't know how well it actually
 works in practice against vanilla Tor, so it doesn't make sense to ask
 how well it would work in practice against a modified Tor design.


We can do some useful back of the envelope calculations so that we
can say _something_ useful about the rounding.

I spent a few minutes now contemplating this, and I thought I'd make
the data available that I used for anyone else for anyone interested
in studying this.

http://myrandomnode.dyndns.org:8080/~gmaxwell/wp_article_sizes.txt.gz

contains the uncompressed sizes of the wikitext for the 3.5 million
English Wikipedia articles (as of Wikimedia's 2010-10 dump).

Here is how we can use the data to reason about this attack:

Assume that the attacker knows the target is browsing Wikipedia, and
that they know the exact size of the pages loaded and want to know
what articles the person is reading. Based on this data we can compute
the  entropy and to discover how much they will learn about each page
load.  We can then study how much quantization the size reduces
entropy.

Of course, attackers have a number of additional avenues to increase
the usefulness of the data they obtain: They may have some assumptions
about the prior probabilities (other than user is browsing
Wikipeda), they may also reason about the interlinkedness of
articles— e.g. a second page load is very likely a page linked from
the first load. You might conservatively estimate that each and every
request adds its total to the attackers aggregate knowledge.

There are a number of limits to this line of study— Wikipedia articles
are served in HTML form (not wikitext) and in the gzip encoding. I can
wave my arms and say that I don't expect the conversion HTML and HTTPS
transport to change the entropy much, and that I expect gzip to
decrease it (because smaller sizes have intrinsically less entropy).
Normally articles contain inline images— the loading sizes of these
objects probably increase the entropy enormously. These probably
aren't important compared to the fact that Wikipedia is not the whole
internet. :) Still, it's a starting point.

Here is some data,

Using the James-Stein shrinkage estimate of entropy (which gives
slightly larger results than the empirical entropy):

log2(Cell size)Entropy in bits
0   13.48422
1   12.48014
2   11.47869
3   10.47837
4   9.478465
5   8.478762
6   7.480331
7   6.48253
8   5.493885
9   4.507543
10  3.526705
11  2.551070
12  1.599523
13  0.8287433
14  0.3627942
15  0.1329697
16  0.03448373
17  0.004374095
18  0.0002002991
19  1.336822e-05
20  6.684109e-06
(there is a single page of size zero, otherwise 20 would have 0
entropy. Over a real transport the size would never be zero, so a unit
of 2^20 would be sufficient to reduce the leakage to zero for this
data).

So for this data, changing the transmission unit from 512 (4) to 1024
(5) would only decrease the information learned by an unbiased
attacker from one request by one bit.  (Unsurprisingly, the entropy of
the pages sizes is not concentrated in the least significant bits)

If you make any assumption that the attacker accumulates data from
request to request (e.g. due to page linkage) then I think that a
change from 512 to 1024 does not effectively thwart this attack
against this data set. If the attacker does not have that ability then
the current transmission unit already provides a substantial, and
probably sufficient, reduction in information leaked.
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/