Can an SSL client send CLIENT HELLO with version 3.2 and NOT negotiate 3.1. For sslv2 and 3, one could do that by sending ssl23 CLIENT HELLO or SSL3. Please provide input on how one can support 3.2 but NOT 3.1 or if it is even possible.
There is a theoretical way which is explained in appendix E of RFC 5246; but its implementation is not necessarily easy.
There is no way for the client to proactively announce exclusions (as in: "I support TLS 1.1 but I don't want to do TLS 1.0"). However, if the server tries to use a protocol version that the client does not want to support, then the client always has the possibility to close the connection. Appendix E says that:
In all generality, if the client wishes to support only a non-contiguous set of protocol versions, then he can enforce that by dint of using several connection attempts. For instance, suppose that, for some reason, the client wants to do TLS 1.1 or SSL 3.0, but not TLS 1.0. In that case, the client may first send a
This works only if the usage context is such that the client can attempt several connections (e.g. we are talking about HTTPS, with TCP connections that the client can open at will).
In practice, a server or a client usually supports a contiguous range of protocol versions (e.g. supports TLS 1.1 and 1.2, but not 1.0 or SSL 3.0). In that case, a single handshake attempt is sufficient: either the server will choose at the first try a protocol version which will be acceptable to the client, or there is no version which is acceptable to both client and server and it will never work.
Whether a given implementation of a SSL client offers an API to disable support of an old protocol version, is another question, of course.