TLS version

[shiva kumar]

Hi,
can anyone please tell, how to check the list of tls versions supported in
openssl build ( version 1.1.1)?

-- 
*With Best Regards*
*Shivakumar S*

Re: aes_cbc_hmac_sha1 implementation

[Matt Caswell]

On 27/02/2020 18:30, Phani 2004 wrote:
> Thanks for the reply.
> 
> In ssl_get_evp_cipher api when etm flag is enabled the
> aesni_cbc_hmac_sha1_cipher is not used. In this cipher only it
> implements mte. This part is not clear to me? Support I implement one
> cipher func which needs to handle both etm as well as mte, at the cipher
> api level how do I know if we have etm extension enabled or not.

At the engine level all it knows about are ciphers and hashes. Engines
know nothing about TLS ciphersuites or TLS extensions. Your engine will
not know whether etm or mte is in use. libssl makes the decision about
what cipher it is going to ask the engine for based on what has been
negotiated.

If mte is in use then it will first look to see if it has an
implementation of "AES-128-CBC-HMAC-SHA1" (of which
aesni_cbc_hmac_sha1_cipher is the built-in implementation).

If that is not available it will look for individual implementations of
"AES-128" and "SHA1".

If etm is in use it will just look for individual implementations of
"AES-128" and "SHA1".

Matt



> 
> Regards
> Phani
> 
> On Wed, 26 Feb, 2020, 6:03 PM Hubert Kario,  > wrote:
> 
> On Wednesday, 26 February 2020 08:59:01 CET, Phani 2004 wrote:
> > Thanks for the quick response Matt.
> >
> > My command was :
> > openssl s_client -connect 10.29.20.26 -cipher ECDHE-RSA-AES128-SHA
> -tls1_2.
> > I did not realise that "2" was not copied.
> >
> > I am trying to implement combined algo support on our engine.
> > I am using the openssl s_server and s_client apps to validate my
> > implementation.
> > The combined algo that i am looking to implement is AES128/256 and
> SHA1.
> > Its clear that i should always use tls version less than 1.3
> otherwise GCM
> > ciphers are used.
> >
> > What cipher suites can i use to validate the above combination of
> combined
> > algo?
> 
> OpenSSL internally treats key exchange and symmetric cipher
> separately, so
> all "*AES128-SHA" ciphers use the same cipher backend
> 
> you should also test AES256-SHA, AES128-SHA256, AES256-SHA256 and
> AES256-SHA384
> 
> > Which tls versions support which cipher suites?
> 
> *-SHA1 and *MD5 is supported by everything between SSL3 and TLS 1.2
> *-SHA256 and *-SHA384 (if they are not TLS1.3 cipher suites) are
> supported
> by TLS 1.2 only
> 
> > Should i be doing "encrypt-then-mac" or "mac-then-encrypt" in my
> > implementation?
> > Does the cipher suite decide this?
> > If yes, what are the ciphers which do "encrypt-then-mac" and what
> ciphers
> > to "mac-then-encrypt"?
> 
> etm vs mte happens based on negotiated extension, not cipher suite
> 
> -- 
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com 
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
> 

Re: OpenSSL 3.0

[Matt Caswell]

On 27/02/2020 20:37, Jason Schultz wrote:
> Thanks for all of the responses. This question has led to other related
> topics, so I have another one. According to this blog:
> 
> https://keypair.us/2019/12/rip-fips-186-2/
> 
> The OpenSSL FIPS Object Module will be moved to the CMVP historical list
> as of 9/1/2020. Since there is no OpenSSL 3.0 until Q4 2020, and a FIPS
> Module will be after that sometime, where does this leave 1.0.2 users
> who need a FIPS validated object module past that date? 

Going to the historic list will not impact existing deployments at all.
If you already have the old module deployed you can continue to use it,
even if it is on the historic list as I understand it.

You will not be able to make *new* deployments if it goes historic.

The problem is with FIPS 186-2 RSA Key gen. Modules now need to be FIPS
186-4 compliant. But the OpenSSL FIPS Object Module 2.0 is not 186-4 and
will not updated to be so. One option is to update the validation to
remove RSA as an approved algorithm (this can be done as a purely
paperwork exercise). But doing that has implications for existing
deployments. The OMC discussed this some months ago but decided not to
take any action at that time. I'm sure it will be discussed again next
time we have a f2f.

Matt



> 
> 
> 
> 
> *From:* openssl-users  on behalf of
> Salz, Rich via openssl-users 
> *Sent:* Thursday, February 27, 2020 1:31 PM
> *To:* Matt Caswell ; openssl-users@openssl.org
> 
> *Subject:* Re: OpenSSL 3.0
>  
> 
>>    It would probably be a good idea for us to pull together a "Getting
>     Started" guide on the Wiki with some basic information on how to get
>     things going, with some links to the various man pages etc where more
>     detailed information is required.
>  
> This needs to be real user documentation as part of the FIPS
> deliverable, right?
> 

Re: Support FFDHE?

[Salz, Rich via openssl-users]

>Per section Supported Groups in RFC 8446 [1], FFDHE groups could be supported.

I was wrong, sorry for the distraction.

As others have pointed out, it will be in the next (3.0) release.

Re: Support FFDHE?

[John Jiang]

On Thu, Feb 27, 2020 at 9:27 PM Salz, Rich  wrote:

>
>- Run the command: openssl s_client -tls1_3 -groups ffdhe2048 host:port
>
>
>
> TLS 1.3 doesn’t have those groups.
>
Per section Supported Groups in RFC 8446 [1], FFDHE groups could be
supported.
enum {

/* Elliptic Curve Groups (ECDHE) */
secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
x25519(0x001D), x448(0x001E),

/* Finite Field Groups (DHE) */
ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
ffdhe6144(0x0103), ffdhe8192(0x0104),

/* Reserved Code Points */
ffdhe_private_use(0x01FC..0x01FF),
ecdhe_private_use(0xFE00..0xFEFF),
(0x)
} NamedGroup;

[1] https://tools.ietf.org/html/rfc8446#section-4.2.7

>

Re: OpenSSL 3.0

[Walter Paley]

To clarify an important distinction - SafeLogic Extended Support for 1.0.2 
architecture will not keep the OpenSSL FOM validated past 9/1/2020. SafeLogic 
does offer a compatible drop-in replacement module that is validated, will 
remain validated past the 186-2 deprecation on 9/1/2020, and is available with 
RapidCert, an accelerated validation in your company’s name, but that is a 
separate offering.

- Walt



Walter Paley
w...@safelogic.com

> On Feb 27, 2020, at 12:59 PM, openssl-users-requ...@openssl.org wrote:
> 
> Send openssl-users mailing list submissions to
>openssl-users@openssl.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
>openssl-users-requ...@openssl.org
> 
> You can reach the person managing the list at
>openssl-users-ow...@openssl.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: OpenSSL 3.0 (Salz, Rich)
>   2. Re: OpenSSL 3.0 (Neptune)
>   3. Re: OpenSSL 3.0 (Salz, Rich)
>   4. Re: OpenSSL 3.0 (Jason Schultz)
> 
> 
> --
> 
> Message: 1
> Date: Thu, 27 Feb 2020 20:49:33 +
> From: "Salz, Rich" 
> To: Jason Schultz , "openssl-users@openssl.org"
>
> Subject: Re: OpenSSL 3.0
> Message-ID: <1e825139-40c4-4888-ab96-32fc423f0...@akamai.com>
> Content-Type: text/plain; charset="utf-8"
> 
>  *   The OpenSSL FIPS Object Module will be moved to the CMVP historical list 
> as of 9/1/2020. Since there is no OpenSSL 3.0 until Q4 2020, and a FIPS 
> Module will be after that sometime, where does this leave 1.0.2 users who 
> need a FIPS validated object module past that date?
> 
> Without their free lunch?
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://mta.openssl.org/pipermail/openssl-users/attachments/20200227/6e69ca80/attachment-0001.html>
> 
> --
> 
> Message: 2
> Date: Thu, 27 Feb 2020 13:56:10 -0700 (MST)
> From: Neptune 
> To: openssl-users@openssl.org
> Subject: Re: OpenSSL 3.0
> Message-ID: <1582836970178-0.p...@n7.nabble.com>
> Content-Type: text/plain; charset=us-ascii
> 
> You essentially have three choices:
> 1. Stay on the 1.0.2 branch to continue FIPS compliance, but go the entire
> year without support or security patches.
> 2. Pay OpenSSL for a premium support contract ($50,000 per year) to continue
> to receive patches on 1.0.2 for the remainder of the year.
> 3. Pay SafeLogic for support contract to receive 1.0.2 security patches
> through the year. Cost is roughly half what OpenSSL is asking, but you may
> be able to negotiate.
> 
> These are the only options of which I am aware.
> 
> 
> 
> 
> --
> Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
> 
> 
> --
> 
> Message: 3
> Date: Thu, 27 Feb 2020 20:58:10 +
> From: "Salz, Rich" 
> To: Jason Schultz , "openssl-users@openssl.org"
>
> Subject: Re: OpenSSL 3.0
> Message-ID: <3cfef9fc-d5e7-46d4-8d61-c485bf81e...@akamai.com>
> Content-Type: text/plain; charset="utf-8"
> 
>  *   That's fair. So the only option is to use another module? Extended 1.0.2 
> support does not resolve this either, correct?
> 
> I do not think that is the only option.  For example, you might be able to 
> use 3.0 and say it?s ?in evaluation.? There might be other options, that was 
> all I could think of while composing this email.
> 
> HOWEVER, note that the set of validated platforms for 3.0 is very different 
> from the current FOM.  Someone officially with the project will have to 
> provide details on that, not me.
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://mta.openssl.org/pipermail/openssl-users/attachments/20200227/985830ee/attachment-0001.html>
> 
> --
> 
> Message: 4
> Date: Thu, 27 Feb 2020 20:58:36 +
> From: Jason Schultz 
> To: "openssl-users@openssl.org" 
> Subject: Re: OpenSSL 3.0
> Message-ID:
>
> 
>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> For option 2, we have a support contract in place. But does this actually 
> help us as far as the FIPS Object Module?
> 
> 
> 
> From: openssl-users  on behalf of Neptune 
> 
> Sent: Thursday, February 27,

Re: OpenSSL 3.0

[Jason Schultz]

That's fair. So the only option is to use another module? Extended 1.0.2 
support does not resolve this either, correct?


From: Salz, Rich 
Sent: Thursday, February 27, 2020 8:49 PM
To: Jason Schultz ; openssl-users@openssl.org 

Subject: Re: OpenSSL 3.0


  *   The OpenSSL FIPS Object Module will be moved to the CMVP historical list 
as of 9/1/2020. Since there is no OpenSSL 3.0 until Q4 2020, and a FIPS Module 
will be after that sometime, where does this leave 1.0.2 users who need a FIPS 
validated object module past that date?



Without their free lunch?

Re: OpenSSL 3.0

[Salz, Rich via openssl-users]

None of those choices address what happens in the 1.0.2 module goes to historic 
on Sept 1.  See 
https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules
 for details.

Re: OpenSSL 3.0

[Jason Schultz]

For option 2, we have a support contract in place. But does this actually help 
us as far as the FIPS Object Module?



From: openssl-users  on behalf of Neptune 

Sent: Thursday, February 27, 2020 8:56 PM
To: openssl-users@openssl.org 
Subject: Re: OpenSSL 3.0

You essentially have three choices:
1. Stay on the 1.0.2 branch to continue FIPS compliance, but go the entire
year without support or security patches.
2. Pay OpenSSL for a premium support contract ($50,000 per year) to continue
to receive patches on 1.0.2 for the remainder of the year.
3. Pay SafeLogic for support contract to receive 1.0.2 security patches
through the year. Cost is roughly half what OpenSSL is asking, but you may
be able to negotiate.

These are the only options of which I am aware.




--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html

Re: OpenSSL 3.0

[Salz, Rich via openssl-users]

  *   That's fair. So the only option is to use another module? Extended 1.0.2 
support does not resolve this either, correct?

I do not think that is the only option.  For example, you might be able to use 
3.0 and say it’s “in evaluation.” There might be other options, that was all I 
could think of while composing this email.

HOWEVER, note that the set of validated platforms for 3.0 is very different 
from the current FOM.  Someone officially with the project will have to provide 
details on that, not me.

Re: OpenSSL 3.0

[Neptune]

You essentially have three choices:
1. Stay on the 1.0.2 branch to continue FIPS compliance, but go the entire
year without support or security patches.
2. Pay OpenSSL for a premium support contract ($50,000 per year) to continue
to receive patches on 1.0.2 for the remainder of the year.
3. Pay SafeLogic for support contract to receive 1.0.2 security patches
through the year. Cost is roughly half what OpenSSL is asking, but you may
be able to negotiate.

These are the only options of which I am aware.




--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html

Re: OpenSSL 3.0

[Salz, Rich via openssl-users]

  *   The OpenSSL FIPS Object Module will be moved to the CMVP historical list 
as of 9/1/2020. Since there is no OpenSSL 3.0 until Q4 2020, and a FIPS Module 
will be after that sometime, where does this leave 1.0.2 users who need a FIPS 
validated object module past that date?

Without their free lunch?

Re: OpenSSL 3.0

[Jason Schultz]

Thanks for all of the responses. This question has led to other related topics, 
so I have another one. According to this blog:

https://keypair.us/2019/12/rip-fips-186-2/

The OpenSSL FIPS Object Module will be moved to the CMVP historical list as of 
9/1/2020. Since there is no OpenSSL 3.0 until Q4 2020, and a FIPS Module will 
be after that sometime, where does this leave 1.0.2 users who need a FIPS 
validated object module past that date?




From: openssl-users  on behalf of Salz, Rich 
via openssl-users 
Sent: Thursday, February 27, 2020 1:31 PM
To: Matt Caswell ; openssl-users@openssl.org 

Subject: Re: OpenSSL 3.0


>It would probably be a good idea for us to pull together a "Getting
Started" guide on the Wiki with some basic information on how to get
things going, with some links to the various man pages etc where more
detailed information is required.

This needs to be real user documentation as part of the FIPS deliverable, right?

[RFC] TLS salt length auto detection, switch from DIGEST to AUTO

[Andersen, John S]

Hi All,

The TPM 2.0 PKCS11 project has been attempting to get the TPM working with
EAP-TLS WiFi.

We've run into an issue where the TPM spec specifies that for RSA PSS signing
keys, the random salt length will be the largest size allowed by the key size
and message digest size.

Server side, in SSL state machine the salt length gets set to
RSA_PSS_SALTLEN_DIGEST (aka -1) which means the salt length must equal the
hash length. Since the TPM used the largest size allowed by the key size and
message digest size, rather than digest size, the handshake fails.

The TSS and TPM TCG working groups will be working to modify this behavior, so
that the salt length equals the hash length. However, rolling out the update to
the spec and then firmware updates to TPMs will take a very long time. As such
we're wondering if OpenSSL would default to verifying with
RSA_PSS_SALTLEN_AUTO for RSA PSS keys instead of RSA_PSS_SALTLEN_DIGEST
as an intermediary measure.

This was my original stab at it which made it work, which of course isn't 
upstreamable.

diff --git a/crypto/rsa/rsa_pss.c b/crypto/rsa/rsa_pss.c
index f7c575d00a..26c9dcd078 100644
--- a/crypto/rsa/rsa_pss.c
+++ b/crypto/rsa/rsa_pss.c
@@ -50,6 +50,10 @@ int RSA_verify_PKCS1_PSS_mgf1(RSA *rsa, const unsigned char 
*mHash,
 hLen = EVP_MD_size(Hash);
 if (hLen < 0)
 goto err;
+
+dprintf(2, "openssl: sLen: %d\n", sLen);
+sLen = -2;
+
 /*-
  * Negative sLen has special meanings:
  *  -1  sLen == hLen



The following isn't hacky, but it doesn't work and I'm not yet sure why (still 
in the
process of debugging but wanted to float the idea on the list).



diff --git b/ssl/statem/statem_srvr.c a/ssl/statem/statem_srvr.c
index 8cf9c40d15..d6793e01a4 100644
--- b/ssl/statem/statem_srvr.c
+++ a/ssl/statem/statem_srvr.c
@@ -2783,7 +2783,7 @@ int tls_construct_server_key_exchange(SSL *s, WPACKET 
*pkt)
 }
 if (lu->sig == EVP_PKEY_RSA_PSS) {
 if (EVP_PKEY_CTX_set_rsa_padding(pctx, RSA_PKCS1_PSS_PADDING) <= 0
-|| EVP_PKEY_CTX_set_rsa_pss_saltlen(pctx, 
RSA_PSS_SALTLEN_DIGEST) <= 0) {
+|| EVP_PKEY_CTX_set_rsa_pss_saltlen(pctx, 
RSA_PSS_SALTLEN_AUTO) <= 0) {
 SSLfatal(s, SSL_AD_INTERNAL_ERROR,
  SSL_F_TLS_CONSTRUCT_SERVER_KEY_EXCHANGE,
 ERR_R_EVP_LIB);


Reference: 
https://github.com/tpm2-software/tpm2-pkcs11/pull/403#issuecomment-590395767


Thank you,
John

Re: aes_cbc_hmac_sha1 implementation

[Phani 2004]

Thanks for the reply.

In ssl_get_evp_cipher api when etm flag is enabled the
aesni_cbc_hmac_sha1_cipher is not used. In this cipher only it implements
mte. This part is not clear to me? Support I implement one cipher func
which needs to handle both etm as well as mte, at the cipher api level how
do I know if we have etm extension enabled or not.

Regards
Phani

On Wed, 26 Feb, 2020, 6:03 PM Hubert Kario,  wrote:

> On Wednesday, 26 February 2020 08:59:01 CET, Phani 2004 wrote:
> > Thanks for the quick response Matt.
> >
> > My command was :
> > openssl s_client -connect 10.29.20.26 -cipher ECDHE-RSA-AES128-SHA
> -tls1_2.
> > I did not realise that "2" was not copied.
> >
> > I am trying to implement combined algo support on our engine.
> > I am using the openssl s_server and s_client apps to validate my
> > implementation.
> > The combined algo that i am looking to implement is AES128/256 and SHA1.
> > Its clear that i should always use tls version less than 1.3 otherwise
> GCM
> > ciphers are used.
> >
> > What cipher suites can i use to validate the above combination of
> combined
> > algo?
>
> OpenSSL internally treats key exchange and symmetric cipher separately, so
> all "*AES128-SHA" ciphers use the same cipher backend
>
> you should also test AES256-SHA, AES128-SHA256, AES256-SHA256 and
> AES256-SHA384
>
> > Which tls versions support which cipher suites?
>
> *-SHA1 and *MD5 is supported by everything between SSL3 and TLS 1.2
> *-SHA256 and *-SHA384 (if they are not TLS1.3 cipher suites) are supported
> by TLS 1.2 only
>
> > Should i be doing "encrypt-then-mac" or "mac-then-encrypt" in my
> > implementation?
> > Does the cipher suite decide this?
> > If yes, what are the ciphers which do "encrypt-then-mac" and what ciphers
> > to "mac-then-encrypt"?
>
> etm vs mte happens based on negotiated extension, not cipher suite
>
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
>
>

Re: OpenSSL 3.0

[Salz, Rich via openssl-users]

>It would probably be a good idea for us to pull together a "Getting
Started" guide on the Wiki with some basic information on how to get
things going, with some links to the various man pages etc where more
detailed information is required.
  
This needs to be real user documentation as part of the FIPS deliverable, right?

Re: Support FFDHE?

[Salz, Rich via openssl-users]

  *   Run the command: openssl s_client -tls1_3 -groups ffdhe2048 host:port

TLS 1.3 doesn’t have those groups.

Re: Support FFDHE?

[Nicola Tuveri]

FFDHE arrived quite late so it missed the window for being included in the
1.1.1 release and won't be added to it in a patch release as it is a new
feature.

FFDHE support is available in master so it will be part of the upcoming 3.0
release and it is already possible to test it using a development build
from latest master.


Best regards,

Nicola Tuveri

On Thu, Feb 27, 2020, 10:15 John Jiang  wrote:

> I would have highlighted that OpenSSL 1.1.1d was being used in my testing.
>
> On Thu, Feb 27, 2020 at 5:13 PM John Jiang 
> wrote:
>
>> Hi,
>> It sounds FFDHE groups are already supported [1]
>> But the tools, like s_client, also support them.
>> Run the command: openssl s_client -tls1_3 -groups ffdhe2048 host:port
>> it just raised the issue: Error with command: "-groups ffdhe2048"
>> If using P-256 or X25519, it worked fine.
>>
>> I also tried option "-groups FFDHE2048". The same error raised again.
>>
>> [1] https://github.com/openssl/openssl/pull/8178
>>
>

Re: Support FFDHE?

[John Jiang]

I would have highlighted that OpenSSL 1.1.1d was being used in my testing.

On Thu, Feb 27, 2020 at 5:13 PM John Jiang  wrote:

> Hi,
> It sounds FFDHE groups are already supported [1]
> But the tools, like s_client, also support them.
> Run the command: openssl s_client -tls1_3 -groups ffdhe2048 host:port
> it just raised the issue: Error with command: "-groups ffdhe2048"
> If using P-256 or X25519, it worked fine.
>
> I also tried option "-groups FFDHE2048". The same error raised again.
>
> [1] https://github.com/openssl/openssl/pull/8178
>

Support FFDHE?

[John Jiang]

Hi,
It sounds FFDHE groups are already supported [1]
But the tools, like s_client, also support them.
Run the command: openssl s_client -tls1_3 -groups ffdhe2048 host:port
it just raised the issue: Error with command: "-groups ffdhe2048"
If using P-256 or X25519, it worked fine.

I also tried option "-groups FFDHE2048". The same error raised again.

[1] https://github.com/openssl/openssl/pull/8178