summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorjsing <>2019-01-19 04:02:29 +0000
committerjsing <>2019-01-19 04:02:29 +0000
commitcb97f4527d54b35cc93596c8f1b490f8d328b598 (patch)
treefea5018f516ff6a2faceec1edac71422e5395a81
parent7307a8285d2bab3e12d69b620aba48a1554ea4f7 (diff)
downloadopenbsd-cb97f4527d54b35cc93596c8f1b490f8d328b598.tar.gz
openbsd-cb97f4527d54b35cc93596c8f1b490f8d328b598.tar.bz2
openbsd-cb97f4527d54b35cc93596c8f1b490f8d328b598.zip
Add handshake message type checking and special case certificate requests.
Check that the handshake message type received matches that required by the state machine. However, thanks to poor state design in the TLSv1.3 RFC, there is no way to know if you're going to receive a certificate request message or not, hence we have to special case it and teach the receive handler how to handle this situation. Discussed at length with beck@ and tb@ during the hackathon. ok tb@
-rw-r--r--src/lib/libssl/tls13_handshake.c31
1 files changed, 30 insertions, 1 deletions
diff --git a/src/lib/libssl/tls13_handshake.c b/src/lib/libssl/tls13_handshake.c
index b566ed2298..f322cbe39b 100644
--- a/src/lib/libssl/tls13_handshake.c
+++ b/src/lib/libssl/tls13_handshake.c
@@ -1,4 +1,4 @@
1/* $OpenBSD: tls13_handshake.c,v 1.9 2019/01/19 03:32:03 jsing Exp $ */ 1/* $OpenBSD: tls13_handshake.c,v 1.10 2019/01/19 04:02:29 jsing Exp $ */
2/* 2/*
3 * Copyright (c) 2018-2019 Theo Buehler <tb@openbsd.org> 3 * Copyright (c) 2018-2019 Theo Buehler <tb@openbsd.org>
4 * Copyright (c) 2019 Joel Sing <jsing@openbsd.org> 4 * Copyright (c) 2019 Joel Sing <jsing@openbsd.org>
@@ -351,6 +351,22 @@ int
351tls13_handshake_recv_action(struct tls13_ctx *ctx, 351tls13_handshake_recv_action(struct tls13_ctx *ctx,
352 struct tls13_handshake_action *action) 352 struct tls13_handshake_action *action)
353{ 353{
354 uint8_t msg_type;
355
356 msg_type = 0; /* XXX */
357
358 /*
359 * In TLSv1.3 there is no way to know if you're going to receive a
360 * certificate request message or not, hence we have to special case it
361 * here. The receive handler also knows how to deal with this situation.
362 */
363 if (msg_type != action->handshake_type &&
364 (msg_type != TLS13_MT_CERTIFICATE ||
365 action->handshake_type != TLS13_MT_CERTIFICATE_REQUEST)) {
366 /* XXX send unexpected message alert */
367 return TLS13_IO_FAILURE;
368 }
369
354 return action->recv(ctx); 370 return action->recv(ctx);
355} 371}
356 372
@@ -482,6 +498,19 @@ tls13_server_certificate_send(struct tls13_ctx *ctx)
482int 498int
483tls13_server_certificate_request_recv(struct tls13_ctx *ctx) 499tls13_server_certificate_request_recv(struct tls13_ctx *ctx)
484{ 500{
501 uint8_t msg_type = 0; /* XXX */
502
503 /*
504 * Thanks to poor state design in the RFC, this function can be called
505 * when we actually have a certificate message instead of a certificate
506 * request... in that case we call the certificate handler after
507 * switching state, to avoid advancing state.
508 */
509 if (msg_type == TLS13_MT_CERTIFICATE) {
510 ctx->handshake.hs_type |= WITHOUT_CR;
511 return tls13_server_certificate_recv(ctx);
512 }
513
485 return 0; 514 return 0;
486} 515}
487 516