Proxy_pass not seen as SNI-client according to Apache directive

Hi guys,

I’m having a rather odd behavior - I use nginx as a reverse proxy
(basically as a CDN) - where if the file isn’t in cache, I do use
proxy_pass to the origin server, to get the file and then cache it.

This works perfectly in most cases, but if the origin is running apache
and happen to use the Apache Directive “SSLStrictSNIVHostCheck” where
it’s set to On.

Basically it decides whether a non-SNI client is allowed to access a
name-based virtual host over SSL or not.
But when using proxy_pass this seems to the apache server that it’s a
non-SNI client:
[Sun Feb 14 19:32:50 2016] [error] No hostname was provided via SNI for
a name based virtual host
[Sun Feb 14 19:33:00 2016] [error] No hostname was provided via SNI for
a name based virtual host

I was able to replicate this issue on multiple nginx versions (both on
1.8.1, 1.9.9 and 1.9.10).
It results in 403 forbidden for the client.

If I set the directive SSLStrictSNIVHostCheck to off, I do not get a 403
forbidden - and the files I try to fetch gets fetched correctly.
(Meaning proxy_pass do understand SNI).

The nginx zone does a proxy_pass https://my_domain; and the my_domain is
running on a server that runs SNI.

Best Regards,
Lucas Rolff

Hello!

On Sun, Feb 14, 2016 at 08:14:20PM +0100, Lucas Rolff wrote:

I’m having a rather odd behavior - I use nginx as a reverse proxy (basically
as a CDN) - where if the file isn’t in cache, I do use proxy_pass to the
origin server, to get the file and then cache it.

This works perfectly in most cases, but if the origin is running apache and
happen to use the Apache Directive “SSLStrictSNIVHostCheck” where it’s set
to On.

http://nginx.org/r/proxy_ssl_server_name


Maxim D.
http://nginx.org/

This works perfectly in most cases, but if the origin is running apache and
happen to use the Apache Directive “SSLStrictSNIVHostCheck” where it’s set
to On.

http://nginx.org/r/proxy_ssl_server_name

Out of curiosity, is there a philosophical/design reason this option is
not enabled by default?

Hi Maxim,

Thank you a lot for the quick reply, I’ll give it a test tomorrow
morning!

And Robert has a valid point indeed, why is it actually disabled by
default?

Hello!

On Sun, Feb 14, 2016 at 01:46:48PM -0800, Robert P. wrote:

This works perfectly in most cases, but if the origin is running apache and
happen to use the Apache Directive “SSLStrictSNIVHostCheck” where it’s set
to On.

http://nginx.org/r/proxy_ssl_server_name

Out of curiosity, is there a philosophical/design reason this
option is not enabled by default?

There was no support for client-side SNI till nginx 1.7.0, and
when introduced it was set off by default to avoid breaking
existing configurations.

Additionally, client-side SNI discloses information about domain
name used to connect to (which is bad from security point of
view), and hardly make sense without peer certificate verification
(http://nginx.org/r/proxy_ssl_verify), which is also off by
default and can’t be enabled without a list of trusted
certificates.


Maxim D.
http://nginx.org/

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs