Re: [tor-dev] Development of an HTTP PT

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17/11/13 14:22, dardok wrote: > Hi, > > I've been reading about Selenium web-browser driver thing and I > consider that is not very handy to do what an HTTP PT client side > needs, that is to forge HTTP requests and embbed the TOR traffic into >

[tor-dev] Development Calendar

Hello humans, I know that meetings and scheduling are a pain. That sucks. Here's a calendar of our regular meetings, which might make it easier: I hope that helps a bit. Her

Re: [tor-dev] obfsproxy buffering

yeah... you are right! Thanks for the clarification. I've been meaning to read the Stegotorus paper soon. Cheers! David On Mon, Nov 18, 2013 at 9:24 AM, Zack Weinberg wrote: > On Mon, Nov 18, 2013 at 10:47 AM, David Stainton > wrote: >>> Super-simple framing protocols often fall victim to at

[tor-dev] Speeding Up Tor with SPDY

Dear all, Andrey Uzunov's Master's thesis on "Speeding Up Tor with SPDY" is now available at https://gnunet.org/content/speeding-tor-spdy My personal conclusions are that SPDY PUSH should not be used with Tor, and that modest performance gains with SPDY are attainable for typical websites. Aside

Re: [tor-dev] Apple App Store Redux

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2013 02:07 PM, Nathan Freitas wrote: > Now, mobile is different, because the behaviors of users looking > to find and install software is quite different than on the > web/desktop. As a side note, for those interested, we are really investing

Re: [tor-dev] Apple App Store Redux

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2013 01:39 PM, Erinn Clark wrote: > * Ralf-Philipp Weinmann [2013:11:17 10:25 > +0100]: >>> Getting TBB into the App Store would definitely help increase >>> its visibility on the OSX side. However, I am not really in >>> favour of giving a U

Re: [tor-dev] Apple App Store Redux

* Fabio Pietrosanti (naif) [2013:11:17 11:08 +0100]: > I think, as already discussed here [1] and [2], that TBB *must* goes in > all kind of application store. Please see Ralf's reply to me elsewhere in the thread -- do you still think this while taking into account what we know about US compani

Re: [tor-dev] Apple App Store Redux

* Ralf-Philipp Weinmann [2013:11:17 10:25 +0100]: > Getting TBB into the App Store would definitely help increase its visibility > on > the OSX side. However, I am not really in favour of giving a US company a list > of all users having downloaded TBB plus information whether or not they are >

Re: [tor-dev] obfsproxy buffering

On Mon, Nov 18, 2013 at 10:47 AM, David Stainton wrote: >> Super-simple framing protocols often fall victim to attacks in which the >> adversary messes with the length in the frame header. See, for example, >> "Plaintext Recovery Attacks Against SSH": >> http://www.isg.rhul.ac.uk/~kp/SandPfinal.p

Re: [tor-dev] obfsproxy buffering

>> It seems like the solution is to write a super simple "framing >> protocol"... which is to say that I can first send a frame length; and >> on the receiving end simply read until frame length worth of data is >> consumed... and then apply the crypto_stream cipher on that frame with >> the correc

Re: [tor-dev] obfsproxy buffering

> Super-simple framing protocols often fall victim to attacks in which the > adversary messes with the length in the frame header. See, for example, > "Plaintext Recovery Attacks Against SSH": > http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf > > So be careful here. > >- Ian Over Tor it won't be

Re: [tor-dev] obfsproxy buffering

On Sun, Nov 17, 2013 at 07:33:12PM -0800, David Stainton wrote: > Hi, > > I noticed that because the obfsproxy api can sometimes buffer and > resend smaller chunks of data. My simple use of Nacl stream_crypto to > wrap each incoming data buffers will not work... that is because the > client and se

Re: [tor-dev] Fwd: Stem Tor - Establish a user defined circuit

On Saturday 16 November 2013 20:02:26 Damian Johnson wrote: > Hi Aravindan. I haven't personally done much work with manual path > selection, but RTT Prober does. I'd suggest looking at it as an > example... > > https://bitbucket.org/ra_/tor-rtt/src/3a2ef9343d3054b8bcf37877d81d926400ed8 > 512/rttp

Re: [tor-dev] obfsproxy buffering

On Sun, Nov 17, 2013 at 07:33:12PM -0800, David Stainton wrote: > It seems like the solution is to write a super simple "framing > protocol"... which is to say that I can first send a frame length; and > on the receiving end simply read until frame length worth of data is > consumed... and then app

Re: [tor-dev] next globe update feedback

On 11/8/13 2:59 AM, Matthew Finkel wrote: > On Thu, Nov 07, 2013 at 03:33:23PM -0500, m...@rndm.de wrote: >> I also added relay family links. While working on this feature I noticed >> that the onionoo family field can return fingerprints of bridges. >> I modified the way the relay details route w