[gnutls-devel] GnuTLS | keyEncipherment-only RSA keys are used with TLS 1.3 (#690)

[Development of GNU's TLS library]

New Issue was created.

Issue 690: https://gitlab.com/gnutls/gnutls/issues/690
Author:    David Benjamin
Assignee:  

## Description of problem:
GnuTLS appears to have logic to look at the key usage bits and filter the cipher suite in TLS 1.2, but it doesn't do the same in TLS 1.3, where the only operations are sign-only.

The result is that callers who accidentally created an encryption-only RSA key silently (though not ideally since it uses a plain RSA cipher) worked at TLS 1.2, but, once upgrading to a newer GnuTLS, break at TLS 1.3.

See also: https://github.com/apple/cups/issues/5506

## Version of gnutls used:
master branch

## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL)
built from source

## How reproducible:

Steps to Reproduce:

 * Save the following as `enc-only-cert.pem`:
```
-----BEGIN CERTIFICATE-----
MIICzzCCAbegAwIBAgIRALllB5+ixBXbLJKkHn9ofl4wDQYJKoZIhvcNAQELBQAw
EjEQMA4GA1UEChMHQWNtZSBDbzAeFw0xOTAyMDEyMjAwMDNaFw0xOTAyMDEyMjAw
MDNaMBIxEDAOBgNVBAoTB0FjbWUgQ28wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQC6C9qEGRIBQXV8Lj29vVu+U+tyXzSSinWIumK5ijPhCm3DLnv4Rayx
kFwemtnkGRZ/o94ZnsXkBfU/IlsYdkuq8wK9WI/ql3gwWjH+KARIhIQcSLGiJcLN
6kGuG2nlRBKMcPgPiEq2B0yBXFf4tG3CBbeae7+8G7uvOmv8NLyKj32neWpnUCTL
5o2VwyPoxjLxT5gUR69v9XSVFj2irCZbsEedeKSb++LqyMhLfnRTzNv+ZHNh4izZ
HrktR25MvnT5QyBq32hx7AjZ2/xo70OmH7w10a2DwsVjJNMdxTEmgyvU9M6CeYRP
X1Ykfg+sXCTtkTVAlBDUviIqY95CKy25AgMBAAGjIDAeMA4GA1UdDwEB/wQEAwIF
IDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBCwUAA4IBAQBfCc01lNWc68F9qHzt
OZFquAps5KXiZXeXhHcYi7Xwk7AUwmX1LhDGkrZih6fPbM7uNXHqNKTEQwj8SDoo
PFZ1EN3nbgjE7gV451xOcCeS+kW7poCeU7JWmdKgt4iL1SMJMjXtBIKbsp91YKLs
HOUE6jYtLDyZ/Qk+kZBW8YbLIly937oott7yr7nXMWPNpOgiECAmSHUvzB1fSSuJ
Mw4lx3sgVwxjCaQExKocKokFKB6oooO8DMmc9VD6MNOMY1Pv9Mrutb3KsmymjLdW
RjNl0DVpWZxgWoJMAXOkowlwlEh+CCEXeVXGs/tD5Amtacg9M/b3pIONmciojCrx
DvYB
-----END CERTIFICATE-----
```

 * Save the following as `enc-only-key.pem`.
```
-----BEGIN PRIVATE KEY-----
MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQC6C9qEGRIBQXV8
Lj29vVu+U+tyXzSSinWIumK5ijPhCm3DLnv4RayxkFwemtnkGRZ/o94ZnsXkBfU/
IlsYdkuq8wK9WI/ql3gwWjH+KARIhIQcSLGiJcLN6kGuG2nlRBKMcPgPiEq2B0yB
XFf4tG3CBbeae7+8G7uvOmv8NLyKj32neWpnUCTL5o2VwyPoxjLxT5gUR69v9XSV
Fj2irCZbsEedeKSb++LqyMhLfnRTzNv+ZHNh4izZHrktR25MvnT5QyBq32hx7AjZ
2/xo70OmH7w10a2DwsVjJNMdxTEmgyvU9M6CeYRPX1Ykfg+sXCTtkTVAlBDUviIq
Y95CKy25AgMBAAECggEAHPvvxRiqx2tNRFVn5QF1I4erbJwMcrADc5OmAcXYIz0e
sIOzaJBiQR9+Wn5BZ9nIuYXr+g3UQpvzAyz1CDCVxUIqsRj1AtUqMk4675+IW0vZ
0RY6Jkq/uJjANsGqk78xLJQE8VaIXSdx8c1THznsx4dgfT6+Ni4T5U6yuA33OZaw
4NdYZYtEkqNiqK6VYe4mAxxVh5qscihVVMGkBVqJNiiEotctm1lph8ow+7o8ggXO
W9xm+RHHPcH7Epx7hjkb/helANcYOK950W5/R+2zWV9R6kxo6R+/hfGFFmCvl4k5
+i8Y0IlEv3fze1E0Lwyf379i3C/cKcuaE5gwR54BAQKBgQDxlsNy9M37HgguglHt
8W+cuPNtxNjFCWIjNR9dSvdr1Oi28Z1AY+BBPSv6UBKnT5PpOFjqxfMY/j/zoKdI
aYX1phgeQHXcHrB1pS8yoaF/pTJSN2Yb8v9kl/Ch1yeYXaNVGmeBLkH9H6wIcUxD
Mas1i8VUzshzhcluCNGoJj9wUQKBgQDFJOoWncssfWCrsuDWEoeU71Zh3+bD96GF
s29CdIbHpcbxhWYjA9RM8yxbGPopexzoGcV1HX6j8E1s0xfYZJV23rxoM9Zj9l5D
mZAJQPxYXIdu3h4PslhZLd3p+DEHjbsLC/avk3M4iZim1FMPBJMswKSL23ysqXoY
/ynor+W06QKBgHYeu6M6NHgCYAe1ai+Hq4WaHFNgOohkJRqHv7USkVSkvb+s9LDl
5GChcx4pBmXNj8ko5rirXkerEEOjGgdaqMfJlOM9qyKb0rVCtYfw5RCPCcKPGZqy
vdJGQ74tf0uNBO34QgE0R8lmMevS0XHNGCPPGgV0MSfikvD82N15De1xAoGAbsZM
RsMJfAlDPZc4oPEuf/BwMHTYPTsy5map2MSTSzGKdQHJH1myfD6TqOiDALXtyzlX
63PUShfn2YNPvcbe+Tk00rR1/htcYk2yUpDSenAbpZ9ncth6rjmInURZgG4SMKXb
SlLnBljCjtN1jFW8wQPKMc/14SslsVAHY3ka8KkCgYB58QNT1YfH3jS62+mT2pXq
qLjLqvsD742VYnFoHR+HBOnN8ry0dda4lgwM106L5FgSg9DOZvASZ+QGFk+QVQv+
c77ASWpuhmBmamZCrwZXrq9Xc92RDPkKFqnP9MVv06hYKNp0moSdM8dIaM6uSows
/r/aDs4oudubz26o5GDKmA==
-----END PRIVATE KEY-----
```
 * `gnutls-serv -p 4433 -a --x509certfile enc-only-cert.pem --x509keyfile enc-only-key.pem`
 * Build BoringSSL from source. Then run the command-line testing tool:
 * `bssl client -connect localhost:4433 -max-version tls1.3`
 * `bssl client -connect localhost:4433 -max-version tls1.2`

## Actual results:
The first `bssl` run fails with `KEY_USAGE_BIT_INCORRECT`.
The second `bssl` run succeeds but negotiates `TLS_RSA_WITH_AES_128_GCM_SHA256`

## Expected results:
It's unclear how feasible this is or how well it fits with the rest of what GnuTLS does, but given that you all already filter the cipher list based on key usage (otherwise presumably `gnutls-serv` would have negotiated ECDHE_RSA), it seemed odd that you don't also take it into consideration for TLS 1.3. Then again, versions are usually negotiated fairly early, so you may consider it a WontFix. Anyway, I thought I would bring this up in case you wished to do anything about it.

A footnote: BoringSSL doesn't currently enforce the key usage extension at TLS 1.2 yet, though we're [working on changing that](https://crbug.com/795089). We do enforce it at TLS 1.3 as there were no risks with antivirus and bad Enterprise deployments. Though that's moot here since GnuTLS's behavior at TLS 1.2 *does* satisfy the key usage extension.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/690
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20190201/d80990b0/attachment-0001.html>