gnutls28 appears to allow 512bit RSA keys, when it shouldn't

[Dimitri John Ledkov]

To prevent lp bad formatting, please see the attached tarball.

The gist is that it appears that PROFILE_* settings are not applied correctly. By default it should require 1024bit RSA keys minimum

gnutls-serv command accepts and uses 512bit RSA certificate.
openssl s_server in comparison does not, due to key size too small.

operating openssl s_client against the gnutls-serv server, fails to connect again due to key size too small.

Yet gnutls-cli successfully connects to gnutls-serv with 512bit RSA key.

Attempting to override priority strings using SECURE256 or %PROFILE_HIGH and the like, does not make gnutls reject the small key size.

Tested on focal using gnutls28 3.6.10-5

[Dimitri John Ledkov (xnox)]

i really hope i am doing something wrong.

[Alex Murray (alexmurray)]

When you say 'By default it should require 1024bit RSA keys minimum' where is this defined?

[Dimitri John Ledkov (xnox)]

--with-default-priority-string is NORMAL when not specified, which is how we compile it.

That in turn means https://gnutls.org/manual/html_node/Priority-Strings.html#tab_003aprio_002dkeywords

6.10 Priority strings
Normal
Means all the known to be secure ciphersuites. The ciphers are sorted by security margin, although the 256-bit ciphers are included as a fallback only. The message authenticity security level is of 64 bits or more, and the certificate verification profile is set to GNUTLS_PROFILE_LOW (80-bits).
This priority string implicitly enables ECDHE and DHE. The ECDHE ciphersuites are placed first in the priority order, but due to compatibility issues with the DHE ciphersuites they are placed last in the priority order, after the plain RSA ciphersuites.

6.11 Selecting cryptographic key sizes
GNUTLS_PROFILE_LOW is defined in a different table https://gnutls.org/manual/html_node/Selecting-cryptographic-key-sizes.html#tab_003akey_002dsizes

Which states 1024bit keys for RSA for LOW aka equivalent of 80bits of security.

In the code it is in ./lib/priority.c
const char *_gnutls_default_priority_string = DEFAULT_PRIORITY_STRING;

        {.name = LEVEL_NORMAL,
         .cipher_list = &cipher_priority_normal,
         .mac_list = &mac_priority_normal,
         .kx_list = &kx_priority_secure,
         .sign_list = &sign_priority_default,
         .group_list = &supported_groups_normal,
         .profile = GNUTLS_PROFILE_LOW,
         .sec_param = GNUTLS_SEC_PARAM_WEAK
        },

Not quite sure the difference between PROFILE_LOW and SEC_PARAM_WEAK as normally PROFILE_LOW profile enables SEC_PARAM_LOW... and i think it should set level on gnutls_priority_t....

The actual sec parameters are in lib/algorithms/secparams.c and sort of look like Weak and Low have 1008 and 1024 set for pk_bits respectively.

[Dimitri John Ledkov (xnox)]

Unless that's not the parameters i'm looking for.

From server messages:

- Ephemeral EC Diffie-Hellman parameters
 - Using curve: SECP256R1
 - Curve size: 256 bits
- Version: TLS1.3
- Server Signature: RSA-PSS-RSAE-SHA256
- Cipher: AES-256-GCM

These are all strong ciphers / EC DH parameters etc. But all of that is pointless if the cert itself is 512 RSA.... Maybe the cert's key sizes are not vetted at all?!

[Alex Murray (alexmurray)]

xnox> Maybe the cert's key sizes are not vetted at all?!

I think this is likely the case - I have also reproduced this on a current debian stable install with gnutls 3.6.7-4 - am keen to see how it behaves on say Fedora as well - I am wondering if this is just how gnutls is...

[Alex Murray (alexmurray)]

I can also reproduce it on Fedora 31 with gnutls-utils-3.6.11-1.fc31.x86_64 so this sounds like 'expected' upstream behaviour - I suggest filing a bug upstream to enquire about whether this is actually intended.

[Dimitri John Ledkov (xnox)]

Ok, will do so.

[Dimitri John Ledkov (xnox)]

Opened confidential issue https://gitlab.com/gnutls/gnutls/issues/877

[Dimitri John Ledkov (xnox)]

So, gnutls has different validation based on whether or not something is a CA or not.

Any self-signed certificate that is trusted, is always accepted. Irrespective of how strong or weak it is.

A weak certificate in a chain, even if trusted, gets rejected.

I.e. created 4k CA + 512bit Cert, or 512bit CA + 4k Cert, or 512bit CA + 512bit Cert => they all get rejected by the client-only.

server always starts.

Discussing if these minor bugs should be fixed.

Given that if somebody managed to sneak in a 512 self signed cert into the trust store, they may as well sneak in a strong one as well.

[Dimitri John Ledkov (xnox)]

There is flag which will reject all self-signed certs - GNUTLS_VERIFY_DO_NOT_ALLOW_SAME

Which is a bit a harsh, as ideally i want to only reject weak self-signed certs.

[Dimitri John Ledkov (xnox)]

https://gitlab.com/gnutls/gnutls/issues/877 is now public. Basically direct certs in the trust store are trusted without minimum security verification. I.e. self-signed system trusted cert connecting to a host using that self-signed cert, without any CA chain.

https://gitlab.com/gnutls/gnutls/issues/877 server code upon loading the server cert/key does not validate that cert/keys meet minimum security requirement, thus it relies on the clients to reject weak servers upon connection.

[Dimitri John Ledkov (xnox)]

The second url was meant to be https://gitlab.com/gnutls/gnutls/issues/881