URGENT: Parsing DTLS Alerts in OpenSSL
Hi,
I am facing issue while trying to parse the Alert received from client.
I could see the Alert on wireshark as "Alert(21) Handshake Failure" but
while trying to parse it from below code doesn't work.
I want to parse this error and try to re-initiate the handshake from my
server code.
ctx_info_callback( const SSL *s, int where, int ret )
{
const char *str;
int w;
if( w & SSL_ST_ACCEPT) // I only have server implemented
str = "SSL_accept"
if( where & SSL_CB_LOOP)
{
// printed state string
}else if (where & SSL_CB_ALERT)
{
// printed alert type
}else if ( where & SSL_CB_EXIT )
{
// checked ret type --> Run time only shows "SSL_accept : error in
SSLv3 read client hello B"
}
}
I could not complete SSL_do_handshake (in certain cases like network
connection failure) completed and my server gets stuck in read message.
I am trying to understand what might be causing this issue but meanwhile the
client is keep on re-initializing and sending Alert messages.
Any insight on as why I keep on getting this "read client hello B" message
will be helpful. I am using non-blocking sockets so based on documentation
it is correct behavior and for most of the cases I see the sever completes
handshake after certain tries and gets out of this loop.
Only for few cases it gets stuck like when the network connection is lost
but I think if the network connection re-initializes I should be able to
recover it if I could parse these Alerts ?
In order to re-initialize connection I am completely resetting all CTX,SSL,
and socket objects so there is no stale SSL object which might be causing
issues.
Thanks,
NJ
--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Re: Blinding implementation in OpenSSL
("OpenSSL doesn't do" _scalar_ blinding! Coordinate blinding is there.
sorry ...)
RE: Best way of preventing denial of service attacks by way of secure client-initiated renegotiation
Ok, great thanks. -Original Message- From: Matt Caswell Sent: Monday 15 April 2019 14:45 To: tim.j.culh...@gmail.com; openssl-users@openssl.org Subject: Re: Best way of preventing denial of service attacks by way of secure client-initiated renegotiation On 15/04/2019 14:41, tim.j.culh...@gmail.com wrote: > Hi Matt, > > Many thanks for your informative reply. > > So it seems the best approach is to upgrade to a version of OpenSSL > supporting the SSL_OP_NO_RENGOTIATION option. > > If this option is enabled will it still allow server-initiated secure > renegotiations if TLS 1.3 is being used? > > The docs suggests that only client side renegotiation requests are disabled > in TLS 1.3. Renegotiation does not exist as a concept in TLSv1.3 so this option has no impact in TLSv1.3. Matt > > Tim > > > -Original Message- > From: openssl-users On Behalf Of > Matt Caswell > Sent: Monday 15 April 2019 13:44 > To: openssl-users@openssl.org > Subject: Re: Best way of preventing denial of service attacks by way > of secure client-initiated renegotiation > > > > On 15/04/2019 09:35, tim.j.culh...@gmail.com wrote: >> I'm not sure if this means renegotiation has failed? Either way the >> connection remains open. Presumably if a client issued a large >> number of renegotiations like this the server could become overwhelmed. > > No - renegotiation was successful. > >> Note that I got the same results if I remove the >> -legacy_renegotiation option, so I don't think this has any impact? > > The legacy_renegotiation option does something different to what you > think it does. This option allows "insecure" renegotiation as opposed > to the later (and > default) "secure" renegotiation. This dates back to 2009 when a flaw in the > TLS protocol for renegotiation was discovered. > >> >> So, I suppose I firstly need to know if the results from testssl.sh >> and from my own investigations point to a potential security risk by >> way of a DoS attack? > > Over the years there have been many attacks against renegotiation. They've > all been fixed, however since this is a common attack vector and many > applications don't need this feature it is often recommended that it is > disabled. > > >> If so, what is the best way to prevent this. > > The best way is to upgrade to a recent version of OpenSSL and use the > SSL_OP_NO_RENGOTIATION option for this purpose (available from 1.1.0h and > above). > > If you *must* use OpenSSL 1.0.2 then there is a way to do it but it is > undocumented and unfortunately this method is no longer possible in OpenSSL > 1.1.0+ due to the opacity changes. > > You can mark a particular SSL object (call it "s") so that it should not do > renegotiation like this: > > s->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS; > > >> From what I've read online it isn't possible to disable >> client-initiated secure renegotiation in openssl. >> Indeed, it could be argued that there are circumstances when it is >> perfectly valid for a client to renegotiate a connection especially >> if it is a long-running connection. >> >> The only way I could find of limiting such an attack was to track >> the number of renegotiation requests over a time and if we get a high >> number in a short period then close the connection. >> I believe this can be done in a callback function set up via a call to: >> >> SSL_CTX_set_info_callback > > I'd recommend against this approach. A number of applications took this route > due to a lack of a good alternative. However it can have unexpected > consequences if you later upgrade to OpenSSL 1.1.1 and start using TLSv1.3 > (where a number of legitimate interactions happen post-handshake that can be > mistaken for renegotiations). > > Matt >
Re: Blinding implementation in OpenSSL
> > Could you please explain how blinding works in OpenSSL? > > > > EC_KEY structure seems to have an unblinded private key structure and > > blinded X, Y, Z- coordinates of the public key when blinding is in > > use. But if I understand correctly, he idea of blinding is protecting > > the private key from extracting from memory/swap/etc? Am I wrong? > > No, blinding is done during the private key operations to "randomize" > the computations so timing and other side channels do not leak the > private key. The private key itself is not modified. Dmitry is correct in that coordinate blinding and scalar blinding are different things. The question seems to be why doesn't OpenSSL do coordinate blinding. (Hoping I'm not interpreting too much.) BBB
Re: Best way of preventing denial of service attacks by way of secure client-initiated renegotiation
On 15/04/2019 14:41, tim.j.culh...@gmail.com wrote: > Hi Matt, > > Many thanks for your informative reply. > > So it seems the best approach is to upgrade to a version of OpenSSL > supporting the SSL_OP_NO_RENGOTIATION option. > > If this option is enabled will it still allow server-initiated secure > renegotiations if TLS 1.3 is being used? > > The docs suggests that only client side renegotiation requests are disabled > in TLS 1.3. Renegotiation does not exist as a concept in TLSv1.3 so this option has no impact in TLSv1.3. Matt > > Tim > > > -Original Message- > From: openssl-users On Behalf Of Matt > Caswell > Sent: Monday 15 April 2019 13:44 > To: openssl-users@openssl.org > Subject: Re: Best way of preventing denial of service attacks by way of > secure client-initiated renegotiation > > > > On 15/04/2019 09:35, tim.j.culh...@gmail.com wrote: >> I'm not sure if this means renegotiation has failed? Either way the >> connection remains open. Presumably if a client issued a large number >> of renegotiations like this the server could become overwhelmed. > > No - renegotiation was successful. > >> Note that I got the same results if I remove the -legacy_renegotiation >> option, so I don't think this has any impact? > > The legacy_renegotiation option does something different to what you think it > does. This option allows "insecure" renegotiation as opposed to the later (and > default) "secure" renegotiation. This dates back to 2009 when a flaw in the > TLS protocol for renegotiation was discovered. > >> >> So, I suppose I firstly need to know if the results from testssl.sh >> and from my own investigations point to a potential security risk by >> way of a DoS attack? > > Over the years there have been many attacks against renegotiation. They've > all been fixed, however since this is a common attack vector and many > applications don't need this feature it is often recommended that it is > disabled. > > >> If so, what is the best way to prevent this. > > The best way is to upgrade to a recent version of OpenSSL and use the > SSL_OP_NO_RENGOTIATION option for this purpose (available from 1.1.0h and > above). > > If you *must* use OpenSSL 1.0.2 then there is a way to do it but it is > undocumented and unfortunately this method is no longer possible in OpenSSL > 1.1.0+ due to the opacity changes. > > You can mark a particular SSL object (call it "s") so that it should not do > renegotiation like this: > > s->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS; > > >> From what I've read online it isn't possible to disable >> client-initiated secure renegotiation in openssl. >> Indeed, it could be argued that there are circumstances when it is >> perfectly valid for a client to renegotiate a connection especially >> if it is a long-running connection. >> >> The only way I could find of limiting such an attack was to track the >> number of renegotiation requests over a time and if we get a high >> number in a short period then close the connection. >> I believe this can be done in a callback function set up via a call to: >> >> SSL_CTX_set_info_callback > > I'd recommend against this approach. A number of applications took this route > due to a lack of a good alternative. However it can have unexpected > consequences if you later upgrade to OpenSSL 1.1.1 and start using TLSv1.3 > (where a number of legitimate interactions happen post-handshake that can be > mistaken for renegotiations). > > Matt >
RE: Best way of preventing denial of service attacks by way of secure client-initiated renegotiation
Hi Matt, Many thanks for your informative reply. So it seems the best approach is to upgrade to a version of OpenSSL supporting the SSL_OP_NO_RENGOTIATION option. If this option is enabled will it still allow server-initiated secure renegotiations if TLS 1.3 is being used? The docs suggests that only client side renegotiation requests are disabled in TLS 1.3. Tim -Original Message- From: openssl-users On Behalf Of Matt Caswell Sent: Monday 15 April 2019 13:44 To: openssl-users@openssl.org Subject: Re: Best way of preventing denial of service attacks by way of secure client-initiated renegotiation On 15/04/2019 09:35, tim.j.culh...@gmail.com wrote: > I'm not sure if this means renegotiation has failed? Either way the > connection remains open. Presumably if a client issued a large number > of renegotiations like this the server could become overwhelmed. No - renegotiation was successful. > Note that I got the same results if I remove the -legacy_renegotiation > option, so I don't think this has any impact? The legacy_renegotiation option does something different to what you think it does. This option allows "insecure" renegotiation as opposed to the later (and default) "secure" renegotiation. This dates back to 2009 when a flaw in the TLS protocol for renegotiation was discovered. > > So, I suppose I firstly need to know if the results from testssl.sh > and from my own investigations point to a potential security risk by > way of a DoS attack? Over the years there have been many attacks against renegotiation. They've all been fixed, however since this is a common attack vector and many applications don't need this feature it is often recommended that it is disabled. > If so, what is the best way to prevent this. The best way is to upgrade to a recent version of OpenSSL and use the SSL_OP_NO_RENGOTIATION option for this purpose (available from 1.1.0h and above). If you *must* use OpenSSL 1.0.2 then there is a way to do it but it is undocumented and unfortunately this method is no longer possible in OpenSSL 1.1.0+ due to the opacity changes. You can mark a particular SSL object (call it "s") so that it should not do renegotiation like this: s->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS; > From what I've read online it isn't possible to disable > client-initiated secure renegotiation in openssl. > Indeed, it could be argued that there are circumstances when it is > perfectly valid for a client to renegotiate a connection especially > if it is a long-running connection. > > The only way I could find of limiting such an attack was to track the > number of renegotiation requests over a time and if we get a high > number in a short period then close the connection. > I believe this can be done in a callback function set up via a call to: > > SSL_CTX_set_info_callback I'd recommend against this approach. A number of applications took this route due to a lack of a good alternative. However it can have unexpected consequences if you later upgrade to OpenSSL 1.1.1 and start using TLSv1.3 (where a number of legitimate interactions happen post-handshake that can be mistaken for renegotiations). Matt
Re: Blinding implementation in OpenSSL
On Mon, 2019-04-15 at 10:39 +0300, Dmitry Belyavsky wrote: > Hello, > > Could you please explain how blinding works in OpenSSL? > > EC_KEY structure seems to have an unblinded private key structure and > blinded X, Y, Z- coordinates of the public key when blinding is in > use. But if I understand correctly, he idea of blinding is protecting > the private key from extracting from memory/swap/etc? Am I wrong? No, blinding is done during the private key operations to "randomize" the computations so timing and other side channels do not leak the private key. The private key itself is not modified. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
Re: Best way of preventing denial of service attacks by way of secure client-initiated renegotiation
On 15/04/2019 09:35, tim.j.culh...@gmail.com wrote: > I'm not sure if this means renegotiation has failed? Either way the > connection remains open. Presumably if a client issued a large number of > renegotiations like this the server could become overwhelmed. No - renegotiation was successful. > Note that I got the same results if I remove the -legacy_renegotiation > option, so I don't think this has any impact? The legacy_renegotiation option does something different to what you think it does. This option allows "insecure" renegotiation as opposed to the later (and default) "secure" renegotiation. This dates back to 2009 when a flaw in the TLS protocol for renegotiation was discovered. > > So, I suppose I firstly need to know if the results from testssl.sh and from > my own investigations point to a potential security risk by way of a DoS > attack? Over the years there have been many attacks against renegotiation. They've all been fixed, however since this is a common attack vector and many applications don't need this feature it is often recommended that it is disabled. > If so, what is the best way to prevent this. The best way is to upgrade to a recent version of OpenSSL and use the SSL_OP_NO_RENGOTIATION option for this purpose (available from 1.1.0h and above). If you *must* use OpenSSL 1.0.2 then there is a way to do it but it is undocumented and unfortunately this method is no longer possible in OpenSSL 1.1.0+ due to the opacity changes. You can mark a particular SSL object (call it "s") so that it should not do renegotiation like this: s->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS; > From what I've read online it isn't possible to disable client-initiated > secure renegotiation in openssl. > Indeed, it could be argued that there are circumstances when it is perfectly > valid for a client to renegotiate a connection especially if it is a > long-running connection. > > The only way I could find of limiting such an attack was to track the > number of renegotiation requests over a time and if we get a high number in > a short period then close the connection. > I believe this can be done in a callback function set up via a call to: > > SSL_CTX_set_info_callback I'd recommend against this approach. A number of applications took this route due to a lack of a good alternative. However it can have unexpected consequences if you later upgrade to OpenSSL 1.1.1 and start using TLSv1.3 (where a number of legitimate interactions happen post-handshake that can be mistaken for renegotiations). Matt
Re: CRYPTO_LOCK_X509_STORE in OpenSSL 1.1.0
On 15/04/2019 12:25, Swamy J-S wrote: > Hi All, > > > I updated openssl from 1.0.2n to 1.1.0g recently and facing some errors in > building my application because many functions and structures are opaque now > in > 1.1.0g. Errors am getting are as below : > > > error: ‘CRYPTO_LOCK_X509_STORE’ undeclared (first use in this function); did > you > mean ‘CRYPTO_EX_INDEX_X509_STORE’? > CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE); > ^~ > CRYPTO_EX_INDEX_X509_STORE > > warning: implicit declaration of function ‘CRYPTO_w_lock’; did you mean > ‘CRYPTO_zalloc’? [-Wimplicit-function-declaration] > CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE); > ^ > CRYPTO_zalloc > > So what is the alternate option available for "CRYPTO_LOCK_X509_STORE" and > "CRYPTO_w_lock" in openssl 1.1.0g ? > What are you attempting to do that requires you to acquire this lock? The API functions should acquire and release the lock automatically where appropriate. Matt
CRYPTO_LOCK_X509_STORE in OpenSSL 1.1.0
Hi All, I updated openssl from 1.0.2n to 1.1.0g recently and facing some errors in building my application because many functions and structures are opaque now in 1.1.0g. Errors am getting are as below : error: ‘CRYPTO_LOCK_X509_STORE’ undeclared (first use in this function); did you mean ‘CRYPTO_EX_INDEX_X509_STORE’? CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE); ^~ CRYPTO_EX_INDEX_X509_STORE warning: implicit declaration of function ‘CRYPTO_w_lock’; did you mean ‘CRYPTO_zalloc’? [-Wimplicit-function-declaration] CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE); ^ CRYPTO_zalloc So what is the alternate option available for "CRYPTO_LOCK_X509_STORE" and "CRYPTO_w_lock" in openssl 1.1.0g ?
Best way of preventing denial of service attacks by way of secure client-initiated renegotiation
Hi all, A customer of ours was recently running security checks against our mail server. To do this they were running the testssl.sh script available at: https://testssl.sh/ The test tool reports a potential DoS thread as a result of client-initiated secure renegotiation as shown from the following line from the test tool's output: [1m Secure Client-Initiated Renegotiation [m[0;33mVULNERABLE (NOT ok)[m, potential DoS threat I have also reproduced their findings in-house. Our mail server is using version 1.0.2g of openssl and the client openssl version was 1.0.2j. In the testssl.sh script it connects to the ssl port using TLS1.2 and the legacy_renegotiation option. When I do a similar test in my test environment I get results like the below: Issue a connect request, pause for 1 second and then Send 'R' to start a renegotiation: (echo -n; sleep 1; echo R) | openssl s_client -CAfile NightlyBuild-CA.cert -crlf -tls1_2 -legacy_renegotiation -connect :465 Output is as follows: CONNECTED(0003) --- Certificate chain 0 s:/C=ie/CN=something/CN=devimpala13.es.cpth.ie i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd --- Server certificate -BEGIN CERTIFICATE- MIIC0DCCAjmgAwIBAgIBATANBgkqhkiG9w0BAQQFADBFMQswCQYDVQQGEwJBVTET ... -END CERTIFICATE- subject=/C=ie/CN=something/CN=devimpala13.es.cpth.ie issuer=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd --- No client certificate CA names sent Client Certificate Types: RSA sign, DSA sign, ECDSA sign Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SH A256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA +SHA1:ECDSA+SHA1 Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SH A256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA +SHA1:ECDSA+SHA1 Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 1297 bytes and written 445 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-GCM-SHA384 Session-ID: A1E559EAFC571033874C52C715E8CE3452751FB80AD843F4E051E77664F20FFE Session-ID-ctx: Master-Key: BE06E684D71B9B3349DBB057C433BB0C0C44717EF2157EAA912A896F43DF8E6E912A69B8258E C9031CF2219F0F031C1B Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: - 61 3a da 77 02 6c 7e 26-c1 98 84 ae 26 21 8f 1d a:.w.l~&&!.. ... Start Time: 1555315404 Timeout : 7200 (sec) Verify return code: 0 (ok) --- 220 devimpala13.es.cpth.ie ESMTP Service ready RENEGOTIATING depth=1 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd verify return:1 depth=0 C = ie, CN = something, CN = devimpala13.es.cpth.ie verify return:1 DONE So, as you can see the initial connection is successful. The renegotiation begins and it returns: verify return:1 I'm not sure if this means renegotiation has failed? Either way the connection remains open. Presumably if a client issued a large number of renegotiations like this the server could become overwhelmed. Note that I got the same results if I remove the -legacy_renegotiation option, so I don't think this has any impact? So, I suppose I firstly need to know if the results from testssl.sh and from my own investigations point to a potential security risk by way of a DoS attack? If so, what is the best way to prevent this. >From what I've read online it isn't possible to disable client-initiated secure renegotiation in openssl. Indeed, it could be argued that there are circumstances when it is perfectly valid for a client to renegotiate a connection especially if it is a long-running connection. The only way I could find of limiting such an attack was to track the number of renegotiation requests over a time and if we get a high number in a short period then close the connection. I believe this can be done in a callback function set up via a call to: SSL_CTX_set_info_callback So, is the above information correct or is there a better way of preventing this sort of attack. Do we really need to allow a limited form of client-based secure renegotiation? If preventing an attack by way of monitoring the number of renegotiations over time is the only good approach, do you have any code examples in C as to how to implement this? Many thanks, Tim
Blinding implementation in OpenSSL
Hello, Could you please explain how blinding works in OpenSSL? EC_KEY structure seems to have an unblinded private key structure and blinded X, Y, Z- coordinates of the public key when blinding is in use. But if I understand correctly, he idea of blinding is protecting the private key from extracting from memory/swap/etc? Am I wrong? Many thanks in advance! -- SY, Dmitry Belyavsky
RE: How to disable tls 1.0 and tls 1.1
>>If you want to disable TLSv1.0 and TLSv1.1 then you should do so at run time. >>Use the SSL_OP_NO_TLSv1 and SSL_OP_NO_TLSv1_1 options to the >>SSL_CTX_set_options() or SSL_set_options() functions. Since we have many applications using openssl services, it is difficult to implement this in all applications. I need to find a single point in openssl source code[If not in Makefile] to disable TLSv1.0 and TLS1.1 for both server and client communications. Thanks in advance, Chethan -Original Message- From: Matt Caswell [mailto:m...@openssl.org] Sent: Friday, April 12, 2019 9:21 PM To: Chethan Kumar ; openssl-users@openssl.org Subject: Re: How to disable tls 1.0 and tls 1.1 On 12/04/2019 15:50, Chethan Kumar wrote: > Thank to both Hubert Kario and Matt Caswell for your valuable information. > This group has helped a lot in gaining many insights on openssl for newbie > like me. > > I was wrong with my understanding. > But i executed below command to communicate with TLS1.2 when only > TLS1.0 and 1.1 was disabled, Even it got failed to execute by saying "unknown > option -tls1_2". > Any reason for that.? Ah! My apologies - I've just now realised that you are using OpenSSL 1.0.2 (and going back to your original post I see that you did actually say that). Sorry for misleading you. OpenSSL 1.0.2 works differently to later versions in this regards and quite inconsistently. You can disable SSLv2 and SSLv3 at compile time (SSLv2 is disabled by default) using the no-ssl2 and no-ssl3 options. If you want to disable TLSv1.0 and TLSv1.1 then you should do so at run time. Use the SSL_OP_NO_TLSv1 and SSL_OP_NO_TLSv1_1 options to the SSL_CTX_set_options() or SSL_set_options() functions. Matt > > Thanks in advance, > Chethan Kumar > > -Original Message- > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On > Behalf Of Matt Caswell > Sent: Friday, April 12, 2019 7:28 PM > To: openssl-users@openssl.org > Subject: Re: How to disable tls 1.0 and tls 1.1 > > > > 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(0003) >> 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 > > The information contained in this e-mail message and in any > attachments/annexure/appendices is confidential to the recipient and > may contain privileged information. > If you are not the intended recipient, please notify the sender and > delete the message along with any attachments/annexure/appendices. You > should not disclose, copy or otherwise use the information contained > in the message or any annexure. Any views expressed in this e-mail are > those of the individual sender except where the sender specifically > states them to be the views of Toshiba Software India Pvt. Ltd. > (TSIP),Bangalore. > > Although this transmission and any attachments are believed to be free > of any virus or other defect that might affect any computer system > into which it is received and opened, it is the responsibility of the > recipient to ensure that it is virus free and no responsibility is > accepted by Toshiba Embedded Software India Pvt. Ltd,
