Relax parsing of TLS key share extensions on the server.

The RFC does not require X25519 and it also allows clients to send an empty
key share when the want the server to select a group. The current behaviour
results in handshake failures where the client supports TLS 1.3 and sends a
TLS key share extension that does not contain X25519.

Issue reported by Hubert Kario via github.

ok tb@

1 files changed, 2 insertions, 5 deletions

diff --git a/src/lib/libssl/ssl_tlsext.c b/src/lib/libssl/ssl_tlsext.c
index 506cfbcfea..91b74b5d3f 100644
--- a/src/lib/libssl/ssl_tlsext.c
+++ b/src/lib/libssl/ssl_tlsext.c
@@ -1,4 +1,4 @@
-/* $OpenBSD: ssl_tlsext.c,v 1.48 2019/05/29 17:25:27 jsing Exp $ */
+/* $OpenBSD: ssl_tlsext.c,v 1.49 2019/05/29 17:28:37 jsing Exp $ */
 /*
  * Copyright (c) 2016, 2017, 2019 Joel Sing <jsing@openbsd.org>
  * Copyright (c) 2017 Doug Hogan <doug@openbsd.org>
@@ -1272,7 +1272,6 @@ tlsext_keyshare_server_parse(SSL *s, CBS *cbs, int *alert)
         CBS key_exchange;
         uint16_t group;
         size_t out_len;
-        int ret = 0;
 
         if (!CBS_get_u16_length_prefixed(cbs, &client_shares))
                 goto err;
@@ -1304,11 +1303,9 @@ tlsext_keyshare_server_parse(SSL *s, CBS *cbs, int *alert)
                 if (!CBS_stow(&key_exchange, &S3I(s)->hs_tls13.x25519_peer_public,
                     &out_len))
                         goto err;
-
-                ret = 1;
         }
 
-        return ret;
+        return 1;
 
  err:
         *alert = SSL_AD_DECODE_ERROR;