As a workaround, what about first making a JNI call to a trivial shared object
that does an explicit dlopen of the OpenSSL shared object? The JVM wouldn't
know about that load, and its subsequent unload of the shared object wouldn't
remove it from the process address space, because there would
Hi,
with OpenSSL 1.1.1 it is possible to turn off the automatic cleanup with
an atexit() handler by passing the flag OPENSSL_INIT_NO_ATEXIT to
OPENSSL_init_crypto().
Is it possible to configure this also at the thread level, so that no
automatic thread cleanup occurs, with the option to do
On 27/03/2020 21:52, Viktor Dukhovni wrote:
> On Fri, Mar 27, 2020 at 09:25:28PM +, Jeremy Harris wrote:
>
>>> If the distro started with 1.1.1 and only backported security fixes, you
>>> could be running an OpenSSL version with the unintentional bidirectional
>>> setting.
>>
>> .. either
On Fri, Mar 27, 2020 at 08:20:55PM +, Jeremy Harris wrote:
> > Right, you're running out of space by trying to send too many
> > CA names. It is better to have this fail, so you can figure
> > what is trying to dump your entire trusted CA list (of names)
> > to the server, than to actually
On Fri, Mar 27, 2020 at 09:25:28PM +, Jeremy Harris wrote:
> > If the distro started with 1.1.1 and only backported security fixes, you
> > could be running an OpenSSL version with the unintentional bidirectional
> > setting.
>
> .. either this, or even an unpatched basic 1.1.1 .
>
> A
On 27/03/2020 21:07, Viktor Dukhovni wrote:
> That function should only affect the server -> client direction.
> Briefly, in OpenSSL 1.1.1 it affected both the client and server
> directions, but this was fixed in OpenSSL 1.1.1a.
If Centos is following the same pattern in 8 as they did in 7,
they
On 26/03/2020 00:58, Viktor Dukhovni wrote:
> On Thu, Mar 26, 2020 at 12:40:08AM +, Jeremy Harris wrote:
>
>> Looks like I'm wrong, from the behaviour.
>>
>> It's the second of the possible places, and "i" is 129.
>> It appears to be failing the WPACKET_sub_allocate_bytes_u16()
>> call.
On Fri, Mar 27, 2020 at 10:10:16PM +, Jeremy Harris wrote:
> >> A simple code addition to avoid that call in the client case sounds
> >> in order.
>
> Testing, it appears to work - I get resumption and not that error.
> And the Exim testsuite shows no regressions, at least on my laptop
>
I am writing a SSL/TLS client (using Boost.Beast but underlying it's using
OpenSSL) and although I have set on the SSL context the 'verify_peer' flag,
there is no verification to prove the server presents an X509 which
contains in the Subject Alternative Names the hostname of that server.
As this
On Fri, Mar 27, 2020 at 07:38:35PM +0200, George-Theodor Serbana wrote:
> I am writing a SSL/TLS client (using Boost.Beast but underlying it's using
> OpenSSL) and although I have set on the SSL context the 'verify_peer' flag,
> there is no verification to prove the server presents an X509 which
Hello Michael,
Am 27.03.20 um 15:46 schrieb Michael Wojcik:
As a workaround, what about first making a JNI call to a trivial shared
object that does an explicit dlopen of the OpenSSL shared object? The
JVM wouldn't know about that load, and its subsequent unload of the
shared object wouldn't
11 matches
Mail list logo
