Re: SNI disable by default on 1.0 and 1.1.0?
On Mon, Dec 02, 2019 at 10:39:26PM +, Michael Wojcik wrote: > > SNI is not "disabled" in any of these versions, it is not just turned on > > by default in the s_client command-line utility (a testing tool). The > > OpenSSL library does not by default turn on SNI in any of these > > releases. The application code has to call SSL_set_tlsext_host_name(3) > > in order to enable SNI. > > And, indeed, how could it be otherwise? The value of the SNI extension > should always be the peer name, as intended by the client. Is OpenSSL > supposed to discern this by magic? The caller has to tell the library what > value to put in the extension. Well, OpenSSL does have some interfaces for connecting to a named host, and those could potentially enable SNI by default, but that is not yet the case, and is not necessarily appropriate in all cases. That said enabling SNI for the cases where OpenSSL is doing the name to IP resolution and setting up the socket is perhaps something that can be done in a future major release. -- Viktor.
RE: SNI disable by default on 1.0 and 1.1.0?
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Viktor Dukhovni > Sent: Monday, December 02, 2019 13:48 > To: openssl-users@openssl.org > Subject: Re: SNI disable by default on 1.0 and 1.1.0? > > SNI is not "disabled" in any of these versions, it is not just turned on > by default in the s_client command-line utility (a testing tool). The > OpenSSL library does not by default turn on SNI in any of these > releases. The application code has to call SSL_set_tlsext_host_name(3) > in order to enable SNI. And, indeed, how could it be otherwise? The value of the SNI extension should always be the peer name, as intended by the client. Is OpenSSL supposed to discern this by magic? The caller has to tell the library what value to put in the extension. -- Michael Wojcik Distinguished Engineer, Micro Focus
Re: SNI disable by default on 1.0 and 1.1.0?
On Mon, Dec 02, 2019 at 09:05:33PM +0100, aeris wrote: > Hello here, > > I try to compile 1.0.2t and 1.1.0l, but I notice SNI seems disabled by > default, when it's enabled by default on 1.1.1d… Please specify whether you are concerned about the s_client behavior specifically or the libssl library behavior. > openssl-1.0.2t > $ ./config enable-tlsext && make > $ echo -n "" | ./apps/openssl s_client -connect blog.imirhil.fr:443 | ./apps/ > openssl x509 -noout -subject > subject= /CN=localhost # No SNI by default, default vhost, bad certificate > $ echo -n "" | ./apps/openssl s_client -connect blog.imirhil.fr:443 - > servername blog.imirhil.fr | ./apps/openssl x509 -noout -subject > subject= /CN=blog.imirhil.fr # SNI, correct vhost, good certificate > > openssl-1.1.1d > $ ./config && make > $ echo -n "" | ./apps/openssl s_client -connect blog.imirhil.fr:443 | ./apps/ > openssl x509 -noout -subject > subject= /CN=blog.imirhil.fr # SNI by default, correct vhost, good certificate > > According to changelog, enable-tlsext is available since 0.9.8f and by > default > since 0.9.8j, but seems something is wrong somewhere… > The observed behaviour breaks all applications which don't set SNI > explicitly, > hitting the default vhost and not the real content… > Is there any way to force SNI activation by default at build time on pre > 1.1.1 > versions, like under 1.1.1d ? I think your tests are just finding the changes from https://github.com/openssl/openssl/pull/2614 but other applications using libssl still need to use the SSL_set_tlsext_host_name() API in order to send the SNI extension. -Ben
Re: SNI disable by default on 1.0 and 1.1.0?
On Mon, Dec 02, 2019 at 09:05:33PM +0100, aeris wrote: > I try to compile 1.0.2t and 1.1.0l, but I notice SNI seems disabled by > default, when it's enabled by default on 1.1.1d… SNI is not "disabled" in any of these versions, it is not just turned on by default in the s_client command-line utility (a testing tool). The OpenSSL library does not by default turn on SNI in any of these releases. The application code has to call SSL_set_tlsext_host_name(3) in order to enable SNI. > The observed behaviour breaks all applications which don't set SNI > explicitly, > hitting the default vhost and not the real content… Applications have to set SNI explicitly. > Is there any way to force SNI activation by default at build time on pre > 1.1.1 > versions, like under 1.1.1d ? No, and the same applies to 1.1.1d. -- Viktor.
SNI disable by default on 1.0 and 1.1.0?
Hello here, I try to compile 1.0.2t and 1.1.0l, but I notice SNI seems disabled by default, when it's enabled by default on 1.1.1d… openssl-1.0.2t $ ./config enable-tlsext && make $ echo -n "" | ./apps/openssl s_client -connect blog.imirhil.fr:443 | ./apps/ openssl x509 -noout -subject subject= /CN=localhost # No SNI by default, default vhost, bad certificate $ echo -n "" | ./apps/openssl s_client -connect blog.imirhil.fr:443 - servername blog.imirhil.fr | ./apps/openssl x509 -noout -subject subject= /CN=blog.imirhil.fr # SNI, correct vhost, good certificate openssl-1.1.1d $ ./config && make $ echo -n "" | ./apps/openssl s_client -connect blog.imirhil.fr:443 | ./apps/ openssl x509 -noout -subject subject= /CN=blog.imirhil.fr # SNI by default, correct vhost, good certificate According to changelog, enable-tlsext is available since 0.9.8f and by default since 0.9.8j, but seems something is wrong somewhere… The observed behaviour breaks all applications which don't set SNI explicitly, hitting the default vhost and not the real content… Is there any way to force SNI activation by default at build time on pre 1.1.1 versions, like under 1.1.1d ? Regards, -- aeris Individual crypto-terrorist group self-radicalized on the digital darknet https://imirhil.fr/ Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://café-vie-privée.fr/ signature.asc Description: This is a digitally signed message part.
