I'd like to canvas opinion on this PR: https://github.com/openssl/openssl/pull/2614
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.: https://github.com/openssl/openssl/issues/2580 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 needed. 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)? Discuss. Matt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev