[openssl-dev] SNI by default in s_client

Tomas Mraz tmraz at redhat.com
Mon Feb 13 16:36:47 UTC 2017


On Mon, 2017-02-13 at 16:13 +0000, Matt Caswell wrote:
> I'd like to canvas opinion on this PR:
> https://github.com/openssl/openssl/pull/2614

....

> 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)?

In my opinion the PR should be allowed in 1.1.x release, depending on
s_client to not send SNI in some kind of scripts seems to me like a
fairly obscure corner case. I would view this change as a simple
usability improvement.

But if you decide to postpone such changes to 1.2.0 I would recommend
to create some intermediate step between fully breaking API/ABI and
command line use changes. I mean - release 1.2.0 as something API/ABI
compatible with 1.1.x, but allowing such usability changes for command-
line and also allowing things like removal of obscure or insecure
features but keeping the function signatures intact (they would simply
return errors). And also keep the library SONAME so dependencies do not
need to be rebuilt.

And spare full break of API/ABI for something like 2.0 release.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)



More information about the openssl-dev mailing list