[tahoe-dev] Troubleshooting node connectivity

[Nathan]

This is a tangent on a (freely available) TLS analysis tool I use at
work, and how it works with the web's PKI security model but fails
with Foolscap's end-to-end security model.

I don't think this is necessary for Shawn's purpose (probably foolscap
diagnostics are much better), but here's a quick plug:

My coworker Brad Hill wrote the Cybervillains CA [1] tool which is a
library for executing TLS interception attacks (aka MitM [2]).  It
does not do anything funky with certificates to take advantage of
client implementation vulnerabilities.  Rather it simply creates a new
certificate (signed by a custom CA).

So, for the PKI trust model, you can either tell your client the funky
cert is ok, *or* if you do this all day long, you can tell your client
to trust the custom CA as a root cert.  Because clients like web
browsers trust *any* CA in the root list equally, they cannot notice
this interception attack.

For foolscap, my understanding is that this would not work, because
FURLs include a certificate fingerprint.  This ties authentication
end-to-end in a manner that assumes secure introduction, ie: If I
received a FURL from an authenticated, trustworthy source, then the
resulting connection has transitively bootstrapped authentication.  In
the case of the CybervillainsCA interception attack, there's no 3rd
party CA pool which can be abused, so this tool is thwarted.


[1] The CybervillainsCA page:
http://isecpartners.com/cybervillainsca.html

Also a plug for our other freely available tools:
http://isecpartners.com/tools.html

[2] I advocate "interception attack" in favor of "Man in the Middle"
because it is more descriptive (ie: messages are intercepted, but what
does a Man in the Middle do?) and it is gender neutral (ie: are you
sure it's not a woman, a dog, a buggy proxy, or Skynet in the
middle?).  Alas, nomenclature change is hard.  (See also other worse
misnomers: CSRF, XSS.)



On Tue, Sep 8, 2009 at 7:40 PM, Zooko O'Whielacronx <zookog at gmail.com> wrote:
>  On Tue, Sep 8, 2009 at 6:27 AM, Shawn Willden<shawn at willden.org> wrote:
>> Any idea what the problem might be?  What can I do to get more visibility into
>> what connections Tahoe is attempting to make (and failing)?
>
> I'll try to address your second question.  :-)  Wireshark is an
> excellent tool, and not too hard to learn to use (if you aren't
> already familiar with it).  Using it can give you "traffic analysis"
> information about the connection pattern -- who sends which TCP setup
> packets to whom, timing of retries, etc..  I think wireshark might
> also be able to do a MITM attack on your SSL connections for you (if
> you provide it with the private key), but I'm not sure, and in any
> case that would be overkill for this purpose.
>
> At the same time, turn on logging:
>
> http://allmydata.org/trac/tahoe/browser/docs/logging.txt
>
> Hm I wonder what the status of this comment is: "[TODO: not yet true,
> requires foolscap-0.3.1 and a change to allmydata.node]".
> Nonetheless, most of the content of logging.txt should help you.
> flogtool tail in particular will make all loggable events visible to
> you, so you can correlate those with things like which nodes are
> connecting to each other and when.
>
> Oh, and I guess the very first thing to do would be to look in your
> incidents directory and examine any incident files you find therein.
> They are (as far as I know) clean of secrets so you can attach them to
> a ticket and ask others to look at them too.
>
> Regards,
>
> Zooko
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at allmydata.org
> http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
>