Re: [tor-dev] xxx-draft-spec-for-TLS-normalization.txt

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

Aha.  Let's see if I have the tor-dev address right at long long last.
 Apologies to Peter, who will have received more than one copy of this
already.

(Apparently , I am told, the "lists." in tor-dev@xxxxxxxxxxxxxxxxxxxx
is not optional.)

On Mon, Feb 21, 2011 at 12:52 PM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
> On Sun, Feb 20, 2011 at 10:49 PM, Peter Gutmann
> <pgut001@xxxxxxxxxxxxxxxxx> wrote:
>> Nick Mathewson <nickm@xxxxxxxxxxxxx> writes:
>>
>>>Preliminary results suggest that there wasn't actually a crowd here: the
>>>reason that we switched the browser DH paramaters in the most recent releases
>>>is that the old (standard!) primes were in fact blocked by at least one
>>>nation-level censor because we used them.  It seems that in practice, if we
>>>want to blend with a crowd, we need to use the hardwired DH parameters from
>>>mod_ssl.
>>
>> So the SSL handshake was blocked if you used the Oakley (RFC 2412) DH values?
>
> Just the 1024-bit one, I would guess (the one in section E.2 of
> RFC2412, a.k.a. the one from RFC2409 section 6.2, a.k.a Second Oakley
> Group).  Or to be precise, we used to use that group, and then we were
> blocked, and when we changed to a different group, we weren't.  It
> might be that they were blocking based on more than one factor, only
> one of which was the use of the prime in a TLS ephemeral DH handshake.
>
>> Is there a server in said location for which access gets blocked that I could
>> test against?  I'd love to try some variations on SSL handshakes to see what
>> gets blocked and what doesn't.
>
> The use in question was a client in the country trying to connect to a
> server outside the country, and the server providing this DH parameter
> value.  I'll ask our contacts if they can get you shell access there.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev