Re: 1.0.2 to 1.1 migration problem with verify_callback()

[Remy Lebeau]

In my verify callback (for 1.0.2, mind you), I use 
X509_STORE_CTX_get_app_data(ctx) to get the SSL* pointer. 
X509_STORE_CTX_get_app_data(ctx) is a macro in OpenSSL's "x509_vfy.h" 
header file that maps to X509_STORE_CTX_get_ex_data(ctx,0) (why doesn't 
it use SSL_get_ex_data_X509_STORE_CTX_idx() instead of 0?).



Remy Lebeau
Lebeau Software

On 8/5/2019 7:40 AM, Matt Caswell wrote:

 From within your callback you can do this to get hold of the SSL object:

SSL *s = (SSL *)X509_STORE_CTX_get_ex_data(ctx,
SSL_get_ex_data_X509_STORE_CTX_idx());

And then this to get hold of the hostname requested:

const char *hostname = SSL_get_servername(s, TLSEXT_NAMETYPE_host_name);

AW: FIPS_selftest() Usage

[Dr. Matthias St. Pierre]

> For an application linked to FIPS capable OpenSSL, 

> 1) After calls to FIPS_mode_set() and FIPS_mode() both succeed, is it good 
> practice to call FIPS_selftest()? Or is this redundant call?
>
> 2) Did come across documentation which only hinted that FIPS_mode_set() calls 
> FIPS_selftest() internally. Is this correct?

> Regards.

Indeed, FIPS_mode_set() calls FIPS_selftest() internally(*), and if the 
selftest fails, FIPS mode will not be enabled. So there is no
need to run the selftest immediately after FIPS_mode_set() again. If your 
program is a long-running service, it might be a good idea
to  re-run the selftest on a regular base, but I have no particular 
recommendations about how often would be reasonable.

(*) It is stated explicitly in the manual pages, which are printed in Appendix 
D.2 of the OpenSSL FIPS 2.0 User Guide:

>Appendix D.2  FIPS_mode_set(), FIPS_selftest() 
> FIPS_mode_set() enables the FIPS mode of operation for applications
> that have complied with all the provisions of the OpenSSL FIPS 140-2 Security
> Policy. Successful execution of this function call with non-zero ONOFF is the
> only way to enable FIPS mode. After verifying the integrity of the executable
> object code using the stored digest FIPS_mode_set() performs the power-up 
> self-test.

https://www.openssl.org/docs/fips/UserGuide-2.0.pdf

This document is the official documentation and most comprehensive guide for 
the OpenSSL FIPS 2.0
object module. Anything you need to know you should be able to find in there.

Regards,
Matthias

FIPS_selftest() Usage

[Dipak B]

Hi,


For an application linked to FIPS capable OpenSSL,

1) After calls to FIPS_mode_set() and FIPS_mode() both succeed, is it good
practice to call FIPS_selftest()? Or is this redundant call?


2) Did come across documentation which only hinted that FIPS_mode_set()
calls FIPS_selftest() internally. Is this correct?

Regards.

Re: master branch: EC test broken AGAIN?

[Blumenthal, Uri - 0553 - MITLL]

On 8/7/19, 10:57 AM, "openssl-users on behalf of Matt Caswell" 
 wrote:
  >  >> ../test/recipes/15-test_ec.t (Wstat: 256 Tests: 5 
Failed: 1)
   > > 
   > > Assuming you are building with enable-ec_nistp_64_gcc_128 then the fix 
for this
   > > issue is here:
   > > 
   > > https://github.com/openssl/openssl/pull/9546
   >
   > ...now pushed to master.

Thank you - yes the build was with "enable-ec_nistp_64_gcc_128", and I confirm 
that the fix works.





smime.p7s
Description: S/MIME cryptographic signature

Re: master branch: EC test broken AGAIN?

[Matt Caswell]

On 07/08/2019 15:49, Matt Caswell wrote:
> 
> 
> On 07/08/2019 15:48, Blumenthal, Uri - 0553 - MITLL wrote:
>> Test Summary Report
>>
>> ---
>>
>> ../test/recipes/15-test_ec.t                     (Wstat: 256 Tests: 5 
>> Failed: 1)
>>
>>   Failed test:  2
>>
>>   Non-zero exit status: 1
>>
>> Files=174, Tests=1660, 122 wallclock secs ( 1.27 usr  0.34 sys + 81.53 cusr
>> 29.91 csys = 113.05 CPU)
>>
>> Result: FAIL
>>
>>  
>>
>> Does it seem to have become repetitive? ;-)
> 
> Assuming you are building with enable-ec_nistp_64_gcc_128 then the fix for 
> this
> issue is here:
> 
> https://github.com/openssl/openssl/pull/9546

...now pushed to master.

Matt

Re: master branch: EC test broken AGAIN?

[Matt Caswell]

On 07/08/2019 15:48, Blumenthal, Uri - 0553 - MITLL wrote:
> Test Summary Report
> 
> ---
> 
> ../test/recipes/15-test_ec.t                     (Wstat: 256 Tests: 5 Failed: 
> 1)
> 
>   Failed test:  2
> 
>   Non-zero exit status: 1
> 
> Files=174, Tests=1660, 122 wallclock secs ( 1.27 usr  0.34 sys + 81.53 cusr
> 29.91 csys = 113.05 CPU)
> 
> Result: FAIL
> 
>  
> 
> Does it seem to have become repetitive? ;-)

Assuming you are building with enable-ec_nistp_64_gcc_128 then the fix for this
issue is here:

https://github.com/openssl/openssl/pull/9546

Matt

master branch: EC test broken AGAIN?

[Blumenthal, Uri - 0553 - MITLL]

Test Summary Report

---

../test/recipes/15-test_ec.t (Wstat: 256 Tests: 5 Failed: 1)

  Failed test:  2

  Non-zero exit status: 1

Files=174, Tests=1660, 122 wallclock secs ( 1.27 usr  0.34 sys + 81.53 cusr 
29.91 csys = 113.05 CPU)

Result: FAIL

 

Does it seem to have become repetitive? ;-)

-- 

Regards,

Uri



smime.p7s
Description: S/MIME cryptographic signature

Re: SSL Server setup DH/ECDH

[Matt Caswell]

On 07/08/2019 12:19, Chitrang Srivastava wrote:
> Hi Matt,
> 
> I tried following code but it is crashing @ *SSL_CTX_set_ciphersuites*
> s_ctx = SSL_CTX_new(TLS_method());
> SSL_CTX_set_options(s_ctx,  SSL_OP_NO_RENEGOTIATION |
> SSL_OP_CIPHER_SERVER_PREFERENCE);
> SSL_CTX_set_min_proto_version(s_ctx, TLS1_2_VERSION);
> SSL_CTX_set_ciphersuites(s_ctx,
> "TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384");
> 
> In the debugger I noticed 
> 
> s_ctx :: cipher_list & cipher_list_by_id are both NULL

Well, that is very strange. I just tried the code above and it works just fine
for me.

s_ctx->cipher_list, and s_ctx->cipher_lib_by_id should be populated in the
SSL_CTX_new call:

https://github.com/openssl/openssl/blob/c50fd0f959de5b256d8eefb8ad2a82fcdcb899c3/ssl/ssl_lib.c#L3091-L3101

So you should never have an SSL_CTX object without those things being set.

Matt


> However tls13_ciphersuites is populated.
> Further in update_cipher_list which is called by SSL_CTX_set_ciphersuites 
> tries
> to delete this cipher_list and hence crash ?
> 
> Any pointer what I am missing?
> 
> -Thanks
> 
> 
> 
> On Tue, Aug 6, 2019 at 7:48 PM Matt Caswell  > wrote:
> 
> 
> 
> On 06/08/2019 14:58, Chitrang Srivastava wrote:
> > Yeah I mean TLS 1.3 cipher , sorry I haven't pasted exact names.
> > So after SSL_OP_CIPHER_SERVER_PREFERENCE, server uses 
> > TLS_1_3_AES_256_SHA_384.
> > While without that it uses TLS_1_3_AES_128_SHA_256, which is better in
> terms of
> > performance.
> 
> Ah! Right - now I understand.
> 
> So the option SSL_OP_CIPHER_SERVER_PREFERENCE means that the server 
> prefers the
> server's ordering of ciphersuites compared to the clients. With that 
> option set
> it will use the first ciphersuite that is in the server's list that is 
> also in
> the client's list. Without the set it will use the first ciphersuite that 
> is in
> the client's list that is also in the server's list. Server operators 
> often
> prefer this because it gives more control over which ciphersuite 
> ultimately gets
> used. But that's only really useful if you also look at this list of 
> configured
> ciphersuites and make sure they are in your preferred order! Otherwise the
> option is fairly pointless!
> 
> For TLSv1.3 the default list is:
> 
> #   define TLS_DEFAULT_CIPHERSUITES "TLS_AES_256_GCM_SHA384:" \
>                                     "TLS_CHACHA20_POLY1305_SHA256:" \
>                                     "TLS_AES_128_GCM_SHA256"
> 
> If you want a different order you can use the functions
> SSL_CTX_set_ciphersuites() (or SSL_set_ciphersuites()) to amend it:
> 
> https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_ciphersuites.html
> 
> Matt
> 
> >
> > Thanks very much,
> > Chitrang
> >
> > Tuesday, August 6, 2019, Matt Caswell  
> > >> wrote:
> >
> >
> >
> >     On 06/08/2019 12:20, Chitrang Srivastava wrote:
> >     > Noticed that if I set  SSL_OP_CIPHER_SERVER_PREFERENCE,
> >     TLS_1_3_AES_256_SHA_384
> >     > is being used while without that
> >     > AES_128_SHA256 is being used and I see client(Chrome) send this 
> as first
> >     preference.
> >     > Is there anyway where I can always prefer AES-128-SHA256 cipher 
> suite of
> >     TLS 1.3?
> >
> >     Hmmm...are you sure?
> >
> >     Those names don't look like OpenSSL names for those ciphersuites. I
> guess you
> >     mean TLS_AES_256_GCM_SHA384 and AES128-SHA256. The former is a 
> TLSv1.3
> >     ciphersuite and the latter is for TLSv1.2 and below. They are 
> mutually
> >     exclusive. If you negotiate TLSv1.3 then you can't use TLSv1.2
> ciphersuites and
> >     vice versa.
> >
> >     SSL_OP_CIPHER_SERVER_PREFERENCE should not affect the protocol 
> version
> >     negotiated. OpenSSL negotiates the version *first* before deciding 
> what
> >     ciphersuite to use. So it should not be the case that
> >     SSL_OP_CIPHER_SERVER_PREFERENCE suddenly causes a TLSv1.3 
> ciphersuite
> to be used
> >     when a TLSv1.2 ciphersuite was used without it.
> >
> >     Matt
> >
> >
> >     >
> >     > On Tue, Aug 6, 2019 at 3:53 PM Matt Caswell  
> >     >
> >     > 
>  >     >
> >     >
> >     >
> >     >     On 06/08/2019 11:21, Chitrang Srivastava wrote:
> >     >     > Yes , since in my case mostly browser will be used to access
> >     webserver running
> >     >     > on embedded platform.
> >     >     > Another question, since my 

Re: SSL Server setup DH/ECDH

[Chitrang Srivastava]

Hi Matt,

I tried following code but it is crashing @ *SSL_CTX_set_ciphersuites*
s_ctx = SSL_CTX_new(TLS_method());
SSL_CTX_set_options(s_ctx,  SSL_OP_NO_RENEGOTIATION |
SSL_OP_CIPHER_SERVER_PREFERENCE);
SSL_CTX_set_min_proto_version(s_ctx, TLS1_2_VERSION);
SSL_CTX_set_ciphersuites(s_ctx,
"TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384");

In the debugger I noticed

s_ctx :: cipher_list & cipher_list_by_id are both NULL
However tls13_ciphersuites is populated.
Further in update_cipher_list which is called by SSL_CTX_set_ciphersuites
tries to delete this cipher_list and hence crash ?

Any pointer what I am missing?

-Thanks



On Tue, Aug 6, 2019 at 7:48 PM Matt Caswell  wrote:

>
>
> On 06/08/2019 14:58, Chitrang Srivastava wrote:
> > Yeah I mean TLS 1.3 cipher , sorry I haven't pasted exact names.
> > So after SSL_OP_CIPHER_SERVER_PREFERENCE, server uses
> > TLS_1_3_AES_256_SHA_384.
> > While without that it uses TLS_1_3_AES_128_SHA_256, which is better in
> terms of
> > performance.
>
> Ah! Right - now I understand.
>
> So the option SSL_OP_CIPHER_SERVER_PREFERENCE means that the server
> prefers the
> server's ordering of ciphersuites compared to the clients. With that
> option set
> it will use the first ciphersuite that is in the server's list that is
> also in
> the client's list. Without the set it will use the first ciphersuite that
> is in
> the client's list that is also in the server's list. Server operators often
> prefer this because it gives more control over which ciphersuite
> ultimately gets
> used. But that's only really useful if you also look at this list of
> configured
> ciphersuites and make sure they are in your preferred order! Otherwise the
> option is fairly pointless!
>
> For TLSv1.3 the default list is:
>
> #   define TLS_DEFAULT_CIPHERSUITES "TLS_AES_256_GCM_SHA384:" \
> "TLS_CHACHA20_POLY1305_SHA256:" \
> "TLS_AES_128_GCM_SHA256"
>
> If you want a different order you can use the functions
> SSL_CTX_set_ciphersuites() (or SSL_set_ciphersuites()) to amend it:
>
> https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_ciphersuites.html
>
> Matt
>
> >
> > Thanks very much,
> > Chitrang
> >
> > Tuesday, August 6, 2019, Matt Caswell  > > wrote:
> >
> >
> >
> > On 06/08/2019 12:20, Chitrang Srivastava wrote:
> > > Noticed that if I set  SSL_OP_CIPHER_SERVER_PREFERENCE,
> > TLS_1_3_AES_256_SHA_384
> > > is being used while without that
> > > AES_128_SHA256 is being used and I see client(Chrome) send this as
> first
> > preference.
> > > Is there anyway where I can always prefer AES-128-SHA256 cipher
> suite of
> > TLS 1.3?
> >
> > Hmmm...are you sure?
> >
> > Those names don't look like OpenSSL names for those ciphersuites. I
> guess you
> > mean TLS_AES_256_GCM_SHA384 and AES128-SHA256. The former is a
> TLSv1.3
> > ciphersuite and the latter is for TLSv1.2 and below. They are
> mutually
> > exclusive. If you negotiate TLSv1.3 then you can't use TLSv1.2
> ciphersuites and
> > vice versa.
> >
> > SSL_OP_CIPHER_SERVER_PREFERENCE should not affect the protocol
> version
> > negotiated. OpenSSL negotiates the version *first* before deciding
> what
> > ciphersuite to use. So it should not be the case that
> > SSL_OP_CIPHER_SERVER_PREFERENCE suddenly causes a TLSv1.3
> ciphersuite to be used
> > when a TLSv1.2 ciphersuite was used without it.
> >
> > Matt
> >
> >
> > >
> > > On Tue, Aug 6, 2019 at 3:53 PM Matt Caswell  > 
> > > >> wrote:
> > >
> > >
> > >
> > > On 06/08/2019 11:21, Chitrang Srivastava wrote:
> > > > Yes , since in my case mostly browser will be used to access
> > webserver running
> > > > on embedded platform.
> > > > Another question, since my webserver is running on embedded
> platform and
> > > it has
> > > > limited memory , I have disabled
> > > > ARIA/CAMELLIA  and few others, is that OK ? because I don't
> see any
> > ciphers
> > > > suites which is used in practice.
> > >
> > > Yes, that should be fine.
> > >
> > > Matt
> > >
> > > >
> > > >
> > > >
> > > > On Tue, Aug 6, 2019 at 3:42 PM Matt Caswell <
> m...@openssl.org
> > 
> > > >
> > > > 
> >  > > >
> > > >
> > > >
> > > > On 06/08/2019 11:07, Chitrang Srivastava wrote:
> > > > > Thanks Matt,
> > > > >
> > > > > So now I have, which i believe is enough ?
> > > > >
> > > > > 

Re: OPENSSL_thread_stop() equivalent

[Matt Caswell]

On 07/08/2019 01:36, Salz, Rich via openssl-users wrote:
>>Due to this I have to remove the usage of OPENSSL_thread_stop(), want to know
> the equivalent call in OpenSSL 1.0.2s? if applicable. 
> 
> 1.0.2 has no concept/support for threads, so you probably don’t need to do 
> anything.

That's not entirely true. 1.0.2 does support threads, but does so through
various callback mechanisms. It also has a pseudo thread local storage concept
in the error mechanism.

In 1.0.2, instead of OPENSSL_thread_stop(), you should call:

ERR_remove_thread_state()

However the conditions are slightly different in 1.0.2.

1.1.x will usually detect thread exit automatically and you don't need to call
OPENSSL_thread_stop() at all. For all the details see the OPENSSL_thread_stop()
man page:

https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_thread_stop.html

None of the capability to automatically detect thread exit exists in 1.0.2.

Matt

AW: EVP_KEY_cmp and -_parameters issues

[Johannes.Heinz]

Now I've got it.
Thank you very much.

-Ursprüngliche Nachricht-
Von: Thulasi Goriparthi  
Gesendet: Mittwoch, 7. August 2019 09:42
An: Heinz, Johannes 
Cc: openssl-users@openssl.org
Betreff: Re: EVP_KEY_cmp and -_parameters issues

RSA keys wouldn't have parameters that are separated from key components. So, 
EVP_PKEY_cmp() is applicable, but not EVP_PKEY_cmp_parameters().

DH keys, which are generally used for key exchange, are short lived, though the 
group parameters can be comparatively valid for longer duration (let's say for 
a whole session) and can be used to generate multiple DH keys. So, 
EVP_PKEY_cmp_parameters() is useful to validate peer's public key parameters 
during key exchange to confirm that both peers are working in the same group.

Though EVP_PKEY_cmp() function can be extended to compare both parameters and 
key components for DH keys,  it wouldn't be of much use as DH keys are 
ephemeral and we never need to compare two of them for their key components.

Thanks,
Thulasi.

On Wed, 7 Aug 2019 at 12:27,  wrote:
>
> I have a question to following situation with RSA and DH structures:
>
> I’m testing these in separated unit tests.
>
> Both test cases (each one for RSA and DH) are doing the same:
>
>
>
> I’m creating a new DH or RSA structure, filling it with my params (pqg 
> …) and convert it to an EVP_PKEY (for example: EVP_PKEY_assign_DH => 
> pkey1)
>
> Next step, I’m writing and reading this structure with these functions:
>
> PEM_write_bio_PrivateKey() (not PEM_write_bio_PrivateKey_traditional() 
> ) (with password)
>
> EVP_PKEY* pkey2 = PEM_read_bio_PrivateKey() (with same password)
>
> (or even without a password)
>
>
>
> Now I want to compare these two EVP_PKEY* variables (pkey1 and pkey2) and for 
> that I can use these two functions:
>
> EVP_PKEY_cmp(pkey1, pkey2) (compares components and params)
>
> EVP_PKEY_cmp_parameters(pkey1, pkey2) (compares params)
>
>
>
> Now the Problem:
>
> Even the tests work the same way, the one with RSA only accept the 
> compare-function “EVP_PKEY_cmp” and not the other one.
>
> The one with DH is only with the “EVP_PKEY_cmp_parameters” successful.
>
>
>
> Question:
>
> Why can the first compare function find the components and params of the RSA 
> structure (and even after the PEM_write_bio…) and not of the DH?
>
> Also, why it’s with the second compare function (only params) the other way 
> around (keys match in DH unit test and not in RSA unit test)?
>
>
>
> Thanks

Re: i2d_ASN1_INTEGER zero pad

[Matt Caswell]

On 06/08/2019 17:16, Matt Caswell wrote:
> sig->r = BN_bin2bn(r, rlen, NULL);
> sig->s = BN_bin2bn(s, slen, NULL);

As a slight amendment to my earlier answer - a better way to do the above two
lines would be to use the ECDSA_SIG_set0() function to set the r and s
components rather than diving into the internals of the ECDSA_SIG structure.

Matt

Re: EVP_KEY_cmp and -_parameters issues

[Thulasi Goriparthi]

RSA keys wouldn't have parameters that are separated from key
components. So, EVP_PKEY_cmp() is applicable, but not
EVP_PKEY_cmp_parameters().

DH keys, which are generally used for key exchange, are short lived,
though the group parameters can be comparatively valid for longer
duration (let's say for a whole session) and can be used to generate
multiple DH keys. So, EVP_PKEY_cmp_parameters() is useful to validate
peer's public key parameters during key exchange to confirm that both
peers are working in the same group.

Though EVP_PKEY_cmp() function can be extended to compare both
parameters and key components for DH keys,  it wouldn't be of much use
as DH keys are ephemeral and we never need to compare two of them for
their key components.

Thanks,
Thulasi.

On Wed, 7 Aug 2019 at 12:27,  wrote:
>
> I have a question to following situation with RSA and DH structures:
>
> I’m testing these in separated unit tests.
>
> Both test cases (each one for RSA and DH) are doing the same:
>
>
>
> I’m creating a new DH or RSA structure, filling it with my params (pqg …) and 
> convert it to an EVP_PKEY (for example: EVP_PKEY_assign_DH => pkey1)
>
> Next step, I’m writing and reading this structure with these functions:
>
> PEM_write_bio_PrivateKey() (not PEM_write_bio_PrivateKey_traditional() ) 
> (with password)
>
> EVP_PKEY* pkey2 = PEM_read_bio_PrivateKey() (with same password)
>
> (or even without a password)
>
>
>
> Now I want to compare these two EVP_PKEY* variables (pkey1 and pkey2) and for 
> that I can use these two functions:
>
> EVP_PKEY_cmp(pkey1, pkey2) (compares components and params)
>
> EVP_PKEY_cmp_parameters(pkey1, pkey2) (compares params)
>
>
>
> Now the Problem:
>
> Even the tests work the same way, the one with RSA only accept the 
> compare-function “EVP_PKEY_cmp” and not the other one.
>
> The one with DH is only with the “EVP_PKEY_cmp_parameters” successful.
>
>
>
> Question:
>
> Why can the first compare function find the components and params of the RSA 
> structure (and even after the PEM_write_bio…) and not of the DH?
>
> Also, why it’s with the second compare function (only params) the other way 
> around (keys match in DH unit test and not in RSA unit test)?
>
>
>
> Thanks

EVP_KEY_cmp and -_parameters issues

[Johannes.Heinz]

I have a question to following situation with RSA and DH structures:
I'm testing these in separated unit tests.
Both test cases (each one for RSA and DH) are doing the same:

I'm creating a new DH or RSA structure, filling it with my params (pqg ...) and 
convert it to an EVP_PKEY (for example: EVP_PKEY_assign_DH => pkey1)
Next step, I'm writing and reading this structure with these functions:
PEM_write_bio_PrivateKey() (not PEM_write_bio_PrivateKey_traditional() ) (with 
password)
EVP_PKEY* pkey2 = PEM_read_bio_PrivateKey() (with same password)
(or even without a password)

Now I want to compare these two EVP_PKEY* variables (pkey1 and pkey2) and for 
that I can use these two functions:
EVP_PKEY_cmp(pkey1, pkey2) (compares components and params)
EVP_PKEY_cmp_parameters(pkey1, pkey2) (compares params)

Now the Problem:
Even the tests work the same way, the one with RSA only accept the 
compare-function "EVP_PKEY_cmp" and not the other one.
The one with DH is only with the "EVP_PKEY_cmp_parameters" successful.

Question:
Why can the first compare function find the components and params of the RSA 
structure (and even after the PEM_write_bio...) and not of the DH?
Also, why it's with the second compare function (only params) the other way 
around (keys match in DH unit test and not in RSA unit test)?

Thanks