Resolved force TLSv1.2 only and Ciphers for specific Domains possible?!

[daanse]

HI,

we have a Task which is not clear to me.
We managed this on Server Wide Base not Domain based.

Is it possible to deactivate following for a NGINX Hosting Domain?
deactivate: TLS 1.0, TLS 1.1, 3DES (I think weak Cipher, if its still there)
and force https to be over TLSv1.2 ?

WE use:
Plesk Onyx
Version 17.8.11 Update #31
‪Debian 8.11‬

 

[IgorG]

How to enable or disable TLS protocol versions in Plesk for Linux

 

[daanse]

Hi @IgorG ,

thank you for fast reply but i need this for only one domain. Can this be done with additional NGINX directives?

 

[IgorG]

As far as I know, such functionality is not implemented in Plesk. Only server-wide.

 

[ChristophRo]

thank you for fast reply but i need this for only one domain. Can this be done with additional NGINX directives?

I assume (did not test it) that this is already possible if you assign a dedicated IP address for that domain.
Then it will mostly likely just work if you specify a "ssl_protocols TLSv1.2;" in the additional NGINX directives for that domain.

As for doing this in the same IP address, you are out of luck and there is nothing that Plesk or nginx could do.
The TLS handshake is done before the client submits the host header, so the server does not know to which domain the client tries to connect at that moment.
Might be possible in the future with some changes to the OpenSSL library, though....

 

[daanse]

I assume (did not test it) that this is already possible if you assign a dedicated IP address for that domain.
Then it will mostly likely just work if you specify a "ssl_protocols TLSv1.2;" in the additional NGINX directives for that domain.

Hi,

thank you, i did add something in NGNX directives and i think this has worked. Some Tools outside say its TLS 1.2 only.
I put following into NGINX directives:

ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers Off;
ssl_ciphers ECDH+AESGCM:ECDH+CHACHA20:ECDH+AES256:ECDH+AES128:!aNULL:!SHA1;

# Shared cache size 30MB
ssl_session_cache shared:SSL:30m;
# Default timeout is 5m
ssl_session_timeout 10m;
# OCSP-Stapling
ssl_stapling on;
ssl_stapling_verify on;

 

[virtubox]

I assume (did not test it) that this is already possible if you assign a dedicated IP address for that domain.
Then it will mostly likely just work if you specify a "ssl_protocols TLSv1.2;" in the additional NGINX directives for that domain.

As for doing this in the same IP address, you are out of luck and there is nothing that Plesk or nginx could do.
The TLS handshake is done before the client submits the host header, so the server does not know to which domain the client tries to connect at that moment.
Might be possible in the future with some changes to the OpenSSL library, though....

Hello,
Even on the same IP, directives ssl_protocols and ssl_ciphers can be different for each Nginx vhost.

 

[trialotto]

@daanse

The (recent) answer by @virtubox is correct: you manage settings individually for each vhost by altering the Nginx templates.

Let me explain a bit.

Plesk by default uses specific Nginx (related) templates to generate the Nginx configuration, on a per-domain (read: per-vhost) basis.

Plesk also allows for customization of the before mentioned Nginx templates: customization will allow you to create persistent generation of Nginx templates.

Nginx itself consists of a number of blocks, being either http (not relevant here), location (barely relevant here) and server blocks.

The Nginx server blocks are the parts of Nginx configuration that contain the configuration for a specific domain (read: vhost) and these blocks contain SSL/TLS directives.

Any Nginx server block for a specific domain can be altered, either manually or via a custom template: the manual edits to a template will be overwritten if you reconfigure the domain (read:vhost) and/or can be overwritten if a Plesk update is applied, whereas the method of custom templates does not have these disadvantages.

Any Nginx server block for a specific domain can be different and unique: Nginx will be smart enough to find the right server block when getting requests for a domain.

In short, @virtubox is right, it is possible ....... but it is also recommended to use the method of custom Nginx templates.

Hope the above helps a bit.

Regards.....

 

[ChristophRo]

Hello,
Even on the same IP, directives ssl_protocols and ssl_ciphers can be different for each Nginx vhost.

No Sir, you are incorrect.
Yes, you can configure ssl_protocols and ssl_ciphers at server level and thus have them different for each vhost, but (only) the configuration of the first loaded server/vhost will apply - at least for the same listener. (aka IP address)

 

[virtubox]

No Sir, you are incorrect.
Yes, you can configure ssl_protocols and ssl_ciphers at server level and thus have them different for each vhost, but (only) the configuration of the first loaded server/vhost will apply - at least for the same listener. (aka IP address)

First vhost :

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'TLS13+AESGCM+AES128:EECDH+AES128';

ssllabs result:

2nd vhost (subdomain) :

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers TLS13+AESGCM+AES128:TLS13+AESGCM+AES256:TLS13+CHACHA20:EECDH+CHACHA20:EECDH+AESGCM:EECDH+AES;

ssllabs result :

 

[ChristophRo]

different ciphers per vhost do work (was not aware of that, so thanks for updating me on that knowledge)
but different ssl/tsl protocols do not work (that I was aware of for sure)

• nginx/1.14.1 & OpenSSL 1.1.1

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'TLS13+AESGCM+AES128:EECDH+AES128';

ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4';

 

[trialotto]

@ChristophRo

The statement

different ciphers per vhost do work (was not aware of that, so thanks for updating me on that knowledge)
but different ssl/tsl protocols do not work (that I was aware of for sure)

is party true and mostly not.

Let me explain a bit.

Nginx is compiled with a specific version of OpenSSL and the combination of specific versions of both programmes determines the capabilities of Nginx.

OpenSSL is a bit odd with TLSv1.3 support, but at least there is some support.

However, that does not imply that Nginx fully supports TLSv1.3 - Nginx has a history of problematic support of TLSv1.3 and this certainly applies to "lower" Nginx versions.

Now, your test case is essentially including TLSv1.3 as a basic element of the protocols enabled.

It can be the case that all of the test results will differ if the test will be executed without TLSv1.3 activated.

Moreover, it is certain that all of the test results will significantly differ if you would use a mainline version of Nginx (1.15.7) instead of a stable version (1.14.1).

In summary, it is hard to draw any proper conclusion if the test case itself is to some extent flawed.

I would really recommend to have some patience and wait for the next Nginx release that properly supports TLSv1.3 - that might take some time though.

Regards........

 

[ChristophRo]

No need to complicate things here, I'm well aware of the technical implications and limitations
So I don't know why you even mention TLSv1.3, as it has clearly nothing to do with the current case?

Yes the whole problem is not limited to nginx, but rather anything that uses OpenSSL.
And technically it's currently not possible, to use different TLS protocols depending on domains/vhosts.
There simply exists no hook in OpenSSL for applications like nginx, apache2 or whatever, to determine/switch the configured/required TLS version based on the domain name

 

[daanse]

How do you test this? Whats the tool or Command to get this view?

 

[learning_curve]

@daanse You can run this yourself using this package: drwetter/testssl.sh

 

[trialotto]

No need to complicate things here, I'm well aware of the technical implications and limitations
So I don't know why you even mention TLSv1.3, as it has clearly nothing to do with the current case?

Yes the whole problem is not limited to nginx, but rather anything that uses OpenSSL.
And technically it's currently not possible, to use different TLS protocols depending on domains/vhosts.
There simply exists no hook in OpenSSL for applications like nginx, apache2 or whatever, to determine/switch the configured/required TLS version based on the domain name

@ChristophRo

If you don't mind me saying so, but you are creating noise in the communication here and/or the topic thread as a whole.

First note that I talked about TLSv1.3, because your own output indicates clearly that you are testing with that protocol, even as negotiated protocol.

Furthermore, note that protocol negotation has nothing to do with server-side applications like Nginx or Apache.

In essence, server-side applications of the kind Nginx or Apache can be compiled and/or configured to offer support for specific protocols, but actually the web client (hence including browsers) is determining the protocol that is factually used.

As such, OpenSSL is barely relevant, in the sense that it is only relevant at (one the one hand) compilation time, in order to allow certain protocols for server-side applications like Apache or Nginx and (on the other hand) the client-side, which client-side also has to be enabled to support specific protocols.

There is a huge difference between "allow" (on the server-side) and "support" (on the client-side).

In summary, it does not matter how one wants to view or explain this protocol negotation, the facts remain that

- TLSv1.2 and TLSv1.1 are widely supported by default in both client-side and server-wide applications
- TLSv1.2 is widely preferred in both client-side and server-side applications
- TLSv1.2 is widely allowed in server-side applications
- TLSv1.3 is commonly (but not generally offered) in proper client-side applications
- TLSv1.3 is often not supported and/or not allowed in server-side applications, due to many issues with TLSv1.3

and note that the issues with TLSv1.3 are not related to server-side applications alone: in essence, the root cause of the majority of problems with TLSv1.3 are very closely related to OpenSSL and in particular the misalignment of OpenSSL with the commonly standards used by both server-side and client-side applications.

Simply stated, TLSv1.3 has never been working properly and development of client-side/server-side has never been able to grasp all (bug related) complexity of TLSv1.3.

And again, I can finish the above explanation with the statement: it is and was always possible to allow (multiple) protocols on a per-domain/vhost basis.

Regards................

 

[ChristophRo]

@trialotto
You lack of knowledge in this matter is disturbing, for the fact that you go so vocal about that here.

Different SSL/TLS versions are currently not possible on the same IP address/port combination, no matter what you use or do.
Yes, if you assign a dedicated IP address to your vhost, then you can have different TLS versions on that vhost....but that is what I already said on the very first post.

I'll gladly invite you to read through the various sources on the internet regarding this matter, i.e.

• define sslprotocol for each vhost · Issue #4301 · openssl/openssl
• 55707 – SSLProtocol directive seem to be ignored over different virtualhosts on the same ip+port
• Ssl_protocols per server?

 

[trialotto]

@ChristophRo

I find your tone of voice and remarks very disturbing, it is not appropriate at all.

In essence, two or three people are trying to help you voluntarily and they all (simply state) "it is possible" - you just disagree with that statement and in a sense, there is some disregard on your side to the time and effort people put into helping you.

In the short run, you are the only one having a problem or issue related to protocols - other people do not.

In the long run, you are still the one having the same problem - in addition, you are not very likely to make friends on this forum.

Again, I have to emphasize that it is possible what you want to achieve:just tweak Nginx.

Regards.......

 

[trialotto]

@virtubox, @daanse, @learning_curve, @ChristophRo and @AlL others,

It seems to be the case that @ChristophRo has been providing evidence and arguments in the form of output that is reflecting some Nginx related oddities (read: odd behavior of Nginx that can be expected with specific versions of Nginx and OpenSSL) and/or Nginx related bugs.

In essence, the analysis in this topic thread has been a bit flawed and biased.

I have tried to mention the issues with Nginx and/or the combination of Nginx and specific versions of OpenSSL in one of my earlier posts.

For your information: Nginx released stable version 1.14.2 to address some or most of the underlying bugs, have a look at this page.

Also note that Plesk has been updated to Nginx version 1.14.1 - it is a pity that we do not have Nginx version 1.14.2 yet: some bugs will persist in current version 1.14.1.

Hope to have you informed sufficiently.....

Kind regards........