The forum will be down for maintenance over the weekend of August 18-20, 2017. The forum will be shut down on the evening (EDT) of Friday, August 18. Downtime is unknown but may be up to two days. The forum will be restarted as soon as maintenance is complete.

19.08.2015 - 17:57:39 CET - Info for Customer by SAP
Hi Ilia,
We have fixed a memory leak as part of CR #788402 in 12.0.1.4310 and
16.0.1.2173 (this is the reference number you will find in the readme
file that ships with each patch): "When calling a secure web
procedure, the database server would leak memory. This has been fixed"...

I don't recognize this pattern myself. If this information does not help do open up a support call to help drill into this deeper.

One factor to be aware of is that the encryption libraries changed from Certicom to OpenSSL between those builds. So, this issue could be related to the conditions on that machine in relationship with the latter library. But it is hard to ascribe that assertion to this scenario.

Is this constant error for all connection attempts? Intermittent? Just rare?

FWIW If this turns out to be just an issue with encrypted connections, you should be able to run unencrypted or with just simple encryption until this is resolved.

The assertion itself is not so much a leak but related to address map allocation. It is related to an attempt access a large contiguous block of addresses (which itself makes less sense). How that is being caused by a new connection attempt is not so clear.

I would like to clarify once again:
- HTTPS-Request with 'Certificate Signing, CRL Signing'-certificate done many times (~1000).
- Suddenly there is 'The TLS handshake failed, error code 8'-error.
- Error is repeated for every request until the ASA12-server is rebooted.
- After rebooting the ASA12-server requests are "error-free" again...

Error occurs approximately once a day.
The certificate remains unchanged.

To test the hypothesis about memory leaks I use Resource Monitor.
I performed 3,600 HTTPS-requests.
At the same time the working set:
for 12.0.1.4178 increased by approximately 20,000 K,
for 12.0.1.3537 has not changed.

I guess there is always a chance you are hitting a vulnerability CVE-2015-0205

According to the OpenSSL site
"... A memory leak can occur in . . . under certain conditions. . . . The memory leak
could be exploited by an attacker in a Denial of Service attack through memory exhaustion. ... "
•Fixed in OpenSSL 1.0.1k

We started shipping EBFs / SPs with OpenSSL 1.0.1k (or higher) for Windows as of EBF#4183 / SP82; so you should retest with one of those.

I don't believe you have described a vulnerability to this ... but I am also uncertain if your -xs logging would show such a denial of service attack if you are exposed to that possibility.

... but again ... if this does not help we would need to reproduce this happening