summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorjsing <>2020-05-16 14:44:55 +0000
committerjsing <>2020-05-16 14:44:55 +0000
commit05b86acd86a3e9f27019baf407fa6cc21987115c (patch)
treedeaa6e5465c23ac8df9e8a0e2afe3ddc37ec8360
parent2e6606d801cdc2d2ca745d14827a8171b3a12b17 (diff)
downloadopenbsd-05b86acd86a3e9f27019baf407fa6cc21987115c.tar.gz
openbsd-05b86acd86a3e9f27019baf407fa6cc21987115c.tar.bz2
openbsd-05b86acd86a3e9f27019baf407fa6cc21987115c.zip
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@
-rw-r--r--src/lib/libssl/tls13_client.c10
1 files changed, 9 insertions, 1 deletions
diff --git a/src/lib/libssl/tls13_client.c b/src/lib/libssl/tls13_client.c
index dbd5b0add7..d3a68528bc 100644
--- a/src/lib/libssl/tls13_client.c
+++ b/src/lib/libssl/tls13_client.c
@@ -1,4 +1,4 @@
1/* $OpenBSD: tls13_client.c,v 1.59 2020/05/13 17:51:48 jsing Exp $ */ 1/* $OpenBSD: tls13_client.c,v 1.60 2020/05/16 14:44:55 jsing Exp $ */
2/* 2/*
3 * Copyright (c) 2018, 2019 Joel Sing <jsing@openbsd.org> 3 * Copyright (c) 2018, 2019 Joel Sing <jsing@openbsd.org>
4 * 4 *
@@ -595,6 +595,14 @@ tls13_server_certificate_recv(struct tls13_ctx *ctx, CBS *cbs)
595 cert = NULL; 595 cert = NULL;
596 } 596 }
597 597
598 /* A server must always provide a non-empty certificate list. */
599 if (sk_X509_num(certs) < 1) {
600 ctx->alert = TLS13_ALERT_ILLEGAL_PARAMETER;
601 tls13_set_errorx(ctx, TLS13_ERR_NO_PEER_CERTIFICATE, 0,
602 "peer failed to provide a certificate", NULL);
603 goto err;
604 }
605
598 /* 606 /*
599 * At this stage we still have no proof of possession. As such, it would 607 * At this stage we still have no proof of possession. As such, it would
600 * be preferable to keep the chain and verify once we have successfully 608 * be preferable to keep the chain and verify once we have successfully