Holy shit I caught 1

[Matthias Fischmann]

On Tue, Aug 29, 2006 at 11:35:28AM +0200, Christian Kellermann wrote:
> To: Nick Mathewson <nickm at freehaven.net>, or-talk at freehaven.net
> From: Christian Kellermann <Christian.Kellermann at nefkom.net>
> Date: Tue, 29 Aug 2006 11:35:28 +0200
> Subject: Re: Holy shit I caught 1
> 
> * Nick Mathewson <nickm at freehaven.net> [060828 19:07]:
> > On Mon, Aug 28, 2006 at 09:34:38AM +0200, Christian Kellermann wrote:
> > > Hi,
> > > 
> > > * Nick Mathewson <nickm at freehaven.net> [060828 04:44]:
> > > > Another note: if people want to continue running these checks against
> > > > exits (and I hope you do!) I'd suggest you keep what, exactly, you're
> > > > checking for a secret until *after* you run each round of tests.  Then
> > > > announce the results, release the source, and think of more stuff to
> > > > test for.  Releasing the source will help other people check out
> > > > whether the network is behaving correctly, but keeping mum about what
> > > > you're checking for will keep dishonest/broken people from changing
> > > > their behavior before you can find them out.
> > > 
> > > That security by obscurity approach won't work. If someone trys to
> > > attack the tor network we should assume that this person knows what
> > > he/she is doing. So keeping the test method a secret will hinder the
> > > good guys from making sure that this old attack does not persist any
> > > more.
> >  [...]
> > 
> > Errr.  I'm afraid I can't agree here.  The term "security through
> > obscurity" is generally reserved for attempts to keep a vulnerability
> > secret in hopes that attackers won't notice it.   You are correct that
> > such approaches aren't stable, but that's not what I was advocating.
> > 
> Oh, I've misunderstood your point then. Apologies for that.
> 
> > Instead, I was suggesting that if you come up with a way to check for
> > a previously non-checked attack, it makes sense to run the scan before
> > you announce the scan.  Otherwise, you're giving people notice that an
> > attack that they were (possibly) previously getting away will soon be
> > detected.  Once you've got initial results, it makes more sense to
> > distribute the scanning code so others can improve it.
> 
> I still don't see the difference of this approach compared to the
> usual implementation cycle with tor. Maybe there is none after all?
> As soon as you implement checks in tor, people will know what to
> look out for. I assumed that you indeed do some testing before
> incorporating such tests.
> 
> In this thread's case, saying "I've found some way to detect man in the
> middle attacks" won't make an attacker more alert than a svn checkin
> message, would it?
> 
> I am sure we both agree, that it is always better to test a method
> before publishing it, avoiding confusion about what is possible and
> what is just bla bla...

i think there is still a misunderstanding: nick was saying that if you
want to go on a hunt for malicious nodes, you don't want to publish
what scanning methods you are using before you do that.  the order
should rather be something like this:

  * write a script to detect men in the middle
  * run it in secret obscurity
  * publish the script and whatever you shot on your hunt
  * start talking about how to harden the network in public

does this clarify things further?  or was it already obvious to everybody?
matthias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20060830/5d9b9886/attachment.pgp>