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 <[email protected]> wrote: > On Tue, Sep 8, 2009 at 6:27 AM, Shawn Willden<[email protected]> 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 > [email protected] > http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev > _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
