It seems any TLS being allocated from the call stack of ERR_get_state() is not getting freed. I used an OPENSSL sample demos\bio\server-cmod.c and it reproduces the issue.
Any tips to resolve this issue is appreciated.
> testConsoleApplication.exe!CRYPTO_THREAD_init_local(unsigned long * key, void (void *) * cleanup) Line 93 C
testConsoleApplication.exe!err_do_init() Line 637 C
testConsoleApplication.exe!err_do_init_ossl_() Line 634 C
testConsoleApplication.exe!CRYPTO_THREAD_run_once(long * once, void (void) * init) Line 82 C
testConsoleApplication.exe!ERR_get_state() Line 643 C
testConsoleApplication.exe!ERR_put_error(int lib, int func, int reason, const char * file, int line) Line 358 C
testConsoleApplication.exe!BIO_new_file(const char * filename, const char * mode) Line 75 C
testConsoleApplication.exe!def_load(conf_st * conf, const char * name, long * line) Line 140 C
testConsoleApplication.exe!NCONF_load(conf_st * conf, const char * file, long * eline) Line 217 C
testConsoleApplication.exe!CONF_modules_load_file(const char * filename, const char * appname, unsigned long flags) Line 129 C
testConsoleApplication.exe!main(int argc, char * * argv) Line 120 C++
[External Code]
//demos\bio\server-cmod.c
#include <stdio.h>
#include <signal.h>
#include <openssl/err.h>
#include <openssl/ssl.h>
#include <openssl/conf.h>
int main(int argc, char *argv[])
{
unsigned char buf[512];
char *port = "*:4433";
BIO *in = NULL;
BIO *ssl_bio, *tmp;
SSL_CTX *ctx;
int ret = 1, i;
ctx = SSL_CTX_new(TLS_server_method());
if (CONF_modules_load_file("cmod.cnf", "testapp", 0) <= 0) {
fprintf(stderr, "Error processing config file\n");
goto err;
}
if (SSL_CTX_config(ctx, "server") == 0) {
fprintf(stderr, "Error configuring server.\n");
goto err;
}
/* Setup server side SSL bio */
ssl_bio = BIO_new_ssl(ctx, 0);
if ((in = BIO_new_accept(port)) == NULL)
goto err;
/*
* This means that when a new connection is accepted on 'in', The ssl_bio
* will be 'duplicated' and have the new socket BIO push into it.
* Basically it means the SSL BIO will be automatically setup
*/
BIO_set_accept_bios(in, ssl_bio);
again:
/*
* The first call will setup the accept socket, and the second will get a
* socket. In this loop, the first actual accept will occur in the
* BIO_read() function.
*/
if (BIO_do_accept(in) <= 0)
goto err;
for (;;) {
i = BIO_read(in, buf, sizeof(buf));
if (i == 0) {
/*
* If we have finished, remove the underlying BIO stack so the
* next time we call any function for this BIO, it will attempt
* to do an accept
*/
printf("Done\n");
tmp = BIO_pop(in);
BIO_free_all(tmp);
goto again;
}
if (i < 0) {
if (BIO_should_retry(in))
continue;
goto err;
}
fwrite(buf, 1, i, stdout);
fflush(stdout);
}
ret = 0;
err:
if (ret) {
ERR_print_errors_fp(stderr);
}
BIO_free(in);
exit(ret);
return (!ret);
}
On Sat, Mar 25, 2017 at 8:59 PM, ghanashyam satpathy <ghanashyam.satpathy@xxxxxxxxx> wrote:
However this type of TLS leak was not there when my application was using OpenSSL 1.0.2Noticed after using OpenSSL 1.1.0bOn Sat, Mar 25, 2017 at 8:12 PM, <openssl-users-request@openssl.org > wrote:Send openssl-users mailing list submissions to
openssl-users@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
openssl-users-request@openssl.org
You can reach the person managing the list at
openssl-users-owner@xxxxxxxxxxg
When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."
Today's Topics:
1. OpenSSL sending close_notify right after responding to a
heartbeat request (R Kaja Mohideen)
2. Re: how to implement functions for STACK OF custom type?
(Dr. Stephen Henson)
3. TLSv1_2_method (Lei Kong)
4. Re: TLSv1_2_method (Viktor Dukhovni)
5. TLS leak for openssl 1.1.0b with libcurl 7.50.3
(ghanashyam satpathy)
6. Re: TLS leak for openssl 1.1.0b with libcurl 7.50.3 (Salz, Rich)
------------------------------------------------------------ ----------
Message: 1
Date: Fri, 24 Mar 2017 19:10:41 +0530
From: R Kaja Mohideen <reachme@xxxxxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: OpenSSL sending close_notify right after
responding to a heartbeat request
Message-ID:
<CAMSoAtDCh7AZTBJeOtVa=Gdk3YZ2yTStdwem56eN_d=eNVgaCQ@mail. gmail.com >
Content-Type: text/plain; charset=UTF-8
Hi,
We have a TLS Server (Written in C) and Client (Written in Java using
Netty + OpenSSL).
I see that when Server sends a TLS extension Heartbeat request to
client - OpenSSL responds to it and sends a close_notify alert right
after it - causing the server to close the session with client.
I don't have any callback registered in client (HB request recipient
side - Java/Netty doesn't really have that support) and so I'm sure
that it is OpenSSL by itself is responding to that heartbeat request.
But, who or what is making OpenSSL to send an alert & close the
session upon responding to heartbeat remains a mystery.
Any help / suggestions to investigate this issue is highly appreciated.
Thanks & regards,
R Kaja Mohideen
------------------------------
Message: 2
Date: Fri, 24 Mar 2017 17:46:28 +0000
From: "Dr. Stephen Henson" <steve@xxxxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: Re: how to implement functions for STACK OF
custom type?
Message-ID: <20170324174628.GA16753@openssl.org >
Content-Type: text/plain; charset=iso-8859-1
On Tue, Mar 21, 2017, lists wrote:
> Sorry, I first posted this on the -dev list, likely inappropriate... now with an update:
>
> I am exploring my options with OpenSSL and specifically I am trying to manage the stacks for some custom objects.
> Currently, I have this code (sort of) in the headers:
>
> typedef struct myThingA_st
> {
> ???? ASN1_OBJECT aID;
> ???? ASN1_OCTET_STRING aOCST;
> }
> ???? myThingA;
>
> DECLARE_ASN1_ITEM(myThingA)
> DECLARE_ASN1_FUNCTIONS(myThingA)
> DECLARE_STACK_OF(myThingA)
> // the next one seems to be ininfluent for my purpose, is it?
> DECLARE_ASN1_SET_OF(myThingA)
>
> typedef struct myThingB_st
> {
> ???? // SEQUENCE OF { ... }
> ???? STACK_OF(myThingA) myThingA_sk;
> }
> ???? myThingB;
>
> // DECLARE_ASN1_ITEM(myThingB)
> DECLARE_STACK_OF(myThingB)
> // DECLARE_ASN1_FUNCTIONS(myThingB)
> // the next one seems to be ininfluent for my purpose, is it?
> DECLARE_ASN1_SET_OF(myThingB)
>
> Then, in the .c file...
>
> IMPLEMENT_STACK_OF(myThingA)
> IMPLEMENT_STACK_OF(myThingB)
>
> I thought that the basic functions for the stacks to be available (such as sk_myThingA_new, sk_myThingA_push...), yet by compiling a main, for
> the first one that I try to use I get:
>
> ?????? undefined reference to `sk_myThingA_value'
>
> What am I doing wrong here?
If you're using OpenSSL 1.1.0 you need to include:
DEFINE_STACK_OF(FOO)
in a header file and that should be it. That implements a set of inline
functions that do the right thing.
For OpenSSL versions before 1.1.0 it's a bit messier. The type specific
STACK_OF functions are actually macros which are generated by the mkstack.pl
script and appear in the safestack.h header file. If you want to create your
own one way is to extract a type specific section from safestack.h, copy it
to your own header file and do a search/replace for the new type.
So for example extract the sk_OPENSSL_BLOCK macros and replace OPENSSL_BLOCK
with FOO.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
------------------------------
Message: 3
Date: Fri, 24 Mar 2017 21:51:07 +0000
From: Lei Kong <leikong@xxxxxxx>
To: "openssl-users@xxxxxxxxxxx" <openssl-users@xxxxxxxxxxx>
Subject: TLSv1_2_method
Message-ID:
<BN1PR01MB021823477985DD1AFB7D042A83E0@xxxxxxxxxxxxxxxxxxxxx >hangelabs.com
Content-Type: text/plain; charset="us-ascii"
Can processes running with TLSv1_2_method talk to processes running with something older, e.g. TLSv1_1_method? Along the same lines, will new TLS versions be backward compatible with TLSv1_2_method ?
I would like to make my code proof, is there something like TLS_latest_method()?
I have a cluster of nodes that talk to each other with TLS, currently the version is hardcoded to TLSv1_2_method. Suppose TLSv1_2 is deprecated by TLS_new one day, I update my service to use TLS_new node by node, during this time, some old nodes are running with TLSv1_2, some new nodes are running with new TLS_new, will the communication between old and new nodes work?
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/ >20170324/1f4d53f0/attachment- 0001.html
------------------------------
Message: 4
Date: Sat, 25 Mar 2017 03:19:55 -0400
From: Viktor Dukhovni <openssl-users@xxxxxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: Re: TLSv1_2_method
Message-ID: <5D881D46-87A5-4053-B166-F1EE4AA52619@xxxxxxxxxxxx >
Content-Type: text/plain; charset=us-ascii
> On Mar 24, 2017, at 5:51 PM, Lei Kong <leikong@xxxxxxx> wrote:
>
> TLS_latest_method
https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_new.html
...
TLS_method(), TLS_server_method(), TLS_client_method()
These are the general-purpose version-flexible SSL/TLS methods.
The actual protocol version used will be negotiated to the
highest version mutually supported by the client and the server.
The supported protocols are SSLv3, TLSv1, TLSv1.1 and TLSv1.2.
Applications should use these methods, and avoid the version-specific
methods described below.
With OpenSSL 1.0.2 these are called SSLv23_method(), ...
https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_new.html
--
Viktor.
------------------------------
Message: 5
Date: Sat, 25 Mar 2017 19:35:06 +0530
From: ghanashyam satpathy <ghanashyam.satpathy@xxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: TLS leak for openssl 1.1.0b with libcurl
7.50.3
Message-ID:
<CAKn+8OKWHspSvk=sxZfz3PSOZK5qXkWQTy3z+3PimCiFrOnXkw@xxxxxxx >ail.com
Content-Type: text/plain; charset="utf-8"
I use libcurl 7.50.3 as statically linked in my application dll , along
with openssl 1.1.0b also statically linked. The dll is dynamically loaded
using LoadLibrary() and unloaded using FreeLibrary() inside application
exe. I observed a TLS index is not getting freed which was allocated inside
openssl. To narrow down the issue I have following exported function, which
I call from my application exe. After FreeLibrary() I see the TLS leak
through APplication verifier.
extern "C" __declspec(dllexport)
void CurlSetup()
{
curl_global_init(CURL_GLOBAL_DEFAULT);
curl_global_cleanup();
return;
}
An early reply in this context is appreciated.
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/ >20170325/12c0ccde/attachment- 0001.html
------------------------------
Message: 6
Date: Sat, 25 Mar 2017 14:13:47 +0000
From: "Salz, Rich" <rsalz@xxxxxxxxxx>
To: "openssl-users@xxxxxxxxxxx" <openssl-users@xxxxxxxxxxx>
Subject: Re: TLS leak for openssl 1.1.0b with libcurl
7.50.3
Message-ID:
<6d87957f6c654825a6a6c6f0d3d4a20a@xxxxxxxxxxxxxxxxxxxxxxxx.a >kamai.com
Content-Type: text/plain; charset="utf-8"
Those are curl functions, not openssl
--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz@xxxxxxxxx Twitter: RichSalz
From: ghanashyam satpathy [mailto:ghanashyam.satpathy@gmail.com ]
Sent: Saturday, March 25, 2017 10:05 AM
To: openssl-users@xxxxxxxxxxx
Subject: TLS leak for openssl 1.1.0b with libcurl 7.50.3
I use libcurl 7.50.3 as statically linked in my application dll , along
with openssl 1.1.0b also statically linked. The dll is dynamically loaded
using LoadLibrary() and unloaded using FreeLibrary() inside application
exe. I observed a TLS index is not getting freed which was allocated inside
openssl. To narrow down the issue I have following exported function, which
I call from my application exe. After FreeLibrary() I see the TLS leak
through APplication verifier.
extern "C" __declspec(dllexport)
void CurlSetup()
{
curl_global_init(CURL_GLOBAL_DEFAULT);
curl_global_cleanup();
return;
}
An early reply in this context is appreciated.
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/ >20170325/1a5b8980/attachment. html
------------------------------
Subject: Digest Footer
_______________________________________________
openssl-users mailing list
openssl-users@xxxxxxxxxxx
https://mta.openssl.org/mailman/listinfo/openssl-users
------------------------------
End of openssl-users Digest, Vol 28, Issue 33
*********************************************
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
