Actually, Abhijit, I think your question still has merit. The documentation says that a client will use a TLS hello even when SSLv3 is one of its supported protocols. The problem then is, how can such a client communicate with an SSLv3 only server, which probably won’t understand the TLS hello msg?
How can a client force the library to use a SSLv3 hello msg while still advertising that is also supports higher TLS protocols? It wasn’t apparent to me how to cause this behavior from the top level documentation. Cheers! ----- John Lane Schultz Spread Concepts LLC Cell: 443 838 2200 On Sep 18, 2014, at 4:37 AM, abhijit pai <abhijitpa...@gmail.com> wrote: Thanks John, After reading through http://tools.ietf.org/html/rfc2246#appendix-E I understood what you meant here, and couls make sense about fallback to SSLv3. " TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both is easy. TLS clients who wish to negotiate with SSL 3.0 servers should send client hello messages using the SSL 3.0 record format and client hello structure, sending {3, 1} for the version field to note that they support TLS 1.0. If the server supports only SSL 3.0, it will respond with an SSL 3.0 server hello; if it supports TLS, with a TLS server hello. The negotiation then proceeds as appropriate for the negotiated protocol. " I was under impression that client should advertise SSLv3.0 in its minimum version, but it was the Server who had to fallback to SSLv3. Thanks to all of you who bothered to help me on this. Regards, Abhijit On Tue, Sep 16, 2014 at 10:34 PM, John Lane Schultz <jschu...@spreadconcepts.com> wrote: As Thulasi wrote, SSLv23_client_method supports *ALL* protocols that your library supports by default. The name of the function is just historical and should be ignored. From the documentation: "If the cipher list does not contain any SSLv2 ciphersuites (the default cipher list does not) or extensions are required (for example server name) a client will send out TLSv1 client hello messages including extensions and will indicate that it also understands TLSv1.1, TLSv1.2 and permits a fallback to SSLv3." The real question is why the server that didn’t support TLS couldn’t fall back to SSLv3? If a SSLv3 server can’t understand a TLSv1 hello, then it kind of defeats the purpose of being able to fallback to SSLv3 ... Cheers! ----- John Lane Schultz Spread Concepts LLC Cell: 443 838 2200 On Sep 16, 2014, at 12:36 PM, abhijit pai <abhijitpa...@gmail.com> wrote: Hi Thulasi, Thanks for the response. But my point is little different here. I have a generic HTTP client, that talks to SSL 3.0 as well as TLS 1.x enabled server. And as mentioned earlier, I have disabled SSLv2. Now, when I talk to any server, shouldn't the client be sending SSLv3(SSL 3.0) in the version instead of TLS 1.0 as seen from packet capture? Is it some default behaviour? Is it configurable? Regards, Abhijit > Thulasi Goriparthi > SSLv23_client_method supports all protocols by default and connects using > the highest protocol that server supports(as received from server hello) > > I suggest you try disabling TLS 1.0 along with SSL2 if you want to force > your client to use SSL3 without changing the context's method. > SSL_CTX_set_options(ctx, SSL_OP_ALL| > SSL_OP_NO_SSLv2 | > SSL_OP_NO_TLSv1); > > If the server supports TLS1.1 and TLS 1.2, update the client ctx option to > use SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 also. On Fri, Sep 12, 2014 at 6:01 PM, abhijit pai <abhijitpa...@gmail.com> wrote: Hello All, I am using openSSL in my custom HTTP client. Here I use SSLv23_client_method() and disable SSLv2 using SSL_CTX_set_options(ctx, SSL_OP_ALL| SSL_OP_NO_SSLv2) I would expect the handshake method sent out to the server be SSL v3.0 but to my surprise it is TLS 1.0, which for some reasons the server does not support. This is a generic code, that would talk to even TLS 1.x enabled servers, so I cannot fix it using SSLv3_client_method(). Is there any other API that I am not aware of that could help me achieve it? Thanks in advance! Regards, Abhijit ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
