PRNG not available when multiple providers are configured?

[Thomas Dwyer III]

I'm having trouble getting RAND_status() to return 1 when my openssl.cnf
has both the default provider and the fips provider configured at the same
time:

openssl_conf = openssl_init

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
fips = fips_sect

[default_sect]
activate = 1

.include /conf/openssl/fips.cnf

If I remove either default or fips from [provider_sect] then RAND_status()
returns 1. If I leave them both specified there, RAND_status() always
returns 0. Is this the expected behavior or am I doing something wrong? I
understand that I must specify properties when fetching algorithms in order
to get deterministic behavior with multiple providers loaded. Is there an
analogous API for the PRNG that I'm overlooking?

Interestingly, setting activate=0 for either provider is not sufficient to
work around this issue.


Thanks,
Tom.III

Re: Project direction

[Michael Richardson]

Angus Robertson - Magenta Systems Ltd  wrote:
> Also, there is an assumption OpenSSL is only used by other C developers,
> by the use of public macros that are not usable in any other language.
> BoringSSL replaced macros with exports and OpenSSL should consider
> doing the same.

This.

> There needs to be more task oriented documentation, for instance
> collecting the APIs needed to create a CSR or certificate, using APIs
> rather than command line tools which is where much of the documentation
> currently resides. For instance there is no documentation about
> building a stack of extensions to add SANs to requests and certificates
> so a lot of research is needed to adds SANs to a certificate.

My claim is that much of the "applications" should be removed from the core
system, and should be re-implemented in a cleaner way using the APIs.
I.e. into a separate git repo with it's own release schedule.

They should serve as exemplars for using the APIs, which they are often are not.

In particular, the way that many things are only doable via "configuration file"
is a serious problem.

Yes, the applications are used as part of the tests, but I'm not saying that
they shouldn't be pulled in as a github.

Could Perl wrapper be used for more?  Could it be used exclusively?
(No calls out to "openssl ca" to generate a certificate...)
The tests do not serve as particularly good examplars, because of the mix of
C and perl, sometimes the perl is just running some .c code that was 
compiled... sometimes not.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[










signature.asc
Description: PGP signature

Re: Project direction

[Angus Robertson - Magenta Systems Ltd]

> The idea being that supporting existing users means not changing 
> the existing API, whereas catering to new users means working 
> towards a new fresh consistent API.

OpenSSL has been in use for getting on for 20 years (I think) and may
still be in use in another 20 years, so can not stay still to make life
easy for old projects, it has to evolve for new projects, as it does.  

But any changes should be clearly documented and should not require the
use of third party sites like ABI to discover new APIs and changes to
old ones.  Major changes are usually in the changelog, but can be hard
to find when updating from a much earlier release.  

There should really be detailed articles about upgrading from any long
term release to the latest release, with simple lists of all exports or
macros removed or added, or whose use has changed. 

Also, there is an assumption OpenSSL is only used by other C developers,
by the use of public macros that are not usable in any other language.
BoringSSL replaced macros with exports and OpenSSL should consider
doing the same.  

Currently changing a macro to an export is rarely documented, so it's
hard for those that have rewritten macros in other languages to know
something will be broken. 

There needs to be more task oriented documentation, for instance
collecting the APIs needed to create a CSR or certificate, using APIs
rather than command line tools which is where much of the documentation
currently resides. For instance there is no documentation about
building a stack of extensions to add SANs to requests and certificates
so a lot of research is needed to adds SANs to a certificate. 

Angus


  

openssl ocsp(responder) cmd is giving error for ipv6

[perumal v]

HI All,
I tried openssl ocsp for ipv6 and got the error message for the
OCSP.

  IPv6 address with the "[]" bracket.
---
openssl ocsp -url http://*[2001:DB8:64:FF9B:0:0:A0A:285E]*:8090/ocsp-100/
-issuer /etc/cert/ipsec/cert0/ca.crt -CAfile /etc/cert/ipsec/cert0/ca.crt
-cert /etc/cert/ipsec/cert0/cert.crt
*Error creating connect BIO*
*140416130504448:error:20088081:BIO routines:BIO_parse_hostserv:ambiguous
host or service:crypto/bio/b_addr.c:547:*

IPv6 address without the "[]" bracket.
--
openssl ocsp -url http://*2001:DB8:64:FF9B:0:0:A0A:285E*:8090/ocsp-100/
-issuer /etc/cert/ipsec/cert0/ca.crt -CAfile /etc/cert/ipsec/cert0/ca.crt
-cert /etc/cert/ipsec/cert0/cert.crt


*Error connecting BIOError querying OCSP responder*

i am using openssl version : *openssl version*
*OpenSSL 1.1.1h  22 Sep 2020*

Can anybody help me to find out if it is the correct way to use it?.

Thanks,
Perumal.

Re: Decrypt error when using openssl 1.1.1b during SSL handshake

[Matt Caswell]

On 02/11/2020 09:00, Mahendra SP wrote:
> Hi Matt,
> 
> Error is reported from this:
> FILE:../openssl-1.1.1b/ssl/statem/statem_srvr.c, FUNCTION:415,
> LINE:3055, reason=147, alert=51
> 
> We see that hardware is returning 48 bytes. Even if the decrypted
> premaster data is correct, openssl is expecting more than 48 bytes in
> return.
> This check fails as decrypt_len is 48.
> decrypt_len < 11 + SSL_MAX_MASTER_KEY_LENGTH 

Just above this line we call RSA_private_decrypt() with padding set to
RSA_NO_PADDING.

We expect the output *once padding is removed* to be 48 bytes. But
RSA_private_decrypt() should be returning the data *with the padding
included* (because we called it with RSA_NO_PADDING). The minimum valid
padding length is 11 bytes (hence the check above). So it looks to me
like the engine is incorrectly ignoring the RSA_NO_PADDING, and
stripping the padding anyway.

Matt

> 
> We compared the data returned when software is used. Decrypt_len is 256
> bytes and the last 48 bytes are actual premaster secret. Also, openssl
> checks for if the first byte is 0 and second byte is 2. 
> We are trying to rectify this issue in hardware and return the correct data.
> 
> Please suggest if you have any comments for the above info.
> 
> Thanks
> Mahendra
> 
> On Fri, Oct 30, 2020 at 7:50 PM Matt Caswell  > wrote:
> 
> 
> 
> On 30/10/2020 11:22, Mahendra SP wrote:
> > Hi Matt,
> >
> > Thank you for the inputs.
> > Yes, we had encountered the padding issue initially. But we added
> > support for RSA_NO_PADDING in our hardware. That's why we are able to
> > successfully decrypt the premaster secret in the hardware.
> > Hence the issue does not seem to be related to padding. We have
> > confirmed this by comparing the premaster secret on both client and
> > server and they are the same.
> 
> Ok, good.
> 
> >
> > We suspect in this case, verification of "encrypted handshake message"
> > failure is happening.
> 
> It's possible. It would be helpful if you can get more information from
> the error stack on the server, e.g. by using ERR_print_errors_fp() or
> something similar. I'm particularly interested in identifying the source
> file and line number where the decrypt_error is coming from. Printing
> the error stack should give us that information. There are a number of
> places that a "decrypt error" can occur and it would be helpful to
> identify which one is the cause of the problem.
> 
> 
> > We understand constant_time_xx APIs get used for CBC padding
> validation.
> > Will this have  any dependency on the compiler optimization or asm
> > flags?
> 
> CBC padding validation is fairly independent of anything to do with RSA,
> so I think its unlikely to be the culprit here. Of course sometimes
> compiler optimization/asm issues do occur so it can't be ruled out
> entirely - but it's not where I would start looking.
> 
> > Will this issue be seen if hardware takes more time for the
> > operation?
> >
> 
> No. Constant time here just means that we implement the code without any
> branching based on secret data (e.g. no "if" statements/while loops etc
> based on secret dependent data). It has very little to do with how long
> something actually takes to process.
> 
> 
> > Here is the snippet of the wireshark where our device acting as server
> > closes the connection with decryption failure.
> 
> Thanks. To narrow it down further I need to figure out which line of
> code the decrypt_error is coming from as described above.
> 
> Matt
> 
> 
> 
> > If you need any further info, please let us know. 
> > image.png
> > Thanks
> > Mahendra
> >
> > Please suggest.
> >
> >
> >
> > On Fri, Oct 30, 2020 at 3:32 PM Matt Caswell  
> > >> wrote:
> >
> >
> >
> >     On 30/10/2020 09:18, Mahendra SP wrote:
> >     > Hi All.
> >     >
> >     > We have upgraded openssl version to 1.1.1b
> >     >
> >     > With this, we are seeing decryption error during SSL
> handshake for the
> >     > below explained scenario. Our device acts as an SSL server.
> >     >
> >     > We have external hardware to offload RSA private key
> operations using
> >     > the engine.
> >     > Decryption of pre-master secret is done using hardware and is
> >     > successful. We compared the pre-master secret on both server and
> >     client
> >     > and they match.
> >     > However, we see that SSL handshake fails with "decrypt error
> (51)"
> >     with
> >     > an alert number 21. Verifying the encrypted finish message
> on the
> >     server
> >     > side fails.
> >     >
> >     > This issue does not happen with software 

Re: Decrypt error when using openssl 1.1.1b during SSL handshake

[Mahendra SP]

Hi Matt,

Error is reported from this:
FILE:../openssl-1.1.1b/ssl/statem/statem_srvr.c, FUNCTION:415, LINE:3055,
reason=147, alert=51

We see that hardware is returning 48 bytes. Even if the decrypted premaster
data is correct, openssl is expecting more than 48 bytes in return.
This check fails as decrypt_len is 48.
decrypt_len < 11 + SSL_MAX_MASTER_KEY_LENGTH

We compared the data returned when software is used. Decrypt_len is 256
bytes and the last 48 bytes are actual premaster secret. Also, openssl
checks for if the first byte is 0 and second byte is 2.
We are trying to rectify this issue in hardware and return the correct data.

Please suggest if you have any comments for the above info.

Thanks
Mahendra

On Fri, Oct 30, 2020 at 7:50 PM Matt Caswell  wrote:

>
>
> On 30/10/2020 11:22, Mahendra SP wrote:
> > Hi Matt,
> >
> > Thank you for the inputs.
> > Yes, we had encountered the padding issue initially. But we added
> > support for RSA_NO_PADDING in our hardware. That's why we are able to
> > successfully decrypt the premaster secret in the hardware.
> > Hence the issue does not seem to be related to padding. We have
> > confirmed this by comparing the premaster secret on both client and
> > server and they are the same.
>
> Ok, good.
>
> >
> > We suspect in this case, verification of "encrypted handshake message"
> > failure is happening.
>
> It's possible. It would be helpful if you can get more information from
> the error stack on the server, e.g. by using ERR_print_errors_fp() or
> something similar. I'm particularly interested in identifying the source
> file and line number where the decrypt_error is coming from. Printing
> the error stack should give us that information. There are a number of
> places that a "decrypt error" can occur and it would be helpful to
> identify which one is the cause of the problem.
>
>
> > We understand constant_time_xx APIs get used for CBC padding validation.
> > Will this have  any dependency on the compiler optimization or asm
> > flags?
>
> CBC padding validation is fairly independent of anything to do with RSA,
> so I think its unlikely to be the culprit here. Of course sometimes
> compiler optimization/asm issues do occur so it can't be ruled out
> entirely - but it's not where I would start looking.
>
> > Will this issue be seen if hardware takes more time for the
> > operation?
> >
>
> No. Constant time here just means that we implement the code without any
> branching based on secret data (e.g. no "if" statements/while loops etc
> based on secret dependent data). It has very little to do with how long
> something actually takes to process.
>
>
> > Here is the snippet of the wireshark where our device acting as server
> > closes the connection with decryption failure.
>
> Thanks. To narrow it down further I need to figure out which line of
> code the decrypt_error is coming from as described above.
>
> Matt
>
>
>
> > If you need any further info, please let us know.
> > image.png
> > Thanks
> > Mahendra
> >
> > Please suggest.
> >
> >
> >
> > On Fri, Oct 30, 2020 at 3:32 PM Matt Caswell  > > wrote:
> >
> >
> >
> > On 30/10/2020 09:18, Mahendra SP wrote:
> > > Hi All.
> > >
> > > We have upgraded openssl version to 1.1.1b
> > >
> > > With this, we are seeing decryption error during SSL handshake for
> the
> > > below explained scenario. Our device acts as an SSL server.
> > >
> > > We have external hardware to offload RSA private key operations
> using
> > > the engine.
> > > Decryption of pre-master secret is done using hardware and is
> > > successful. We compared the pre-master secret on both server and
> > client
> > > and they match.
> > > However, we see that SSL handshake fails with "decrypt error (51)"
> > with
> > > an alert number 21. Verifying the encrypted finish message on the
> > server
> > > side fails.
> > >
> > > This issue does not happen with software performing RSA private key
> > > operations.
> > >
> > > Can someone help with the reason for decryption failure? Below is
> the
> > > compiler and processor details. It is 64 bit.
> > > arm-linux-gnueabihf-gcc  -march=armv7ve -mthumb -mfpu=neon
> > -mfloat-abi=hard
> >
> > Potentially this is related to the use of PSS padding in libssl
> which is
> > mandated in TLSv1.3. The TLSv1.3 spec also requires its use even in
> > TLSv1.2.
> >
> > The PSS padding is implemented within the EVP layer. Ultimately EVP
> > calls the function RSA_private_encrypt() with padding set to
> > RSA_NO_PADDING.
> >
> > Assuming your engine is implemented via a custom RSA_METHOD does it
> > support RSA_private_encrypt(() with RSA_NO_PADDING? If not this is
> > likely to be the problem.
> >
> > More discussion of this is here:
> >
> > https://github.com/openssl/openssl/issues/7968
> >
> > Also related is the recent discussion on this