From uri at ll.mit.edu  Mon Oct  2 14:00:02 2017
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Mon, 2 Oct 2017 14:00:02 +0000
Subject: [openssl-dev] Missing EVP_PKEY_meth_get_xxx methods?
Message-ID: <87DED275-1E79-46DA-8B6F-A67654A0E53D@ll.mit.edu>

Moving to openssl-dev, because I think OpenSSL-1.0.2 needs a fix.

 

To be more specific, the following get methods are missing in 1.0.2:

 

- EVP_PKEY_meth_get_sign(EVP_PKEY_METHOD *,? ?)

- EVP_PKEY_meth_get_decrypt(EVP_PKEY_METHOD *,? ?)

- EVP_PKEY_meth_get_encrypt(EVP_PKEY_METHOD *,? ?)

 

Note that the corresponding set methods are (thankfully) already present:

 

 - EVP_PKEY_meth_set_sign(EVP_PKEY_METHOD *,? ?)

 - EVP_PKEY_meth_set_decrypt(EVP_PKEY_METHOD *,? ?)

 - EVP_PKEY_meth_set_encrypt(EVP_PKEY_METHOD *,? ?)

 

Can I hope that these get methods would be added? Maybe even soon?

--

Regards,

Uri Blumenthal

 

From: Uri Blumenthal <uri at ll.mit.edu>
Date: Sunday, October 01, 2017 at 19:59
To: <openssl-users at openssl.org>
Subject: Re: [openssl-users] Missing EVP_PKEY method to set engine?

 

Thank you! 

 

I observe that in 1.1.x everything's fine - the structure evp_pkey_methods_st is opaque, but both getters and setters are defined and available. 

 

In 1.0.2 the structure is already opaque, the setters are present, but some getters are absent. Which makes it quite hard to work with members of this structure.

 

I think this is a bug, and two possible remedies INHO are: add getter functions for the members, or add/move this structure from evp-int.h to evp.h (so it's no longer opaque).

 

What is your opinion? 

 

Thanks!

 

Regards,

Uri

 

Sent from my iPhone


On Oct 1, 2017, at 18:54, Dr. Stephen Henson <steve at openssl.org> wrote:

On Fri, Sep 29, 2017, Blumenthal, Uri - 0553 - MITLL wrote:



Apologies in advance for cross-posting ??? but I???m not sure which of the two mailing lists this belongs to.

 

A key (say, private key) is loaded from the pkcs11 engine via privkey = ENGINE_load_private_key(engine, <whatever else>); and this operation succeeds.

 

However the resulting key handle has its engine == NULL. I looked for a method or a macro to explicitly set that value to the pointer to the engine that this key is bound to, but couldn???t find any. I define new methods such as pkcs11_pkey_rsa_decrypt(), and  try to make OpenSSL aware of them via:

 

        EVP_PKEY_METHOD *orig_pmeth = EVP_PKEY_meth_find(EVP_PKEY_RSA);

 

   EVP_PKEY_METHOD *pmeth = EVP_PKEY_meth_new(EVP_PKEY_RSA, EVP_PKEY_FLAG_AUTOARGLEN);

 

   EVP_PKEY_meth_copy(pmeth, orig_pmeth);

 

   EVP_PKEY_meth_get_decrypt(orig_pmeth, &pdecr_init, &pdecr);

 

   EVP_PKEY_meth_set_decrypt(pmeth, pdecr_init, pkcs11_pkey_rsa_decrypt);

 


There doesn't seem to be any easy way to do that for an existing method. If
the ENGINE has its own ASN.1 method things become easier.

A workaround might be to use a copy of an existing A workaround might be to
create a copy of an existing ASN.1 method but I've not tried that.



 

In ENGINE_set_pkey_meths(engine, pkey_meths) what should pkey_meths() actually be? Is it documented? 

 

 


Not currently but it similar to the cipher/digest functions but handles
EVP_PKEY_METHOD instead.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171002/a984f54e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171002/a984f54e/attachment-0001.bin>

From matt at openssl.org  Mon Oct  2 14:06:47 2017
From: matt at openssl.org (Matt Caswell)
Date: Mon, 2 Oct 2017 15:06:47 +0100
Subject: [openssl-dev] Missing EVP_PKEY_meth_get_xxx methods?
In-Reply-To: <87DED275-1E79-46DA-8B6F-A67654A0E53D@ll.mit.edu>
References: <87DED275-1E79-46DA-8B6F-A67654A0E53D@ll.mit.edu>
Message-ID: <d3cd4981-e094-0c4f-f2d8-611f058d7285@openssl.org>



On 02/10/17 15:00, Blumenthal, Uri - 0553 - MITLL wrote:
> Moving to openssl-dev, because I think OpenSSL-1.0.2 needs a fix.
> 
> ?
> 
> To be more specific, the following get methods are missing in 1.0.2:
> 
> ?
> 
> - EVP_PKEY_meth_get_sign(EVP_PKEY_METHOD *,? ?)
> 
> - EVP_PKEY_meth_get_decrypt(EVP_PKEY_METHOD *,? ?)
> 
> - EVP_PKEY_meth_get_encrypt(EVP_PKEY_METHOD *,? ?)
> 
> ?
> 
> Note that the corresponding set methods are (thankfully) already present:
> 
> ?
> 
> - EVP_PKEY_meth_set_sign(EVP_PKEY_METHOD *,? ?)
> 
> - EVP_PKEY_meth_set_decrypt(EVP_PKEY_METHOD *,? ?)
> 
> - EVP_PKEY_meth_set_encrypt(EVP_PKEY_METHOD *,? ?)
> 
> ?
> 
> Can I hope that these get methods would be added? Maybe even soon?

Normally we don't add new features/functions to a stable release.
However our policy for 1.1.0 (which obviously made lots of structures
opaque), is that missing accessors are considered a bug - and we do add
those. The situation is less clear for 1.0.2 since most structures are
not opaque and we did not make wholesale opacity changes for that release.

If we had a PR to add them it might spur the discussion about whether
adding these is valid for 1.0.2 or not to a conclusion!! Fancy creating one?

Matt


> 
> --
> 
> Regards,
> 
> Uri Blumenthal
> 
> ?
> 
> *From: *Uri Blumenthal <uri at ll.mit.edu>
> *Date: *Sunday, October 01, 2017 at 19:59
> *To: *<openssl-users at openssl.org>
> *Subject: *Re: [openssl-users] Missing EVP_PKEY method to set engine?
> 
> ?
> 
> Thank you!?
> 
> ?
> 
> I observe that in 1.1.x everything's fine - the structure
> evp_pkey_methods_st is opaque, but both getters and setters are defined
> and available.?
> 
> ?
> 
> In 1.0.2 the structure is already opaque, the setters are present, but
> some getters are absent. Which makes it quite hard to work
> with?members?of this structure.
> 
> ?
> 
> I think this is a bug, and two possible remedies INHO are: add getter
> functions for the members, or add/move this structure from evp-int.h to
> evp.h (so it's no longer opaque).
> 
> ?
> 
> What is your opinion??
> 
> ?
> 
> Thanks!
> 
> ?
> 
> Regards,
> 
> Uri
> 
> ?
> 
> Sent from my iPhone
> 
> 
> On Oct 1, 2017, at 18:54, Dr. Stephen Henson <steve at openssl.org
> <mailto:steve at openssl.org>> wrote:
> 
>     On Fri, Sep 29, 2017, Blumenthal, Uri - 0553 - MITLL wrote:
> 
> 
>         Apologies in advance for cross-posting ??? but I???m not sure
>         which of the two mailing lists this belongs to.
> 
>         ?
> 
>         A key (say, private key) is loaded from the pkcs11 engine via
>         privkey = ENGINE_load_private_key(engine, <whatever else>); and
>         this operation succeeds.
> 
>         ?
> 
>         However the resulting key handle has its engine == NULL. I
>         looked for a method or a macro to explicitly set that value to
>         the pointer to the engine that this key is bound to, but
>         couldn???t find any. I define new methods such as
>         pkcs11_pkey_rsa_decrypt(), and ?try to make OpenSSL aware of
>         them via:
> 
>         ?
> 
>         ????????EVP_PKEY_METHOD *orig_pmeth =
>         EVP_PKEY_meth_find(EVP_PKEY_RSA);
> 
>         ?
> 
>         ?? EVP_PKEY_METHOD *pmeth = EVP_PKEY_meth_new(EVP_PKEY_RSA,
>         EVP_PKEY_FLAG_AUTOARGLEN);
> 
>         ?
> 
>         ?? EVP_PKEY_meth_copy(pmeth, orig_pmeth);
> 
>         ?
> 
>         ?? EVP_PKEY_meth_get_decrypt(orig_pmeth, &pdecr_init, &pdecr);
> 
>         ?
> 
>         ?? EVP_PKEY_meth_set_decrypt(pmeth, pdecr_init,
>         pkcs11_pkey_rsa_decrypt);
> 
>         ?
> 
> 
>     There doesn't seem to be any easy way to do that for an existing
>     method. If
>     the ENGINE has its own ASN.1 method things become easier.
> 
>     A workaround might be to use a copy of an existing A workaround
>     might be to
>     create a copy of an existing ASN.1 method but I've not tried that.
> 
> 
>         ?
> 
>         In ENGINE_set_pkey_meths(engine, pkey_meths) what should
>         pkey_meths() actually be? Is it documented?
> 
>         ?
> 
>         ?
> 
> 
>     Not currently but it similar to the cipher/digest functions but handles
>     EVP_PKEY_METHOD instead.
> 
>     Steve.
>     --
>     Dr Stephen N. Henson. OpenSSL project core developer.
>     Commercial tech support now available see: http://www.openssl.org
>     -- 
>     openssl-users mailing list
>     To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> 
> 

From steve at openssl.org  Mon Oct  2 16:40:46 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Mon, 2 Oct 2017 16:40:46 +0000
Subject: [openssl-dev] Missing EVP_PKEY_meth_get_xxx methods?
In-Reply-To: <d3cd4981-e094-0c4f-f2d8-611f058d7285@openssl.org>
References: <87DED275-1E79-46DA-8B6F-A67654A0E53D@ll.mit.edu>
 <d3cd4981-e094-0c4f-f2d8-611f058d7285@openssl.org>
Message-ID: <20171002164046.GA23830@openssl.org>

On Mon, Oct 02, 2017, Matt Caswell wrote:
> 
> 
> On 02/10/17 15:00, Blumenthal, Uri - 0553 - MITLL wrote:
> > Moving to openssl-dev, because I think OpenSSL-1.0.2 needs a fix.
> > 
> > ?
> > 
> > To be more specific, the following get methods are missing in 1.0.2:
> > 
> > ?
> > 
> > - EVP_PKEY_meth_get_sign(EVP_PKEY_METHOD *,? ???)
> > 
> > - EVP_PKEY_meth_get_decrypt(EVP_PKEY_METHOD *,? ???)
> > 
> > - EVP_PKEY_meth_get_encrypt(EVP_PKEY_METHOD *,? ???)
> > 
> > ?
> > 
> > Note that the corresponding set methods are (thankfully) already present:
> > 
> > ?
> > 
> > - EVP_PKEY_meth_set_sign(EVP_PKEY_METHOD *,? ???)
> > 
> > - EVP_PKEY_meth_set_decrypt(EVP_PKEY_METHOD *,? ???)
> > 
> > - EVP_PKEY_meth_set_encrypt(EVP_PKEY_METHOD *,? ???)
> > 
> > ?
> > 
> > Can I hope that these get methods would be added? Maybe even soon?
> 
> Normally we don't add new features/functions to a stable release.
> However our policy for 1.1.0 (which obviously made lots of structures
> opaque), is that missing accessors are considered a bug - and we do add
> those. The situation is less clear for 1.0.2 since most structures are
> not opaque and we did not make wholesale opacity changes for that release.
> 
> If we had a PR to add them it might spur the discussion about whether
> adding these is valid for 1.0.2 or not to a conclusion!! Fancy creating one?
> 

Personally I'm in favour of adding these to 1.0.2, that structure has always
been opaque.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From uri at ll.mit.edu  Mon Oct  2 17:59:32 2017
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Mon, 2 Oct 2017 17:59:32 +0000
Subject: [openssl-dev] Missing EVP_PKEY_meth_get_xxx methods?
In-Reply-To: <20171002164046.GA23830@openssl.org>
References: <87DED275-1E79-46DA-8B6F-A67654A0E53D@ll.mit.edu>
 <d3cd4981-e094-0c4f-f2d8-611f058d7285@openssl.org>
 <20171002164046.GA23830@openssl.org>
Message-ID: <9517E3E3-5230-4EF3-A59C-93AF61267FEE@ll.mit.edu>

Matt and Steve,

Thank you! I indeed fancied creating a PR to add those: https://github.com/openssl/openssl/pull/4452

;-)
--
Regards,
Uri Blumenthal

On 10/2/17, 12:41, "openssl-dev on behalf of Dr. Stephen Henson" <openssl-dev-bounces at openssl.org on behalf of steve at openssl.org> wrote:

    On Mon, Oct 02, 2017, Matt Caswell wrote:
    > 
    > 
    > On 02/10/17 15:00, Blumenthal, Uri - 0553 - MITLL wrote:
    > > Moving to openssl-dev, because I think OpenSSL-1.0.2 needs a fix.
    > > 
    > >  
    > > 
    > > To be more specific, the following get methods are missing in 1.0.2:
    > > 
    > >  
    > > 
    > > - EVP_PKEY_meth_get_sign(EVP_PKEY_METHOD *,  ???)
    > > 
    > > - EVP_PKEY_meth_get_decrypt(EVP_PKEY_METHOD *,  ???)
    > > 
    > > - EVP_PKEY_meth_get_encrypt(EVP_PKEY_METHOD *,  ???)
    > > 
    > >  
    > > 
    > > Note that the corresponding set methods are (thankfully) already present:
    > > 
    > >  
    > > 
    > > - EVP_PKEY_meth_set_sign(EVP_PKEY_METHOD *,  ???)
    > > 
    > > - EVP_PKEY_meth_set_decrypt(EVP_PKEY_METHOD *,  ???)
    > > 
    > > - EVP_PKEY_meth_set_encrypt(EVP_PKEY_METHOD *,  ???)
    > > 
    > >  
    > > 
    > > Can I hope that these get methods would be added? Maybe even soon?
    > 
    > Normally we don't add new features/functions to a stable release.
    > However our policy for 1.1.0 (which obviously made lots of structures
    > opaque), is that missing accessors are considered a bug - and we do add
    > those. The situation is less clear for 1.0.2 since most structures are
    > not opaque and we did not make wholesale opacity changes for that release.
    > 
    > If we had a PR to add them it might spur the discussion about whether
    > adding these is valid for 1.0.2 or not to a conclusion!! Fancy creating one?
    > 
    
    Personally I'm in favour of adding these to 1.0.2, that structure has always
    been opaque.
    
    Steve.
    --
    Dr Stephen N. Henson. OpenSSL project core developer.
    Commercial tech support now available see: http://www.openssl.org
    -- 
    openssl-dev mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171002/c629502e/attachment.bin>

From robbat2 at gentoo.org  Mon Oct  2 19:20:15 2017
From: robbat2 at gentoo.org (Robin H. Johnson)
Date: Mon, 2 Oct 2017 19:20:15 +0000
Subject: [openssl-dev] [RFC] enc utility & under-documented behavior
 changes: improving backward compatibility
Message-ID: <robbat2-20171002T183923-631359582Z@orbis-terrarum.net>

Commit f8547f62c212837dbf44fb7e2755e5774a59a57b (documented in
9e8b6f042749ded556380227c9f2db7ffad9a3aa), changed the default digest
for the 'enc' utility from MD5 to SHA256.

While I do strongly encourage getting away from MD5, this has the
unfortunate side effect of silently breaking existing data.

An old encrypted file would be generated with MD5 as the digest used on
the passphrase. Then if you tried to decrypt it on a new version of
OpenSSL, that defaults to SHA256, you'd get just garbage output.

This recently bit me when trying to decrypt Amanda backups:
https://github.com/zmanda/amanda/blob/8136c076757d2e54fa7d4df15f002187823d8787/common-src/amcrypt-ossl.sh#L81
https://github.com/zmanda/amanda/blob/8136c076757d2e54fa7d4df15f002187823d8787/common-src/amcrypt-ossl-asym.sh#L134
(yes, I'm aware that the asym variant also passes in -nosalt).

This happens because there is no metadata that conveys what parameters
were used during encryption. Unless you happen to know exactly which
version of OpenSSL was used, and what parameters, you risk getting
garbage data back.

This can also happen already when the ciphers are mismatched between
encryption & decryption.

The -salt option already sets a precedent for adding a header with the
salt data, and I'd like to extend that, to improve backwards
compatibility.

1. Encrypted data should include a header block, that OPTIONALLY
   specifies each of:
   - cipher & parameters (e.g. salt, padding)
   - key derivation function & parameters (MD)
1.1. Some users might want to leave the fields empty, to increase
     security by obscurity.
1.2. This also opens the path to stronger key derivation (PBKDF2)
2. During decryption, if no header block is present, and no message
   digest was specified, the default digest SHOULD be MD5.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer
E-Mail   : robbat2 at gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1113 bytes
Desc: Digital signature
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171002/31f9a15f/attachment.sig>

From matt at openssl.org  Tue Oct  3 07:23:19 2017
From: matt at openssl.org (Matt Caswell)
Date: Tue, 3 Oct 2017 08:23:19 +0100
Subject: [openssl-dev] [RFC] enc utility & under-documented behavior
 changes: improving backward compatibility
In-Reply-To: <robbat2-20171002T183923-631359582Z@orbis-terrarum.net>
References: <robbat2-20171002T183923-631359582Z@orbis-terrarum.net>
Message-ID: <dd83d71a-e629-7dbd-4378-9049ef524972@openssl.org>



On 02/10/17 20:20, Robin H. Johnson wrote:
> Commit f8547f62c212837dbf44fb7e2755e5774a59a57b (documented in
> 9e8b6f042749ded556380227c9f2db7ffad9a3aa), changed the default digest
> for the 'enc' utility from MD5 to SHA256.
> 
> While I do strongly encourage getting away from MD5, this has the
> unfortunate side effect of silently breaking existing data.
> 
> An old encrypted file would be generated with MD5 as the digest used on
> the passphrase. Then if you tried to decrypt it on a new version of
> OpenSSL, that defaults to SHA256, you'd get just garbage output.
> 
> This recently bit me when trying to decrypt Amanda backups:
> https://github.com/zmanda/amanda/blob/8136c076757d2e54fa7d4df15f002187823d8787/common-src/amcrypt-ossl.sh#L81
> https://github.com/zmanda/amanda/blob/8136c076757d2e54fa7d4df15f002187823d8787/common-src/amcrypt-ossl-asym.sh#L134
> (yes, I'm aware that the asym variant also passes in -nosalt).
> 
> This happens because there is no metadata that conveys what parameters
> were used during encryption. Unless you happen to know exactly which
> version of OpenSSL was used, and what parameters, you risk getting
> garbage data back.
> 
> This can also happen already when the ciphers are mismatched between
> encryption & decryption.
> 
> The -salt option already sets a precedent for adding a header with the
> salt data, and I'd like to extend that, to improve backwards
> compatibility.

I am in favour of a new output format. In fact a new output format has
been discussed before and I believe there was broad support for the idea:

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

That PR didn't turn into anything, but I'm not sure why.

A new output format will help to stop things getting worse if we change
the format again (which I think we should in order to use PBKDF2 and
more iterations). However it won't help handle the historic issue. If
you attempt to decrypt a file that isn't in the new format, you won't
know whether it was generated by OpenSSL 1.1.0 (and is therefore using
SHA256), or whether it was generated by some earlier version (and is
therefore using MD5).

> 
> 1. Encrypted data should include a header block, that OPTIONALLY
>    specifies each of:
>    - cipher & parameters (e.g. salt, padding)
>    - key derivation function & parameters (MD)
> 1.1. Some users might want to leave the fields empty, to increase
>      security by obscurity.

I think we probably should have an option to not write out the header at
all - but not to "increase security by obscurity". Rather it would be
about having the ability to write out a "raw" encrypted file that could
be consumed by some other tool.


> 1.2. This also opens the path to stronger key derivation (PBKDF2)
> 2. During decryption, if no header block is present, and no message
>    digest was specified, the default digest SHOULD be MD5.

Should it? What about compatibility with OpenSSL 1.1.0? We cannot make
breaking changes in 1.1.1, so it has to be compatible with 1.1.0.

Matt



From tmraz at redhat.com  Tue Oct  3 07:45:43 2017
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 03 Oct 2017 09:45:43 +0200
Subject: [openssl-dev] [RFC] enc utility & under-documented behavior
 changes: improving backward compatibility
In-Reply-To: <dd83d71a-e629-7dbd-4378-9049ef524972@openssl.org>
References: <robbat2-20171002T183923-631359582Z@orbis-terrarum.net>
 <dd83d71a-e629-7dbd-4378-9049ef524972@openssl.org>
Message-ID: <1507016743.11542.2.camel@redhat.com>

On Tue, 2017-10-03 at 08:23 +0100, Matt Caswell wrote:
> 
> > 1.2. This also opens the path to stronger key derivation (PBKDF2)
> > 2. During decryption, if no header block is present, and no message
> > ???digest was specified, the default digest SHOULD be MD5.
> 
> Should it? What about compatibility with OpenSSL 1.1.0? We cannot
> make
> breaking changes in 1.1.1, so it has to be compatible with 1.1.0.

Yeah, the ship has sailed. SHA-256 should be used by default as in
1.1.0.

-- 
Tom?? Mr?z
Red Hat

No matter how far down the wrong road you've gone, turn back.
??????????????????????????????????????????????Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

 * Google and NSA associates, this message is none of your business.
 * Please leave it alone, and consider whether your actions are
 * authorized by the contract with Red Hat, or by the US constitution.
 * If you feel you're being encouraged to disregard the limits built
 * into them, remember Edward Snowden and Wikileaks.

From bkaduk at akamai.com  Tue Oct  3 15:15:48 2017
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Tue, 3 Oct 2017 10:15:48 -0500
Subject: [openssl-dev] rejecting elliptic_curves/supported_groups in
 ServerHello (new behavior in master/1.1.1 vs 1.1.0)
Message-ID: <96b0a23a-84ef-d010-68ae-fd4cfafd3dff@akamai.com>

Hi all,

Doing some testing with a snapshot of master (s_client with -tls1_2 and
optionally a cipherspec that prefers ECDHE ciphers), we're running into
a sizeable number of servers that are sending extension 0xa (formerly
"elliptic_curves", now "supported_groups") in the ServerHello.? This is
not supported by RFC 7919 or RFC 4492 (the server is supposed to
indicate it's selected curve/group in the ServerKeyExchange message
instead), or by the TLS 1.3 draft spec (which permits "supported_groups"
in EncryptedExtensions, so the client can update a cache of groups
supported by the server).

In OpenSSL 1.1.0 we seem to have treated the elliptic_curves extension
in a ServerHello as an extension unknown to the library code and passed
it off to the custom extension handler.? With the extension processing
rework in master done to support TLS 1.3, which admits extensions in
many more contexts than previously, we now check that a received
extension is allowable in the context at hand.? In the table of
extensions, supported_groups is marked only as allowable in the
ClientHello and TLS 1.3 EncryptedExtensions, per the spec.? However,
this new strict behavior causes connection failures when talking to
these buggy servers.? So far we've seen this behavior from servers that
send a Server: header indicating Microsoft-IIS/7.5 and just "Apache".

This raises some question of what behavioral compatibility is desired
between 1.1.0 and 1.1.1 -- do we need to disable the "extension context"
verification for ServerHello processing entirely, or maybe just for the
one extension known to cause trouble in practice?? Or should we have an
SSL/SSL_CTX option to control the behavior (and which behavior should be
the default)?

Also, I'd be interested in hearing whether anyone else has observed this
sort of behavior.

Thanks,

Ben

From davidben at google.com  Tue Oct  3 16:37:05 2017
From: davidben at google.com (David Benjamin)
Date: Tue, 03 Oct 2017 16:37:05 +0000
Subject: [openssl-dev] rejecting elliptic_curves/supported_groups in
 ServerHello (new behavior in master/1.1.1 vs 1.1.0)
In-Reply-To: <96b0a23a-84ef-d010-68ae-fd4cfafd3dff@akamai.com>
References: <96b0a23a-84ef-d010-68ae-fd4cfafd3dff@akamai.com>
Message-ID: <CAF8qwaBghYeK1W0kO5ckPUbefQO+RyLf5M3tbsB0AwJsw8Ab=g@mail.gmail.com>

It's just that extension in our experience. Enforcing that servers don't
send extensions they aren't supposed to generally works fine and is good
for the ecosystem. But that particular extension needs a quirk.

I suspect there was some confusion because ec_point_format_list can be
server-sent in TLS 1.2 while elliptic_curves cannot. To be honest, I think
that was just a mistake in RFC 4492. TLS 1.2 has no way for the server to
tell the client what curves are acceptable for client certificates while
the converse is possible. (TLS 1.3 avoids this mess entirely with
SignatureScheme.)

I do not know how widespread this one is. It looks like we coincidentally
retained the quirk for this extension in BoringSSL when we first rewrote
our extension-handling from the 1.0.2 code. Later on, I encountered the
issue unrelatedly (I was probing some servers with some custom Go code),
noticed we were already tolerant of this, and merely added a clarifying
comment:
https://boringssl.googlesource.com/boringssl/+/4ac2dc4c0d48ca45da4f66c40e60d6b425fa94a3

(Speaking of which, I think I forgot to inform the vendor. I'll send them a
note.)

David

On Tue, Oct 3, 2017 at 11:16 AM Benjamin Kaduk via openssl-dev <
openssl-dev at openssl.org> wrote:

> Hi all,
>
> Doing some testing with a snapshot of master (s_client with -tls1_2 and
> optionally a cipherspec that prefers ECDHE ciphers), we're running into
> a sizeable number of servers that are sending extension 0xa (formerly
> "elliptic_curves", now "supported_groups") in the ServerHello.  This is
> not supported by RFC 7919 or RFC 4492 (the server is supposed to
> indicate it's selected curve/group in the ServerKeyExchange message
> instead), or by the TLS 1.3 draft spec (which permits "supported_groups"
> in EncryptedExtensions, so the client can update a cache of groups
> supported by the server).
>
> In OpenSSL 1.1.0 we seem to have treated the elliptic_curves extension
> in a ServerHello as an extension unknown to the library code and passed
> it off to the custom extension handler.  With the extension processing
> rework in master done to support TLS 1.3, which admits extensions in
> many more contexts than previously, we now check that a received
> extension is allowable in the context at hand.  In the table of
> extensions, supported_groups is marked only as allowable in the
> ClientHello and TLS 1.3 EncryptedExtensions, per the spec.  However,
> this new strict behavior causes connection failures when talking to
> these buggy servers.  So far we've seen this behavior from servers that
> send a Server: header indicating Microsoft-IIS/7.5 and just "Apache".
>
> This raises some question of what behavioral compatibility is desired
> between 1.1.0 and 1.1.1 -- do we need to disable the "extension context"
> verification for ServerHello processing entirely, or maybe just for the
> one extension known to cause trouble in practice?  Or should we have an
> SSL/SSL_CTX option to control the behavior (and which behavior should be
> the default)?
>
> Also, I'd be interested in hearing whether anyone else has observed this
> sort of behavior.
>
> Thanks,
>
> Ben
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171003/c9ce4f67/attachment.html>

From rsalz at akamai.com  Tue Oct  3 17:36:03 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 3 Oct 2017 17:36:03 +0000
Subject: [openssl-dev] Can I haz TLS 1.3 ?
Message-ID: <EC2534F5-5555-4C72-A893-DD19D5871FBC@akamai.com>

Some people have asked why TLS 1.3 isn?t available yet.  This might help; it?s a draft of a posting for my company?s blog.


Can I Haz TLS 1.3 ?

Everybody wants to be able to use TLS 1.3. Among the reasons are:
                It?s faster ? being able to reconnect to a server you?ve previously used, and saving a full round-trip latency is impressive.
                It?s more reliable ? the protocol has been cleaned up and simplified. For example, the related concepts of sessions, tickets, and pre-shared keys are merged and treated consistently. To a protocol designer, it is much more elegant, and therefore much easier to implement
                It?s more secure ? Many world-class cryptographers have been involved in the protocol design, analyzed it, and tried to break it.

TLS has been in the ?last call? for several weeks now.  What does that mean, and what?s holding it up?

The IETF is the organization that defines most of the standards that define how the Internet works. They cover everything from naming (DNS) to routing around firewalls, up to and including HTTP. The documents, known as RFCs, are created by working groups, passed to a steering committee for review, and then published as ?Internet Standards.?

Participation in a working group (WG) is, by design, very easy and not a lot of overhead.  You just have to join a mailing list.  Every WG has a mailing list and there are currently more than 110 working groups hosted at the IETF. Each one has a status page, that shows their charter (what they are working on), the current sent of documents, and pointers to the mailing lists.  For the TLS working group, that page is at https://datatracker.ietf.org/wg/tls/documents/.

Future RFC?s start as Internet-Drafts. Each draft usually goes through multiple revisions, as the working group members comment on it, other feedback is addressed, and so on.  At some point, the authors or editors will post a new draft.  By convention, every working group draft is named ?draft-ietf-{WGNAME}-{subject}-{nn}? where {WGNAME} is the name of the working group, {subject} is the name of the document, and {nn} is the revision number.  For example, ?draft-ietf-tls-tls13-21? is the 21st draft of the TLS 1.3 specification from the TLS working group.

When the working group thinks a document is done, it enters WGLC, working group last call.  This period, usually lasting a couple of weeks, is the last chance to make editorial or serious factual fixes.  Since most people are deadline-driven, this is usually when many on the WG wake up and read the drafts. After WGLC, it goes to the IESG (technical leadership basically) for review.  As I said, TLS 1.3 has been in WGLC for weeks.  So why can?t we use it yet?

First, the different drafts don?t interoperate. Each represents a different milestone on the way to the full specification, and a flag in the header identifies which draft is being used. OpenSSL, used by most of the servers on the Internet, is currently at draft-21. Chrome and Firefox, two of the most popular browsers on the Internet, are staying at draft-18; they don?t want to upgrade until we have the final version. (I think that?s silly, but I don?t work for either browser.)

Tests run by various companies, including Google, Mozilla, and Facebook, indicate that the ?failure rate? of TLS 1.3 is disturbingly high. It appears that network hardware such as routers, gateways, load balancers and the like, are blocking TLS 1.3 packets because they don?t recognize the protocol. They are doing ?fail closed? and block the connections because they don?t understand it, rather than assuming it?s safe to forward. The IETF often uses the term ?middlebox? to describe such hardware that operates between endpoints, and this type of behavior that blocks new protocols as ?ossificiation.?  The various companies, and no doubt others, are trying experiments to tweak the protocol to lower the failure rate. For example, in some circumstances it might be acceptable to make a TLS 1.3 message look like a TLS 1.2 message (after you?ve already committed to doing TLS 1.3).

So far nobody has released any details. When it happens, it will be on the TLS-WG mailing list, which you can find at the page I referenced above. Until then, because of the draft differences, it?s impractical to run even limited deployment tests unless you?re willing to work with bleeding edge releases and undocumented flags. That?s unfortunate, and we all hope that the situation will be improved by the next IETF meeting in November. Until then, we just have to sit tight and wait.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171003/8e41ae73/attachment-0001.html>

From robbat2 at gentoo.org  Tue Oct  3 17:51:20 2017
From: robbat2 at gentoo.org (Robin H. Johnson)
Date: Tue, 3 Oct 2017 17:51:20 +0000
Subject: [openssl-dev] [RFC] enc utility & under-documented behavior
 changes: improving backward compatibility
In-Reply-To: <1507016743.11542.2.camel@redhat.com>
References: <robbat2-20171002T183923-631359582Z@orbis-terrarum.net>
 <dd83d71a-e629-7dbd-4378-9049ef524972@openssl.org>
 <1507016743.11542.2.camel@redhat.com>
Message-ID: <robbat2-20171003T174835-061554044Z@orbis-terrarum.net>

On Tue, Oct 03, 2017 at 09:45:43AM +0200, Tomas Mraz wrote:
> On Tue, 2017-10-03 at 08:23 +0100, Matt Caswell wrote:
> > 
> > > 1.2. This also opens the path to stronger key derivation (PBKDF2)
> > > 2. During decryption, if no header block is present, and no message
> > > ???digest was specified, the default digest SHOULD be MD5.
> > 
> > Should it? What about compatibility with OpenSSL 1.1.0? We cannot
> > make
> > breaking changes in 1.1.1, so it has to be compatible with 1.1.0.
> Yeah, the ship has sailed. SHA-256 should be used by default as in
> 1.1.0.
It's a breaking change from 1.0.

At the very least, it should be added to the big notes:
https://www.openssl.org/news/openssl-1.1.0-notes.html
(this was in fact the first place I looked when my data was broken,
there was nothing about the enc tool here).

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer
E-Mail   : robbat2 at gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1113 bytes
Desc: Digital signature
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171003/ab583768/attachment.sig>

From hanno at hboeck.de  Tue Oct  3 19:45:09 2017
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Tue, 3 Oct 2017 21:45:09 +0200
Subject: [openssl-dev] Can I haz TLS 1.3 ?
In-Reply-To: <EC2534F5-5555-4C72-A893-DD19D5871FBC@akamai.com>
References: <EC2534F5-5555-4C72-A893-DD19D5871FBC@akamai.com>
Message-ID: <20171003214509.56593923@pc1>

Hi,

On Tue, 3 Oct 2017 17:36:03 +0000
"Salz, Rich via openssl-dev" <openssl-dev at openssl.org> wrote:

> Tests run by various companies, including Google, Mozilla, and
> Facebook, indicate that the ?failure rate? of TLS 1.3 is disturbingly
> high. It appears that network hardware such as routers, gateways,
> load balancers and the like, are blocking TLS 1.3 packets because
> they don?t recognize the protocol. They are doing ?fail closed? and
> block the connections because they don?t understand it, rather than
> assuming it?s safe to forward. The IETF often uses the term
> ?middlebox? to describe such hardware that operates between
> endpoints, and this type of behavior that blocks new protocols as
> ?ossificiation.?  The various companies, and no doubt others, are
> trying experiments to tweak the protocol to lower the failure rate.
> For example, in some circumstances it might be acceptable to make a
> TLS 1.3 message look like a TLS 1.2 message (after you?ve already
> committed to doing TLS 1.3).

So I heard chatter about this, but not much details. Which I find
unfortunate and a bit disturbing. (I'm aware of a single case with
bluetooth HW, but this sounds like this is much more common.)

Can the people involved in these Tests please speak up what's going on
here? Particularly can you please name vendor names?
And quite frankly I think we need to have a discussion about those
vendors. They're harming the Internet and they shouldn't be able to do
so without consequences.
TLS 1.3 is already built to workaround broken middleboxes (the whole
new version negotiation and GREASE approach), yet it doesn't seem to
help.

If I may dream I'd like to see a situation where large TLS-friendly
players (thinking Google, Cloudflare etc.) speak up and say that
in the future they'll boycott vendors that deploy such
Internet-breaking devices.

-- 
Hanno B?ck
https://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

From rsalz at akamai.com  Tue Oct  3 21:52:50 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 3 Oct 2017 21:52:50 +0000
Subject: [openssl-dev] Can I haz TLS 1.3 ?
In-Reply-To: <20171003214509.56593923@pc1>
References: <EC2534F5-5555-4C72-A893-DD19D5871FBC@akamai.com>
 <20171003214509.56593923@pc1>
Message-ID: <1B76841D-6FC0-4365-A9E8-93917FFF4353@akamai.com>


    Can the people involved in these Tests please speak up what's going on
    here? Particularly can you please name vendor names?


Tbe TLSWG mailing list is probably a more effective place to have that discussion; I was just informing the OpenSSL community of the state of play ;)



From michel.sales at free.fr  Wed Oct  4 08:45:18 2017
From: michel.sales at free.fr (Michel)
Date: Wed, 4 Oct 2017 10:45:18 +0200
Subject: [openssl-dev] [RFC] enc utility & under-documented behavior
	changes: improving backward compatibility
In-Reply-To: <dd83d71a-e629-7dbd-4378-9049ef524972@openssl.org>
References: <robbat2-20171002T183923-631359582Z@orbis-terrarum.net>
 <dd83d71a-e629-7dbd-4378-9049ef524972@openssl.org>
Message-ID: <000601d33ced$1c2a3440$547e9cc0$@sales@free.fr>


[...]
I think we probably should have an option to not write out the header at all
- but not to "increase security by obscurity". Rather it would be about
having the ability to write out a "raw" encrypted file that could be
consumed by some other tool.
[...]


+1

I will probably come back on this soon.

Michel


From ted.marynicz at gmail.com  Wed Oct  4 08:53:35 2017
From: ted.marynicz at gmail.com (Ted Marynicz)
Date: Wed, 4 Oct 2017 09:53:35 +0100
Subject: [openssl-dev] Can I haz TLS 1.3 ?
In-Reply-To: <EC2534F5-5555-4C72-A893-DD19D5871FBC@akamai.com>
References: <EC2534F5-5555-4C72-A893-DD19D5871FBC@akamai.com>
Message-ID: <CAAZ_7Po+ozDPN9sSSr14tTxME-478rzugQjay5emjCt6hP4Y0A@mail.gmail.com>

Haz?

Is that some kind of devops-speak I am not (yet) aware of?

Ted
(a grand-father)

On 3 October 2017 at 18:36, Salz, Rich via openssl-dev <
openssl-dev at openssl.org> wrote:

> Some people have asked why TLS 1.3 isn?t available yet.  This might help;
> it?s a draft of a posting for my company?s blog.
>
>
>
>
>
> Can I Haz TLS 1.3 ?
>
>
>
> Everybody wants to be able to use TLS 1.3. Among the reasons are:
>
>                 It?s faster ? being able to reconnect to a server you?ve
> previously used, and saving a full round-trip latency is impressive.
>
>                 It?s more reliable ? the protocol has been cleaned up and
> simplified. For example, the related concepts of sessions, tickets, and
> pre-shared keys are merged and treated consistently. To a protocol
> designer, it is much more elegant, and therefore much easier to implement
>
>                 It?s more secure ? Many world-class cryptographers have
> been involved in the protocol design, analyzed it, and tried to break it.
>
>
>
> TLS has been in the ?last call? for several weeks now.  What does that
> mean, and what?s holding it up?
>
>
>
> The IETF is the organization that defines most of the standards that
> define how the Internet works. They cover everything from naming (DNS) to
> routing around firewalls, up to and including HTTP. The documents, known as
> RFCs, are created by working groups, passed to a steering committee for
> review, and then published as ?Internet Standards.?
>
>
>
> Participation in a working group (WG) is, by design, very easy and not a
> lot of overhead.  You just have to join a mailing list.  Every WG has a
> mailing list and there are currently more than 110 working groups hosted at
> the IETF. Each one has a status page, that shows their charter (what they
> are working on), the current sent of documents, and pointers to the mailing
> lists.  For the TLS working group, that page is at
> https://datatracker.ietf.org/wg/tls/documents/.
>
>
>
> Future RFC?s start as Internet-Drafts. Each draft usually goes through
> multiple revisions, as the working group members comment on it, other
> feedback is addressed, and so on.  At some point, the authors or editors
> will post a new draft.  By convention, every working group draft is named
> ?draft-ietf-{WGNAME}-{subject}-{nn}? where {WGNAME} is the name of the
> working group, {subject} is the name of the document, and {nn} is the
> revision number.  For example, ?draft-ietf-tls-tls13-21? is the 21st
> draft of the TLS 1.3 specification from the TLS working group.
>
>
>
> When the working group thinks a document is done, it enters WGLC, working
> group last call.  This period, usually lasting a couple of weeks, is the
> last chance to make editorial or serious factual fixes.  Since most people
> are deadline-driven, this is usually when many on the WG wake up and read
> the drafts. After WGLC, it goes to the IESG (technical leadership
> basically) for review.  As I said, TLS 1.3 has been in WGLC for weeks.  So
> why can?t we use it yet?
>
>
>
> First, the different drafts don?t interoperate. Each represents a
> different milestone on the way to the full specification, and a flag in the
> header identifies which draft is being used. OpenSSL, used by most of the
> servers on the Internet, is currently at draft-21. Chrome and Firefox, two
> of the most popular browsers on the Internet, are staying at draft-18; they
> don?t want to upgrade until we have the final version. (I think that?s
> silly, but I don?t work for either browser.)
>
>
>
> Tests run by various companies, including Google, Mozilla, and Facebook,
> indicate that the ?failure rate? of TLS 1.3 is disturbingly high. It
> appears that network hardware such as routers, gateways, load balancers and
> the like, are blocking TLS 1.3 packets because they don?t recognize the
> protocol. They are doing ?fail closed? and block the connections because
> they don?t understand it, rather than assuming it?s safe to forward. The
> IETF often uses the term ?middlebox? to describe such hardware that
> operates between endpoints, and this type of behavior that blocks new
> protocols as ?ossificiation.?  The various companies, and no doubt others,
> are trying experiments to tweak the protocol to lower the failure rate. For
> example, in some circumstances it might be acceptable to make a TLS 1.3
> message look like a TLS 1.2 message (after you?ve already committed to
> doing TLS 1.3).
>
>
>
> So far nobody has released any details. When it happens, it will be on the
> TLS-WG mailing list, which you can find at the page I referenced above.
> Until then, because of the draft differences, it?s impractical to run even
> limited deployment tests unless you?re willing to work with bleeding edge
> releases and undocumented flags. That?s unfortunate, and we all hope that
> the situation will be improved by the next IETF meeting in November. Until
> then, we just have to sit tight and wait.
>
>
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171004/cbe8b183/attachment-0001.html>

From matt at openssl.org  Wed Oct  4 09:30:25 2017
From: matt at openssl.org (Matt Caswell)
Date: Wed, 4 Oct 2017 10:30:25 +0100
Subject: [openssl-dev] rejecting elliptic_curves/supported_groups in
 ServerHello (new behavior in master/1.1.1 vs 1.1.0)
In-Reply-To: <96b0a23a-84ef-d010-68ae-fd4cfafd3dff@akamai.com>
References: <96b0a23a-84ef-d010-68ae-fd4cfafd3dff@akamai.com>
Message-ID: <50a7adb8-3852-1171-a180-9726659289d0@openssl.org>



On 03/10/17 16:15, Benjamin Kaduk via openssl-dev wrote:
> Hi all,
> 
> Doing some testing with a snapshot of master (s_client with -tls1_2 and
> optionally a cipherspec that prefers ECDHE ciphers), we're running into
> a sizeable number of servers that are sending extension 0xa (formerly
> "elliptic_curves", now "supported_groups") in the ServerHello.? This is
> not supported by RFC 7919 or RFC 4492 (the server is supposed to
> indicate it's selected curve/group in the ServerKeyExchange message
> instead), or by the TLS 1.3 draft spec (which permits "supported_groups"
> in EncryptedExtensions, so the client can update a cache of groups
> supported by the server).
> 
> In OpenSSL 1.1.0 we seem to have treated the elliptic_curves extension
> in a ServerHello as an extension unknown to the library code and passed
> it off to the custom extension handler.? With the extension processing
> rework in master done to support TLS 1.3, which admits extensions in
> many more contexts than previously, we now check that a received
> extension is allowable in the context at hand.? In the table of
> extensions, supported_groups is marked only as allowable in the
> ClientHello and TLS 1.3 EncryptedExtensions, per the spec.? However,
> this new strict behavior causes connection failures when talking to
> these buggy servers.? So far we've seen this behavior from servers that
> send a Server: header indicating Microsoft-IIS/7.5 and just "Apache".
> 
> This raises some question of what behavioral compatibility is desired
> between 1.1.0 and 1.1.1 -- do we need to disable the "extension context"
> verification for ServerHello processing entirely, or maybe just for the
> one extension known to cause trouble in practice?? Or should we have an
> SSL/SSL_CTX option to control the behavior (and which behavior should be
> the default)?
> 
> Also, I'd be interested in hearing whether anyone else has observed this
> sort of behavior.

Looks like we should have an exception for this case (with a suitable
comment explaining why). Will you create a PR?

Matt


From matt at openssl.org  Wed Oct  4 09:39:03 2017
From: matt at openssl.org (Matt Caswell)
Date: Wed, 4 Oct 2017 10:39:03 +0100
Subject: [openssl-dev] [RFC] enc utility & under-documented behavior
 changes: improving backward compatibility
In-Reply-To: <robbat2-20171003T174835-061554044Z@orbis-terrarum.net>
References: <robbat2-20171002T183923-631359582Z@orbis-terrarum.net>
 <dd83d71a-e629-7dbd-4378-9049ef524972@openssl.org>
 <1507016743.11542.2.camel@redhat.com>
 <robbat2-20171003T174835-061554044Z@orbis-terrarum.net>
Message-ID: <de8bb2b6-8328-001b-cd97-033f1a8bf415@openssl.org>



On 03/10/17 18:51, Robin H. Johnson wrote:
> On Tue, Oct 03, 2017 at 09:45:43AM +0200, Tomas Mraz wrote:
>> On Tue, 2017-10-03 at 08:23 +0100, Matt Caswell wrote:
>>>
>>>> 1.2. This also opens the path to stronger key derivation (PBKDF2)
>>>> 2. During decryption, if no header block is present, and no message
>>>> ???digest was specified, the default digest SHOULD be MD5.
>>>
>>> Should it? What about compatibility with OpenSSL 1.1.0? We cannot
>>> make
>>> breaking changes in 1.1.1, so it has to be compatible with 1.1.0.
>> Yeah, the ship has sailed. SHA-256 should be used by default as in
>> 1.1.0.
> It's a breaking change from 1.0.

As Tomas said - that ship has sailed. In my mind that change was a
mistake. It could have been done in a non-breaking way by introducing a
new header format at that time. That way if the header was not present
then we would have known to use MD5 - otherwise use the hash as
specified in the header. But its too late now. Breaking it again back to
what it was before is the wrong answer.

> At the very least, it should be added to the big notes:
> https://www.openssl.org/news/openssl-1.1.0-notes.html
> (this was in fact the first place I looked when my data was broken,
> there was nothing about the enc tool here).

Well in fact it is there:

  *) Changed default digest for the dgst and enc commands from MD5 to
     sha256
     [Rich Salz]

Perhaps that is a little brief - it doesn't really explain the
implications of the change.

Matt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 480 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171004/d3e0be07/attachment.sig>

From levitte at openssl.org  Wed Oct  4 10:16:07 2017
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 04 Oct 2017 12:16:07 +0200
Subject: [openssl-dev] Can I haz TLS 1.3 ?
In-Reply-To: <CAAZ_7Po+ozDPN9sSSr14tTxME-478rzugQjay5emjCt6hP4Y0A@mail.gmail.com>
References: <EC2534F5-5555-4C72-A893-DD19D5871FBC@akamai.com>
 <CAAZ_7Po+ozDPN9sSSr14tTxME-478rzugQjay5emjCt6hP4Y0A@mail.gmail.com>
Message-ID: <37564897-A8AF-4223-ADAD-115EEABC3DB8@openssl.org>

It's not specific to devops. Here, a quick history lesson:

https://english.stackexchange.com/questions/20356/origin-of-i-can-haz

Cheers
Richard 

Ted Marynicz <ted.marynicz at gmail.com> skrev: (4 oktober 2017 10:53:35 CEST)
>Haz?
>
>Is that some kind of devops-speak I am not (yet) aware of?
>
>Ted
>(a grand-father)
>
>On 3 October 2017 at 18:36, Salz, Rich via openssl-dev <
>openssl-dev at openssl.org> wrote:
>
>> Some people have asked why TLS 1.3 isn?t available yet.  This might
>help;
>> it?s a draft of a posting for my company?s blog.
>>
>>
>>
>>
>>
>> Can I Haz TLS 1.3 ?
>>
>>
>>
>> Everybody wants to be able to use TLS 1.3. Among the reasons are:
>>
>>                 It?s faster ? being able to reconnect to a server
>you?ve
>> previously used, and saving a full round-trip latency is impressive.
>>
>>                 It?s more reliable ? the protocol has been cleaned up
>and
>> simplified. For example, the related concepts of sessions, tickets,
>and
>> pre-shared keys are merged and treated consistently. To a protocol
>> designer, it is much more elegant, and therefore much easier to
>implement
>>
>>                 It?s more secure ? Many world-class cryptographers
>have
>> been involved in the protocol design, analyzed it, and tried to break
>it.
>>
>>
>>
>> TLS has been in the ?last call? for several weeks now.  What does
>that
>> mean, and what?s holding it up?
>>
>>
>>
>> The IETF is the organization that defines most of the standards that
>> define how the Internet works. They cover everything from naming
>(DNS) to
>> routing around firewalls, up to and including HTTP. The documents,
>known as
>> RFCs, are created by working groups, passed to a steering committee
>for
>> review, and then published as ?Internet Standards.?
>>
>>
>>
>> Participation in a working group (WG) is, by design, very easy and
>not a
>> lot of overhead.  You just have to join a mailing list.  Every WG has
>a
>> mailing list and there are currently more than 110 working groups
>hosted at
>> the IETF. Each one has a status page, that shows their charter (what
>they
>> are working on), the current sent of documents, and pointers to the
>mailing
>> lists.  For the TLS working group, that page is at
>> https://datatracker.ietf.org/wg/tls/documents/.
>>
>>
>>
>> Future RFC?s start as Internet-Drafts. Each draft usually goes
>through
>> multiple revisions, as the working group members comment on it, other
>> feedback is addressed, and so on.  At some point, the authors or
>editors
>> will post a new draft.  By convention, every working group draft is
>named
>> ?draft-ietf-{WGNAME}-{subject}-{nn}? where {WGNAME} is the name of
>the
>> working group, {subject} is the name of the document, and {nn} is the
>> revision number.  For example, ?draft-ietf-tls-tls13-21? is the 21st
>> draft of the TLS 1.3 specification from the TLS working group.
>>
>>
>>
>> When the working group thinks a document is done, it enters WGLC,
>working
>> group last call.  This period, usually lasting a couple of weeks, is
>the
>> last chance to make editorial or serious factual fixes.  Since most
>people
>> are deadline-driven, this is usually when many on the WG wake up and
>read
>> the drafts. After WGLC, it goes to the IESG (technical leadership
>> basically) for review.  As I said, TLS 1.3 has been in WGLC for
>weeks.  So
>> why can?t we use it yet?
>>
>>
>>
>> First, the different drafts don?t interoperate. Each represents a
>> different milestone on the way to the full specification, and a flag
>in the
>> header identifies which draft is being used. OpenSSL, used by most of
>the
>> servers on the Internet, is currently at draft-21. Chrome and
>Firefox, two
>> of the most popular browsers on the Internet, are staying at
>draft-18; they
>> don?t want to upgrade until we have the final version. (I think
>that?s
>> silly, but I don?t work for either browser.)
>>
>>
>>
>> Tests run by various companies, including Google, Mozilla, and
>Facebook,
>> indicate that the ?failure rate? of TLS 1.3 is disturbingly high. It
>> appears that network hardware such as routers, gateways, load
>balancers and
>> the like, are blocking TLS 1.3 packets because they don?t recognize
>the
>> protocol. They are doing ?fail closed? and block the connections
>because
>> they don?t understand it, rather than assuming it?s safe to forward.
>The
>> IETF often uses the term ?middlebox? to describe such hardware that
>> operates between endpoints, and this type of behavior that blocks new
>> protocols as ?ossificiation.?  The various companies, and no doubt
>others,
>> are trying experiments to tweak the protocol to lower the failure
>rate. For
>> example, in some circumstances it might be acceptable to make a TLS
>1.3
>> message look like a TLS 1.2 message (after you?ve already committed
>to
>> doing TLS 1.3).
>>
>>
>>
>> So far nobody has released any details. When it happens, it will be
>on the
>> TLS-WG mailing list, which you can find at the page I referenced
>above.
>> Until then, because of the draft differences, it?s impractical to run
>even
>> limited deployment tests unless you?re willing to work with bleeding
>edge
>> releases and undocumented flags. That?s unfortunate, and we all hope
>that
>> the situation will be improved by the next IETF meeting in November.
>Until
>> then, we just have to sit tight and wait.
>>
>>
>>
>> --
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From steve at openssl.org  Wed Oct  4 10:22:26 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 4 Oct 2017 10:22:26 +0000
Subject: [openssl-dev] [RFC] enc utility & under-documented behavior
 changes: improving backward compatibility
In-Reply-To: <de8bb2b6-8328-001b-cd97-033f1a8bf415@openssl.org>
References: <robbat2-20171002T183923-631359582Z@orbis-terrarum.net>
 <dd83d71a-e629-7dbd-4378-9049ef524972@openssl.org>
 <1507016743.11542.2.camel@redhat.com>
 <robbat2-20171003T174835-061554044Z@orbis-terrarum.net>
 <de8bb2b6-8328-001b-cd97-033f1a8bf415@openssl.org>
Message-ID: <20171004102226.GA29548@openssl.org>

On Wed, Oct 04, 2017, Matt Caswell wrote:

> 
> As Tomas said - that ship has sailed. In my mind that change was a
> mistake. It could have been done in a non-breaking way by introducing a
> new header format at that time.
> 

As regards a new header format. In the case of some of the structures we use
there is an appropriate password based encryption ASN.1 AlgorithmIdentifier.
The code to encode and decode that format is already in OpenSSL and it
is documented in various standards. It is currently used for private key
encryption (via PKCS#8) and PKCS#7 EncryptedData format (used by PKCS#12).
One of several advantages of using that form is that any new forms we want to
support just need to be a new password based encryption algorithm and "enc"
handles it automatically. So we'd get scrypt, PBKDF2 and all the older PKCS#12
algorithms automatically. We wouldn't be able to use the current non-standard
password based encrytion algorithm without defining our own OID but I can't
see why we'd want to use that when much better alternatives are available.

In fact if we were feeling particularly adventurous we could output a CMS or
PKCS#7 EncryptedData ContentInfo in the enc utility.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From bkaduk at akamai.com  Wed Oct  4 13:22:29 2017
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Wed, 4 Oct 2017 08:22:29 -0500
Subject: [openssl-dev] rejecting elliptic_curves/supported_groups in
 ServerHello (new behavior in master/1.1.1 vs 1.1.0)
In-Reply-To: <50a7adb8-3852-1171-a180-9726659289d0@openssl.org>
References: <96b0a23a-84ef-d010-68ae-fd4cfafd3dff@akamai.com>
 <50a7adb8-3852-1171-a180-9726659289d0@openssl.org>
Message-ID: <7a7e272f-3d50-b9f3-7055-326de627a8a2@akamai.com>

On 10/04/2017 04:30 AM, Matt Caswell wrote:
>
> Looks like we should have an exception for this case (with a suitable
> comment explaining why). Will you create a PR?
>

Yes, I was planning to.? I was just taking some time to ponder whether
it's worth burning an option bit on, to allow an opt-out (probably not).

-Ben

From maheshbhooth at gmail.com  Wed Oct  4 14:10:18 2017
From: maheshbhooth at gmail.com (Mahesh Bhoothapuri)
Date: Wed, 4 Oct 2017 07:10:18 -0700
Subject: [openssl-dev] rejecting elliptic_curves/supported_groups in
 ServerHello (new behavior in master/1.1.1 vs 1.1.0)
In-Reply-To: <96b0a23a-84ef-d010-68ae-fd4cfafd3dff@akamai.com>
References: <96b0a23a-84ef-d010-68ae-fd4cfafd3dff@akamai.com>
Message-ID: <CAFTmK8FJ74nKaE2w+JBE2inaDa+ZKxzDx21o1tNwvJqQ0DhSrQ@mail.gmail.com>

    if (SSL_CTX_set1_groups_list(ctx, "P-521:P-384:P-256") == 0) {
           //error
    }

    The client and server both use SSL_CTX_set1_groups-list to set the
supported group list.  Right now,  the server always
    has P-256 in the supported groups extension.
    When the the groups list is changed to add X25519,  the server responds
with P-256.   Is there a way to have the server support
    multiple specified groups.

    Section 9.1 of the rfc states:
    "

A TLS-compliant application MUST support digital signatures with
   rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
   CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
   TLS-compliant application MUST support key exchange with secp256r1
   (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748
<https://tools.ietf.org/html/rfc7748>].
  "

  So, having the server support P-256 satisfies the MUST part.  How
can we support X25519 on the server, or

  a list of different groups.

Thanks,
Mahesh

On Tue, Oct 3, 2017 at 8:15 AM, Benjamin Kaduk via openssl-dev <
openssl-dev at openssl.org> wrote:

> Hi all,
>
> Doing some testing with a snapshot of master (s_client with -tls1_2 and
> optionally a cipherspec that prefers ECDHE ciphers), we're running into
> a sizeable number of servers that are sending extension 0xa (formerly
> "elliptic_curves", now "supported_groups") in the ServerHello.  This is
> not supported by RFC 7919 or RFC 4492 (the server is supposed to
> indicate it's selected curve/group in the ServerKeyExchange message
> instead), or by the TLS 1.3 draft spec (which permits "supported_groups"
> in EncryptedExtensions, so the client can update a cache of groups
> supported by the server).
>
> In OpenSSL 1.1.0 we seem to have treated the elliptic_curves extension
> in a ServerHello as an extension unknown to the library code and passed
> it off to the custom extension handler.  With the extension processing
> rework in master done to support TLS 1.3, which admits extensions in
> many more contexts than previously, we now check that a received
> extension is allowable in the context at hand.  In the table of
> extensions, supported_groups is marked only as allowable in the
> ClientHello and TLS 1.3 EncryptedExtensions, per the spec.  However,
> this new strict behavior causes connection failures when talking to
> these buggy servers.  So far we've seen this behavior from servers that
> send a Server: header indicating Microsoft-IIS/7.5 and just "Apache".
>
> This raises some question of what behavioral compatibility is desired
> between 1.1.0 and 1.1.1 -- do we need to disable the "extension context"
> verification for ServerHello processing entirely, or maybe just for the
> one extension known to cause trouble in practice?  Or should we have an
> SSL/SSL_CTX option to control the behavior (and which behavior should be
> the default)?
>
> Also, I'd be interested in hearing whether anyone else has observed this
> sort of behavior.
>
> Thanks,
>
> Ben
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171004/51ace953/attachment-0001.html>

From richmoore44 at gmail.com  Wed Oct  4 14:59:48 2017
From: richmoore44 at gmail.com (Richard Moore)
Date: Wed, 4 Oct 2017 15:59:48 +0100
Subject: [openssl-dev] Can I haz TLS 1.3 ?
In-Reply-To: <20171003214509.56593923@pc1>
References: <EC2534F5-5555-4C72-A893-DD19D5871FBC@akamai.com>
 <20171003214509.56593923@pc1>
Message-ID: <CAMp7mVuZWR6bt=f9Zxnur-f6KopV4vMJvo999wC4VNzaLMpYBA@mail.gmail.com>

On 3 October 2017 at 20:45, Hanno B?ck <hanno at hboeck.de> wrote:

> On Tue, 3 Oct 2017 17:36:03 +0000
> "Salz, Rich via openssl-dev" <openssl-dev at openssl.org> wrote:
>
> So I heard chatter about this, but not much details. Which I find
> unfortunate and a bit disturbing. (I'm aware of a single case with
> bluetooth HW, but this sounds like this is much more common.)
>
>
?http://bluecoat.force.com/knowledgebase/articles/Technical_Alert/000032878?
??
Cheers

Rich.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171004/66cf37da/attachment.html>

From steve at openssl.org  Wed Oct  4 15:02:26 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 4 Oct 2017 15:02:26 +0000
Subject: [openssl-dev] rejecting elliptic_curves/supported_groups in
 ServerHello (new behavior in master/1.1.1 vs 1.1.0)
In-Reply-To: <CAFTmK8FJ74nKaE2w+JBE2inaDa+ZKxzDx21o1tNwvJqQ0DhSrQ@mail.gmail.com>
References: <96b0a23a-84ef-d010-68ae-fd4cfafd3dff@akamai.com>
 <CAFTmK8FJ74nKaE2w+JBE2inaDa+ZKxzDx21o1tNwvJqQ0DhSrQ@mail.gmail.com>
Message-ID: <20171004150226.GA3340@openssl.org>

On Wed, Oct 04, 2017, Mahesh Bhoothapuri wrote:

>     if (SSL_CTX_set1_groups_list(ctx, "P-521:P-384:P-256") == 0) {
>            //error
>     }
> 

If you have the above line you're telling the client to advertise support for
P-521:P-384:P-256 in that order and the server to only use them.

>     The client and server both use SSL_CTX_set1_groups-list to set the
> supported group list.  Right now,  the server always
>     has P-256 in the supported groups extension.
>     When the the groups list is changed to add X25519,  the server responds
> with P-256.   Is there a way to have the server support
>     multiple specified groups.
> 
>     Section 9.1 of the rfc states:
>     "
> 
> A TLS-compliant application MUST support digital signatures with
>    rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
>    CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
>    TLS-compliant application MUST support key exchange with secp256r1
>    (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748
> <https://tools.ietf.org/html/rfc7748>].
>   "
> 

Yes and OpenSSL does support those but there is nothing stopping a server or
client being configured to support a different set of groups.

>   So, having the server support P-256 satisfies the MUST part.  How
> can we support X25519 on the server, or
> 

Use X25519 in the supported group list.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From maheshbhooth at gmail.com  Wed Oct  4 17:46:42 2017
From: maheshbhooth at gmail.com (Mahesh Bhoothapuri)
Date: Wed, 4 Oct 2017 10:46:42 -0700
Subject: [openssl-dev] rejecting elliptic_curves/supported_groups in
 ServerHello (new behavior in master/1.1.1 vs 1.1.0)
In-Reply-To: <20171004150226.GA3340@openssl.org>
References: <96b0a23a-84ef-d010-68ae-fd4cfafd3dff@akamai.com>
 <CAFTmK8FJ74nKaE2w+JBE2inaDa+ZKxzDx21o1tNwvJqQ0DhSrQ@mail.gmail.com>
 <20171004150226.GA3340@openssl.org>
Message-ID: <CAFTmK8G2sU0jsFCOvwHTq4VegpxYgrCUTD0+zBKTfN_0PdSdrg@mail.gmail.com>

I am attaching a pcap where I set the supported list to contain X25519.
The client extension contains X25519.  However, the server still responds
with keyshare extension secp256r1 in a hello retry request.

This is the case for all the 5 TLS 1.3 ciphers.  Is there another setting
for the server to enable the supported groups?


Thanks,
Mahesh

On Wed, Oct 4, 2017 at 8:02 AM, Dr. Stephen Henson <steve at openssl.org>
wrote:

> On Wed, Oct 04, 2017, Mahesh Bhoothapuri wrote:
>
> >     if (SSL_CTX_set1_groups_list(ctx, "P-521:P-384:P-256") == 0) {
> >            //error
> >     }
> >
>
> If you have the above line you're telling the client to advertise support
> for
> P-521:P-384:P-256 in that order and the server to only use them.
>
> >     The client and server both use SSL_CTX_set1_groups-list to set the
> > supported group list.  Right now,  the server always
> >     has P-256 in the supported groups extension.
> >     When the the groups list is changed to add X25519,  the server
> responds
> > with P-256.   Is there a way to have the server support
> >     multiple specified groups.
> >
> >     Section 9.1 of the rfc states:
> >     "
> >
> > A TLS-compliant application MUST support digital signatures with
> >    rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
> >    CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
> >    TLS-compliant application MUST support key exchange with secp256r1
> >    (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748
> > <https://tools.ietf.org/html/rfc7748>].
> >   "
> >
>
> Yes and OpenSSL does support those but there is nothing stopping a server
> or
> client being configured to support a different set of groups.
>
> >   So, having the server support P-256 satisfies the MUST part.  How
> > can we support X25519 on the server, or
> >
>
> Use X25519 in the supported group list.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171004/1dfaf625/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x25519_trace0.pcap
Type: application/octet-stream
Size: 3120 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171004/1dfaf625/attachment.obj>

From steve at openssl.org  Wed Oct  4 19:49:27 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 4 Oct 2017 19:49:27 +0000
Subject: [openssl-dev] rejecting elliptic_curves/supported_groups in
 ServerHello (new behavior in master/1.1.1 vs 1.1.0)
In-Reply-To: <CAFTmK8G2sU0jsFCOvwHTq4VegpxYgrCUTD0+zBKTfN_0PdSdrg@mail.gmail.com>
References: <96b0a23a-84ef-d010-68ae-fd4cfafd3dff@akamai.com>
 <CAFTmK8FJ74nKaE2w+JBE2inaDa+ZKxzDx21o1tNwvJqQ0DhSrQ@mail.gmail.com>
 <20171004150226.GA3340@openssl.org>
 <CAFTmK8G2sU0jsFCOvwHTq4VegpxYgrCUTD0+zBKTfN_0PdSdrg@mail.gmail.com>
Message-ID: <20171004194927.GA9583@openssl.org>

On Wed, Oct 04, 2017, Mahesh Bhoothapuri wrote:

> I am attaching a pcap where I set the supported list to contain X25519.
> The client extension contains X25519.  However, the server still responds
> with keyshare extension secp256r1 in a hello retry request.
> 

Are you calling SSL_CTX_set1_groups_list() including X25519 on the server too?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From uri at ll.mit.edu  Wed Oct  4 20:03:17 2017
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Wed, 4 Oct 2017 20:03:17 +0000
Subject: [openssl-dev] Nasty bug in crypto/evp/m_sigver.c
Message-ID: <98847EEB-0606-4E2B-9CA4-D4190CA011AF@ll.mit.edu>

This bug prevents normal working of EVP_DigestSignInit() and subsequent calls when pkcs11 engine is involved.

 

Scenario: hashing and signing data, when signing is done on a token that supports only internal padding (aka it performs RSA-PSS padding on-board, rather than letting software such as OpenSSL do the PSS padding for it).

 

The current implementation works if either the token (pkcs11 engine) can do the digest (data hashing) on-board, or when it doesn?t do anything on-board except for the raw RSA.

 

For a pkcs11 device that does not hash data on-board, but does the padding on-board, one needs to pass two contexts to EVP_DigestSignInit(): md_ctx that does not point at an engine, and ?signing context? ctx that was created with the engine so it can pass signing request to it.

 

The nature of this bug is that EVP_DigestSignInit() ignores provided ctx. Then if you provide the engine, it is used for both digest and signature ? which fails on the attempt to off-load digest to the engine (HSM device that does not hash data). If you don?t provide the engine, then everything is done in software, and the engine receives only the very last raw RSA request ? which gets rejected as this HSM device does not support raw RSA.

 

Here?s the patch:

 

--- a/crypto/evp/m_sigver.c

+++ b/crypto/evp/m_sigver.c

@@ -19,8 +19,12 @@ static int do_sigver_init(EVP_MD_CTX *ctx, EVP_PKEY_CTX **pctx,

?????????????????????????? const EVP_MD *type, ENGINE *e, EVP_PKEY *pkey,

?????????????????????????? int ver)

 {

-??? if (ctx->pctx == NULL)

-??????? ctx->pctx = EVP_PKEY_CTX_new(pkey, e);

+??? if (ctx->pctx == NULL) {

+??????? if (pctx && *pctx)

+??????????? ctx->pctx = *pctx;

+??????? else

+??????????? ctx->pctx = EVP_PKEY_CTX_new(pkey, e);

+??? }

???? if (ctx->pctx == NULL)

???????? return 0;

 

I?ve tested with and without this patch. Here are the results (debugging information is from the libp11 pkcs11 engine):

 

Without the patch:

$ ./t2

Using YubiHSM device...

Signature padding is RSA-PSS padding

Enter PKCS#11 token PIN for YubiHSM:

Set RSA signature padding to RSA-PSS padding

t2.c:178 sign: EVP_DigestSignFinal() failed olen=512 (rv=0)

140736410264512:error:8207A070:PKCS#11 module:pkcs11_private_encrypt:Mechanism invalid:p11_rsa.c:140:

 

Mechanism invalid because raw RSA operation is requested, and the device does not support it.

 

With the above patch:

$ ./t2

Using YubiHSM device...

Signature padding is RSA-PSS padding

Enter PKCS#11 token PIN for YubiHSM:

Set RSA signature padding to RSA-PSS padding

p11_pkey.c:171 pkcs11_pkey_rsa_sign(): sig=0x7fa38f645cd0 *siglen=512 tbs=0x7fff51d83d40 tbslen=32

p11_pkey.c:215 saltlen=478 hashAlg=SHA256 mgf=MGF1-SHA256 

p11_pkey.c:513 hashAlg=SHA256 mgf=MGF1-SHA256 

Signed (data len=83, sig len=512):

1b d9 56 0e 80 80 7d 3b 29 0a 93 34 7d c5 27 7b 

54 d3 c8 2d 59 3d 08 fc 59 d4 62 64 ce 1c 73 51 

d9 9f 87 41 2e 2b 6c 2c d6 7e 9f 30 60 cf 0c 99 

4e 85 b4 7b 9e 82 63 40 ce 33 27 4c 13 aa 3c b7 

ba 8f 77 e1 5e 32 7c 70 78 e8 74 5a 6f cf 0f f3 

5c 56 91 c9 62 46 a4 c2 3e 7d 54 2b ed a5 e1 ec 

ff a1 54 29 f2 ac d6 91 09 98 3a 8f 99 1b 22 32 

c0 a5 84 ce a8 ee fc 89 db 6e 82 50 0b 62 57 1b 

09 cc 70 f6 57 27 b3 e4 4f fe 8d 65 e5 4c 61 ad 

0b a8 77 97 22 14 59 6d 25 28 b2 8a 3f ee 63 a1 

fc fa ab 20 f3 68 37 65 b2 3a c6 71 75 ac 2d fd 

79 67 17 27 62 b2 26 35 0b 84 9b 1a db d7 23 c1 

cb de 7d 29 5d 87 24 7b f5 88 45 82 d9 7a 84 e8 

80 36 35 f8 a6 79 a5 54 98 4b 37 e0 1d b2 ff 4f 

0e d2 f5 a2 b7 21 26 96 8c b8 f4 c2 32 6d 7b 62 

16 57 de 29 b9 f9 df 6d db 9b 4e 8b b5 00 c5 3f 

7b 21 03 36 10 50 e6 e3 93 52 07 15 c1 15 7d 92 

02 8e 89 df d3 63 0d 8d d3 ca 22 bb 7f d1 1d c2 

9c d8 e9 3b 7a c4 52 de 5d 71 a4 08 6e 18 a9 ff 

4a 36 7f 54 c3 ae 1d 91 f1 aa 46 30 b6 ba 0b cb 

46 fc bb de bb d5 5e e5 aa 9e f4 93 9b 6f 68 dc 

83 20 b0 e0 74 be 1b c7 87 f9 8e ef 47 eb 1a 7d 

93 0d be e8 66 ca 4a ff c0 f7 66 58 32 39 2d 84 

9f 0c 63 53 11 4e 92 44 a1 83 59 09 1a 86 04 21 

05 c5 35 6c f7 46 96 08 ff 2c 37 3b 48 a2 28 50 

60 2d 1e 54 ce 4f d5 00 c8 58 86 6e 61 ca 68 d6 

16 f6 16 60 22 9e 9a 64 f2 1a ff 87 1d 56 59 48 

c8 c6 c7 eb 43 0a 02 10 a9 6e fa d1 86 32 a0 c4 

f2 de d6 94 e1 4a cd 41 64 73 e3 85 0f 07 57 f9 

85 ef 38 8f f9 01 6d 94 28 c7 a3 51 8f b5 47 16 

b7 15 d7 0b b6 c1 58 26 5a 2c 18 b4 ca 9a ab d1 

8b d8 b9 d6 03 80 7e c4 a6 28 27 6b 51 dd 3e 41 

 

$

 

Digest is correctly performed by OpenSSL, and the entire RSA-PSS operation is sent to the engine. HSM device completes it successfully.

 

I?d really appreciate if you could apply it.

--

Regards,

Uri Blumenthal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171004/d6200dbc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171004/d6200dbc/attachment-0001.bin>

From uri at ll.mit.edu  Wed Oct  4 20:22:58 2017
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Wed, 4 Oct 2017 20:22:58 +0000
Subject: [openssl-dev] Nasty bug in crypto/evp/m_sigver.c
In-Reply-To: <98847EEB-0606-4E2B-9CA4-D4190CA011AF@ll.mit.edu>
References: <98847EEB-0606-4E2B-9CA4-D4190CA011AF@ll.mit.edu>
Message-ID: <47E99265-FCEB-44F4-AA2A-9A3C9BE08936@ll.mit.edu>

Forgot to add that when you do provide the engine impl in the EVP_DigestSignInit() invocation, the app fails because it tries to ?outsource? the digesting of the data to the engine as well:

 

$ ./t2a

Using YubiHSM device...

Signature padding is RSA-PSS padding

Enter PKCS#11 token PIN for YubiHSM:

t2.c:143 sign: EVP_DigestSignInit() failed (rv=0)

140736410264584:error:260BA093:engine routines:ENGINE_get_digest:unimplemented digest:tb_digest.c:126:

140736410264584:error:06080086:digital envelope routines:EVP_DigestInit_ex:initialization error:digest.c:193:

 

--

Regards,

Uri Blumenthal

 

From: Uri Blumenthal <uri at ll.mit.edu>
Date: Wednesday, October 04, 2017 at 16:03
To: openssl-dev <openssl-dev at openssl.org>
Subject: Nasty bug in crypto/evp/m_sigver.c

 

This bug prevents normal working of EVP_DigestSignInit() and subsequent calls when pkcs11 engine is involved.

 

Scenario: hashing and signing data, when signing is done on a token that supports only internal padding (aka it performs RSA-PSS padding on-board, rather than letting software such as OpenSSL do the PSS padding for it).

 

The current implementation works if either the token (pkcs11 engine) can do the digest (data hashing) on-board, or when it doesn?t do anything on-board except for the raw RSA.

 

For a pkcs11 device that does not hash data on-board, but does the padding on-board, one needs to pass two contexts to EVP_DigestSignInit(): md_ctx that does not point at an engine, and ?signing context? ctx that was created with the engine so it can pass signing request to it.

 

The nature of this bug is that EVP_DigestSignInit() ignores provided ctx. Then if you provide the engine, it is used for both digest and signature ? which fails on the attempt to off-load digest to the engine (HSM device that does not hash data). If you don?t provide the engine, then everything is done in software, and the engine receives only the very last raw RSA request ? which gets rejected as this HSM device does not support raw RSA.

 

Here?s the patch:

 

--- a/crypto/evp/m_sigver.c

+++ b/crypto/evp/m_sigver.c

@@ -19,8 +19,12 @@ static int do_sigver_init(EVP_MD_CTX *ctx, EVP_PKEY_CTX **pctx,

                           const EVP_MD *type, ENGINE *e, EVP_PKEY *pkey,

                           int ver)

{

-    if (ctx->pctx == NULL)

-        ctx->pctx = EVP_PKEY_CTX_new(pkey, e);

+    if (ctx->pctx == NULL) {

+        if (pctx && *pctx)

+            ctx->pctx = *pctx;

+        else

+            ctx->pctx = EVP_PKEY_CTX_new(pkey, e);

+    }

     if (ctx->pctx == NULL)

         return 0;

 

I?ve tested with and without this patch. Here are the results (debugging information is from the libp11 pkcs11 engine):

 

Without the patch:

$ ./t2

Using YubiHSM device...

Signature padding is RSA-PSS padding

Enter PKCS#11 token PIN for YubiHSM:

Set RSA signature padding to RSA-PSS padding

t2.c:178 sign: EVP_DigestSignFinal() failed olen=512 (rv=0)

140736410264512:error:8207A070:PKCS#11 module:pkcs11_private_encrypt:Mechanism invalid:p11_rsa.c:140:

 

Mechanism invalid because raw RSA operation is requested, and the device does not support it.

 

With the above patch:

$ ./t2

Using YubiHSM device...

Signature padding is RSA-PSS padding

Enter PKCS#11 token PIN for YubiHSM:

Set RSA signature padding to RSA-PSS padding

p11_pkey.c:171 pkcs11_pkey_rsa_sign(): sig=0x7fa38f645cd0 *siglen=512 tbs=0x7fff51d83d40 tbslen=32

p11_pkey.c:215 saltlen=478 hashAlg=SHA256 mgf=MGF1-SHA256 

p11_pkey.c:513 hashAlg=SHA256 mgf=MGF1-SHA256 

Signed (data len=83, sig len=512):

1b d9 56 0e 80 80 7d 3b 29 0a 93 34 7d c5 27 7b 

54 d3 c8 2d 59 3d 08 fc 59 d4 62 64 ce 1c 73 51 

d9 9f 87 41 2e 2b 6c 2c d6 7e 9f 30 60 cf 0c 99 

4e 85 b4 7b 9e 82 63 40 ce 33 27 4c 13 aa 3c b7 

ba 8f 77 e1 5e 32 7c 70 78 e8 74 5a 6f cf 0f f3 

5c 56 91 c9 62 46 a4 c2 3e 7d 54 2b ed a5 e1 ec 

ff a1 54 29 f2 ac d6 91 09 98 3a 8f 99 1b 22 32 

c0 a5 84 ce a8 ee fc 89 db 6e 82 50 0b 62 57 1b 

09 cc 70 f6 57 27 b3 e4 4f fe 8d 65 e5 4c 61 ad 

0b a8 77 97 22 14 59 6d 25 28 b2 8a 3f ee 63 a1 

fc fa ab 20 f3 68 37 65 b2 3a c6 71 75 ac 2d fd 

79 67 17 27 62 b2 26 35 0b 84 9b 1a db d7 23 c1 

cb de 7d 29 5d 87 24 7b f5 88 45 82 d9 7a 84 e8 

80 36 35 f8 a6 79 a5 54 98 4b 37 e0 1d b2 ff 4f 

0e d2 f5 a2 b7 21 26 96 8c b8 f4 c2 32 6d 7b 62 

16 57 de 29 b9 f9 df 6d db 9b 4e 8b b5 00 c5 3f 

7b 21 03 36 10 50 e6 e3 93 52 07 15 c1 15 7d 92 

02 8e 89 df d3 63 0d 8d d3 ca 22 bb 7f d1 1d c2 

9c d8 e9 3b 7a c4 52 de 5d 71 a4 08 6e 18 a9 ff 

4a 36 7f 54 c3 ae 1d 91 f1 aa 46 30 b6 ba 0b cb 

46 fc bb de bb d5 5e e5 aa 9e f4 93 9b 6f 68 dc 

83 20 b0 e0 74 be 1b c7 87 f9 8e ef 47 eb 1a 7d 

93 0d be e8 66 ca 4a ff c0 f7 66 58 32 39 2d 84 

9f 0c 63 53 11 4e 92 44 a1 83 59 09 1a 86 04 21 

05 c5 35 6c f7 46 96 08 ff 2c 37 3b 48 a2 28 50 

60 2d 1e 54 ce 4f d5 00 c8 58 86 6e 61 ca 68 d6 

16 f6 16 60 22 9e 9a 64 f2 1a ff 87 1d 56 59 48 

c8 c6 c7 eb 43 0a 02 10 a9 6e fa d1 86 32 a0 c4 

f2 de d6 94 e1 4a cd 41 64 73 e3 85 0f 07 57 f9 

85 ef 38 8f f9 01 6d 94 28 c7 a3 51 8f b5 47 16 

b7 15 d7 0b b6 c1 58 26 5a 2c 18 b4 ca 9a ab d1 

8b d8 b9 d6 03 80 7e c4 a6 28 27 6b 51 dd 3e 41 

 

$

 

Digest is correctly performed by OpenSSL, and the entire RSA-PSS operation is sent to the engine. HSM device completes it successfully.

 

I?d really appreciate if you could apply it.

--

Regards,

Uri Blumenthal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171004/bcfc1742/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171004/bcfc1742/attachment-0001.bin>

From maheshbhooth at gmail.com  Wed Oct  4 23:48:39 2017
From: maheshbhooth at gmail.com (Mahesh Bhoothapuri)
Date: Wed, 4 Oct 2017 16:48:39 -0700
Subject: [openssl-dev] rejecting elliptic_curves/supported_groups in
 ServerHello (new behavior in master/1.1.1 vs 1.1.0)
In-Reply-To: <20171004194927.GA9583@openssl.org>
References: <96b0a23a-84ef-d010-68ae-fd4cfafd3dff@akamai.com>
 <CAFTmK8FJ74nKaE2w+JBE2inaDa+ZKxzDx21o1tNwvJqQ0DhSrQ@mail.gmail.com>
 <20171004150226.GA3340@openssl.org>
 <CAFTmK8G2sU0jsFCOvwHTq4VegpxYgrCUTD0+zBKTfN_0PdSdrg@mail.gmail.com>
 <20171004194927.GA9583@openssl.org>
Message-ID: <CAFTmK8E243qeRVT3MMmAghorAsh6hgd9H9HEGkVq6qYQphNqCg@mail.gmail.com>

Thanks for the hint.  The problem is fixed.

Server was setting:

if (SSL_CTX_set1_groups_list(ctx, "X25519:P-256") == 0) {
//
}

The call succeeds.

But the old TLS 1.2 code was setting:

            int nid = NID_X9_62_prime256v1;
            EC_KEY* ecdh = EC_KEY_new_by_curve_name(nid);
            if (ecdh == NULL)
            {
               //error
            }
            SSL_CTX_set_tmp_ecdh(ctx, ecdh);

After disabling this, the server responds with the right group - X25519.

Thanks,
Mahesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171004/54fcb3e2/attachment.html>

From steve at openssl.org  Thu Oct  5 14:28:31 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 5 Oct 2017 14:28:31 +0000
Subject: [openssl-dev] rejecting elliptic_curves/supported_groups in
 ServerHello (new behavior in master/1.1.1 vs 1.1.0)
In-Reply-To: <CAFTmK8E243qeRVT3MMmAghorAsh6hgd9H9HEGkVq6qYQphNqCg@mail.gmail.com>
References: <96b0a23a-84ef-d010-68ae-fd4cfafd3dff@akamai.com>
 <CAFTmK8FJ74nKaE2w+JBE2inaDa+ZKxzDx21o1tNwvJqQ0DhSrQ@mail.gmail.com>
 <20171004150226.GA3340@openssl.org>
 <CAFTmK8G2sU0jsFCOvwHTq4VegpxYgrCUTD0+zBKTfN_0PdSdrg@mail.gmail.com>
 <20171004194927.GA9583@openssl.org>
 <CAFTmK8E243qeRVT3MMmAghorAsh6hgd9H9HEGkVq6qYQphNqCg@mail.gmail.com>
Message-ID: <20171005142831.GA25055@openssl.org>

On Wed, Oct 04, 2017, Mahesh Bhoothapuri wrote:

> Thanks for the hint.  The problem is fixed.
> 
> Server was setting:
> 
> if (SSL_CTX_set1_groups_list(ctx, "X25519:P-256") == 0) {
> //
> }
> 
> The call succeeds.
> 
> But the old TLS 1.2 code was setting:
> 
>             int nid = NID_X9_62_prime256v1;
>             EC_KEY* ecdh = EC_KEY_new_by_curve_name(nid);
>             if (ecdh == NULL)
>             {
>                //error
>             }
>             SSL_CTX_set_tmp_ecdh(ctx, ecdh);
> 
> After disabling this, the server responds with the right group - X25519.
> 

Yes that's the problem. By doing that you're replacing the groups list with a
single curve.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From robbat2 at gentoo.org  Fri Oct  6 18:41:42 2017
From: robbat2 at gentoo.org (Robin H. Johnson)
Date: Fri, 6 Oct 2017 18:41:42 +0000
Subject: [openssl-dev] [RFC] enc utility & under-documented behavior
 changes: improving backward compatibility
In-Reply-To: <de8bb2b6-8328-001b-cd97-033f1a8bf415@openssl.org>
References: <robbat2-20171002T183923-631359582Z@orbis-terrarum.net>
 <dd83d71a-e629-7dbd-4378-9049ef524972@openssl.org>
 <1507016743.11542.2.camel@redhat.com>
 <robbat2-20171003T174835-061554044Z@orbis-terrarum.net>
 <de8bb2b6-8328-001b-cd97-033f1a8bf415@openssl.org>
Message-ID: <robbat2-20171006T184044-305942396Z@orbis-terrarum.net>

On Wed, Oct 04, 2017 at 10:39:03AM +0100, Matt Caswell wrote:
> > At the very least, it should be added to the big notes:
> > https://www.openssl.org/news/openssl-1.1.0-notes.html
> > (this was in fact the first place I looked when my data was broken,
> > there was nothing about the enc tool here).
> Well in fact it is there:
> 
>   *) Changed default digest for the dgst and enc commands from MD5 to
>      sha256
>      [Rich Salz]
> 
> Perhaps that is a little brief - it doesn't really explain the
> implications of the change.
The entry you just copied is from the full ChangeLog, not the notes
page.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer
E-Mail   : robbat2 at gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1113 bytes
Desc: Digital signature
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171006/f70e9835/attachment.sig>

From matt at openssl.org  Fri Oct  6 21:30:03 2017
From: matt at openssl.org (Matt Caswell)
Date: Fri, 6 Oct 2017 22:30:03 +0100
Subject: [openssl-dev] Fwd: [TLS] Update on TLS 1.3 Middlebox Issues
In-Reply-To: <CABcZeBMoW8B78C5UmLqAim4X=jQ8jVRYTP-L7RVnU3AScdFvFw@mail.gmail.com>
References: <CABcZeBMoW8B78C5UmLqAim4X=jQ8jVRYTP-L7RVnU3AScdFvFw@mail.gmail.com>
Message-ID: <f36065e0-138b-0dbb-8e7f-792e6ebec016@openssl.org>

An update on the TLS1.3 middlebox issue posted to the TLS WG list which
may be of interest to the openssl-dev group.

Matt


-------- Forwarded Message --------
Subject: 	[TLS] Update on TLS 1.3 Middlebox Issues
Date: 	Fri, 6 Oct 2017 13:16:37 -0700
From: 	Eric Rescorla <ekr at rtfm.com>
To: 	tls at ietf.org <tls at ietf.org>



Hi folks,

In Prague I mentioned that we were seeing evidence of increased
failures with TLS 1.3 which we believed were due to middleboxes. In
the meantime, several of us have done experiments on this, and I
wanted to provide an update.

The high-order bit is that *negotiating* TLS 1.3 seems to cause
increased failures with a variety of middleboxes (it?s generally safe
to offer TLS 1.3 to servers which don?t support it). The measured
incremental error rates vary quite a bit, ranging from minimal
(Facebook) to ~1.5% (Firefox) and ~3.4% (Chrome). Each of us is using
a slightly different methodology (organic versus forced traffic) and
different populations (mobile, desktop, enterprise, etc), but it does
seem like there is a nontrivial failure rate. At this point, we have
two options:

- Fall back to TLS 1.2 (as we have unfortunately done for previous releases)
- Try to make small adaptations to TLS 1.3 to make it work better with
middleboxes.

The Chrome team has been working on angle #2 and has been having
success with an approach of trying to make TLS 1.3 connections look
more like TLS 1.2. Their current experiments get them down to about 1%
incremental failures and they are currently measuring some changes
they hope will shave that down more. These changes are a bit annoying
but basically superficial; they do not affect the cryptography.

Separately, Firefox and Facebook have been experimenting with the new
content type described in PR#1051 (Google?s and Facebook?s results
conflict, so this is a bit of a mystery). We hope to have results from
both sets of experiments by end of October, at which point we should
be able to discuss the best way forward as a group.

-Ekr


-------------- next part --------------
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls


From paulyang.inf at gmail.com  Thu Oct 12 02:51:41 2017
From: paulyang.inf at gmail.com (Paul Yang)
Date: Thu, 12 Oct 2017 10:51:41 +0800
Subject: [openssl-dev] how to static compile ssl engine into openssl
In-Reply-To: <31F771DF13463A429610AEEBF6AFAE820183179B@mbx14.360buyAD.local>
References: <31F771DF13463A429610AEEBF6AFAE820182EBC4@mbx14.360buyAD.local>
 <20170926.073206.1731025271528375213.levitte@openssl.org>
 <31F771DF13463A429610AEEBF6AFAE820183179B@mbx14.360buyAD.local>
Message-ID: <305EF57D-0202-4067-A679-8EAD37FB4553@gmail.com>


> On 26 Sep 2017, at 18:13, ??? <chengwenping1 at jd.com <mailto:chengwenping1 at jd.com>> wrote:
> 
> There is some more info.
> 
> https://github.com/01org/QAT_Engine/issues/9 <https://github.com/01org/QAT_Engine/issues/9>

Interesting. This issue was created by me last year, seems some people still struggling with combination of NGINX+OpenSSL+QAT.

Our solution is just to build OpenSSL dynamically with NGINX (although usually most Chinese companies I know like to build OpenSSL statically with NGINX).

> 
> -----????-----
> ???: ??? 
> ????: 2017?9?26? 17:43
> ???: openssl-dev at openssl.org <mailto:openssl-dev at openssl.org>
> ??: ??: [openssl-dev] how to static compile ssl engine into openssl
> 
> Hi Richard,
> 
> 	Thanks for your response. From your meaning, the QAT engine codes is not applicable for static compile into openssl.
> 	Yes, I should keep to run nginx using shared OpenSSL libraries with dynamic QAT engines installed, until QAT engine static compiling is support.
> 
> 	Thank,
> 
> 	Nick Cheng
> -----????-----
> ???: openssl-dev [mailto:openssl-dev-bounces at openssl.org <mailto:openssl-dev-bounces at openssl.org>] ?? Richard Levitte
> ????: 2017?9?26? 13:32
> ???: openssl-dev at openssl.org <mailto:openssl-dev at openssl.org>
> ??: Re: [openssl-dev] how to static compile ssl engine into openssl
> 
> In message <31F771DF13463A429610AEEBF6AFAE820182EBC4 at mbx14.360buyAD.local <mailto:31F771DF13463A429610AEEBF6AFAE820182EBC4 at mbx14.360buyAD.local>> on Mon, 25 Sep 2017 10:16:28 +0000, ??? <chengwenping1 at jd.com <mailto:chengwenping1 at jd.com>> said:
> 
> chengwenping1> I?m working on accelerating ssl traffic with Intel QAT 
> chengwenping1> card, now openssl 1.1.0f is integrated into Nginx, so I 
> chengwenping1> need to static compile Intel QAT engine into openssl, and 
> chengwenping1> I do not find some useful info about it from Internet, 
> chengwenping1> although openssl-1.1.0f/engines/ build.info <http://build.info/>, it is not 
> chengwenping1> applicable from QAT engine from 
> chengwenping1> https://github.com/01org/QAT_Engine <https://github.com/01org/QAT_Engine>. Is there a guide 
> chengwenping1> line for this case?
> 
> Unforatunately, there is no such guide that I know of.  I just had a look in e_qat.c, and there seems to be support for doing that there (see the sections guarded by OPENSSL_NO_DYNAMIC_ENGINES), but I can't see any way to make use of that in their configuration.
> 
> If this is what you really want, I suggest you create an issue in the QAT_Engine project...  but you probably need to understand that you may not get what you want, and if you do, it's probably going to be an unsupported hack.
> 
> chengwenping1> There is another alternative to do it, just to alone 
> chengwenping1> compile openssl and nginx, but it will take effort to 
> chengwenping1> deploy it.
> 
> You mean to have nginx use the shared OpenSSL libraries, which also enables dynamic engines?  Yes, that's the usual way to go about these things.
> 
> Cheers,
> Richard
> 
> -- 
> Richard Levitte         levitte at openssl.org <mailto:levitte at openssl.org>
> OpenSSL Project         http://www.openssl.org/~levitte/ <http://www.openssl.org/~levitte/>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev <https://mta.openssl.org/mailman/listinfo/openssl-dev>
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev <https://mta.openssl.org/mailman/listinfo/openssl-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171012/cc6f7f7d/attachment-0001.html>

From paulyang.inf at gmail.com  Thu Oct 12 02:53:13 2017
From: paulyang.inf at gmail.com (Paul Yang)
Date: Thu, 12 Oct 2017 10:53:13 +0800
Subject: [openssl-dev] how to static compile ssl engine into openssl
In-Reply-To: <31F771DF13463A429610AEEBF6AFAE820183179B@mbx14.360buyAD.local>
References: <31F771DF13463A429610AEEBF6AFAE820182EBC4@mbx14.360buyAD.local>
 <20170926.073206.1731025271528375213.levitte@openssl.org>
 <31F771DF13463A429610AEEBF6AFAE820183179B@mbx14.360buyAD.local>
Message-ID: <DB9B8171-9869-46DC-898A-B99DF30EE300@gmail.com>


> On 26 Sep 2017, at 18:13, ??? <chengwenping1 at jd.com <mailto:chengwenping1 at jd.com>> wrote:
> 
> There is some more info.
> 
> https://github.com/01org/QAT_Engine/issues/9 <https://github.com/01org/QAT_Engine/issues/9>

Interesting. This issue was created by me last year, seems some people still struggling with combination of NGINX+OpenSSL+QAT.

Our solution is just to build OpenSSL dynamically with NGINX (although usually most Chinese companies I know like to build OpenSSL statically with NGINX).

> 
> -----????-----
> ???: ??? 
> ????: 2017?9?26? 17:43
> ???: openssl-dev at openssl.org <mailto:openssl-dev at openssl.org>
> ??: ??: [openssl-dev] how to static compile ssl engine into openssl
> 
> Hi Richard,
> 
> 	Thanks for your response. From your meaning, the QAT engine codes is not applicable for static compile into openssl.
> 	Yes, I should keep to run nginx using shared OpenSSL libraries with dynamic QAT engines installed, until QAT engine static compiling is support.
> 
> 	Thank,
> 
> 	Nick Cheng
> -----????-----
> ???: openssl-dev [mailto:openssl-dev-bounces at openssl.org <mailto:openssl-dev-bounces at openssl.org>] ?? Richard Levitte
> ????: 2017?9?26? 13:32
> ???: openssl-dev at openssl.org <mailto:openssl-dev at openssl.org>
> ??: Re: [openssl-dev] how to static compile ssl engine into openssl
> 
> In message <31F771DF13463A429610AEEBF6AFAE820182EBC4 at mbx14.360buyAD.local <mailto:31F771DF13463A429610AEEBF6AFAE820182EBC4 at mbx14.360buyAD.local>> on Mon, 25 Sep 2017 10:16:28 +0000, ??? <chengwenping1 at jd.com <mailto:chengwenping1 at jd.com>> said:
> 
> chengwenping1> I?m working on accelerating ssl traffic with Intel QAT 
> chengwenping1> card, now openssl 1.1.0f is integrated into Nginx, so I 
> chengwenping1> need to static compile Intel QAT engine into openssl, and 
> chengwenping1> I do not find some useful info about it from Internet, 
> chengwenping1> although openssl-1.1.0f/engines/ build.info <http://build.info/>, it is not 
> chengwenping1> applicable from QAT engine from 
> chengwenping1> https://github.com/01org/QAT_Engine <https://github.com/01org/QAT_Engine>. Is there a guide 
> chengwenping1> line for this case?
> 
> Unforatunately, there is no such guide that I know of.  I just had a look in e_qat.c, and there seems to be support for doing that there (see the sections guarded by OPENSSL_NO_DYNAMIC_ENGINES), but I can't see any way to make use of that in their configuration.
> 
> If this is what you really want, I suggest you create an issue in the QAT_Engine project...  but you probably need to understand that you may not get what you want, and if you do, it's probably going to be an unsupported hack.
> 
> chengwenping1> There is another alternative to do it, just to alone 
> chengwenping1> compile openssl and nginx, but it will take effort to 
> chengwenping1> deploy it.
> 
> You mean to have nginx use the shared OpenSSL libraries, which also enables dynamic engines?  Yes, that's the usual way to go about these things.
> 
> Cheers,
> Richard
> 
> -- 
> Richard Levitte         levitte at openssl.org <mailto:levitte at openssl.org>
> OpenSSL Project         http://www.openssl.org/~levitte/ <http://www.openssl.org/~levitte/>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev <https://mta.openssl.org/mailman/listinfo/openssl-dev>
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev <https://mta.openssl.org/mailman/listinfo/openssl-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171012/bdc57636/attachment-0001.html>

From shaopu.yan at intel.com  Tue Oct 17 03:01:37 2017
From: shaopu.yan at intel.com (Yan, Shaopu)
Date: Tue, 17 Oct 2017 03:01:37 +0000
Subject: [openssl-dev] #GP happens in do_sse3_after_all
Message-ID: <DC6B1A27A69D674084120B3DA9C34E453B181871@shsmsx102.ccr.corp.intel.com>

Hi dear openssl maintainer,
I met an issue in the crypto/chacha/chacha-x86_64.S, could you be kind to have a look on it? Thanks very much.

Currently it will stuck in the function do_sse3_after_all, and a #GP will occurs due to the following instructions
""movdqa %xmm0,0(%rsp)" need 16 bytes alignment, however, after I go through the detail code, I find that it already
adjust the rsp by "subq $64+8,%rsp" and I simply tried to change it like "subq $64,%rsp" then it will works correctly.

I don't know whether there's an issue about it?, if I have some mistake please correct me. :)
I suppose that the "subq $64+8,%rsp" is used to align the stack with 16 bytes, but in my case if the default RSP already be 16 bytes
align then after execute it the stack will becomes 8 bytes align so the #GP happens:(  So could you please help to check it?



438ChaCha20_4x:
439.LChaCha20_4x:
440        movq        %rsp,%r9
441        movq        %r10,%r11
442        shrq        $32,%r10
443        testq        $32,%r10
444        jnz        .LChaCha20_8x
445        cmpq        $192,%rdx
446        ja        .Lproceed4x
447
448        andq        $71303168,%r11
449        cmpq        $4194304,%r11
450        je        .Ldo_sse3_after_all



987.LChaCha20_8x:
988        movq        %rsp,%r9
989        subq        $0x280+8,%rsp
990        andq        $-32,%rsp
991        vzeroupper





.Lproceed4x:
453        subq        $0x140+8,%rsp
454        movdqa        .Lsigma(%rip),%xmm11
455        movdqu        (%rcx),%xmm15
456        movdqu        16(%rcx),%xmm7
457        movdqu        (%r8),%xmm3
458        leaq        256(%rsp),%rcx
459        leaq        .Lrot16(%rip),%r10
460        leaq        .Lrot24(%rip),%r11





.Ldo_sse3_after_all:
312        subq        $64+8,%rsp
313        movdqa        .Lsigma(%rip),%xmm0
314        movdqu        (%rcx),%xmm1
315        movdqu        16(%rcx),%xmm2
316        movdqu        (%r8),%xmm3
317        movdqa        .Lrot16(%rip),%xmm6
318        movdqa        .Lrot24(%rip),%xmm7
319
320        movdqa        %xmm0,0(%rsp)
321        movdqa        %xmm1,16(%rsp)
322        movdqa        %xmm2,32(%rsp)
323        movdqa        %xmm3,48(%rsp)
324        movq        $10,%r8
325        jmp        .Loop_ssse3

/Best Regards!
--Shaopu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171017/3faaaaae/attachment.html>

From appro at openssl.org  Fri Oct 20 08:14:02 2017
From: appro at openssl.org (Andy Polyakov)
Date: Fri, 20 Oct 2017 10:14:02 +0200
Subject: [openssl-dev] #GP happens in do_sse3_after_all
In-Reply-To: <DC6B1A27A69D674084120B3DA9C34E453B181871@shsmsx102.ccr.corp.intel.com>
References: <DC6B1A27A69D674084120B3DA9C34E453B181871@shsmsx102.ccr.corp.intel.com>
Message-ID: <5c7fed30-3cec-fd52-ee18-0dcc8e804144@openssl.org>

Hi,

> I met an issue in the crypto/chacha/chacha-x86_64.S, could you be kind 
> to have a look on it? Thanks very much.
> 
> Currently it will stuck in the function *do_sse3_after_all*, and a #GP 
> will occurs due to the following instructions
> 
> ??movdqa?%xmm0,0(%rsp)? need 16 bytes alignment, however, after I go 
> through the detail code, I find that it already
> 
> adjust the rsp by ?subq?$64+8,%rsp? and I simply tried to change it like 
> ?subq?$64,%rsp? then it will works correctly.
> 
> I don?t know whether there?s an issue about it?, if I have some mistake 
> please correct me. J
> 
> I suppose that the ?subq?$64+8,%rsp? is used to align the stack with 16 
> bytes, but in my case if the default RSP already be 16 bytes
> 
> align then after execute it the stack will becomes 8 bytes align so the 
> #GP happensL ?So could you please help to check it?

All known x86_64 ABIs specify that top of stack is to be aligned at 16 
bytes. Obviously it can't be aligned at each given moment, not on 
x86_64, so question is *when* does it have to be aligned? It has to be 
aligned at least at moment of call to another subroutine. Since x86_64 
call instruction pushes return address to stack, this means that upon 
entry to function stack is actually misaligned. Hence compliant function 
has to allocate 16*n+8 frame. And that's what we see in code, 64+8 in 
the referred case. Now, if you experience crash at the point in 
question, it can only mean one thing, caller is not compliant with ABI. 
Though there is ambiguity and it might be wrong to blame direct caller 
for following reason. Customarily compilers don't explicitly align stack 
in each subroutine, but instead assume that caller aligned it. In other 
words stack alignment is kind of collective effort, with each subroutine 
relying on its caller. So that all subroutines can be compliant, but it 
would still be a problem. This would be case when stack was *initially* 
misaligned [upon its creation]. To summarize, it's either one of 
subroutines in chain of calls leading to ChaCha20_ctr32 that is not 
compliant with ABI, or stack was initially seeded misaligned.

From kimsovan79 at gmail.com  Fri Oct 20 14:11:38 2017
From: kimsovan79 at gmail.com (Kim Sovan)
Date: Fri, 20 Oct 2017 21:11:38 +0700
Subject: [openssl-dev] confirm eaf6a05b1db3ce90b620c3c0e5498d999d97b3eb
In-Reply-To: <mailman.0.1508508451.21106.openssl-dev@openssl.org>
References: <mailman.0.1508508451.21106.openssl-dev@openssl.org>
Message-ID: <78E0D1FA-42D7-4105-B50C-DFF1A8AF5F63@gmail.com>



Sent from my iPhone

> On Oct 20, 29 Heisei, at 9:07 PM, openssl-dev-request at openssl.org wrote:
> 
> Mailing list subscription confirmation notice for mailing list
> openssl-dev
> 
> We have received a request from 103.242.14.62 for subscription of your
> email address, "kimsovan79 at gmail.com", to the openssl-dev at openssl.org
> mailing list.  To confirm that you want to be added to this mailing
> list, simply reply to this message, keeping the Subject: header
> intact.  Or visit this web page:
> 
>    https://mta.openssl.org/mailman/confirm/openssl-dev/eaf6a05b1db3ce90b620c3c0e5498d999d97b3eb
> 
> 
> Or include the following line -- and only the following line -- in a
> message to openssl-dev-request at openssl.org:
> 
>    confirm eaf6a05b1db3ce90b620c3c0e5498d999d97b3eb
> 
> Note that simply sending a `reply' to this message should work from
> most mail readers, since that usually leaves the Subject: line in the
> right form (additional "Re:" text in the Subject: is okay).
> 
> If you do not wish to be subscribed to this list, please simply
> disregard this message.  If you think you are being maliciously
> subscribed to the list, or have any other questions, send them to
> openssl-dev-owner at openssl.org.

From Andrew.Byrne at dell.com  Mon Oct 23 11:51:01 2017
From: Andrew.Byrne at dell.com (APOB83)
Date: Mon, 23 Oct 2017 04:51:01 -0700 (MST)
Subject: [openssl-dev] New crypto algorithms in openSSL engine
In-Reply-To: <15184578-9e9e-90e1-e51d-b25d9e8a2d6c@openssl.org>
References: <5B112BCB3892C248BAA2A6A6B9BCED001ED90C89@MX202CL03.corp.emc.com>
 <15184578-9e9e-90e1-e51d-b25d9e8a2d6c@openssl.org>
Message-ID: <1508759461265-0.post@n7.nabble.com>

Hi,

I've noticed the following statement in another thread here...

*May I suggest you have a look at the GOST engine?  It does implement 
the algorithm entirely in the engine.  The only things added in the 
OpenSSL code are the OIDs (not strictly necessary) and the TLS 
ciphersuites (I don't think that can be done dynamically at all, at 
least yet). *

This suggests to me that I might be able to build a new engine with the new
crypto algorithms and then in the OpenSSL code, add the code necessary to
build the new ciphersuites. Am I correct in how I'm reading this?





--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-Dev-f29372.html

From matt at openssl.org  Mon Oct 23 11:57:47 2017
From: matt at openssl.org (Matt Caswell)
Date: Mon, 23 Oct 2017 12:57:47 +0100
Subject: [openssl-dev] New crypto algorithms in openSSL engine
In-Reply-To: <1508759461265-0.post@n7.nabble.com>
References: <5B112BCB3892C248BAA2A6A6B9BCED001ED90C89@MX202CL03.corp.emc.com>
 <15184578-9e9e-90e1-e51d-b25d9e8a2d6c@openssl.org>
 <1508759461265-0.post@n7.nabble.com>
Message-ID: <f24f6e89-9bb5-8852-f7eb-e680754a4161@openssl.org>



On 23/10/17 12:51, APOB83 wrote:
> Hi,
> 
> I've noticed the following statement in another thread here...
> 
> *May I suggest you have a look at the GOST engine?  It does implement 
> the algorithm entirely in the engine.  The only things added in the 
> OpenSSL code are the OIDs (not strictly necessary) and the TLS 
> ciphersuites (I don't think that can be done dynamically at all, at 
> least yet). *
> 
> This suggests to me that I might be able to build a new engine with the new
> crypto algorithms and then in the OpenSSL code, add the code necessary to
> build the new ciphersuites. Am I correct in how I'm reading this?

This is what was done for the GOST ciphersuites so, yes, it is
theoretically possible. However I think we are unlikely to add
significant code to libssl unless there is a reasonably sized user base.

Matt


From vitus at wagner.pp.ru  Mon Oct 23 12:50:09 2017
From: vitus at wagner.pp.ru (Victor Wagner)
Date: Mon, 23 Oct 2017 15:50:09 +0300
Subject: [openssl-dev] New crypto algorithms in openSSL engine
In-Reply-To: <1508759461265-0.post@n7.nabble.com>
References: <5B112BCB3892C248BAA2A6A6B9BCED001ED90C89@MX202CL03.corp.emc.com>
 <15184578-9e9e-90e1-e51d-b25d9e8a2d6c@openssl.org>
 <1508759461265-0.post@n7.nabble.com>
Message-ID: <20171023155009.0c985f60@fafnir.local.vm>

On Mon, 23 Oct 2017 04:51:01 -0700 (MST)
APOB83 <Andrew.Byrne at dell.com> wrote:

> Hi,
> 
> I've noticed the following statement in another thread here...
> 
> *May I suggest you have a look at the GOST engine?  It does implement 
> the algorithm entirely in the engine.  The only things added in the 
> OpenSSL code are the OIDs (not strictly necessary) and the TLS 
> ciphersuites (I don't think that can be done dynamically at all, at 
> least yet). *

Really, about a ten years ago, when we first developed GOST engine, we
have made patches, that allow to add ciphersuites dynamically.
Unfortunately, that time core team haven't accepted these patches.


-- 

From Andrew.Byrne at dell.com  Mon Oct 23 13:13:15 2017
From: Andrew.Byrne at dell.com (APOB83)
Date: Mon, 23 Oct 2017 06:13:15 -0700 (MST)
Subject: [openssl-dev] New crypto algorithms in openSSL engine
In-Reply-To: <5B112BCB3892C248BAA2A6A6B9BCED001ED90C89@MX202CL03.corp.emc.com>
References: <5B112BCB3892C248BAA2A6A6B9BCED001ED90C89@MX202CL03.corp.emc.com>
Message-ID: <1508764395116-0.post@n7.nabble.com>

Thanks for the replies guys.

I'm happy enough to work on a separate fork. This is a research endevour so
it's not critical that I get something integrated into the master openSSL
branch. I don't see there being a significant enough user base anyway for
anything to get added into core libssl.

@Victor; Are you saying so that the patches that enabled the GOST
ciphersuite be added are not included in openSSL? If so, would that mean
it's not possible for me to fork off openSSL and follow the GOST template?

Putting engines aside for a moment, given that I have the appropriate
headers for the crypto library I want to use, and I can build a shared or
static library for it... would it be a viable option to try and integrate
those headers and libraries directly into openSSL? 



--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-Dev-f29372.html

From rsalz at akamai.com  Mon Oct 23 13:54:46 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 23 Oct 2017 13:54:46 +0000
Subject: [openssl-dev] New crypto algorithms in openSSL engine
In-Reply-To: <20171023155009.0c985f60@fafnir.local.vm>
References: <5B112BCB3892C248BAA2A6A6B9BCED001ED90C89@MX202CL03.corp.emc.com>
 <15184578-9e9e-90e1-e51d-b25d9e8a2d6c@openssl.org>
 <1508759461265-0.post@n7.nabble.com>
 <20171023155009.0c985f60@fafnir.local.vm>
Message-ID: <9269EF36-00AC-4A79-A94E-26EBB8D4349B@akamai.com>

? Really, about a ten years ago, when we first developed GOST engine, we
    have made patches, that allow to add ciphersuites dynamically.
    Unfortunately, that time core team haven't accepted these patches.
    
Do you still have them available?  We might make a different choice now ?


From rsalz at akamai.com  Mon Oct 23 14:01:24 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 23 Oct 2017 14:01:24 +0000
Subject: [openssl-dev] New crypto algorithms in openSSL engine
In-Reply-To: <1508764395116-0.post@n7.nabble.com>
References: <5B112BCB3892C248BAA2A6A6B9BCED001ED90C89@MX202CL03.corp.emc.com>
 <1508764395116-0.post@n7.nabble.com>
Message-ID: <62012E65-CD6E-46E7-84EC-E26879B9788C@akamai.com>

>        @Victor; Are you saying so that the patches that enabled the GOST
    ciphersuite be added are not included in openSSL? If so, would that mean
    it's not possible for me to fork off openSSL and follow the GOST template?
    
Not quite.  He?s saying that adding new crypto to TLS requires some static tables in libssl to be updated.  Some new ?NID? variables in objects.txt, and so on.  The implementation of the algorithm can be done as an ENGINE.

>    Putting engines aside for a moment, given that I have the appropriate
    headers for the crypto library I want to use, and I can build a shared or
    static library for it... would it be a viable option to try and integrate
    those headers and libraries directly into openSSL? 
  
Maybe. Hence the term ?research? :)


From beldmit at gmail.com  Mon Oct 23 14:06:19 2017
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Mon, 23 Oct 2017 17:06:19 +0300
Subject: [openssl-dev] New crypto algorithms in openSSL engine
In-Reply-To: <9269EF36-00AC-4A79-A94E-26EBB8D4349B@akamai.com>
References: <5B112BCB3892C248BAA2A6A6B9BCED001ED90C89@MX202CL03.corp.emc.com>
 <15184578-9e9e-90e1-e51d-b25d9e8a2d6c@openssl.org>
 <1508759461265-0.post@n7.nabble.com>
 <20171023155009.0c985f60@fafnir.local.vm>
 <9269EF36-00AC-4A79-A94E-26EBB8D4349B@akamai.com>
Message-ID: <CADqLbzKtvJrd5GMpUuCyuyw0+yYj83imoem_Wp3F1Ae=13WR7w@mail.gmail.com>

On Mon, Oct 23, 2017 at 4:54 PM, Salz, Rich via openssl-dev <
openssl-dev at openssl.org> wrote:

> ? Really, about a ten years ago, when we first developed GOST engine, we
>     have made patches, that allow to add ciphersuites dynamically.
>     Unfortunately, that time core team haven't accepted these patches.
>
> Do you still have them available?  We might make a different choice now ?
>

Well, as now there are separate structures for key exchange and auth, these
patches seem to have almost no sense.

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171023/bf8d4973/attachment.html>

From Andrew.Byrne at dell.com  Mon Oct 23 14:19:36 2017
From: Andrew.Byrne at dell.com (APOB83)
Date: Mon, 23 Oct 2017 07:19:36 -0700 (MST)
Subject: [openssl-dev] New crypto algorithms in openSSL engine
In-Reply-To: <62012E65-CD6E-46E7-84EC-E26879B9788C@akamai.com>
References: <5B112BCB3892C248BAA2A6A6B9BCED001ED90C89@MX202CL03.corp.emc.com>
 <1508764395116-0.post@n7.nabble.com>
 <62012E65-CD6E-46E7-84EC-E26879B9788C@akamai.com>
Message-ID: <1508768376525-0.post@n7.nabble.com>

OpenSSL - Dev mailing list wrote
>>        @Victor; Are you saying so that the patches that enabled the GOST
>     ciphersuite be added are not included in openSSL? If so, would that
> mean
>     it's not possible for me to fork off openSSL and follow the GOST
> template?
>     
> Not quite.  He?s saying that adding new crypto to TLS requires some static
> tables in libssl to be updated.  Some new ?NID? variables in objects.txt,
> and so on.  The implementation of the algorithm can be done as an ENGINE.

Cool... this makes sense to me but looking for the voice of experience. I
can implement the algorithms in an ENGINE so that they are all available to
libssl. Then, in libssl I add the appropriate code (as you mention) to build
the ciphersuite and let me set up a TLS channel with the ENGINE. 

Unless someone experienced can say "nope, this just won't work", this is my
preferred route to go down as it minimizes how much I have to modify core
code.


OpenSSL - Dev mailing list wrote
>>    Putting engines aside for a moment, given that I have the appropriate
>     headers for the crypto library I want to use, and I can build a shared
> or
>     static library for it... would it be a viable option to try and
> integrate
>     those headers and libraries directly into openSSL? 
>   
> Maybe. Hence the term ?research? :)
> 
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Indeed. I guess I'd just prefer to direct my efforts down the path with the
highest chance of success :)



--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-Dev-f29372.html

From bhat.jayalakshmi at gmail.com  Tue Oct 24 06:06:15 2017
From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat)
Date: Tue, 24 Oct 2017 11:36:15 +0530
Subject: [openssl-dev] Wanted details on ./config or Configure options
Message-ID: <CALq8RvK-rXxa+aVkkqbVUKE68dPdWMNZc2JZp75CHmYWcSy9PA@mail.gmail.com>

Hi All,

I am looking for details on options used to disable or remove unwanted
ciphers, components while openssl building. This is for OpenSSL 1.0.2h. I
am seeing many things on internet. But most of them have minimum
explanation, please can you tell me is there any link that I can refer.

Regards
Jaya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171024/a01d7df5/attachment.html>

From tmraz at redhat.com  Wed Oct 25 15:19:23 2017
From: tmraz at redhat.com (Tomas Mraz)
Date: Wed, 25 Oct 2017 17:19:23 +0200
Subject: [openssl-dev] Systemwide configurability of OpenSSL
In-Reply-To: <20170927222102.O5IFn%steffen@sdaoden.eu>
References: <1506524526.13888.1.camel@redhat.com>
 <20170927222102.O5IFn%steffen@sdaoden.eu>
Message-ID: <76697227-3f38-bf98-3d64-a37b557a4584@redhat.com>

On 09/28/2017 12:21 AM, Steffen Nurpmeso wrote:
> Hello.
> 
> Tomas Mraz <tmraz at redhat.com> wrote:
>  |I would like to restart the discussion about possibilities of system-
>  |wide configurability of OpenSSL and particularly libssl.
>  |
>  |Historically OpenSSL allowed only for configuration of the enabled
>  |ciphersuites list if application called appropriate API call. This is
>  |now enhanced with the SSL_CONF API and the applications can set thing
>  |such as allowed signature algorithms or protocol versions via this API.
> 
> Now is the time to thank the OpenSSL for this improvement which
> will change the world mid- or long term: thank you!

+1

...

>  |However libssl currently does not have a way to apply some policy such
>  |as using just protocol TLS1.2 or better system-wide with a possibility
>  |for sysadmin to configure this via some configuration file. Of course
>  |it would still be up to individual application configurations whether
>  |they override such policy or not, but it would be useful for sysadmin
>  |to be able to set such policy and depend on that setting if he does not
>  |modify the settings in individual application configurations.
>  |
>  |How would openssl maintainers regard a patch that would add loading of
>  |a system-wide SSL configuration file on startup and application of it
> 
> Having a global one and especially giving administrators the
> possibility to provide an outer cramp that cannot be loosened any
> further, though further restricted, would indeed be good.
> And that being applied automatically just when SSL library is
> initialized, without an explicit application-side
> CONF_modules_load_file().  If i recall correctly that was the
> original suggestion.
> 
> And is it actually possible to have a generic "super-section" that
> is applied even if an application specific one has been chosen?
> And unfortunately it is not possible to say MinProtocol=Latest,
> like this users have to be aware, even if they are not.  With
> MinProtocol=Latest they would only have to face this jungle of
> non-understanding (be honest: Google/DuckDuckGo plus
> copy-and-paste, isn't it) if something really fails.

The problem is that by default the applications do not read the file and
do not apply the defaults. Even the openssl s_client/s_server does not
seem to work, but I might be doing something wrong.

What I would like to see is applying the defaults unconditionally or
maybe with some possibility to opt-out of it by application but not opt-in.

Can I please get at least some response from the openssl team? Should I
open an issue on github for that feature?

Tomas Mraz

From matt at openssl.org  Wed Oct 25 15:45:58 2017
From: matt at openssl.org (Matt Caswell)
Date: Wed, 25 Oct 2017 16:45:58 +0100
Subject: [openssl-dev] Systemwide configurability of OpenSSL
In-Reply-To: <76697227-3f38-bf98-3d64-a37b557a4584@redhat.com>
References: <1506524526.13888.1.camel@redhat.com>
 <20170927222102.O5IFn%steffen@sdaoden.eu>
 <76697227-3f38-bf98-3d64-a37b557a4584@redhat.com>
Message-ID: <2e3358d6-5cd5-f54b-64e6-d863cd94374e@openssl.org>



On 25/10/17 16:19, Tomas Mraz wrote:
>>  |However libssl currently does not have a way to apply some policy such
>>  |as using just protocol TLS1.2 or better system-wide with a possibility
>>  |for sysadmin to configure this via some configuration file. Of course
>>  |it would still be up to individual application configurations whether
>>  |they override such policy or not, but it would be useful for sysadmin
>>  |to be able to set such policy and depend on that setting if he does not
>>  |modify the settings in individual application configurations.
>>  |
>>  |How would openssl maintainers regard a patch that would add loading of
>>  |a system-wide SSL configuration file on startup and application of it
>>
>> Having a global one and especially giving administrators the
>> possibility to provide an outer cramp that cannot be loosened any
>> further, though further restricted, would indeed be good.
>> And that being applied automatically just when SSL library is
>> initialized, without an explicit application-side
>> CONF_modules_load_file().  If i recall correctly that was the
>> original suggestion.
>>
>> And is it actually possible to have a generic "super-section" that
>> is applied even if an application specific one has been chosen?
>> And unfortunately it is not possible to say MinProtocol=Latest,
>> like this users have to be aware, even if they are not.  With
>> MinProtocol=Latest they would only have to face this jungle of
>> non-understanding (be honest: Google/DuckDuckGo plus
>> copy-and-paste, isn't it) if something really fails.
> 
> The problem is that by default the applications do not read the file and
> do not apply the defaults. Even the openssl s_client/s_server does not
> seem to work, but I might be doing something wrong.
> 
> What I would like to see is applying the defaults unconditionally or
> maybe with some possibility to opt-out of it by application but not opt-in.
> 
> Can I please get at least some response from the openssl team? Should I
> open an issue on github for that feature?

Hmmmm....seems like something that would go in OPENSSL_init_ssl() (which
is called automatically at start up).

Matt


From bhat.jayalakshmi at gmail.com  Wed Oct 25 17:06:45 2017
From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat)
Date: Wed, 25 Oct 2017 22:36:45 +0530
Subject: [openssl-dev] OpenSSL engine and TPM usage.
Message-ID: <CALq8RvLJVQtPhxtQuJzK5oWpb9w79u02FeW1ZoN636va6=F7NA@mail.gmail.com>

Hi All,

Our device uses TPM to protect certificate private keys. We have written
engine interface to integrate TPM functionality into OpenSSL. Thus TPM gets
loaded as an engine instance.
Also we have mapped RSA operations to TPM APIS as  like
encryption/decryption etc.

Now we are into few issues. there are few applications that wants to use
application specific identity certificate. In such cases RSA APIs should
not get mapped to TPM APIs.

I wanted to know when we use engine instance for encyrption/decryption
operation, can it be done selectively?

Regards
Jayalakshmi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171025/5f87191b/attachment.html>

From kurt at roeckx.be  Wed Oct 25 21:56:15 2017
From: kurt at roeckx.be (Kurt Roeckx)
Date: Wed, 25 Oct 2017 23:56:15 +0200
Subject: [openssl-dev] Systemwide configurability of OpenSSL
In-Reply-To: <76697227-3f38-bf98-3d64-a37b557a4584@redhat.com>
References: <1506524526.13888.1.camel@redhat.com>
 <20170927222102.O5IFn%steffen@sdaoden.eu>
 <76697227-3f38-bf98-3d64-a37b557a4584@redhat.com>
Message-ID: <20171025215614.hrnl7nxnkysilwdk@roeckx.be>

On Wed, Oct 25, 2017 at 05:19:23PM +0200, Tomas Mraz wrote:
> 
> The problem is that by default the applications do not read the file and
> do not apply the defaults. Even the openssl s_client/s_server does not
> seem to work, but I might be doing something wrong.
> 
> What I would like to see is applying the defaults unconditionally or
> maybe with some possibility to opt-out of it by application but not opt-in.
> 
> Can I please get at least some response from the openssl team? Should I
> open an issue on github for that feature?

I would like to see something like that happen.


Kurt


From levitte at openssl.org  Thu Oct 26 11:57:07 2017
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 26 Oct 2017 13:57:07 +0200 (CEST)
Subject: [openssl-dev] [openssl-users] OpenSSL engine and TPM usage.
In-Reply-To: <CALq8RvLJVQtPhxtQuJzK5oWpb9w79u02FeW1ZoN636va6=F7NA@mail.gmail.com>
References: <CALq8RvLJVQtPhxtQuJzK5oWpb9w79u02FeW1ZoN636va6=F7NA@mail.gmail.com>
Message-ID: <20171026.135707.1421528709764134535.levitte@openssl.org>

In message <CALq8RvLJVQtPhxtQuJzK5oWpb9w79u02FeW1ZoN636va6=F7NA at mail.gmail.com> on Wed, 25 Oct 2017 22:36:45 +0530, Jayalakshmi bhat <bhat.jayalakshmi at gmail.com> said:

bhat.jayalakshmi> Our device uses TPM to protect certificate private
bhat.jayalakshmi> keys. We have written engine interface to integrate
bhat.jayalakshmi> TPM functionality into OpenSSL. Thus TPM gets loaded
bhat.jayalakshmi> as an engine instance. Also we have mapped RSA
bhat.jayalakshmi> operations to TPM APIS as like encryption/decryption
bhat.jayalakshmi> etc.
bhat.jayalakshmi> 
bhat.jayalakshmi> Now we are into few issues. there are few
bhat.jayalakshmi> applications that wants to use application specific
bhat.jayalakshmi> identity certificate. In such cases RSA APIs should
bhat.jayalakshmi> not get mapped to TPM APIs.
bhat.jayalakshmi> 
bhat.jayalakshmi> I wanted to know when we use engine instance for
bhat.jayalakshmi> encyrption/decryption operation, can it be done
bhat.jayalakshmi> selectively?

Yes, it should be possible.  However, this is up to the application,
not to your engine.  The engine simply offers methods, the application
chooses to use some or all of them as default algo implementations
through the diverse ENGINE_set_default* functions.

For keys such as RSA ones, you can simply create the resulting fetched
key with RSA_new_method(e), where |e| is your TPM engine, and your
engine's RSA method will be attached to that key rather than the
default.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From James.Bottomley at HansenPartnership.com  Thu Oct 26 16:07:01 2017
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Thu, 26 Oct 2017 18:07:01 +0200
Subject: [openssl-dev] [openssl-users] OpenSSL engine and TPM usage.
In-Reply-To: <20171026.135707.1421528709764134535.levitte@openssl.org>
References: <CALq8RvLJVQtPhxtQuJzK5oWpb9w79u02FeW1ZoN636va6=F7NA@mail.gmail.com>
 <20171026.135707.1421528709764134535.levitte@openssl.org>
Message-ID: <1509034021.3170.3.camel@HansenPartnership.com>

On Thu, 2017-10-26 at 13:57 +0200, Richard Levitte wrote:
> In message <CALq8RvLJVQtPhxtQuJzK5oWpb9w79u02FeW1ZoN636va6=F7NA at mail.
> gmail.com> on Wed, 25 Oct 2017 22:36:45 +0530, Jayalakshmi bhat <bhat
> .jayalakshmi at gmail.com> said:
> 
> bhat.jayalakshmi> Our device uses TPM to protect certificate private
> bhat.jayalakshmi> keys. We have written engine interface to integrate
> bhat.jayalakshmi> TPM functionality into OpenSSL. Thus TPM gets
> loaded
> bhat.jayalakshmi> as an engine instance. Also we have mapped RSA
> bhat.jayalakshmi> operations to TPM APIS as like
> encryption/decryption
> bhat.jayalakshmi> etc.
> bhat.jayalakshmi>?
> bhat.jayalakshmi> Now we are into few issues. there are few
> bhat.jayalakshmi> applications that wants to use application specific
> bhat.jayalakshmi> identity certificate. In such cases RSA APIs should
> bhat.jayalakshmi> not get mapped to TPM APIs.
> bhat.jayalakshmi>?
> bhat.jayalakshmi> I wanted to know when we use engine instance for
> bhat.jayalakshmi> encyrption/decryption operation, can it be done
> bhat.jayalakshmi> selectively?
> 
> Yes, it should be possible.??However, this is up to the application,
> not to your engine.??The engine simply offers methods, the
> application
> chooses to use some or all of them as default algo implementations
> through the diverse ENGINE_set_default* functions.
> 
> For keys such as RSA ones, you can simply create the resulting
> fetched
> key with RSA_new_method(e), where |e| is your TPM engine, and your
> engine's RSA method will be attached to that key rather than the
> default.

Unless you have a Firmware TPM, you really don't want to override the
default methods, all you want to do is load and engine based key and
override only specific key methods which are useful. ?The reason is the
TPM is really slow, so you want the native system to do all the crypto
operations it can rather than routing them through the TPM. ?So, for
instance, if you look at the elliptic curve overrides for the tpm2
engine,

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/

all it does is change the EC_KEY methods for sign and nothing else (so
verify still uses non-TPM methods).

James


From freemonj at gmail.com  Thu Oct 26 20:37:15 2017
From: freemonj at gmail.com (Freemon Johnson)
Date: Thu, 26 Oct 2017 16:37:15 -0400
Subject: [openssl-dev] [openssl-users] OpenSSL engine and TPM usage.
In-Reply-To: <CALq8RvLJVQtPhxtQuJzK5oWpb9w79u02FeW1ZoN636va6=F7NA@mail.gmail.com>
References: <CALq8RvLJVQtPhxtQuJzK5oWpb9w79u02FeW1ZoN636va6=F7NA@mail.gmail.com>
Message-ID: <CALD4PSkC5TuwsCozNn9f7jYTUg7d+wdW2=70d+dCtFYFovf7tg@mail.gmail.com>

Hi Jayalakshmi,

Is your implementation OSS or intellectual property? If it is OSS can you
please provide the URL?

Regards,
Freemon

On Wed, Oct 25, 2017 at 1:06 PM, Jayalakshmi bhat <
bhat.jayalakshmi at gmail.com> wrote:

> Hi All,
>
> Our device uses TPM to protect certificate private keys. We have written
> engine interface to integrate TPM functionality into OpenSSL. Thus TPM gets
> loaded as an engine instance.
> Also we have mapped RSA operations to TPM APIS as  like
> encryption/decryption etc.
>
> Now we are into few issues. there are few applications that wants to use
> application specific identity certificate. In such cases RSA APIs should
> not get mapped to TPM APIs.
>
> I wanted to know when we use engine instance for encyrption/decryption
> operation, can it be done selectively?
>
> Regards
> Jayalakshmi
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171026/4a556a0b/attachment.html>

From matt at openssl.org  Mon Oct 30 13:50:45 2017
From: matt at openssl.org (Matt Caswell)
Date: Mon, 30 Oct 2017 13:50:45 +0000
Subject: [openssl-dev] Forthcoming OpenSSL releases
Message-ID: <d6d04097-d0bc-39c0-4756-ca2686544087@openssl.org>

Forthcoming OpenSSL releases
============================

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.1.0g and 1.0.2m.

These releases will be made available on 2nd November 2017 between
approximately 1300-1700 UTC.

This is a bug-fix release. It will also include a fix for the low
severity security issue previously published here:
https://www.openssl.org/news/secadv/20170828.txt

Please also note that, as per our previous announcements, support for
1.0.1 ended on 31st December 2016.

Yours

The OpenSSL Project Team

From matt at openssl.org  Mon Oct 30 23:06:27 2017
From: matt at openssl.org (Matt Caswell)
Date: Mon, 30 Oct 2017 23:06:27 +0000
Subject: [openssl-dev] Forthcoming OpenSSL releases
In-Reply-To: <d6d04097-d0bc-39c0-4756-ca2686544087@openssl.org>
References: <d6d04097-d0bc-39c0-4756-ca2686544087@openssl.org>
Message-ID: <71d5efbd-31fc-f4b0-91a7-38a95def2c6d@openssl.org>



On 30/10/17 13:50, Matt Caswell wrote:
> Forthcoming OpenSSL releases
> ============================
> 
> The OpenSSL project team would like to announce the forthcoming release
> of OpenSSL versions 1.1.0g and 1.0.2m.
> 
> These releases will be made available on 2nd November 2017 between
> approximately 1300-1700 UTC.
> 
> This is a bug-fix release. It will also include a fix for the low
> severity security issue previously published here:
> https://www.openssl.org/news/secadv/20170828.txt

Correction: It will additionally include a fix for a moderate level
security issue.

> 
> Please also note that, as per our previous announcements, support for
> 1.0.1 ended on 31st December 2016.
> 
> Yours
> 
> The OpenSSL Project Team
>