Errors in config file values get swallowed, disable other directives

[t184256]

OpenSSL master (c809334, ./config no-shared).

I'm gonna define the following config
for use with OPENSSL_CONF=openssl.cnf apps/openssl s_client ecc256.badssl.com:443
and vary just the last two lines for brewity.

config_diagnostics = 1
openssl_conf = openssl_init

[openssl_init]
providers = provider_sect
ssl_conf = ssl_module

[provider_sect]

[ssl_module]
system_default = policy

[policy]
SignatureAlgorithms = ECDSA+SHA256
#Groups = P-521

That allows me to establish a TLS 1.2 connection using ECDSA-SHA256 and prime256v1.

Uncommenting Groups:

SignatureAlgorithms = ECDSA+SHA256
Groups = P-521

leads to SSL alert number 40, which I'm OK with.

Now let's add an unrecognized value to Groups:

SignatureAlgorithms = ECDSA+SHA256
Groups = P-521:nonex

That results in a successful connection like in a baseline case,
so I'm assuming Groups reverts to whatever default it has.

What's worse, is that this effect works across lines:

SignatureAlgorithms = ECDSA+SHA256:nonex
Groups = P-521

also results in a successful connection, as if Groups is ignored!

Finally, switching the order of the directives

Groups = P-521
SignatureAlgorithms = ECDSA+SHA256:nonex

makes the masking effect go away (connection fails),
so I assume it's the rest of the config (section?) that gets ignored
after encountering one invalid value.

I'm aware of config_diagnostics = 1, but it doesn't seem to help here.

Please consider failing hard on encountering an invalid/unrecognized value.
Not only the current behaviour is painfully error prone,
(Groups = P-384:P-512 is the same as Groups = P-384,P-521)
but also the scope of the resulting misconfiguration is much wider than my wildest imagination
(they both effectively mean "ignore this and following lines", somehow).
As a result, it becomes very hard to configure the algorithm selection in a robust and secure manner.

[mattcaswell]

What's worse, is that this effect works across lines:

It should not have an impact across lines

SignatureAlgorithms = ECDSA+SHA256:nonex

My assumption is that the default sigalgs are being used and some non-ec based cipher suite is negotiated meaning that the "Groups" config value is not relevant.

[t184256]

My assumption is that the default sigalgs are being used and some non-ec based cipher suite is negotiated meaning that the "Groups" config value is not relevant.

That'd be great, but the last example (reordering of lines changing the outcome) seems to refute it.

[mattcaswell]

That'd be great, but the last example (reordering of lines changing the outcome) seems to refute it.

Hmm. Good point. That does seem odd. There shouldn't be any across line effects...requires further investigation as to what is happening here.

[t8m]

IMO the right thing would be to behave similarly to ciphers parsing, i.e. ignore unknown groups or sigalgs.

So

Groups = P-521:nonex

and

Groups = P-521

should behave the same.

[beldmit]

Or emit warning/error in strict mode.