Well I think this is a great feature and it's something which people have
been requesting for a while now, and which I know was discussed at the PT
meeting at the last TorDev. I think this is the sort of feature that just
makes transports better for everyone, both transport designers and
applicatio
new transports as they are developed.
On Mon, Oct 15, 2018 at 4:52 PM teor wrote:
> Hi Brandon,
>
> On 16 Oct 2018, at 02:59, Dr. Brandon Wiley wrote:
>
> If you are looking for information about Pluggable Transports, the
> Pluggable Transports website has up-to-date in
If you are looking for information about Pluggable Transports, the
Pluggable Transports website has up-to-date information:
https://www.pluggabletransports.info/
If you want to follow the specification process, drafts and proposal are
available here:
https://github.com/Pluggable-Transports/Pluggab
Hello Jodi. I would like to point out some additional resources for you if
you are interested in Pluggable Transports. First of all check out
https://www.pluggabletransports.info/.
Also, some work has been done in the past on audio data as a transport.
There is of course the venerable SkypeMorph (
used if the connection settings are not correct for the specific
transport being used.
Example
\x00\x00\x00\x39{"shared-secret": "rahasia", "secrets-file": "/tmp/blob"}
On Thu, Oct 12, 2017 at 2:38 PM, Brandon Wiley wrote:
> Below is
Below is a link to the third draft of the Pluggable Transport 2.0
Specification. If you have feedback on this draft, please send me your
comments by October 31. Thank you!
Changes in this version:
- Expanded acknowledgements section - thanks Yawning!
- Removed TransportConn and TransportLis
. following the general principle set forth in the
specification document to make the transport library look as much as
possible like the native socket implementation for the language.
On Tue, Jun 20, 2017 at 10:16 PM, teor wrote:
>
> > On 21 Jun 2017, at 04:07, Brandon Wiley wrote:
> >
Thanks for the feedback. I'll fix this in the next draft.
On Jun 20, 2017 6:07 PM, "Yawning Angel" wrote:
> On Tue, 20 Jun 2017 14:07:39 -0400
> Brandon Wiley wrote:
>
> > Attached is the second draft of the Pluggable Transport 2.0
> > Specification. If you
how to implement a transport
in Go
● Removed unused Javascript and Python APIs
● Removed SSH transport example
● Standardized use of Transports API and Dispatcher IPC language throughout
● Added length to per-connection parameter encoding
On Tue, Jun 20, 2017 at 2:07 PM, Brandon Wiley wrote
Hi Yawning. Thank you for providing these links. This is very helpful. I
will make sure that these issues are discussed at the next specification
meeting.
On Mar 28, 2017 8:36 AM, "Yawning Angel" wrote:
> On Mon, 27 Mar 2017 04:03:47 -0500
> Brandon Wiley wrote:
> > I am
work at all and
> I won't be the one implementing this regardless of what happens, so
> feel free to disregard this.
>
> On Sun, 26 Mar 2017 04:48:44 -0500
> Brandon Wiley wrote:
> > As was discussed in the Pluggable Transports session at TorDev
> > Amsterda
As was discussed in the Pluggable Transports session at TorDev Amsterdam, the
Pluggable Transports 2.0, draft 1 specification [https://www.
pluggabletransports.info/spec/pt2draft1] was created by a committee of
censorship circumvention tool developers: Tor, Lantern, Psiphon, and
uProxy. It specifie
Excellent work on the rewrite. To summarize for those that do not have time
to read the whole document, it's the same spec, it's just been rewritten to
read more clearly. I think it's a great improvement over the previous
version.
I have two suggestions:
Section 4, "Tor Configuration", I think sh
It is my understanding that a sponsored project is coming up to work a
pluggable transport 2.0 specification and implementation. I've also heard
that the first step for this is to have a meeting where we get together
with people that either use pluggable transports or implement them, for the
purpos
On Thu, Sep 10, 2015 at 12:55 AM, Yawning Angel
wrote:
>
> FWIW, I don't particularly think that there must be One True PT
> language[0], I just recommend Go over the other alternatives due to it
> being both memory safe and easy to build on mobile. If someone writes a
> new PT in Python, I don't
p 9, 2015 at 4:50 PM, David Fifield wrote:
> On Wed, Sep 09, 2015 at 03:33:24PM -0400, Brandon Wiley wrote:
> > I am in favor of standardizing on the Go codebase for pluggable
> transports that
> > ship with Tor. This is something we talked about at the last developer
> meeting
> On 09/09/2015 06:43 PM, Brandon Wiley wrote:
> > Another option here, besides getting python to build in gitian is
> > to phase out support for python-based pluggable transports. It's
> > something to consider at least. Which transports are still only
> > availabl
Another option here, besides getting python to build in gitian is to phase
out support for python-based pluggable transports. It's something to
consider at least. Which transports are still only available in python?
On Sun, Sep 6, 2015 at 7:26 PM, Jeremy Rand wrote:
> -BEGIN PGP SIGNED MESSA
I can't do 0200 UTC on Wednesdays. I could potentially do 0200 on some
Thursdays.
On Mon, Apr 6, 2015 at 3:06 PM, isis wrote:
>
> Last chance. http://doodle.com/tn28wgzw8iydpznp
>
> We're currently leaning towards 0200 UTC on Wednesdays. If this doesn't
> work
> for you, now's your chance to R
Hi Dan. Very cool. Would you like some analysis of how well your pluggable
transport mimicks real BitTorrent traffic?
I don't have time to install bitsmuggler myself right now as I am currently
at a conference. However, if you send me a .pcap file recorded with tcpdump
or Wireshark of bitsmuggler
On Thu, Jul 25, 2013 at 10:23 AM, Damian Johnson wrote:
> > (What I'm *not* thrilled about is the idea of using an embedded
> > interpreter for this kind of stuff, or embarking on any direction that
> > requires us to rewrite too much of the program at once. That way, in
> > my opinion, lies long
So far I've implemented Dust and obfs3 and I'm putting the finishing
touches on obfs2. I've also rewritten the pluggable transport API and
rewritten the transport plugins to use this new API.
The API now provides 4 events: start, encodedReceived, decodedReceived, and
end. The plugins implement cal
Status Update - Refactoring
There was a slight change in the schedule in that I moved refactoring up in
front of testing and debugging.
The major refactoring effort was in splitting the project into two parts.
The library for implementing the pluggable transport specification, with
environment va
Here is the proposed schedule for the project:
*Week 1 - pyptlib.config API draft
Week 2 - pyptlib.config implementation
Week 3 - pyptlib.framework API draft
Week 4 - pyptlib.framework implementation
Week 5 - pyptlib.transports example implementations (dummy, rot13) and
command line options
Week 6
Deliverable #1 for this summer’s project is this:
“A library for parsing pluggable transport configuration options
This will be a python library that authors of SOCKS proxies can use to
integrate their proxies with Tor.”
A first pass at this is available from github and pypi:
http://github.com/b
Hello fellow Tor developers!
Some information about me:
*I worked for EFF/Tor Project last year for **GSoC 2011, my project **was a
blocking-resistant transport evaluation framework:
https://gitweb.torproject.org/user/blanu/blocking-test.git*
I am also the author of a pluggable transport written
Hi Sai,
It looks like you've put a lot of thought into what would make a good
hash-to-word system. However, you have a false assumption, that dictionary
systems can simultaneously have all three properties of Zooko's Triangle.
This is a popular idea, but unfortunately untrue.
Hashes are effective
Scoring and reporting for detectors and encoders is pretty much done. The
graphs aren't quite ready yet, for aesthetic reasons, but I have some nice
tables to report:
Length detector: 16% accuracy
Timing detector: 89% accuracy
Entropy detector: 94% accuracy
SSL was correctly identified 25% of the
With the TorDev meetup and everything it's been a while since I sent out an
update on the state of the project, although I think we more or less caught
up on the status at the meetup. The bulk of the implementation work had
already been completed, so what I've been working on since then is just
cle
On Fri, Jul 15, 2011 at 3:16 PM, Nick Jones wrote:
>
>
> On Wednesday, July 13, 2011 at 8:02 PM, Brandon Wiley wrote:
>
> >
> > Cool stuff. I like how the system can be automated and self-funding.
> >
> > With regards to bootstrapping, giving out one node
Cool stuff. I like how the system can be automated and self-funding.
With regards to bootstrapping, giving out one node at a time is not a useful
defense because requests can be parallelized. [1] Moving nodes is similarly
useless because the attacker can continually map the network using free
para
31 matches
Mail list logo
