SSL Handshake with OVH

All products using libneon fail their SSL handshake with OVH shared hosting servers. It seems that the server hates that the versions from the SSL Record layer and the handshake protocol differ.

Assuming libneon is compiled with openssl, this can be fixed by replacing the SSLv23_client_method with, say, TLSv1_client_method. Here is the patch.

::diff
Index: ne_openssl.c
===================================================================
--- ne_openssl.c        (révision 1884)
+++ ne_openssl.c        (copie de travail)
@@ -558,7 +558,7 @@
 {
     ne_ssl_context *ctx = ne_calloc(sizeof *ctx);
     if (mode == NE_SSL_CTX_CLIENT) {
-        ctx->ctx = SSL_CTX_new(SSLv23_client_method());
+        ctx->ctx = SSL_CTX_new(TLSv1_client_method());
         ctx->sess = NULL;
         /* set client cert callback. */
         SSL_CTX_set_client_cert_cb(ctx->ctx, provide_client_cert);

Revised in September 2012:

A friend pointed out the following in RFC5246, appendix E:

TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use compatible ClientHello messages; thus, supporting all of them is relatively easy. Similarly, servers can easily handle clients trying to use future versions of TLS as long as the ClientHello format remains compatible, and the client supports the highest protocol version available in the server.

And also:

Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. Also, it is known that some servers will refuse the connection if any TLS extensions are included in ClientHello. Interoperability with such buggy servers is a complex topic beyond the scope of this document, and may require multiple connection attempts by the client.”

I also had opened a ticket at OVH in the meantime. But the problem disappeared quite mysteriously.