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@lists.torproject.org is not optional.)
On Mon, Feb 21, 2011 at 12:52 PM, Nick Mathewson nickm@freehaven.net wrote:
On Sun, Feb 20, 2011 at 10:49 PM, Peter Gutmann pgut001@cs.auckland.ac.nz wrote:
Nick Mathewson nickm@freehaven.net 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.