SNI disable by default on 1.0 and 1.1.0?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

SNI disable by default on 1.0 and 1.1.0?

aeris
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SNI disable by default on 1.0 and 1.1.0?

Viktor Dukhovni
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.
Reply | Threaded
Open this post in threaded view
|

Re: SNI disable by default on 1.0 and 1.1.0?

OpenSSL - User mailing list
In reply to this post by aeris
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
Reply | Threaded
Open this post in threaded view
|

RE: SNI disable by default on 1.0 and 1.1.0?

Michael Wojcik
In reply to this post by Viktor Dukhovni
> From: openssl-users [mailto:[hidden email]] On Behalf Of
> Viktor Dukhovni
> Sent: Monday, December 02, 2019 13:48
> To: [hidden email]
> 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


Reply | Threaded
Open this post in threaded view
|

Re: SNI disable by default on 1.0 and 1.1.0?

Viktor Dukhovni
On Mon, Dec 02, 2019 at 10:39:26PM +0000, 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.
Reply | Threaded
Open this post in threaded view
|

Re: SNI disable by default on 1.0 and 1.1.0?

aeris
In reply to this post by OpenSSL - User mailing list
> 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.

OK got it.

I have trouble with certificate verification on software using libssl 1.0.2 and
not 1.1.1. And when debugging, I spot the difference of behaviour with openssl
client which also generate _the same_ verification error. This confuse me…
Network debugging the flow show SNI in both case with libssl.

In fact my real problem was because OPENSSLDIR are not the same, and 1.0.2
have no CA but 1.1.1 have one…

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 (849 bytes) Download Attachment