[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tor-talk] 100-Foot Overview on Tor



On 06 May (19:28:38), teor wrote:
> > 
> > Date: Tue, 5 May 2015 18:49:39 -0500
> > From: Tom Ritter <tom@ritter.vg>
> > 
> > On 5 May 2015 at 07:53, Fabian Keil <freebsd-listen@fabiankeil.de> wrote:
> >> Great.
> >> 
> >> A couple of comments (about v1.3):
> > 
> > Thanks! I made the changes and put up a 1.4
> > 
> >> Page 141 and 142 seem to suggest that parsing strings is more
> >> likely to be vulnerable than parsing binary data. Is that intended?
> > 
> > No but mostly yes. It's more a surprise factor: when I tell people tor
> > uses HTTP to upload and download things, they're not surprised - when
> > I tell them it has its own HTTP server implementation that does all
> > the parsing of the requests, they're much more surprised.  I'm not
> > saying tor's code is insecure (I put up a $bounty inside my company
> > with my own money to anyone who finds a bug in it actually) - but
> > implementing your own HTTP server is not a recommended action. :)
> > 
> >> Is the source of the PDF available under a free license?
> >> 
> >> I'm currently preparing a (German) presentation about location
> >> hidden block storage and could reuse the HS-related parts:
> >> http://chaos.cologne/Fahrplan/events/6653.html
> > 
> > It's (now) http://creativecommons.org/licenses/by-sa/4.0/
> > 
> > As far as the sources.... well, I made it in keynote. Yes, I know I'm
> > a bad person. I can export it as powerpoint, html, images, or pdf and
> > send you any one of those five. (Or all of them.)
> 
> Hi Tom,
> 
> Some further feedback:
> 
> Page 20:
> Can you explain why you say that consensuses are valid for 24 hours, and not 3 hours?

Indeed, according to dir-spec.txt, see section "1.4 Voting timeline",
there is an explanation. The current tor code actually randomize some of
those values to be in a specific range that is not more than 3 hours
(iirc).

> 
> Page 113:
> I think there are 3 relays between the client and introduction point, not 2.
> In new_route_len(), each circuit with an endpoint chosen by another relay gets an extra hop, and the hidden service chooses the introduction point, not the client.
> 
> I could be wrong about this - the path code has a few special cases that I haven't quite got my head around.

Yes you are right. Not only that but if the first introduction point
fails (client side), the circuit is re-extended to the second intro
point and so on until it works or the the maximum limit of 7 hops is
reached.

That's maybe a bit too deep to explain in the slides so I guess 4 hops
Client <-> Intro is good enough. :)

Tom, those slides are great! Impressive job! Thanks for this.

David

> 
> teor
> 
> teor2345 at gmail dot com
> pgp 0xABFED1AC
> https://gist.github.com/teor2345/d033b8ce0a99adbc89c5
> 
> teor at blah dot im
> OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
> 



> -- 
> tor-talk mailing list - tor-talk@lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Attachment: signature.asc
Description: Digital signature

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk