I'd like to canvas opinion on this PR:

At the moment s_client does not add the SNI extension by default. You
have to explicitly ask for it using the "-servername" option. This can
lead to some problems where servers reject connection attempts from
s_client, e.g.:


TLSv1.3 says this about SNI:

   Additionally, all implementations MUST support use of the
   "server_name" extension with applications capable of using it.
   Servers MAY require clients to send a valid "server_name" extension.
   Servers requiring this extension SHOULD respond to a ClientHello
   lacking a "server_name" extension by terminating the connection with
   a "missing_extension" alert.

Technically this doesn't really say anything very much other than we
MUST support it (which we do), and that servers may refuse to talk to
clients that don't send it (which we already know). But the direction of
travel seems to be to support SNI where possible.

The PR above changes the default behaviour of s_client so that it always
sends SNI, and adds a "-noservername" option to suppress sending it if

I was targeting this change for 1.1.1. The issue is that this does
change command line behaviour between minor versions of the 1.1.x series
- which is supposed to preserve API and ABI compatibility. Of course
this change affects neither API or ABI as its in the apps only -
although we usually extend that compatibility to try to ensure that
command line behaviour remains stable too.

You could argue that the only change in behaviour here is the addition
of an extension by default that wasn't there before - and that we've
already decided to add new extensions in 1.1.1 due to the forthcoming
TLSv1.3 support. On the other hand you could argue that this could break
existing scripts that rely on the current SNI behaviour.

So the question is: should this (type of) change be allowed in a 1.1.x
release? Or should it only be allowed in some future 1.2.0 (or not at all)?


openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to