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

2017-02-13 Thread 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

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

2017-02-13 Thread 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

2017-02-13 Thread 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

2017-02-13 Thread 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

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

2017-02-13 Thread 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

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

2017-02-13 Thread 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"

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

2017-02-13 Thread 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

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

2017-02-13 Thread 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 >

[openssl-dev] SNI by default in s_client

2017-02-13 Thread 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