How to disable ssl renegotiation?

[okayabc]

[mattcaswell]

Assuming you are using OpenSSL 1.1.1 or above then you should call SSL_CTX_set_options or SSL_set_options with the option SSL_OP_NO_RENEGOTIATION. See the man page here:

https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_options.html

[okayabc]

pkg-config --cflags openssl
-I/usr/local/include

openssl version
OpenSSL 1.1.1d 10 Sep 2019

When i compile my service, it report the following error:

/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: warning: libssl.so.1.1, needed by /usr/local/lib/libevent_openssl.so, may conflict with libssl.so.1.0.0
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: Module/HttpServer.o: undefined reference to symbol 'TLS_server_method@@OPENSSL_1_1_0'
/usr/local/lib64/libssl.so.1.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

what is the reason?

[mattcaswell]

That is an entirely separate question - please raise a different issue for it.

[okayabc]

When i issue my service to other machine using libssl.so.1.1, according to what you said

Assuming you are using OpenSSL 1.1.1 or above then you should call SSL_CTX_set_options or SSL_set_options with the option SSL_OP_NO_RENEGOTIATION

then i should call SSL_CTX_set_options with SSL_OP_NO_RENEGOTIATION?

[mattcaswell]

Yes.

[okayabc]

Current problem is i have compiled my service successfullly in an openssl include directory(temporarily
i call it directory A) with ssl.h which doesn't contain SSL_OP_NO_RENEGOTIATION option.
In order to use this option, i use ssl.h from /usr/local/include/openssl because
pkg-config --cflags openssl
-I/usr/local/include
tells me to do this.
I have changed my makefile to remove openssl include dir of directory A and compile my service again, it report the above error.

[okayabc]

If my openssl version is below 1.1.1, how to disable ssl regotiation?

[mattcaswell]

It's not really properly supported or documented prior to that version. In 1.0.2 you should be able to do this:

s->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS;

But that will fail to compile in later versions.

[okayabc]

I have done like this:
SSL_CTX_set_info_callback(context_.native_handle(),dv_handshake_callback);

static void dv_handshake_callback(const SSL *ssl, int type, int val)
{
if (0 != (type & SSL_CB_HANDSHAKE_DONE))
{
ssl->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS;
}
}
Why dv_handshake_callback is not called when running?

[mattcaswell]

Why do you need to set this via the info callback? Just set the flag after you create the SSL object.

[okayabc]

I have replaced libssl.so.1.1 with libssl.so.1.0.0, it's ok.
But how to verify ssl renegotiation is disabled?
I use openssl s_client -connect 172.31.0.22:443 ,

HEAD / HTTP/1.0
R
RENEGOTIATING
but the output is still RENEGOTIATING and no other response, is renegotiation disabled?

[okayabc]

You mean this?
SSL_CTX ctx= SSL_CTX_new(SSLv23_server_method());
ctx->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS;

[mattcaswell]

No...I mean where ever you create the SSL object via SSL_new().

[okayabc]

After
HEAD / HTTP/1.0
R,
I found using SSL_CTX_set_info_callback, the output is only RENEGOTIATING ,
But using ssl->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS, the output like this:

HEAD / HTTP/1.0
R
RENEGOTIATING
Can't use SSL_get_servername
depth=0 C = US, ST = CA, L = Los Angeles, O = Oblong Industries, OU = Plasma, CN = localhost
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = CA, L = Los Angeles, O = Oblong Industries, OU = Plasma, CN = localhost
verify error:num=21:unable to verify the first certificate
verify return:1

[deepakjain111]

were you able achieve disabling Renegotiation by setting ssl->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS?
If yes, did you set in callback or directly to the SSL object after SSL_New?

[okayabc]

@deepakjain111 , i set it in both place.

[deepakjain111]

@okayabc : It is not working if i set flag after SSL_New whereas if i set through callback function then it hung/block renegotiation request, that is, working.

static void ssl_info_callback(const SSL *ssl, int what, int ret)
{
if (what & SSL_CB_HANDSHAKE_DONE)
ssl->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS;
}

Should we really set flag after SSL_New?
@mattcaswell : Could you please comment here?

P.S : i am using openssl 1.0.2 as well 1.1.
For 1.1, i am using SSL_OP_NO_RENEGOTIATION. Above discussion is for 1.0.2

[mattcaswell]

Should we really set flag after SSL_New?

I can't think of a good reason why it wouldn't work at that point. I had a quick grep through the source and can't find a location where this flag might get reset. To test properly someone would have to put this through a debugger to figure out why it doesn't work.

[boroknagyz]

Hey Everyone,

I ran into the same issue, i.e. I can disable RENEGOTIATIONs when using a callback like the above 'ssl_info_callback()', but cannot disable it when setting the flag right after SSL_new(). Though I can disable RENEGOTIATIONs if I set the flag after SSL_accept().

So I created a debug build of OpenSSL_1_0_2-stable (12ad22d), and checked what resets the flag:

(gdb) watch ssl->s3->flags
...
Hardware watchpoint 2: ssl->s3->flags

Old value = 1
New value = 0
0x00007ffff7898a59 in __memset_sse2 () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff7898a59 in __memset_sse2 () from /lib64/libc.so.6
#1  0x000000000042e899 in ssl3_clear (s=0x86dbd0) at s3_lib.c:3145
#2  0x0000000000403bf8 in tls1_clear (s=0x86dbd0) at t1_lib.c:225
#3  0x00000000004107c4 in SSL_clear (s=0x86dbd0) at ssl_lib.c:270
#4  0x0000000000402834 in ssl23_accept (s=0x86dbd0) at s23_srvr.c:167
#5  0x00000000004121d9 in SSL_accept (s=0x86dbd0) at ssl_lib.c:999
#6  0x0000000000402321 in main (argc=2, argv=0x7fffffffe588) at ssl-echo.c:222

It is getting reset in SSL_accept().
So do you think it is a bug? I know a few projects that set the flag after SSL_new() but before SSL_accept().

[arapov]

@BugOfBugs, if you feel your questions remained unanswered, you might consider finding another medium to pose them. Your questions lie outside the context of the initial report.

[BugOfBugs]

@t8m do you mean application can not set flags? How to set them? In file of configuration of OpenSSL?
Reset of flags can not be irrelevant. User expects them to stay. But they unexpectedly change.

@boroknagyz perhaps could set call back in SSL_accept() to set flags after it resets, but before it negotiates with client.
Or edit source code, and compile.

[t8m]

There is only get flags CTRL and no set flags CTRL on 1.1+.

The flags that can be set there internally from libssl are meaningful only after SSL_accept() call so there is no reason why the clear() call would break anything.

[BugOfBugs]

@t8m you mean ssl->s3->flags are indicators, rather than controls?
This means that @boroknagyz looked at wrong flags.
But @mattcaswell suggests to use those.

[mattcaswell]

@t8m you mean ssl->s3->flags are indicators, rather than controls?
This means that @boroknagyz looked at wrong flags.
But @mattcaswell suggests to use those.

What I said was:

It's not really properly supported or documented prior to that version. In 1.0.2 you should be able to do this:

s->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS;
But that will fail to compile in later versions.

So, there is a "not really properly supported or documented" workaround that should work in 1.0.2 but will fail to compile in later versions. That approach is based on setting a flag. The flags are really an internal thing that were exposed for setting in 1.0.2 (because everything was exposed in 1.0.2), but are no longer accessible in 1.1.1 (hence why you would get a compile failure).

In 1.1.1 and above you should use SSL_OP_NO_RENEGOTIATION instead. This is the supported, documented way to do this.

What @t8m said was:

There is only get flags CTRL and no set flags CTRL on 1.1+.

Which is also entirely correct. You cannot get or set the flags directly in 1.1.1 (you will get a compile failure). You can use a CTRL to get the flags but there is no way to set them in 1.1.1 and above, i.e. what @t8m said and what I said are entirely consistent with each other.