aes_cbc_hmac_sha1 implementation

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

aes_cbc_hmac_sha1 implementation

Phani 2004
Hi Team,

"aes_cbc_hmac_sha1" implementation is currently supported on x86 platforms only.
With which RFC is this compliant with?
This cipher is only used when the "encrypt then mac" option is disabled. Is this understanding correct. I am using openssl s_server and s_client is i use the below command on client side.

openssl s_client -connect 10.29.20.26 -cipher ECDHE-RSA-AES128-SHA -tls1_

Is this correct?
I have following queries:
  1. With which RFC is the current aes_cbc_hmac_sha1 implementation compliant with?
  2. It always does "mac then encrypt". Infact this cipher is invoked only when "encrypt then mac" flag is disabled. Is this correct?
  3. Is the cipher i used in above s_client command correct?
Thanks in advance.

Regards
Phani
Reply | Threaded
Open this post in threaded view
|

Re: aes_cbc_hmac_sha1 implementation

Matt Caswell-2


On 24/02/2020 13:04, Phani 2004 wrote:

> Hi Team,
>
> "aes_cbc_hmac_sha1" implementation is currently supported on x86
> platforms only.
> With which RFC is this compliant with?
> This cipher is only used when the "encrypt then mac" option is disabled.
> Is this understanding correct. I am using openssl s_server and s_client
> is i use the below command on client side.
>
> openssl s_client -connect 10.29.20.26 -cipher ECDHE-RSA-AES128-SHA -tls1_
>
> Is this correct?
> I have following queries:
>
>  1. With which RFC is the current aes_cbc_hmac_sha1 implementation
>     compliant with?

Its a cipher used by AES128 and HMAC-SHA1 based ciphersuites compliant
with TLSv1.2 (RFC5246) and earlier TLS protocol versions.

>  2. It always does "mac then encrypt". Infact this cipher is invoked
>     only when "encrypt then mac" flag is disabled. Is this correct?

Correct. We always try to do encrypt-then-mac by default so s_client
talking to s_server from the same OpenSSL version should never use this
ciphersuuite

>  3. Is the cipher i used in above s_client command correct?
>

openssl s_client -connect 10.29.20.26 -cipher ECDHE-RSA-AES128-SHA -tls1_

The "-tls_" on the end is incorrect - that's not a valid flag. Perhaps
you meant "-no_tls1_3" which would be fine. That's still not sufficient
to guarantee usage of the aes_cbc_hmac_sha1 cipher though because
Encrypt-then-mac will always be preferred.

I don't think there is a command line option to s_client to force that
off, although you can do it through a config file using the
"EncryptThenMac" option.

Matt


> Thanks in advance.
>
> Regards
> Phani
Reply | Threaded
Open this post in threaded view
|

Re: aes_cbc_hmac_sha1 implementation

Phani 2004
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?
Which tls versions support which cipher suites?
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"?

Thanks in advance.

Regards
Phani

On Tue, Feb 25, 2020 at 10:31 AM Matt Caswell <[hidden email]> wrote:


On 24/02/2020 13:04, Phani 2004 wrote:
> Hi Team,
>
> "aes_cbc_hmac_sha1" implementation is currently supported on x86
> platforms only.
> With which RFC is this compliant with?
> This cipher is only used when the "encrypt then mac" option is disabled.
> Is this understanding correct. I am using openssl s_server and s_client
> is i use the below command on client side.
>
> openssl s_client -connect 10.29.20.26 -cipher ECDHE-RSA-AES128-SHA -tls1_
>
> Is this correct?
> I have following queries:
>
>  1. With which RFC is the current aes_cbc_hmac_sha1 implementation
>     compliant with?

Its a cipher used by AES128 and HMAC-SHA1 based ciphersuites compliant
with TLSv1.2 (RFC5246) and earlier TLS protocol versions.

>  2. It always does "mac then encrypt". Infact this cipher is invoked
>     only when "encrypt then mac" flag is disabled. Is this correct?

Correct. We always try to do encrypt-then-mac by default so s_client
talking to s_server from the same OpenSSL version should never use this
ciphersuuite

>  3. Is the cipher i used in above s_client command correct?
>

openssl s_client -connect 10.29.20.26 -cipher ECDHE-RSA-AES128-SHA -tls1_

The "-tls_" on the end is incorrect - that's not a valid flag. Perhaps
you meant "-no_tls1_3" which would be fine. That's still not sufficient
to guarantee usage of the aes_cbc_hmac_sha1 cipher though because
Encrypt-then-mac will always be preferred.

I don't think there is a command line option to s_client to force that
off, although you can do it through a config file using the
"EncryptThenMac" option.

Matt


> Thanks in advance.
>
> Regards
> Phani
Reply | Threaded
Open this post in threaded view
|

Re: aes_cbc_hmac_sha1 implementation

Hubert Kario
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

Reply | Threaded
Open this post in threaded view
|

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, <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: aes_cbc_hmac_sha1 implementation

Matt Caswell-2


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, <[hidden email]
> <mailto:[hidden email]>> 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 <http://www.cz.redhat.com>
>     Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
>
Reply | Threaded
Open this post in threaded view
|

Re: aes_cbc_hmac_sha1 implementation

Phani 2004
OK. I understood that "AES-128-CBC-HMAC-SHA1"(aesni_cbc_hmac_sha1) always does mte.
I am trying to implement engine implementation of combined mode cipher aes_cbc_hmac_sha1.
So in my aes_cbc_hmac_sha1_cipher implementation should i do mte only?

If hardware engine can do both operations in a single request and save time. Also, say there is a flag which indicates whether its mte or etm.
How should my aes_cbc_hmac_sha1 implementation look like?
Should it do only mte always? Should i have two ciphers, one for etm and other for mte.
But how to i tell openssl to use this cipher for etm and other for mte without changing the openssl code.

One more query i have is, how do we pass the etm option to the openssl in conf file.

Regards
Phani

On Fri, Feb 28, 2020 at 8:53 AM Matt Caswell <[hidden email]> wrote:


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, <[hidden email]
> <mailto:[hidden email]>> 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 <http://www.cz.redhat.com>
>     Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
>
Reply | Threaded
Open this post in threaded view
|

Re: aes_cbc_hmac_sha1 implementation

Phani 2004
Hi Team,

Can anyone help me with the below queries.
Thanks in Advance.

Regards
Phani

On Fri, Feb 28, 2020 at 2:41 PM Phani 2004 <[hidden email]> wrote:
OK. I understood that "AES-128-CBC-HMAC-SHA1"(aesni_cbc_hmac_sha1) always does mte.
I am trying to implement engine implementation of combined mode cipher aes_cbc_hmac_sha1.
So in my aes_cbc_hmac_sha1_cipher implementation should i do mte only?

If hardware engine can do both operations in a single request and save time. Also, say there is a flag which indicates whether its mte or etm.
How should my aes_cbc_hmac_sha1 implementation look like?
Should it do only mte always? Should i have two ciphers, one for etm and other for mte.
But how to i tell openssl to use this cipher for etm and other for mte without changing the openssl code.

One more query i have is, how do we pass the etm option to the openssl in conf file.

Regards
Phani

On Fri, Feb 28, 2020 at 8:53 AM Matt Caswell <[hidden email]> wrote:


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, <[hidden email]
> <mailto:[hidden email]>> 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 <http://www.cz.redhat.com>
>     Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
>
Reply | Threaded
Open this post in threaded view
|

Re: aes_cbc_hmac_sha1 implementation

Matt Caswell-2
In reply to this post by Phani 2004


On 28/02/2020 09:11, Phani 2004 wrote:
> OK. I understood that "AES-128-CBC-HMAC-SHA1"(aesni_cbc_hmac_sha1)
> always does mte.
> I am trying to implement engine implementation of combined mode cipher
> aes_cbc_hmac_sha1.
> So in my aes_cbc_hmac_sha1_cipher implementation should i do mte only?

Yes.

> If hardware engine can do both operations in a single request and save
> time. Also, say there is a flag which indicates whether its mte or etm.
> How should my aes_cbc_hmac_sha1 implementation look like?

That cipher only does mte.

> Should it do only mte always? Should i have two ciphers, one for etm and
> other for mte.
> But how to i tell openssl to use this cipher for etm and other for mte
> without changing the openssl code.

If you want to support etm you have to implement aes-cbc and sha1
separately.

>
> One more query i have is, how do we pass the etm option to the openssl
> in conf file.

etm will be negotiated by default if it is available - there is no need
to configure this. You can disable etm using the "EncryptThenMac"
option, e.g.

Options = -EncryptThenMac

See:

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

Matt



>
> Regards
> Phani
>
> On Fri, Feb 28, 2020 at 8:53 AM Matt Caswell <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>
>     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, <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> 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 <http://www.cz.redhat.com>
>     <http://www.cz.redhat.com>
>     >     Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
>     >
>