OpenBSD 6.7 errata 004 6.7/004_libssl.patch.siglibressl-v3.1.2

original commits:

CVSROOT:        /cvs
Module name:    src
Changes by:     jsing@cvs.openbsd.org   2020/05/16 08:44:55

Modified files:
        lib/libssl     : tls13_client.c

Log message:
Ensure that a TLSv1.3 server has provided a certificate.

The RFC requires that a server always provide a certificate for
authentication. Ensure that this is the case, rather than proceeding and
attempting validation. In the case where validation was disabled and the
server returned an empty certificate list, this would have previously
resulted in a NULL pointer deference.

Issue reported by otto@

ok inoguchi@ tb@

CVSROOT:        /cvs
Module name:    src
Changes by:     jsing@cvs.openbsd.org   2020/05/17 08:26:15

Modified files:
        lib/libssl     : tls13_client.c

Log message:
Send a decode error alert if a server provides an empty certificate list.

According to RFC 8446 section 4.4.2.4, a client receiving an empty
certificate list must abort the handshake with a decode error alert.

ok beck@ inoguchi@ tb@ ('it rarely is the alert you'd expect it to be...')

1 files changed, 9 insertions, 1 deletions

diff --git a/src/lib/libssl/tls13_client.c b/src/lib/libssl/tls13_client.c
index 79318d9313..24286569b1 100644
--- a/src/lib/libssl/tls13_client.c
+++ b/src/lib/libssl/tls13_client.c
@@ -1,4 +1,4 @@
-/* $OpenBSD: tls13_client.c,v 1.54 2020/04/28 20:37:22 jsing Exp $ */
+/* $OpenBSD: tls13_client.c,v 1.54.4.1 2020/05/19 20:22:33 tb Exp $ */
 /*
  * Copyright (c) 2018, 2019 Joel Sing <jsing@openbsd.org>
  *
@@ -587,6 +587,14 @@ tls13_server_certificate_recv(struct tls13_ctx *ctx, CBS *cbs)
                 cert = NULL;
         }
 
+        /* A server must always provide a non-empty certificate list. */
+        if (sk_X509_num(certs) < 1) {
+                ctx->alert = SSL_AD_DECODE_ERROR;
+                tls13_set_errorx(ctx, TLS13_ERR_NO_PEER_CERTIFICATE, 0,
+                    "peer failed to provide a certificate", NULL);
+                goto err;
+        }
+
         /*
          * At this stage we still have no proof of possession. As such, it would
          * be preferable to keep the chain and verify once we have successfully