Timo Aaltonen <tjaal...@ubuntu.com> writes: > On 09.03.2012 00:31, Simon Josefsson wrote: >> Timo Aaltonen <tjaal...@ubuntu.com> writes: >> >>> On 08.03.2012 20:06, Timo Aaltonen wrote: >>>> which doesn't say much. I couldn't test 2.11.7 since snapshot.d.o >>>> doesn't have packages for amd64 (FTBFS?), and bisecting without >>>> packages is rather hard I guess... Can't test 3.0.x either, since >>>> openldap doesn't build against libgnutls28. >>> >>> Ok I was able to build 2.11.7 after all (disabled tests), and I can >>> confirm that it's a working version as well, so this broke some time >>> between that and 2.12.0.. trying to bisect more. >> >> Thanks. What do you know about the server you are testing against? > > It's 389 Directory Server on Fedora. > >> Many LDAP servers seems to have non-standards conforming SSL support. >> There is one change between 2.11.7 and 2.12.0 ("Corrected default >> behavior in record version of Client Hellos.") that I suspect. Try >> adding the "SSL3_RECORD_VERSION" or "LATEST_RECORD_VERSION" priority >> string to your client and see if it makes a difference. If this makes a >> difference, the problem is with the server. > > Spot on, that commit changed it. What exactly is broken on the server? > Upstream would like to know :)
If I recall and understand correctly: before, GnuTLS clients sent the latest TLS version it supported in the record layer version of the client hello. This caused some problems with SSL3-only servers. But after 2.12.0 it sent the SSL3 record version even when it supports higher versions. This allows SSL3-only-and-TLS-intolerant servers to talk to GnuTLS but still allow TLS-conforming servers to upgrade to more recent TLS versions. Sadly, it seems the server you hit rejects GnuTLS here, probably because it is confused by seeing a SSL3 record version when there is support for higher TLS versions. This is more uncommon than SSL3-only-and-TLS-intolerant servers, that's why the default was changed. This came up a long time ago and was discussed then, and I may be recalling things incorrectly. RFC 5246 discuss this: Earlier versions of the TLS specification were not fully clear on what the record layer version number (TLSPlaintext.version) should contain when sending ClientHello (i.e., before it is known which version of the protocol will be employed). Thus, TLS servers compliant with this specification MUST accept any value {03,XX} as the record layer version number for ClientHello. TLS clients that wish to negotiate with older servers MAY send any value {03,XX} as the record layer version number. Typical values would be {03,00}, the lowest version number supported by the client, and the value of ClientHello.client_version. No single value will guarantee interoperability with all old servers, but this is a complex topic beyond the scope of this document. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org