RFC 6066 states that IP literals are not permitted in "HostName" for a

TLS Server Name extension, however seemingly several clients (including
Python, Ruby and Safari) violate the RFC. Given that this is a fairly
widespread issue, if we receive a TLS Server Name extension that contains
an IP literal, pretend that we did not receive the extension rather than
causing a handshake failure.

Issue raised by jsg@

ok jsg@

1 files changed, 9 insertions, 3 deletions

diff --git a/src/lib/libtls/tls_server.c b/src/lib/libtls/tls_server.c
index fd5a617582..394cea1e8d 100644
--- a/src/lib/libtls/tls_server.c
+++ b/src/lib/libtls/tls_server.c
@@ -1,4 +1,4 @@
-/* $OpenBSD: tls_server.c,v 1.39 2017/06/22 18:03:57 jsing Exp $ */
+/* $OpenBSD: tls_server.c,v 1.40 2017/07/05 15:38:35 jsing Exp $ */
 /*
  * Copyright (c) 2014 Joel Sing <jsing@openbsd.org>
  *
@@ -91,10 +91,16 @@ tls_servername_cb(SSL *ssl, int *al, void *arg)
                 return (SSL_TLSEXT_ERR_NOACK);
         }
 
-        /* Per RFC 6066 section 3: ensure that name is not an IP literal. */
+        /*
+         * Per RFC 6066 section 3: ensure that name is not an IP literal.
+         *
+         * While we should treat this as an error, a number of clients
+         * (Python, Ruby and Safari) are not RFC compliant. To avoid handshake
+         * failures, pretend that we did not receive the extension.
+         */
         if (inet_pton(AF_INET, name, &addrbuf) == 1 ||
             inet_pton(AF_INET6, name, &addrbuf) == 1)
-                goto err;
+                return (SSL_TLSEXT_ERR_NOACK);
 
         free((char *)conn_ctx->servername);
         if ((conn_ctx->servername = strdup(name)) == NULL)