Dutch CA issues fake *.torproject.org cert (among many others)

For those who haven't been following, check out
https://blog.torproject.org/blog/diginotar-debacle-and-what-you-should-do-about-it

You should pay special attention if you're in an environment where your
ISP (or your government!) might try a man-in-the-middle attack on your
interactions with https://www.torproject.org/.

We stepped up our schedule for switching the Tor Browser Bundle to Firefox
6 (which we can build from source on all platforms, and thus remove the
offending CA ourselves). New bundles are out now:
https://blog.torproject.org/blog/new-tor-browser-bundles-4

Perhaps now is a great time for you to learn how to verify the signatures
on Tor packages you download:
https://www.torproject.org/docs/verifying-signatures

--Roger

_______________________________________________
tor-talk mailing list
tor-talk <at> lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

(FWD) Tor 0.2.2.32 is released

If you're not on tor-announce, consider joining: that's where the stable
Tor releases get announced.

https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-announce

--Roger

----- Forwarded message from Roger Dingledine <arma <at> mit.edu> -----

Date: Mon, 29 Aug 2011 18:05:02 -0400
From: Roger Dingledine <arma <at> mit.edu>
To: tor-announce <at> lists.torproject.org
Subject: Tor 0.2.2.32 is released

The Tor 0.2.2 release series is dedicated to the memory of Andreas
Pfitzmann (1958-2010), a pioneer in anonymity and privacy research,
a founder of the PETS community, a leader in our field, a mentor,
and a friend. He left us with these words: "I had the possibility
to contribute to this world that is not as it should be. I hope I
could help in some areas to make the world a better place, and that
I could also encourage other people to be engaged in improving the
world. Please, stay engaged. This world needs you, your love, your
initiative -- now I cannot be part of that anymore."

Tor 0.2.2.32, the first stable release in the 0.2.2 branch, is finally
ready. More than two years in the making, this release features improved
client performance and hidden service reliability, better compatibility
for Android, correct behavior for bridges that listen on more than
one address, more extensible and flexible directory object handling,
better reporting of network statistics, improved code security, and

Dutch police break into webservers over hidden services

Several people have asked us on irc about recent news articles like
http://wireupdate.com/wires/19812/dutch-police-infiltrate-hidden-child-porn-websites-in-the-u-s/

Apparently the Dutch police exploited vulnerabilities in the webservers
reachable over the hidden services. Some people are confusing this issue
with an attack on Tor. Tor just transports bytes back and forth. If you
have an instant messaging conversation with a Tor user and convince her
to tell you her address, did you break Tor? Having an http conversation
with a webserver running over a Tor hidden service, and convincing it
to tell you its address, is not much different.

So what lessons can we learn here, other than the usual "criminals
are not as smart as your average bear"? (If only we could count on bad
people to run insecure software, and good people to secure their software
correctly, the world would be a much simpler place.) One lesson is that
there are a lot of non-Tor components that can go wrong in keeping a
hidden service hidden -- just as we have a laundry list of security
and privacy issues to consider when using Tor as a normal client (at
the bottom of https://www.torproject.org/download/download.html.en )
there's a whole other set of issues, mostly unexplored, for hidden
service operators to keep in mind:
https://www.torproject.org/docs/tor-hidden-service.html.en#three

--Roger

_______________________________________________
tor-talk mailing list
tor-talk <at> lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: Dutch police break into webservers over hidden services

On 2011-09-01 15:24 , Roger Dingledine wrote:
> Several people have asked us on irc about recent news articles like
> http://wireupdate.com/wires/19812/dutch-police-infiltrate-hidden-child-porn-websites-in-the-u-s/
[..]

In addiotion I want to refer to the below article from the Dutch "Public
Ministry" (literal translation) or how Google Translate translates it as
'the prosecution' which is a bit off also I think, see and throw it
trough your favorite translator if you like:

http://www.om.nl/actueel-0/nieuws-persberichten/ <at> 156657/kinderporno-anonieme/

It is in Dutch, but here are the Tor related portions and my translation
of it:

"In dit onderzoek wil de politie ook duidelijk maken dat anonimiteit
binnen het Tor-netwerk en ook landsgrenzen de opsporing van kinderporno
niet in de weg staan."

english:
"With this investigation the police wants to make clear that anonimity
inside the Tor network and also country borders do not limit the
investigation into childporn".

And then the section at the end "Vrijheid van meningsuiting" which is
IMHO a good thing of them to publish in that way:

my free translation:
8<------------------------------
Freedom of expression

Re: RSA identity keys

On Wed, Aug 31, 2011 at 6:03 AM, grarpamp <grarpamp <at> gmail.com> wrote:
> Tor routers and hidden services use these.
>
> Various other tools can utilize them for sign
> and encrypt. A number of useful scenarious
> can be envisioned.

Hm.  I'm not too fond of the idea of using Tor keys for other stuff
too: there are historically a lot of attacks that have been opened up
when a key that used to be single-purpose started getting used for
other stuff as well, and the two uses opened up attack vectors.

What would be much safer here would be to bootstrap trust from your
Tor ID key to some other key -- for example, by including a gpg key in
your contactinfo.  If there's a good use for it, we could probably
come up with more well-specified ways to do that.

> But I can't put a passphrase on them
> because I've no way to start Tor if
> they have a passphrase set.
>
> Also, without a passphrase, they are more
> prone to undesired use if copies are obtained.
>
> Can some future version of Tor be made to
> deal with that using the usual sources
> of passphrase... stdin, pathname, descriptor,
> environment? Ala: apache and certs, ssh-agent, etc.

Sounds like a fine thing to me, especially if somebody wants to code

Re: RSA identity keys

>> Various other tools can utilize them for sign
>> and encrypt. A number of useful scenarious
>> can be envisioned.

> other stuff as well, and the two uses opened up attack vectors.

I didn't mean to suggest full general purpose use of these keys.
Minimally, users just need to be able to securely sign arbitrary things...

[> What would be much safer here would be to bootstrap trust from]
[> your Tor ID key to some other key]

>> But I can't put a passphrase on them

...which wouldn't be very secure for the general userbase. And
would yield easier unauthorized reassignment of that trust into
the downstream space.

> Much easier and possibly safer IMO is to look into a delegation
> mechanism, where identity keys are never actually loaded by Tor,
> and can be stored offline.

Well, then it's likely looking at some sort of agent/protocol involving
the controller. Managing that type of connection would be a pretty
advanced topic for the general user/operator.

Didn't think of the additional win of the optional passphrase effectively
securing the published descriptor params/config.
_______________________________________________
tor-talk mailing list

Re: Dutch CA issues fake *.torproject.org cert (among many others)

_______________________________________________
tor-talk mailing list
tor-talk <at> lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: Dutch CA issues fake *.torproject.org cert (among many others)

On 9/2/2011 7:55 AM, Achter Lieber wrote:
> ----- Original Message -----
> From: Roger Dingledine
> Sent: 09/01/11 03:47 PM
> To: tor-talk <at> lists.torproject.org
> Subject: [tor-talk] Dutch CA issues fake *.torproject.org cert (among many others)
>
>   New bundles are out now: https://blog.torproject.org/blog/new-tor-browser-bundles-4 Perhaps now
is a great time for you to learn how to verify the signatures on Tor packages you download: https://www.torproject.org/docs/verifying-signatures
Is it really a risk, d/l  Tor or TBB directly from Tor Project's site, 
that verifying signatures is necessary?  What is the reasoning here - if 
getting files from Tor Project server?

_______________________________________________
tor-talk mailing list
tor-talk <at> lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: Dutch CA issues fake *.torproject.org cert (among many others)

_______________________________________________
tor-talk mailing list
tor-talk <at> lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: Dutch CA issues fake *.torproject.org cert (among many others)

On 9/2/2011 9:57 AM, David Carlson wrote:
> On 9/2/2011 9:28 AM, Joe Btfsplk wrote:
>>
>> Is it really a risk, d/l  Tor or TBB directly from Tor Project's site,
>> that verifying signatures is necessary?  What is the reasoning here -
>> if getting files from Tor Project server?
>>
>> _______________________________________________
>> tor-talk mailing list
>> tor-talk <at> lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>>
> I believe that the point of Roger's message was that you or I may not
> really be downloading the package from TorProject, if we are using SSL
> that is authenticated to a fake certificate.
Thanks.  I'm sure many would appreciate a bit more explanation what 
"...if we are using SSL that is authenticated..." means, in this case.
_______________________________________________
tor-talk mailing list
tor-talk <at> lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk