Confirm that we correctly fail if supported_versions is missing from an
HRR.
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25068)
Reviewed-by: Neil Horman <nhorman@openssl.org>
Release: yes
(cherry picked from commit 0ce7d1f355)
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24034)
In the case of no-ecx test 3 in test_tls13hrr was failing because it was
setting the server side support groups to on P-256 in order to induce an
HRR. However with no-ecx the client insteads issues an initial key share
using P-256 anyway and so an HRR is not used. We swap to use P-384 instead.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/21372)
Otherwise this testcase won't work with no-ecx.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/21333)
Test that if the client sends a key share for a group in the server's
supported_group list but is otherwise invalid, that we don't select it
in the HRR.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21163)
This can effectively reduce the binary size for platforms
that don't need ECX feature(~100KB).
Signed-off-by: Yi Li <yi1.li@intel.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20781)
The removed override was: OPENSSL_ia32cap=~0x200000200000000
which disables AESNI codepaths and PCLMULQDQ (useful for ghash).
It is unclear why this was done, but it probably just hides bugs.
[extended tests]
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16693)
Even if EC and DH are disabled then we may still be able to use TLSv1.3
if we have groups that have been plugged in by an external provider.
Fixes#13767
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13916)
Now that we have TLSv1.3 FFDHE support there is no reason why we should
not allow TLSv1.3 to be used in a no-ec build. This commit enables that
to happen.
It also fixes no-ec which was previously broken.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9156)
With the current mechanism, old cipher strings that used to work in 1.1.0,
may inadvertently disable all TLSv1.3 ciphersuites causing connections to
fail. This is confusing for users.
In reality TLSv1.3 are quite different to older ciphers. They are much
simpler and there are only a small number of them so, arguably, they don't
need the same level of control that the older ciphers have.
This change splits the configuration of TLSv1.3 ciphers from older ones.
By default the TLSv1.3 ciphers are on, so you cannot inadvertently disable
them through your existing config.
Fixes#5359
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5392)
Check that we handle changes of ciphersuite between HRR and ServerHello
correctly.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2895)
