On Mon, Dec 3, 2012 at 12:20 PM, David Fifield wrote:
> I noticed a change in behavior in cb62a0b69a7d67b427224ca4c3075b49853a3a1f
> or thereabouts. tor opens a new SOCKS connection to a client transport
> plugin while bootstrapping at 50% (if descriptors are not cached) or at
> 85% (if descriptor
On Mon, Dec 3, 2012 at 10:19 PM, Mike Perry wrote:
> Thus spake George Kadianakis (desnac...@riseup.net):
>
>> Hi,
>>
>> - Started researching and developing obfs3, an improved version of the
>> obfs2 pluggable transport. The proposed protocol currently looks
>> like this:
>>
>> https://git
On Fri, Nov 30, 2012 at 12:07 AM, Mike Perry wrote:
> Thus spake Nick Mathewson (ni...@freehaven.net):
>
>> Title: Improved circuit-creation key exchange
>> Author: Nick Mathewson
>>
>> Summary:
>>
>> This is an attempt to translate the proposed circ
On Nov 29, 2012 9:30 PM, "Andrea Shepard" wrote:
>
> Please review first draft proposed parallel relaycrypt structures
> in my parallel_relay_crypt branch.
>
Hi! Here are some initial thoughts:
* If we're going to do it like this, maybe we need to make cell_t
packed or something eventually. I
On Tue, Nov 27, 2012 at 8:42 PM, Nick Mathewson wrote:
> On Tue, Nov 27, 2012 at 12:49 AM, Roger Dingledine wrote:
[...]
>> While I was looking at this design, I thought of a cool attack on
>> 0.2.3 users:
This is now Ticket #7582 on trac.
On Tue, Nov 27, 2012 at 10:08 AM, Julian Yon wrote:
> On Tue, 27 Nov 2012 00:49:28 -0500
> Roger Dingledine wrote:
>
>> (Also, if we have no client-side dns cache, further streams requesting
>> the same address, e.g. fetching pictures from the website, might try
>> the same circuit even if we cou
On Tue, Nov 27, 2012 at 12:49 AM, Roger Dingledine wrote:
> On Sun, Nov 25, 2012 at 07:54:51PM -0500, Nick Mathewson wrote:
>> [tl;dr: We should make client-side DNS cacheing off by default.]
>
> Be careful -- we seem to rely on the client-side dns cache to let us
> move on t
Added as proposal 217; thanks!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi, all.
This is just the ntor proposal draft, as circulated last year, but
with a proposal number assigned to it, and a closing section about how
to make Tor actually work with it.
Filename: 216-ntor-handshake.txt
Title: Improved circuit-creation key exchange
Author: Nick Mathewson
Created
[tl;dr: We should make client-side DNS cacheing off by default.]
On Fri, Jul 20, 2012 at 6:27 PM, Nick Mathewson wrote:
> Filename: 205-local-dnscache.txt
> Title: Remove global client-side DNS caching
> Author: Nick Mathewson
> Created: 20 July 2012
> Status: Open
[...]
F
On Mon, Nov 19, 2012 at 5:18 PM, Ian Goldberg wrote:
> On Mon, Nov 19, 2012 at 05:06:58PM -0500, Nick Mathewson wrote:
>> On Sun, Nov 18, 2012 at 7:43 PM, Andrea Shepard
>> wrote:
>> > I've made some notes on parallelizing cell crypto on relays which I've
>&
On Sun, Nov 18, 2012 at 7:43 PM, Andrea Shepard wrote:
> I've made some notes on parallelizing cell crypto on relays which I've
> attached to this mail and added to the wiki page on this [1], which I
> would like comment on. Particularly, I want to resolve the following
> points:
>
> * Should we
Filename: 215-update-min-consensus-ver.txt
Title: Let the minimum consensus method change with time
Author: Nick Mathewson
Created: 15 Nov 2012
Status: Open
0. Overview
This proposal suggests that we drop the requirement that
authorities support the very old consensus method "1&
On Wed, Nov 7, 2012 at 12:51 AM, Roger Dingledine wrote:
> On Tue, Nov 06, 2012 at 10:10:15PM -0500, Nick Mathewson wrote:
> > > And if a very few do, maybe the solution is to
> > > move to a new TLS connection for those rare cases, rather than impose
> > > a 2-byt
On Tue, Nov 6, 2012 at 9:55 PM, Roger Dingledine wrote:
> On Tue, Nov 06, 2012 at 09:36:34PM -0500, Nick Mathewson wrote:
> >Relays are running out of circuit IDs. It's time to make the field
> >bigger.
>
> I don't doubt the second sentence, but is the fir
Filename: 214-longer-circids.txt
Title: Allow 4-byte circuit IDs in a new link protocol
Author: Nick Mathewson
Created: 6 Nov 2012
Status: Open
0. Overview
Relays are running out of circuit IDs. It's time to make the field
bigger.
1. Background and Motivation
Long ago, we th
Hi, all!
>From the Tor 0.2.4 schedule at
https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/024 :
"""November 20, 2012: Big feature proposal freeze. Any big feature which
requires a design proposal must have its design proposal finished by this
date. If it needs changes after this da
On Thu, Nov 1, 2012 at 1:04 PM, Gisle Vanem wrote:
> These gcc extensions:
>
Hi, Gisle!
I'm happy to open another ticket for these, but have you tried using the
bugtracker yourself? Is there some UI issue or something that prevents you
from opening tickets? If so I'd be glad to try to help wor
On Thu, Nov 1, 2012 at 1:11 PM, Gisle Vanem wrote:
> The code in tools\tor-fw-helper\tor-fw-**helper-natpmp.c does
> things wrong on Winsock where e.g. errno isn't set on socket-errors and
> 'fd' is (always?) >= FD_SETSIZE. Patch attached.
Thanks. I've copied this information to the bugtracker
On Thu, Oct 18, 2012 at 11:18 PM, Mike Perry wrote:
> Thus spake Nick Mathewson (ni...@alum.mit.edu):
>
>> On Thu, Oct 18, 2012 at 6:10 PM, Mike Perry wrote:
>> [...]
>> >> There are modes that are supposed to prevent this, and applying them
>> >> to
On Thu, Oct 18, 2012 at 6:10 PM, Mike Perry wrote:
[...]
>> There are modes that are supposed to prevent this, and applying them
>> to a decent wide-block cipher might solve the issue. IGE is one of
>> them [IGE], but it turns out to be broken by an attacker who knows
>> some plaintext. The Accu
On Tue, Oct 16, 2012 at 6:41 PM, Mike Perry wrote:
> Also available at:
> https://gitweb.torproject.org/user/mikeperry/torspec.git/blob/tolerate-old-consensus:/proposals/xxx-using-old-consensus.txt
>
> --
>
> Title: Increase Acceptable Consensus Age
> Author: Mike P
On Mon, Oct 15, 2012 at 4:38 PM, Mike Perry wrote:
[...]
>> What does that protect against? My first thought is that you're
>> trying to prevent the case where a malicious local DNS server maps
>> "selftest.torproject.org" to some IP address in their control, and
>> then just runs a server at tha
On Thu, Oct 11, 2012 at 5:32 AM, Mike Perry wrote:
> Also at:
> https://gitweb.torproject.org/user/mikeperry/torspec.git/blob/consensus-bootstrap:/proposals/xxx-faster-headless-consensus-bootstrap.txt
>
> -
>
> Title: Faster H
On Thu, Oct 11, 2012 at 5:38 AM, Mike Perry wrote:
> Also at:
> https://gitweb.torproject.org/user/mikeperry/torspec.git/blob/mapaddress-check:/proposals/xxx-mapaddress-tor-status.txt
>
> ---
>
> Title: Internal Mapaddress for Tor Configu
On Mon, Oct 15, 2012 at 2:48 PM, Mike Perry wrote:
[...]
> Again, this experimentation is already done. It's quite clear that
> adding more objects to the world of Guard activity reduces traffic
> fingerprinting accuracy, regardless of if that activity is concurrent
> with client traffic or not.
On Fri, Oct 12, 2012 at 10:53 PM, Mike Perry wrote:
> Thus spake Nick Mathewson (ni...@alum.mit.edu):
>
>> On Fri, Oct 12, 2012 at 3:17 PM, Mike Perry wrote:
>> > Thus spake Nick Mathewson (ni...@torproject.org):
>> >> Discussion:
>> >>
>> &
On Sun, Oct 14, 2012 at 5:03 AM, Christian Grothoff
wrote:
> Hi!
>
> We're trying to compile Tor with cparser and got some warnings and an
> error.
Patch looks okay to me! In the future, it is indeed best to use the
bugtracker. I've added it at
https://trac.torproject.org/projects/tor/ticket/71
On Fri, Oct 12, 2012 at 3:17 PM, Mike Perry wrote:
> Thus spake Nick Mathewson (ni...@torproject.org):
>> Discussion:
>>
>>The rule that the set of guards and the set of directory guards need to
>>be disjoint, and the rule that multiple directory guards
On Thu, Oct 11, 2012 at 5:38 AM, Mike Perry wrote:
> Also at:
> https://gitweb.torproject.org/user/mikeperry/torspec.git/blob/mapaddress-check:/proposals/xxx-mapaddress-tor-status.txt
>
This is now proposal 211.
___
tor-dev mailing list
tor-dev@lists.to
On Thu, Oct 11, 2012 at 5:32 AM, Mike Perry wrote:
> Also at:
> https://gitweb.torproject.org/user/mikeperry/torspec.git/blob/consensus-bootstrap:/proposals/xxx-faster-headless-consensus-bootstrap.txt
>
Added this as proposal 210.
___
tor-dev mailing li
On Thu, Oct 11, 2012 at 5:20 AM, Mike Perry wrote:
> Also exists at
> https://gitweb.torproject.org/user/mikeperry/torspec.git/blob/path-bias-tuning:/proposals/xxx-path-bias-tuning.txt
>
This is now Proposal 209.
___
tor-dev mailing list
tor-dev@lists.t
Filename: 208-ipv6-exits-redux.txt
Title: IPv6 Exits Redux
Author: Nick Mathewson
Created: 10-Oct-2012
Status: Open
Target: 0.2.4.x
1. Obligatory Motivation Section
[Insert motivations for IPv6 here. Mention IPv4 address exhaustion.
Insert official timeline for official IPv6 adoption
Filename: 207-directory-guards.txt
Title: Directory guards
Author: Nick Mathewson
Created: 10-Oct-2012
Status: Open
Target: 0.2.4.x
Motivation:
When we added guard nodes to resist profiling attacks, we made it so
that clients won't build general-purpose circuits through just any
Filename: 206-directory-sources.txt
Title: Preconfigured directory sources for bootstrapping
Author: Nick Mathewson
Created: 10-Oct-2012
Status: Open
Target: 0.2.4.x
Motivation and History:
We've long wanted a way for clients to do their initial
bootstrapping not from the dire
On Tue, Oct 9, 2012 at 12:31 PM, Robert Ransom wrote:
[...]
>> AES-CTR + HMAC-SHA512/256.
>>
>> AES-CTR + Poly1305. Poly1305 requires nonces, but we can use a
>> counter for those.
>
> Poly1305AES requires nonces. Poly1305 itself requires
> (computationally-indistinguishable-from-) indepe
I should share with the list an update of where I am with a design for
an improved relay crypto protocol. For background and motivation,
please see the last thread on the topic [Prop202].
There are three main questions remaining for me in choosing among new
relay crypto protocols. Basically, the
On Sat, Oct 6, 2012 at 10:32 AM, Fabio Pietrosanti (naif)
wrote:
> On 10/1/12 6:49 PM, Nick Mathewson wrote:
>>> Hi, all!
>>>
>>> From https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/024 :
>>>
>>> "October 10, 2012: Big feature p
On Mon, Oct 1, 2012 at 12:49 PM, Nick Mathewson wrote:
> On Mon, Sep 17, 2012 at 11:47 AM, Nick Mathewson wrote:
>> Hi, all!
>>
>> From https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/024 :
>>
>> "October 10, 2012: Big feature proposal checkp
On Mon, Sep 17, 2012 at 11:47 AM, Nick Mathewson wrote:
> Hi, all!
>
> From https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/024 :
>
> "October 10, 2012: Big feature proposal checkpoint. Any large
> complicated feature which requires a design proposal must
On Mon, Sep 24, 2012 at 4:13 AM, Christian Kujau wrote:
> Hi,
>
> while trying to compile the latest git-checkout against openssl-1.0.2,
> I've come across the following issues:
[...]
> While this is really an issue with openssl, I wanted to have this
> documented, just in case anybody else tries
Hi, all!
>From https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/024 :
"October 10, 2012: Big feature proposal checkpoint. Any large
complicated feature which requires a design proposal must have its
first design proposal draft by this date."
There are only 23 days till October 10.
On Fri, Sep 7, 2012 at 5:53 PM, Mike Perry wrote:
> Thus spake Mike Perry (mikepe...@torproject.org):
>> Thus spake Nick Mathewson (ni...@freehaven.net):
>>
>> > Last year, I announced a tenative schedule for 0.2.3.x. We didn't
>> > stick to it, and thin
Hi, all!
Last year, I announced a tenative schedule for 0.2.3.x. We didn't
stick to it, and things have gone a little pear-shaped with getting
0.2.3.x stabilized, but I think with a few tweaks we can use something
similar to get a good schedule out for 0.2.4.x.
My goals remain about what they we
On Tue, Sep 4, 2012 at 10:57 PM, Jacob Appelbaum wrote:
Hi, Jake!
> I think this is a fine plan - my preference is generally to track git
> tip for urras. I'm happy to track whatever branches need experimenting
> or lots of use. I will need to acquire some IPv6 space for the machine
> soon for i
THINGS I DID IN AUGUST
I spent a few days vacationing with my family in Maine; took a day off
for my birthday, and generally chilled out.
I merged lots of bugfixes and patches -- some mine, some other people's,
some requiring rewriting and review, some not. This included some
security-related st
Hi, all!
Here's an idea I had for directory authorities and the 0.2.3 release series.
"As you know Bob," Tor 0.2.3 will be stable very soon, and I'm hoping
not to take any more patches for it except for important security
issues. I want 0.2.4 to come out very early next year. But in the
meantim
On Fri, Aug 10, 2012 at 6:21 PM, Jordi Espasa Clofent
wrote:
> Well, finally it seems a Tor configure.in bug/problem:
>
> http://lists.freebsd.org/pipermail/freebsd-ports/2012-August/077440.html
>
> So.. I guess it has to be fixed by some tor dev then.
Very interesting. That first stanza is inde
On Fri, Aug 10, 2012 at 10:14 AM, Jordi Espasa Clofent
wrote:
> On 08/09/2012 04:54 PM, Nick Mathewson wrote:
>> Have a look near the top of "config.log" (please don't send the whole
>> file; it will be enormous) -- there should be a part that says what
>>
On Thu, Aug 9, 2012 at 6:04 AM, Jordi Espasa Clofent
wrote:
>>
>> Can you see what arguments are being passed to configure, and what
>> configure does with them? Is the freebsd build process passing
>> --with-tcmalloc to the configure script?
>
>
> Sure.
>
> mb# pwd && make showconfig
Hm. Does a
On Wed, Aug 8, 2012 at 7:09 PM, Jordi Espasa Clofent
wrote:
> Here is the log:
>
> ===> Installing for tor-0.2.2.37
> ===> tor-0.2.2.37 depends on file: /usr/local/lib/libcrypto.so.7 - found
> ===> tor-0.2.2.37 depends on shared library: event-2.0 - found
> ===> tor-0.2.2.37 depends on shar
Hi, all!
Michael Backes, Aniket Kate, and Esfandiar Mohammadi have a paper in
submission called, "An Efficient Key-Exchange for Onion Routing".
It's meant to be more CPU-efficient than the proposed "ntor"
handshake. With permission from Esfandiar, I'm sending a link to the
paper here for discussi
On Wed, Aug 8, 2012 at 4:26 PM, Jordi Espasa Clofent
wrote:
>> What line does the build process use when linking Tor?
>
>
> Hi again Nick,
>
> I have no idea, but I guess I could do the next:
>
> 1. Stop the tor service
> 2. deinstall the present port
> 3. Check the tcmalloc option is enabled
> 4.
On Mon, Aug 6, 2012 at 2:06 PM, Jordi Espasa Clofent
wrote:
> On 08/06/2012 07:03 PM, Nick Mathewson wrote:
>>
>> Hm. Tor itself doesn't have a tcmalloc compilation option, so whatever
>> it's doing is something freebsd added. To debug this kind of thing,
>>
On Wed, Aug 8, 2012 at 1:44 PM, Jason A. Donenfeld wrote:
> Fixed in a gentoo bug report:
>
> https://422645.bugs.gentoo.org/attachment.cgi?id=320722
I've added this to the bug tracker at
https://trac.torproject.org/projects/tor/ticket/6575 so that it
doesn't get lost. Thanks!
--
Nick
On Wed, Aug 8, 2012 at 5:04 AM, Roger Dingledine wrote:
> 1) Do we have any requirements to release an 0.2.4.1-alpha at any
> particular date? I haven't been following e.g. the latest SponsorG
> timelines.
>
> 2) Nick was enthusiastic about an 0.2.2.38 with the latest fix. Nick,
> do you still thi
Hm. Tor itself doesn't have a tcmalloc compilation option, so whatever
it's doing is something freebsd added. To debug this kind of thing, what I
usually suggest is to rebuild and look carefully at which compiler and
linker options are used in building Tor, and see if they include the
appropriate
On Wed, Aug 1, 2012 at 2:55 AM, Erinn Clark wrote:
IMO this comes down to the question of: Can we make the alpha TBB
branch stable fast enough to have it be useful for testing? The crash
bugs that Roger mentions make it less than useful anybody trying to
get good testing info for Tor. So if we
Filename: 205-local-dnscache.txt
Title: Remove global client-side DNS caching
Author: Nick Mathewson
Created: 20 July 2012
Status: Open
0. Overview
This proposal suggests that, for reasons of security, we move
client-side DNS caching from a global cache to a set of per-circuit
caches
On Tue, Jul 17, 2012 at 12:24 AM, Linus Nordberg wrote:
> Hi,
>
> Can votes and consensuses have more than one "a" line? Prop 186 says, on
> one hand
>
> [...] votes should include a single "a" line for every relay that has
> an IPv6 address, to include the first IPv6 line in its
> descripto
On Fri, Jul 13, 2012 at 8:14 AM, Gino Badouri wrote:
Hi!
> From the OpenSSL documentation it seems that no-hw and no-engines leaves out
> support for hardware crypto engines so those are safe to set (our devices
> don't have them).
>
> Could anybody provide us with more "no-" options for ciphers
On Wed, Jul 11, 2012 at 11:09 AM, Nick Mathewson wrote:
> Then I see no reason not to accept this proposal. Does anyone else?
>
Actually, there's a detail to think about: Isolation. If I connect to
foo.a.onion bar.a.onion, should those streams be allowed to go
over the s
On Tue, Jul 10, 2012 at 7:24 AM, Karsten Loesing wrote:
> On 7/7/12 7:06 PM, Nick Mathewson wrote:
>> The only part I'm worried about here is that we had once considered
>> doing authenticated hidden services or some other kind of wacky hidden
>>
Looks
On Fri, Jul 6, 2012 at 10:56 AM, Jérémy Bobbio wrote:
> The implementation is pretty straightforward: parse_extended_hostna me() is
> modified to drop any leading components from an address like
> 'foo..onion'.
Looks good except for a few things:
* It needs a "changes"
On Fri, Jul 6, 2012 at 10:23 AM, wrote:
> Hello!
>
> As discussed with a few people at the Florence Hackfest, here's a quick
> proposal
> for subdomain support on Hidden Service addresses. The implementation seems
> pretty
> straightforward (a patch will follow).
>
> Please forgive me if the pr
June was a pretty decent month!
With help from Mike Perry, I finished a couple of rounds of job
interviews, so we could select a new core developer. Let's welcome
Andrea Shepard to the Tor project; she's already off to a great
start, even though she's only part-time for her first couple of
months
Hi all. Here's a proposal for ticket #5548. Let's discuss!
Filename: 203-https-frontend.txt
Title: Avoiding censorship by impersonating an HTTPS server
Author: Nick Mathewson
Created: 24 Jun 2012
Status: Draft
Overview:
One frequently proposed approach for censorship resistan
On Thu, Jun 21, 2012 at 5:05 PM, Gino Badouri wrote:
> Hi there,
>
> My goal is to run Tor on small cluster of embedded mips devices.
> Because the platform runs on an older version of OpenSSL and libevent I have
> chosen to statically link them with Tor.
>
> So I went ahead to compile the compone
Hi, all.
I have forked off a maint-0.2.3 and a release-0.2.3 branch in the
usual fashion, and incremented the version in the master branch to
"0.2.4.0-alpha-dev".
All branches targeted for inclusion in Tor 0.2.3.x should now be based
on "maint-0.2.3"; all branches targeted for inclusion in 0.2.4
On Tue, Jun 19, 2012 at 2:06 PM, Robert Ransom wrote:
> On 6/19/12, Nick Mathewson wrote:
>> Filename: 202-improved-relay-crypto.txt
>
>> Any new approach should be able to coexist on a circuit
>> with the old approach. That is, if Alice wants to build a
>>
Filename: 202-improved-relay-crypto.txt
Title: Two improved relay encryption protocols for Tor cells
Author: Nick Mathewson
Created: 19 Jun 2012
Status: Open
Overview:
This document describes two candidate designs for a better Tor
relay encryption/decryption protocol, designed to stymie
On Mon, Jun 18, 2012 at 8:30 PM, Jacob Appelbaum wrote:
> On 06/18/2012 11:26 PM, Nick Mathewson wrote:
>> This list of open Tor proposals is based on one I sent out in May of
>> last year. Since I'd like to do this more regularly, I have added to
>> each descriptio
On Mon, Jun 18, 2012 at 10:40 PM, ahmed wrote:
> On Mon, 2012-06-18 at 17:26 -0400, Nick Mathewson wrote:
>> 194 Mnemonic .onion URLs
>
> Hello:
>
> I made a post about that topic in February, and it seems no one was
> interested. I can implement a dictionary compi
This list of open Tor proposals is based on one I sent out in May of
last year. Since I'd like to do this more regularly, I have added to
each description the date when I wrote it. Most of the summaries from
older proposals are unchanged since last May; the later ones in the
list for 6/2012 I wr
uces a
notion of "consensus flavors" such that any every consensus
vote produces a signed consensus in all the formats, caches
cache all the formats, and clients download only those they
need.
(Proposal 158 by Roger Dingledine, revised a bunch by Nick
Mathew
On Wed, Jun 13, 2012 at 7:26 PM, Zack Weinberg wrote:
> Why is the process of going into daemon mode (on Unix) split into two
> functions, start_daemon and finish_daemon?
It's been so long since we added that code; I hope I remember.
If I've got it right, the idea is that you call start_daemon()
On Mon, May 14, 2012 at 2:04 AM, Karsten Loesing wrote:
> Hi Beck,
>
> I don't have good answers to your questions. To be honest, when I
> implemented the Java verification code for #2768, I looked for hints in
> an old Java version of Tor, rewrote that code, updated it for current
> BouncyCastle
On Thu, May 10, 2012 at 4:31 AM, Karsten Loesing wrote:
> Hi Nick,
>
> here is the proposal as discussed in #5807 to improve our bridge usage
> statistics.
>
> Thanks,
> Karsten
This is now proposal 201. Thanks!
___
tor-dev mailing list
tor-dev@lists.t
On Fri, May 4, 2012 at 7:52 AM, Gisle Vanem wrote:
> MSVC doesn't have . Hence this little patch is needed:
Applied; thanks!
--
Nick
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Thu, Apr 26, 2012 at 4:37 PM, Esteban Manchado Velázquez
wrote:
> On Thu, 26 Apr 2012 09:09:09 +0200, Gisle Vanem wrote:
>
>> The src/test/test_util.c doesn't compile with MSVC (CL ver.
>> 16.00.30319.01).
>> It doesn't like the "#ifdef 0" construct, but the whole chunk should be
>> enabled wi
On Sun, Mar 25, 2012 at 1:02 AM, David Fifield wrote:
> I found a little typo in proposal 180.
>
> David Fifield
Thanks; just merged it.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Mon, Mar 26, 2012 at 3:17 AM, Robert Ransom wrote:
[...]
>> (OpenSSL before 1.0.0 did not support ECDHE ciphersuites; OpenSSL
>> before 1.0.0e or so had some security issues with them.)
>
> Can Tor detect that it is running with a version of OpenSSL with those
> security issues and refus
Filename: 200-new-create-and-extend-cells.txt
Title: Adding new, extensible CREATE, EXTEND, and related cells
Author: Robert Ransom
Created: 2012-03-22
Status: Open
History
The original draft of this proposal was from 2010-12-27; nickm revised
it slightly on 2012-03-22 and added it as proposa
On Tue, Mar 20, 2012 at 11:57 PM, Jacob Appelbaum wrote:
[...]
> Ah ha. That sounds like a nightmare. Is there a bug report we can pile
> on to request that they don't create a headache for everyone in the future?
There is, but I don't currently see much point: their developers are
irritated, and
Jacob sent me this message in reply to my last; sending to tor-dev
with permission.
On Tue, Mar 20, 2012 at 11:57 PM, Jacob Appelbaum wrote:
> On 03/20/2012 08:14 PM, Nick Mathewson wrote:
>> On Tue, Mar 20, 2012 at 9:30 PM, Jacob Appelbaum wrote:
>>> On 03/20/2012 08:33
Forgot to send this to tor-dev: ouch. Sending now.
On Tue, Mar 20, 2012 at 9:30 PM, Jacob Appelbaum wrote:
> On 03/20/2012 08:33 AM, Nick Mathewson wrote:
>> Filename: 198-restore-clienthello-semantics.txt
>> Title: Restore semantics of TLS ClientHello
>> Author: Nick Mat
On Tue, Mar 20, 2012 at 10:48 PM, Tom Ritter wrote:
> On 20 March 2012 11:33, Nick Mathewson wrote:
>> Filename: 198-restore-clienthello-semantics.txt
>> Title: Restore semantics of TLS ClientHello
>> Author: Nick Mathewson
>> Created: 19-Mar-2012
>> Status:
Filename: 198-restore-clienthello-semantics.txt
Title: Restore semantics of TLS ClientHello
Author: Nick Mathewson
Created: 19-Mar-2012
Status: Open
Overview:
Currently, all supported Tor versions try to imitate an older version
of Firefox when advertising ciphers in their TLS ClientHello
On Fri, Mar 16, 2012 at 8:15 PM, Mike Perry wrote:
> Ugh.. Without the annoying tabs:
>
Added as proposal 197. Thanks!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ports.txt
> Title: Extended ORPort and TransportControlPort
> Author: George Kadianakis, Nick Mathewson
> Created: 14 Mar 2012
> Status: Open
> Target: 0.2.4.x
Thanks! I have added this as proposal 196.
___
tor-dev mailing list
tor-dev@list
On Fri, Mar 9, 2012 at 5:01 AM, George Kadianakis wrote:
[...]
>
> Hm, when I thought of 'WANT_CONTROL', I was considering that there
> might be transports that absolutely _require_ the use of
> TransportControlPort. Since we don't have such transports at the
> moment, and the short-term future tr
On Sat, Mar 10, 2012 at 9:22 AM, Ondrej Mikle wrote:
> Hi all,
>
> the DNS/DNSSEC resolving draft for seems to be finished.
Hi, Ondrej! I've got a few questions and comments. I might have more
once I've thought a little more about the issues on this.
> I added a few thoughts on mitigating cir
On Fri, Mar 9, 2012 at 8:03 PM, Robert Ransom wrote:
>
> Users need to specify a full certificate chain, not just the
> end-entity certificate.
Agreed that this is desirable, but if we take that route, we need to
amend the current rule for deciding whether to use the v3/v2 vs the v1
handshake. C
On Fri, Mar 9, 2012 at 7:18 PM, George Kadianakis
[...]
> What is the reason we don't like session resumption? Does it still
> makes sense to keep it disabled even after #4436 is implemented?
The main reason not to support session resumption is that, as noted
later in this thread, it can require
Filename: 195-TLS-normalization-for-024.txt
Title: TLS certificate normalization for Tor 0.2.4.x
Author: Jacob Appelbaum, Gladys Shufflebottom, Nick Mathewson, Tim Wilde
Created: 6-Mar-2012
Status: Draft
Target: 0.2.4.x
0. Introduction
The TLS (Transport Layer Security) protocol was designed
On Thu, Jan 26, 2012 at 8:38 PM, George Kadianakis wrote:
> After discussion in tickets #4773 and #3587 this is a pre-draft of a
> proposal that revamps the Extended ORport, introduced in proposal 180,
> and specifies the new TransportControlPort.
>
> Comments are marked with '#', and there is als
On Sat, Feb 11, 2012 at 7:12 AM, Esteban Manchado Velázquez
wrote:
> Hi there,
>
> I'm done with the first batch of work on the test side. You have the
> (rebased just now) work here:
> https://github.com/emanchado/tor/commits/master.
A suggestion: In the future, it's best to do commits on one or
On Tue, Feb 7, 2012 at 7:33 PM, Ondrej Mikle wrote:
> On 02/07/2012 07:18 PM, Nick Mathewson wrote:
>> part of the relay cell header should already fulfill this role, if I'm
>> understanding the purpose of "ID" correctly.
>
> You're understanding t
On Sat, Feb 4, 2012 at 10:38 PM, Ondrej Mikle wrote:
> On 02/01/2012 10:01 AM, Jacob Appelbaum wrote:
>>
>> That sounds good. I'll wait for the first draft and send feedback.
>
> First draft is ready here:
>
> https://github.com/hiviah/torspec/blob/master/proposals/ideas/xxx-dns-dnssec.txt
Cool!
On Sun, Feb 5, 2012 at 7:46 AM, Robert Ransom wrote:
> See attached, because GMail would wrap lines if I sent it inline.
Added as proposal 193.
This seems like a general case of "A and B prove to each other that
they both know some secret S without revealing S." Are there existing
protocols for
601 - 700 of 796 matches
Mail list logo
