Comment 6 for bug 986147

I do understand the severity, and I don't mean to minimise it; the
difficulty is that OpenSSL 1.0.1 has been problematic from the start,
and every change fixes some cases while breaking others. Rolling back
all the way to 1.0.0, while perhaps the safest option in some cases, is
by now too invasive a change to attempt; rolling back libraries to
earlier ABIs is in general problematic once they've been widely
deployed.

It's not true that the buggy servers in question always failed. These
were regressions and they were reported to me as such. You can find the
details in bug 965371, its duplicates, and the linked Debian bug.

Every change that I have made in an attempt to fix it has been directly
backported from upstream CVS and/or recommended by upstream developers.
Here's the commit where they recommend 50:

  http://cvs.openssl.org/chngview?cn=22408

I haven't done the packet arithmetic in detail, but a quick capture here
against cs3-api.salesforce.com (one of the servers previously reported
as failing, though I haven't checked if it was for this reason) shows
that the client hello is currently 240 bytes. If that's true across the
board, then we can only fit in eight more ciphers before exceeding 255
bytes, which isn't enough for you.

As such, I'm happier with the suggested workaround to use
TLS1_get_client_version than with adjusting the workaround than with
tweaking the number. The client version is supposed to be what was sent
by the client in the hello, so in general I think I'd expect s->version
and s->client_version to be the same while *sending* the client hello,
but that's evidently not the case and I have a suspicion that the
version downgrades applied in the current set of backported workarounds
are only applied to s->client_version. I'm going to try this in
-proposed and see how it goes; but this has been so delicate that I
really want to get as widespread testing as possible before promoting it
to general use.