Op 30/06/16 om 21:31 schreef Nima Fatemi:
> Tom van der Woerdt:
>> How about a conf.d style folder that plugins like bridges can drop files in?
>>
>> $ yum install -y obfs4proxy
>> ...
>> $ cat /etc/tor/torrc.d/obfs4.conf
>> ServerTransportPlugin obfs3
How about a conf.d style folder that plugins like bridges can drop files in?
$ yum install -y obfs4proxy
...
$ cat /etc/tor/torrc.d/obfs4.conf
ServerTransportPlugin obfs3,obfs4 exec /usr/bin/obfs4proxy managed
ServerTransportListenAddr obfs4 0.0.0.0:9013
ServerTransportListenAddr obfs4 0.0.0.0:901
Hi Razvan,
The consensus has signatures from all directory operators on it, and computing
those ahead of time requires a lot of private keys. Because they also all
contain the date, they're all unique. So yea, they're both unique and
unpredictable.
As for your idea: it should be noted that th
I can do it. I already package my own RPMs, so I may as well do that properly.
No ldap account though.
Tom
> On 16 Jun 2016, at 15:06, Nick Mathewson wrote:
>
> Hi, all!
>
> Ondrej Mikle, who has built our RPMs for a while, is no longer able to
> do so. (He isn't using RPM distros any more
Hi Patrick,
No, the protocol does not support this. The only command separator is a
newline. Implementing this would likely be hard anyway, as the output of
the double command would be hard to parse.
Tom
Op 10/01/16 om 18:02 schreef Patrick Schleizer:
> TLDR:
>
> Does Tor's control protocol ac
this here, I argue that the ports a relay makes available
> should not impact whether they get the exit flag. This is consistent
> with treating Tor as a mechanism instead of applying top-down a policy
> for how people are "supposed" to use it.
>
> -V
>
>
>
> On
Op 05/01/16 om 10:22 schreef Tim Wilson-Brown - teor:
>
>> On 5 Jan 2016, at 19:33, Tom van der Woerdt > <mailto:i...@tvdw.eu>> wrote:
>> ...
>> Op 05/01/16 om 02:15 schreef Tim Wilson-Brown - teor:
>>>
>>>> On 5 Jan 2016, at 11:29, Tom v
Hi Tim,
Thanks for your comments! Appreciated as always :-)
Op 05/01/16 om 02:15 schreef Tim Wilson-Brown - teor:
>
>> On 5 Jan 2016, at 11:29, Tom van der Woerdt > <mailto:i...@tvdw.eu>> wrote:
>> ...
>> 2.1. Exit flagging
>>
>> By replacing the
0,443,5222]
for Exit flagging.
===
Filename: 264-exit-flag-not-all-plaintext.txt
Title: Stop giving Exit flags when only unencrypted traffic can exit
Author: Tom van der Woerdt
Created: 2016-01-05
Status: Open
1. Introduction
Tor's Exit flags are assigned to relays that have
> On 21 Oct 2015, at 00:18, Alec Muffett wrote:
>
> So I’ve just had a conversation with dgoulet on IRC, which I will reformat
> and subedit here as a conversation regarding OnionBalance and issues in 2.6
> and 2.7 when a recently rebooted HS publishes a fresh descriptor:
>
> […]
>
> alecm:
Op 04/10/15 om 06:46 schreef Tim Wilson-Brown - teor:
On 3 Oct 2015, at 13:34, Tom van der Woerdt mailto:i...@tvdw.eu>> wrote:
...
3. Compatibility and security
The implementation of these methods should, ideally, not change
anything in the network, and all control changes are opt-in, s
Op 02/10/15 om 14:56 schreef Tim Wilson-Brown - teor:
On 2 Oct 2015, at 14:43, Tom van der Woerdt mailto:i...@tvdw.eu>> wrote:
Hi Tim,
Thanks for your great comments, very much appreciated!
Comments inline.
Op 30/09/15 om 19:40 schreef Tim Wilson-Brown - teor:
On 30 Sep 2015, at
Hi Tim,
Thanks for your great comments, very much appreciated!
Comments inline.
Op 30/09/15 om 19:40 schreef Tim Wilson-Brown - teor:
On 30 Sep 2015, at 17:27, Tom van der Woerdt mailto:i...@tvdw.eu>> wrote:
...
Filename: xxx-intro-rendezvous-controlsocket.txt
Title: Load-bal
Hey all,
I'd like your thoughts and comments on this proposal.
Tom
PS: If you want to deliver them in person, I'm in Berlin.
Filename: xxx-intro-rendezvous-controlsocket.txt
Title: Load-balancing hidden services by splitting introduction from
rendezvous
Author: Tom van
Op 12/07/15 om 23:48 schreef John Brooks:
Hello!
George and I, along with the other participants of this hidden services
meeting, have written a proposal for the idea to merge hidden service
directories and introduction points into the same entity along with proposal
224.
Comments are encourage
Hey Jeff,
Definitely very interesting and it's nice to see namecoin and friends in the
Tor context.
Questions :
* are those directives handled on the relay or the client? If relay, how will
the client know which node to talk to?
* please don't add support for .exit here, external parties sho
> On 13 Sep 2015, at 22:09, teor wrote:
>
>
>> On 13 Sep 2015, at 18:18, Sean Saito wrote:
>>
>> >"No Self-Referencing Relays"
>>
>> >I'm not sure what exactly you mean by that but I assume it is a MyFamily
>>
>> >config where a relay includes his own fingerprint. Why does that hurt?
>>
>>
On 10 Sep 2015, at 12:37, tordev...@safe-mail.net wrote:
>>> 3. Additional RELAY_COMMAND_* types for clients to request out-of-band
>>> HMAC request cells for Proposal 253.
>
> Do you need to request that data? How about always sending it from middle
> nodes? (Less leakage about the client.)
>
Op 10/09/15 om 04:10 schreef Mike Perry:
I'm writing a handful of proposals that need to introduce either new
cell sub-payloads or new command types. Specifically, I want to add:
1. Sub-fields to CELL_PADDING to allow clients to tell relays about the
amount of link padding they want for Proposal
I'm not a big fan of automated systems that ban authorities as it may get false
positives and it may be gamed and/or attacked.
An alternative solution is to make the voting a two-step system: first you
publish the sha256 hash of your vote, then a few minutes later you publish the
actual vote.
grarpamp schreef op 16/07/15 om 19:21:
There are about 350 places in tor and torspec that are afflicted
by this ism, other locations surely exist...
find . -type f -exec egrep -i ' ' {} \+
Why is it wrong?
https://en.wikipedia.org/wiki/If_and_only_if
smime.p7s
Description: S/MIME-cryptogra
Magnus Hedemark schreef op 11/07/15 om 04:35:
Hello,
I have set up a Jenkins CI server and have it tracking the Tor project's
git repository. I'm going to be building packages for the OmniOS
platform, which is not yet supported. I tried searching the site for
advice for packagers but haven't fou
Philipp Winter schreef op 12/01/15 om 20:14:
On Mon, Jan 12, 2015 at 06:57:01PM +0100, Tom van der Woerdt wrote:
23% is a lot though - so high that I really doubt it's true. The
ratios between handshakes and deduplicated handshakes is also rather
strange. Is there anything we can do t
David Fifield schreef op 12/01/15 om 18:46:
On Mon, Jan 12, 2015 at 06:26:14PM +0100, Tom van der Woerdt wrote:
On 12 Jan 2015, at 16:25, Philipp Winter wrote:
Versions | Amount total | Amount w/o duplicate hosts
-+---+---
1 and 2 | 34,648
> On 12 Jan 2015, at 16:25, Philipp Winter wrote:
>
>> On Sat, Dec 27, 2014 at 03:38:28PM +0100, Tom van der Woerdt wrote:
>> After reading the Tor spec [1] I did some digging and realized that
>> the old handshakes and link protocols (v1 (certs up-front) and v2
>
Nick Mathewson schreef op 02/01/15 om 15:27:
On Mon, Dec 29, 2014 at 3:33 PM, Tom van der
Woerdt wrote:
Sounds good!
I spent some time writing a patch that removes v1 of the link protocol from
both the server and client, and so far it seems to work nicely: the code
compiles nicely, all test
Nick Mathewson schreef op 29/12/14 om 00:50:
On Sat, Dec 27, 2014 at 9:38 AM, Tom van der Woerdt wrote:
Hi all,
After reading the Tor spec [1] I did some digging and realized that the old
handshakes and link protocols (v1 (certs up-front) and v2 (renegotiation))
are not used anymore as of
Hi all,
After reading the Tor spec [1] I did some digging and realized that the
old handshakes and link protocols (v1 (certs up-front) and v2
(renegotiation)) are not used anymore as of 0.2.3.6-alpha which
introduced link proto v3.
Supporting v1 and v2 requires (among other things) supportin
28 matches
Mail list logo
