On Mon, 30 Sep 2013 19:13:37 -0700
Tom Lowenthal wrote:
> Today, at 1100 Pacific, we spent more than 90 minutes discussing
> [Sponsor F][]. Here's the summary.
>
> **READ THIS**: The next Sponsor F meeting will be held in a mere two
> weeks on **2013-10-14, at 1100h Pacific in #tor-dev**.
>
> T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 30/09/13 09:13 PM, Tom Lowenthal wrote:
> Today, at 1100 Pacific, we spent more than 90 minutes discussing
> [Sponsor F][]. Here's the summary.
>
> **READ THIS**: The next Sponsor F meeting will be held in a mere
> two weeks on **2013-10-14, at
Today, at 1100 Pacific, we spent more than 90 minutes discussing
[Sponsor F][]. Here's the summary.
**READ THIS**: The next Sponsor F meeting will be held in a mere two
weeks on **2013-10-14, at 1100h Pacific in #tor-dev**.
This is a schedule change: from now on, the meetings will be every two
we
Hi Karsten, Sathya,
Hope you've both had great weekends, please see inline!
> Want to help define the remaining data formats? I think we need these
> formats:
>
> - file_upload would be quite similar to file_download, but for the GET
> POST performance experiment. Or maybe we can generalize fi
Below is my first go at a list of criteria to consider when evaluating
pluggable transports for readiness of deployment to users. The goal
isn't to say that every transport has to "pass" each question -- rather,
I'm hoping to fund a researcher-developer at some point soon to polish
some of the rese
Hello,
For those aspiring Pluggable Transports authors out there, I've recently
written a simple library that handles the Tor Pluggable Transport
Configuration protocol. The idea is for this library to be the C/C++
equivalent to pyptlib (and maybe more, depending on how much time I have
to work o
On 30 September 2013 07:01, Ian Goldberg wrote:
> On Mon, Sep 30, 2013 at 01:03:14AM -0700, Rohit wrote:
>> This should satisfy most goals.
>> - A passive attacker wouldn't be able to distinguish between HTTPS->HTTPS
>> traffic and Tor->Bridge. (Both use TLS)
>
> This seems false to me; it's not
On Mon, Sep 30, 2013 at 01:03:14AM -0700, Rohit wrote:
> This should satisfy most goals.
> - A passive attacker wouldn't be able to distinguish between HTTPS->HTTPS
> traffic and Tor->Bridge. (Both use TLS)
This seems false to me; it's not too hard to distinguish Tor-over-TLS
from HTTP-over-TLS,
On 2013-09-30 13:01 , Ian Goldberg wrote:
> On Mon, Sep 30, 2013 at 01:03:14AM -0700, Rohit wrote:
>> This should satisfy most goals.
>> - A passive attacker wouldn't be able to distinguish between HTTPS->HTTPS
>> traffic and Tor->Bridge. (Both use TLS)
>
> This seems false to me; it's not too ha
Hi,
I was thinking about proposal #203 (Avoiding censorship by impersonating an
HTTPS server) and have a few thoughts.
I'm not sure if I've understood how everything fits correctly but here goes:
For each bridge, we give their identity fingerprint and a shared secret along
with their IP address
10 matches
Mail list logo
