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, <hkario@xxxxxxxxxx> 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
