On 12/04/2019 14:37, Chethan Kumar wrote: >> Please note that curl developers have recently changed the meaning of those options, please check if they do what you expect them to do by inspecting the curl man page. > Thanks for the information. I understood it. > I also used openssl s_client to communicate with server using below command. > openssl s_client -connect 172.28.80.66:8080 -tls1_1 > It says " unknown option -tls1_1" > Same for -tls1. If s_client doesn't recognise the -tls1_1 and -tls1 options then this mean that TLSv1.1 and TLSv1.0 have been disabled. > > And even if I disable TLSv1.2 and execute > openssl s_client -connect 172.28.80.66:8080 -no_tls1_2 > WARNING: can't open config file: /usr/local/ebx/ssl/openssl.cnf > CONNECTED(00000003) > 2001716872:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: So you attempt a connection and ask s_client to disable TLSv1.2 at runtime. You've already asked it to disable TLSv1.1 and TLSv1.0 at compile time. Since SSLv3 is also compiled out by default there are no protocol versions left so the expected result will be a handshake failure - which is exactly what you've got. >> what you mean by "used them in Makefile", I'm talking about configure script > I added these options in Makefile like, > CONFOPTS += linux-ppc -DOPENSSL_NO_SSL3 -DOPENSSL_NO_SSL2 -DSSL_OP_NO_SSLv2 no-tls1 no-tls1_1 no-tls1-method no-tls1_1-method *Don't edit the Makefile*. You only need to pass options to Configure. > >> do adding `no-tls1-method` and `no-tls1_1-method` produce the expected result? > Yes, even after adding these options it produces the same result. The result above means you have disabled TLSv1.1 and TLSv1.0 - which was your objective IIUC. > > I am confused what is the problem. > Let me know if there is any other way to disable TLSv1.0 and TLS1.1 It sounds like you already did it. Matt
