Re: [openssl-dev] SNI by default in s_client

[Viktor Dukhovni]

> On Feb 13, 2017, at 12:32 PM, Viktor Dukhovni  
> wrote:
> 
> That said, I don't think that enabling SNI by default *in s_client* is
> sufficient cause to motivate such a feature.  The s_client command adds
> new options from time to time, and IIRC we've never before back-ported
> these as NOPs.  If an "ignore_unknown" option is warranted, it is for
> all the other new things we might add in addition to "-noservername".

One more thing I should note.  The implementation should not break the
"-dane_tldsa_domain" option.  That is, with no explicit "-servername"
and with "-dane_tlsa_domain", the SNI name must come from that option,
and not the "-connect" hostname.

-- 
Viktor.

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

Re: [openssl-dev] SNI by default in s_client

[Viktor Dukhovni]

> On Feb 13, 2017, at 12:35 PM, Salz, Rich  wrote:
> 
> I think it should be called out in the docs and CHANGES however.

Yes, definitely.

-- 
Viktor.

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

Re: [openssl-dev] SNI by default in s_client

[Salz, Rich]

Having asked for Viktor's opinion, and reading it, I withdraw my concerns about 
changing the behavior and adding the flag.  I think it should be called out in 
the docs and CHANGES however.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] SNI by default in s_client

[Benjamin Kaduk]

On 02/13/2017 10:13 AM, Matt Caswell wrote:
> 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)?
>

A few thoughts: I agree that the ecosystem is moving towards using SNI
almost all of the time, and this change is probably net helpful to our
users.  However, it is also the sort of change that I would have
expected to be blocked by the ABI stability promise (as I understand it
to be, or maybe as I imagine it to be in my wishful thinking).  In this
particular case, my personal opinion is that the benefit outweighs the
compatibility breakage, but I could sympathize with someone who felt
differently.

Perhaps a reasonable compromise would be to ensure that the
-noservername option is accepted (as a noop) in 1.1.0, so that
there is a way to write a script that remains compatible between 1.1.0
and 1.1.1 even if the default does change.

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

Re: [openssl-dev] SNI by default in s_client

[Matt Caswell]

On 13/02/17 16:55, Salz, Rich wrote:
>> 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.
> 
> You mean adding new extensions in the wire protocol?  Or are did we modify 
> any API/ABI behavior?

Wire protocol. We haven't modified API/ABI behaviour (except to add new
APIs).

> 
>>  On the other hand you could argue that this could break
>> existing scripts that rely on the current SNI behaviour.
> 
> I would support adding a new -sni flag that is shorter, easier to type, and 
> uses the value of the HOST field.

Which doesn't really solve the problem I was seeking to address.

> 
> Within the team, we previously had agreement that the CLI was part of the ABI 
> "contract."  Waiting for Viktor to weigh in  here :)
> 

I'm all in favour of a stable command line interface. What I think is
unclear is where the line is drawn between what is and isn't allowed.

I'm also waiting for Viktor :-)

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

Re: [openssl-dev] SNI by default in s_client

[Viktor Dukhovni]

> On Feb 13, 2017, at 11:13 AM, Matt Caswell  wrote:
> 
> 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.

So long as the "-servername" option remains in place and supports
setting the SNI name to something other than the host part of the
"-connect" option I think we provide sufficient compatibility with
the legacy s_client CLI interface.  Adding a "-noservername" option
is compatible enough.

The change of default behaviour is not an interface change, it is a
behaviour change, and could even, with enough squinting, be viewed
as a bugfix, given the modern TLS landscape.

That said, even behaviour changes in stable releases do merit
discussion.  Certainly I would not support the proposed change in
a patch release.  For 1.1.1, I am not opposed, because s_client
is not stunnel, it is primarily useful as a diagnostic tool, and
while some monitoring tools built around it may behave differently
as a result of the change, it is not clear that delaying to 1.2.x
helps.  If we're going to do this, I think that 1.1.1 is OK, if the
interface remains compatible.

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

Re: [openssl-dev] SNI by default in s_client

[Salz, Rich]

> 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.

You mean adding new extensions in the wire protocol?  Or are did we modify any 
API/ABI behavior?

>  On the other hand you could argue that this could break
> existing scripts that rely on the current SNI behaviour.

I would support adding a new -sni flag that is shorter, easier to type, and 
uses the value of the HOST field.

Within the team, we previously had agreement that the CLI was part of the ABI 
"contract."  Waiting for Viktor to weigh in  here :)

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

Re: [openssl-dev] SNI by default in s_client

[Tomas Mraz]

On Mon, 2017-02-13 at 16:13 +, 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.)

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

[openssl-dev] SNI by default in s_client

[Matt Caswell]

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