On 09.03.2012 02:10, Simon Josefsson wrote: > Timo Aaltonen <tjaal...@ubuntu.com> writes: > >> On 09.03.2012 00:31, Simon Josefsson wrote: >>> Timo Aaltonen <tjaal...@ubuntu.com> writes: >> 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.
Excellent, thanks! Apparently this is a flaw in NSS, which 389 builds against.. might just reassign this to that package. In the meantime, forcing the ldap server to support SSL3 makes the ipac-client-install work. -- t -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org