Robert Ransom writes:
> On 2012-01-17, Nick Mathewson wrote:
>> On Sun, Nov 6, 2011 at 9:12 PM, George Kadianakis
>> wrote:
>
>
>
>> Marking this proposal needs-revision. Not sure what the actual
>> solution is though. One option might be to look for a way to signal
>> (undetectably) to the c
On 2012-01-18, Nick Mathewson wrote:
> On Tue, Jan 17, 2012 at 1:28 PM, Robert Ransom
> wrote:
>
>> With that hack on top of the v3 protocol, any client able to detect
>> that a bridge is not being MITMed can impersonate the bridge through
>> the TLS handshake, until after the (honest, victim) cl
On Tue, Jan 17, 2012 at 1:28 PM, Robert Ransom wrote:
> With that hack on top of the v3 protocol, any client able to detect
> that a bridge is not being MITMed can impersonate the bridge through
> the TLS handshake, until after the (honest, victim) client speaks the
> Tor protocol at the fake bri
On Wed, Jan 18, 2012 at 07:07:08AM +, Robert Ransom wrote:
> On 2012-01-17, Ian Goldberg wrote:
> > On Tue, Jan 17, 2012 at 08:43:00PM +0200, George Kadianakis wrote:
> >> [0]: Did the Telex people clean up the patch, generalize it, and post
> >> it in openssl-dev? Having configurable {Server,
On 2012-01-17, Ian Goldberg wrote:
> On Tue, Jan 17, 2012 at 08:43:00PM +0200, George Kadianakis wrote:
>> [0]: Did the Telex people clean up the patch, generalize it, and post
>> it in openssl-dev? Having configurable {Server,Client}Hello.Random in
>> a future version of OpenSSL would be neat.
>
On Tue, Jan 17, 2012 at 08:43:00PM +0200, George Kadianakis wrote:
> [0]: Did the Telex people clean up the patch, generalize it, and post
> it in openssl-dev? Having configurable {Server,Client}Hello.Random in
> a future version of OpenSSL would be neat.
At USENIX Security, Adam opined that opens
Nick Mathewson writes:
> On Sun, Nov 6, 2011 at 9:12 PM, George Kadianakis wrote:
>
>> 3.2. AUTHORIZE cell format
>>
>> In shared-secret-based authorization, the MethodFields field of the
>> AUTHORIZE cell becomes:
>>
>> 'shared_secret' [10 octets]
>>
>> where:
>>
>>
On 2012-01-17, Nick Mathewson wrote:
> On Sun, Nov 6, 2011 at 9:12 PM, George Kadianakis
> wrote:
>
>> 3.2. AUTHORIZE cell format
>>
>> In shared-secret-based authorization, the MethodFields field of the
>> AUTHORIZE cell becomes:
>>
>> 'shared_secret' [10 octets]
>>
>>
On Sun, Nov 6, 2011 at 9:12 PM, George Kadianakis wrote:
> 3.2. AUTHORIZE cell format
>
> In shared-secret-based authorization, the MethodFields field of the
> AUTHORIZE cell becomes:
>
> 'shared_secret' [10 octets]
>
> where:
>
> 'shared_secret', is the shared secret
Let's try again this proposal with a more Keep It Simple, Stupid!
approach.
After deciding that MITM is not in our threat model at the moment,
this new proposal 190 doesn't even try to protect against an MITM
adversary! It's slicker, faster and maybe even better.
Inlining:
Filename: 190-shared-se
On 2011-11-04, Robert Ransom wrote:
> On 2011-11-04, George Kadianakis wrote:
>>To avoid problems associated with the human condition, schemes
>>based on public key cryptography and certificates can be used. A
>>public and well tested protocol that can be used as the basis of a
>>
On 2011-11-04, George Kadianakis wrote:
>
> Filename: 190-password-bridge-authorization.txt
> Title: Password-based Bridge Client Authorization
> Author: George Kadianakis
> Created: 04 Nov 2011
> Status: Open
>
> 1. Overview
>
>Proposals 187 and 189 introduced the AUTHORIZE and AUTHORIZED cel
Filename: 190-password-bridge-authorization.txt
Title: Password-based Bridge Client Authorization
Author: George Kadianakis
Created: 04 Nov 2011
Status: Open
1. Overview
Proposals 187 and 189 introduced the AUTHORIZE and AUTHORIZED cells.
Their purpose is to make bridge relays scanning res
13 matches
Mail list logo
