o: CODERE Carl-Eric ; openssl-
> > > us...@openssl.org
> > > Subject: Re: OpenSSL 3.0.0 security concerns using dynamic
> > > providers
> > >
> > >
> > >
> > > On 01/09/2020 03:01, CODERE Carl-Eric wrote:
> > > > 1. Replacing
On 01/09/2020 16:46, CODERE Carl-Eric wrote:
> Greetings,
> Thanks for the quick reply, actually from the perspective
> of mobile
> security, once the platform sandbox has been compromised, it is much
> easier for an attacker to replace a shared library with another one he
On Tue, 2020-09-01 at 15:46 +, CODERE Carl-Eric wrote:
> > -Original Message-
> > From: Matt Caswell [mailto:m...@openssl.org]
> > Sent: mardi 1 septembre 2020 18:57
> > To: CODERE Carl-Eric ; openssl-
> > us...@openssl.org
> > Subject: Re: OpenSSL 3
> -Original Message-
> From: Matt Caswell [mailto:m...@openssl.org]
> Sent: mardi 1 septembre 2020 18:57
> To: CODERE Carl-Eric ; openssl-
> us...@openssl.org
> Subject: Re: OpenSSL 3.0.0 security concerns using dynamic providers
>
>
>
> On 01/09/2020
On 01/09/2020 03:01, CODERE Carl-Eric wrote:
> 1. Replacing the provider by a tampered provider by replacing the
> shared/dynamic library. This can partially be protected by the caller
> verifying the hash of the provider before calling it, will OpenSSL 3.0.0
> do this, or will need to be done a
Greetings,
We are currently investigating the usage of OpenSSL 3.0.0 on
our side, especially for FIPS usage, but it seems that for OpenSSL 3.0.0 the
providers, especially the FIPS provider, will be loaded dynamically, my main
worry is that this will easily permit some kind of
