HTTP/2 support released

[trialotto]

@IgorG,

Having given the before mentioned post as a general guide for those people that happen to have Apache 2.4.17 (or higher), which should be exceptional, I can turn to the relevant part.

I sincerely question the support for HTTP/2 in a Nginx instance, that functions as a proxy for Apache with (only) HTTP/1 support.

Sure, the Plesk Panel could benefit from allowing HTTP/2 support, but that is not the case of the moment (the Plesk Panel is still on SPDY).

In essence, all Nginx proxies with HTTP/2 support are only benefitting from the HTTP/2 protocol, if and only if

- Nginx is used to serve static files (and preferably a significant amount of the static files served by the Apache + Nginx stack), (and/or)
- Nginx is used to serve requests from some kind of cache (and the type of caching mechanism is barely relevant), (and/or)
- Nginx is used to serve requests with PHP-FPM.

In all other cases, Apache with (only) the support for the HTTP/1 protocol will be a bottleneck, that can cause serious performance problems, with Apache related issues as the endresult.

In short, the default Apache + Nginx stack, with Apache serving PHP-FPM, becomes the proverbial "oddball" if Nginx is on HTTP/2 and Apache is on HTTP/1 protocol.

I would strongly recommend to make a KB with respect to the possibilities and challenges of the current Apache + Nginx stack, if Nginx is allowed to run on the HTTP/2 protocol.

Regards.....

 

[Michael Lux]

Hello everybody,

great job, I can't wait to try this out, BUT...
we have an owncloud instance on one domain, which might cause problems with SPDY/HTTP2 because of a restriction in the Qt desktop Clients, see https://github.com/owncloud/client/issues/3146
Is it possible to run this particular domain without HTTP2?
More precisely, is there some per-domain checkbox to do this, or do we need a custom config template?

Kind regards,
Michael

 

[Arne Fahrenwalde]

I would like to note that enabling HTTP/2 sets the following ciphers in /etc/nginx/conf.d/ssl.conf :
ssl_ciphers EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EECDH+CHACHA20:EDH+AESGCM+AES128:EDH+AESGCM+AES256:EDH+CHACHA20;

Testing my server afterwards with SSLLabs showed that this configuration leaves out HTTP/1(.1) completely - dropping lot's of still used clients for your website (e.g. Android < 4.4.2, Internet Explorer < 11 ...) - Together with the recommended HTTP to HTTPS rediretion you can lose many potential visitors.

I suggest everyone to use the Mozilla SSL Configurator afterward and chose the desired setup. I went for the intermediate setup for now which only drops IE6 and Java 6. Maybe Plesks default setup is a bit too harsh here. (nginx handles HTTP/1(.1) and HTTP/2 alongside pretty well - with the intermediate setup the new browsers get v2 and the older clients can still access the site with v1).

 

[trialotto]

@Michael Lux

You stated or asked

Is it possible to run this particular domain without HTTP2?

Yes, when having the http_v2_module compiled into the Nginx binary, activating becomes as simple as adding http2 to the line containing the listen directive for port 443:

server {
listen 443 ssl http2;

ssl_certificate server.crt;
ssl_certificate_key server.key;
}

The above implies that simply removing the http2 entry for one specific domain would be a sufficient work-around.

Note that this is not a permanent solution, any update can undo your changes.

In short, when wanting to deactivate http2 for a specific domain, just edit (read: remove the text "http2") the /var/www/vhosts/system/<domain>/conf/nginx.conf file.

More precisely, is there some per-domain checkbox to do this, or do we need a custom config template?

Ehm, this is not "more precisely", neither of them applies:

- there is no checkbox, let alone a per-domain checkbox,
- one does not need a custom config template.

Simply follow the instructions above, with respect to editing the nginx.conf file.

Regards....

 

[trialotto]

@Arne Fahrenwalde

Thanks for sharing this remark

Testing my server afterwards with SSLLabs showed that this configuration leaves out HTTP/1(.1) completely - dropping lot's of still used clients for your website (e.g. Android < 4.4.2, Internet Explorer < 11 ...) - Together with the recommended HTTP to HTTPS rediretion you can lose many potential visitors.

and it is partially relevant, in the sense that

- TLS version support should not be mistaken for HTTP version support,
- accepting HTTP/2 connections over TLS is all about the required "“Application-Layer Protocol Negotiation” (ALPN) TLS extension support,
- ALPN is all about the OpenSSL version: OpenSSL version 1.0.2 (or higher), or your OS provided OpenSSL package should contain ALPN support.

In short, client configurations are barely relevant, in the sense that it is all about ALPN support.

Nevertheless, HTTP/2 with TLS version 1.2 and a proper OpenSSL version is a quite common "requirement" (read: necessity).

Note that other setups are in theory possible: I will not discuss them, since they are involving TLS and OpenSSL versions that can be deemed to be unsecure.

Now, this brings me to the remark made: HTTP/2 activation can result in connectivity issues for specific clients.

Well, it must be clear by now that is has nothing to do with HTTP/2: it has everything to do with the ssl ciphers applied in the Plesk HTTP/2 configuration.

For that reason, I will quote

I suggest everyone to use the Mozilla SSL Configurator afterward and chose the desired setup. I went for the intermediate setup for now which only drops IE6 and Java 6. Maybe Plesks default setup is a bit too harsh here. (nginx handles HTTP/1(.1) and HTTP/2 alongside pretty well - with the intermediate setup the new browsers get v2 and the older clients can still access the site with v1).

and I admit that "Plesk default setup is a little bit harsh", as you pointed out.

However, to solve that "harshness", one can "simply" edit the cipher suite used by Plesk for TLS negotation.

I really have to put "simply" in quotation marks, since it is requires some decent knowledge about the topic.

I certainly do not recommend to use the Mozilla SSL Configurator, for many reasons, the two most important ones being

- the Mozilla SSL Configurator often is wrong (!)
- the Mozilla SSL Configurator makes good suggestions, giving you inspiration, but it really requires decent knowledge to apply the suggestions correctly to Plesk´s configuration.

Finally, I want to make the important note that Plesk has HTTP/2 support for Nginx (only), Apache is still going strong on HTTP/1.

The latter also implies that Nginx, which functions as a reverse proxy for Apache, does not really need HTTP/2 support (but it does need security hardening though).

In essence, with Nginx having the ability to process > 10K requests per second, Nginx (as reverse proxy for Apache) really is sufficient (and almost equivalent to HTTP/2: a very huge number of requests can be processed by Nginx at the same time and forwarded to Apache, that uses worker processes that can exist simultaneously).

In short, be careful with the HTTP/2 hype, one should view this hype from the correct context only: ask yourself the question "do I actually NEED it?".

Hope the above helps and gives some clarity.

Regards....

 

[Arne Fahrenwalde]

- TLS version support should not be mistaken for HTTP version support,
- accepting HTTP/2 connections over TLS is all about the required "“Application-Layer Protocol Negotiation” (ALPN) TLS extension support,
- ALPN is all about the OpenSSL version: OpenSSL version 1.0.2 (or higher), or your OS provided OpenSSL package should contain ALPN support.

I was propably not specific enough here: the above Cipher configuration are all TLS1.2 ciphers, still plesk leaves
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
as default when switching to HTTP2, suggesting v1.0 and 1.1 would still work - which they don't because there aren't any ciphers they support left.

I love Plesk for making configuration mostly easy and taking lot's of work from me - but at the same time I hate it for interfering with my working configurations way too often (either after an update or simply when changing e.g. mail server settings - and plesk then goes on to mess up my postfix configuration kicking out dSpam, other blocklists and setting SSL to a weak standard again (and messing up my certificate/key settings because I placed them in a different location and not always want to symlink everything (which might create other problems in the future). But that's all off topic.

But back to topic:
I think the Mozilla Configurator is a good starting point - they prefer AES128 over 256 which you can agree or disagree with (they do it in favor for the server load/performance and because it's still considered safe "enough").

And ALPN is supported in OpenSSL 1.0.2 I believe. But for example RHEL/CentOS 7 still ship with 1.0.1 and therefore ALPN is unfortunately not present (and compiling your own nginx wih ossl 1.0.2 gives you lot's of responsibility in terms of staying up to date / watching out for security updates etc).

I use intermediate configuration of the Mozilla Configurator but I removed all DES entries at the end (which is considered insecure and still leaves TLS1 ciphers for older clients (I still don't consider Android < 4.4.2 old because I think many phones with that OS unfortunately get sold x.x))

For people who want to harden their setup I recommend testssl.sh. which states (for the Mozilla SSL intermediate setup):

Triple DES Ciphers offered (NOT ok)
BEAST (CVE-2011-3389) TLS1: DES-CBC3-SHA EDH-RSA-DES-CBC3-SHA
AES128-SHA DHE-RSA-AES128-SHA AES256-SHA
DHE-RSA-AES256-SHA ECDHE-RSA-DES-CBC3-SHA ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
VULNERABLE -- but also supports higher protocols (possible mitigation): TLSv1.1 TLSv1.2

Removing the ciphers containing DES fixes the first point, but removing all of them results in TLS1 having no ciphers left (so it's up to the admin/host/you to decide if you still want to support Android < 4.4.2 and IE < 11).

In the end I ended up with:

ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:!DSS';

which drops Triple DES but still leaves

BEAST (CVE-2011-3389) TLS1: AES128-SHA DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA
VULNERABLE -- but also supports higher protocols (possible mitigation): TLSv1.1 TLSv1.2

but supports these clients

Running browser simulations (experimental)

Android 2.3.7 TLSv1.0 DHE-RSA-AES128-SHA
Android 4.0.4 TLSv1.0 ECDHE-RSA-AES128-SHA
Android 4.1.1 TLSv1.0 ECDHE-RSA-AES128-SHA
Android 4.2.2 TLSv1.0 ECDHE-RSA-AES128-SHA
Android 4.3 TLSv1.0 ECDHE-RSA-AES128-SHA
Android 4.4.2 TLSv1.1 ECDHE-RSA-AES128-SHA
Android 5.0.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256
Baidu Jan 2015 TLSv1.0 ECDHE-RSA-AES128-SHA
BingPreview Jan 2015 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256
Chrome 47 / OSX TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256
Firefox 31.3.0ESR / Win7 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256
Firefox 42 / OSX TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256
GoogleBot Feb 2015 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256
IE6 / XP No connection
IE7 / Vista TLSv1.0 ECDHE-RSA-AES128-SHA
IE8 / XP No connection
IE8-10 / Win7 TLSv1.0 ECDHE-RSA-AES128-SHA
IE11 / Win7 TLSv1.2 DHE-RSA-AES128-GCM-SHA256
IE11 / Win8.1 TLSv1.2 DHE-RSA-AES128-GCM-SHA256
IE10 / Win Phone 8.0 TLSv1.0 ECDHE-RSA-AES128-SHA
IE11 / Win Phone 8.1 TLSv1.2 ECDHE-RSA-AES128-SHA256
IE11 / Win Phone 8.1 Update TLSv1.2 DHE-RSA-AES128-GCM-SHA256
IE11 / Win10 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256
Edge 13 / Win10 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256
Edge 12 / Win Phone 10 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256
Java 6u45 TLSv1.0 DHE-RSA-AES128-SHA
Java 7u25 TLSv1.0 ECDHE-RSA-AES128-SHA
Java 8u31 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256
OpenSSL 0.9.8y TLSv1.0 DHE-RSA-AES128-SHA
OpenSSL 1.0.1l TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256
OpenSSL 1.0.2e TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256
Safari 5.1.9/ OSX 10.6.8 TLSv1.0 ECDHE-RSA-AES128-SHA
Safari 6 / iOS 6.0.1 TLSv1.2 ECDHE-RSA-AES128-SHA256
Safari 6.0.4/ OS X 10.8.4 TLSv1.2 ECDHE-RSA-AES128-SHA
Safari 7 / iOS 7.1 TLSv1.2 ECDHE-RSA-AES128-SHA256
Safari 7 / OS X 10.9 TLSv1.2 ECDHE-RSA-AES128-SHA256
Safari 8 / iOS 8.4 TLSv1.2 ECDHE-RSA-AES128-SHA256
Safari 8 / OS X 10.10 TLSv1.2 ECDHE-RSA-AES128-SHA256
Safari 9 / iOS 9 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256
Safari 9 / OS X 10.11 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256

(note: compared to SSLLabs testssl.sh states Android 4.4.2 using SHA instead of SHA256 - I actually don't know if this is true but in case it is you'd even lose Android < 5.0 if you disable all SHA(1) ciphers).

About the BEAST attack I don't know how serious it still is.

 

[trialotto]

@Arne Fahrenwalde

As seems to become custom, I like your last post.

Sure, some of your statements are "open for discussion", but I suggest that I will start a personal conversation with you. Just did that.

In my current response, I will stick to the general remarks, that are relevant or beneficial to all forum members.

First of all, AES128 is just not safe enough: AES256 should be preferred (that is different from being obligatory).

Second, you stated

And ALPN is supported in OpenSSL 1.0.2 I believe. But for example RHEL/CentOS 7 still ship with 1.0.1 and therefore ALPN is unfortunately not present (and compiling your own nginx wih ossl 1.0.2 gives you lot's of responsibility in terms of staying up to date / watching out for security updates etc).

and I can react to that with the remarks that

a) most OSes have their own (compiled) versions of OpenSSL, which are often (read: almost always) updated to be safe with respect to the latest vulnerabilities,

b) one has to track development and release branches of OpenSSL packages of the specific OS, which is quite inconvenient by the way,

c) one has to make sure that OpenSSL packages, provided with the OS, are regularly updated: people tend to forget that.

In short, the OS provided OpenSSL package is often "okay".

Third, you stated

I love Plesk for making configuration mostly easy and taking lot's of work from me - but at the same time I hate it for interfering with my working configurations way too often (either after an update or simply when changing e.g. mail server settings - and plesk then goes on to mess up my postfix configuration kicking out dSpam, other blocklists and setting SSL to a weak standard again (and messing up my certificate/key settings because I placed them in a different location and not always want to symlink everything (which might create other problems in the future). But that's all off topic.

and I must emphasize that it really is ON topic.

Plesk is a little bit odd, in the sense that it is a ready-steady-out-of-the-box hosting panel, with a lot of convenience, that seems to suggest that nothing has to be done, except for the installation of the Plesk instance itself.

The problem is that Plesk still requires that a sysadmin or a Plesk admin has a good look at the system configuration and, more important, the security configuration.

It is not a surprise that Plesk applies some general, "must do" security configuration: not every individual scenario can be accounted for, a "general approach" is almost necessary.

Now, with the above, your "problem" becomes actuall on topic, for two reasons:

a) Plesk ignores individual (security) scenario´s, by applying a "general approach" over and over again, (and)

b) Plesk´s general, "must do" security configuration is not tight enough, in the sense that is must be hardened.

In short, what you experience (probably as a "problem"), is actually a pitfall in the current Plesk (default) configuration, so it really is ON topic.

Finally, you stated a lot of things with respect to tests and cipher suites.

To be honest, you should not worry about that at all, neither confide in most of the online tests (they can be very unreliable).

In all of the relevant scenario´s, there is always a solution that does not involve weak ciphers or bad security config settings.

Moreover, most of the "dangers" signalled online or with some online tests are not really dangers at all.

On the contrary, some of the default settings in Plesk and/or some of the standard advices online really include unsafe security setups.

I can go on, but I will not do so: it is just required to find a balance between all relevant factors, which factors are many in number and which factors vary across scenario´s.

In essence, I think it is wise to start with the hardening of the default Plesk installation and that certainly is not contained to ciphers, TLS, OpenSSL etc.


In conclusion, let´s not talk, let´s start with some security hardening: see my PM.

Regards....

 

[Franco]

Apparently it works for me on apache 2.2.15 (CentOs), is it normal?

 

[IgorG]

Apparently it works for me on apache 2.2.15 (CentOs), is it normal?

Do you mean HTTP/2? As I wrote before, support of HTTP/2 has been added since Apache version 2.4.17 as mod_http2.

 

[Franco]

Yes, http/2 it seems to work on my apache 2.2 (at least that's what my browser says), is that normal? I am using nginx with apache and let's encrypt certificate on a test WP website and the browser shows the blue lightning.

 

[trialotto]

@Franco,

Actually, the answer is of the type "yes and no" and I will explain.

In general, it is "normal behaviour" in the Apache + Nginx stack and this combination of components identifies the "yes" and "no" parts of the answer:

a) NO - Apache 2.2.x does not support HTTP/2,

b) YES - Nginx 1.9.14 does support HTTP/2, if and only if enabled.

What actually happens is the following:

- Nginx is the reverse proxy, listening to requests on port 80 (http) and 443 (https)
- all http and https requests are passing through Nginx
- given that Nginx HTTP/2 support is enabled, Nginx accepts http and https requests via HTTP/2 protocol
- given that most client implementations (read: modern browsers, in a nutshell) require TLS for HTTP/2 support, Nginx accepts (only) https requests via HTTP/2 protocol (in general)
- Nginx forwards all requests via HTTP/2 protocol to Apache, with Apache itself not necessarily required to support HTTP/2 protocol

That is about it, at least in rough outlines.

In short, your Apache web server does not support HTTP/2 protocol, but that is not necessary, as long as Nginx supports HTTP/2 protocol.

Note that Nginx actually should be able to accept http requests via HTTP/2 protocol, but will almost never do so, given the nature of most client implementations: TLS required.

In conclusion, the lack of HTTP/2 support by Apache has been resolved by putting the Nginx reverse proxy in front of Apache, that is all there is to it.

Hope the above explains a little bit.

Regards.....

 

[Franco]

Hi Trialotto, that's a very good explanation, I almost understood everythig

Just on your statement about the nature of client implementations that won't support TLS. Perhaps you means older versions (still used by majority of users)? All latest versions of FF, Chrome and even Edge support it out of the box, I think, which should be a large number out there, albeit certainly much less than 50% of users. Or am I not getting the point?

Regards

 

[trialotto]

Hi Trialotto, that's a very good explanation, I almost understood everythig

Just on your statement about the nature of client implementations that won't support TLS. Perhaps you means older versions (still used by majority of users)? All latest versions of FF, Chrome and even Edge support it out of the box, I think, which should be a large number out there, albeit certainly much less than 50% of users. Or am I not getting the point?

Regards

@Franco,

You are exactly getting the point: all modern (mainstream) browsers are having native HTTP/2 support and will connect via HTTP/2 if and whenever possible.

This is also a major drawback of enabling the HTTP/2 protocol via the Nginx reverse proxy: modern browsers will "force" HTTP/2 connections.

Maybe that does not seem to be a disadvantage, but it can actually become problematic: consider the two following scenario´s

a) an Apache + Nginx stack, with

- Apache not supporting HTTP/2,
- Nginx supporting HTTP/2 and also able to serve > 10 K requests per second,

implying that client implementations, that use multiplexing (read: multiple request over a single TCP connection) for HTTP/2 based requests, can lead to

- Nginx accepting > 10K multiplexed requests per second and forwarding these multiplexed requests to Apache, with Apache dealing with each request on per-request basis,
- Nginx forwarding (more than) n times 10K requests per second, if a multiplexed request is (the combination of) on average n (individual) requests per second,
- Apache overloading and overusing resources, even if the number of worker processes is perfectly fine-tuned for performance.

In normal circumstances, all of the above is not that troublesome, in the sense that it rarely occurs that the Apache + Nginx stack reaches it´s limits.

However, when under some kind of distributed attack, the stress on the (web) server can become quite huge (and bigger than in the case of the HTTP/1 protocol).

The problem is that almost every server is daily under attack, as a result of various automated hack scripts (just have a look at the fail2ban or apache logs).

In short, implementing HTTP/2 in the current default Apache + Nginx stack would at least require some decent security settings.

b) the HTTP/2 protocol with pipelining (read: multiple HTTP requests are sent on a single TCP connection without waiting for the corresponding responses) enabled, with

- most modern client implementations (read: mainly mainstream browsers) not supporting pipelining by default,
- automated hack scripts potentially exploiting the native pipelining support in the HTTP/2 protocol, with an Apache overload as the undesirable endresult (see point a).


In general, enabling HTTP/2 can lead to drastic increases in the load times of web pages, but that performance increase can come with a penalty.

It should be duly noted that the best performance can be obtained with caching of some kind, with HTTP/2 being an additional option to increase performance even further.

In most cases, performance improvements, when adding HTTP/2 support to enhance performance of caching mechanisms, are not significant.

In short, I would always recommend to start with increasing performance by introducing caching mechanisms, before "simply enabling" HTTP/2 protocol.

However, I must admit that in more advanced scenario´s, HTTP/2 implementations are very valuable.

Nevertheless, these kinds of "advanced scenario´s" often do not apply to the case of a single Plesk instance.


In conclusion, in the context of Plesk, it is just a little bit "strange" to enable HTTP/2 protocol on a high performant Nginx reverse proxy, whilst not having HTTP/2 support on Apache.

Hope the above explains a bit.

Regards....

 

[Franco]

Very interesting, I am impressed. Well, I have memcached running, would that help?
Also, shall I upgrade to apache 2.4? Plesk does not have it and I 'd have to do it manually. Hard to do? What do you suggest? I read somewhere that it would be better to be on CentOs 7 for that (I am on 6, final).

Regards

 

[trialotto]

@Franco,

I am a fan of "keeping it simple": I would not recommend to upgrade Apache, one could better upgrade the OS to CentOS 7 (or Ubuntu 14.04.4, rather user-friendly).

Both OSes ship with an Apache 2.4.6 or 2.4.7 version.

The Apache version required for HTTP/2 support is Apache 2.4.17 (and that is not a default package on all OSes, if I am not mistaken).

So, if you would a "better version" of Apache: just upgrade.

Now, if you really want that, then there is a problem: your current Apache 2.2.x settings are not really compatible with the settings of Apache 2.4.x.

But that problem can be easily resolved by just spinning up a new VM, do a clean install, migrate the site data and use the pre-flight check of Plesk Migrator to adjust settings.

That way, you would be at least in "control" of the adjustments that have to be made to upgrade to Apache 2.4.x.

With respect to the "memcached part" of your post: I am always in favour of Redis.

In essence, Memcached and Redis perform similar, with the exception that Memcached has considerable limitations for field values (these limitations hardly apply to Redis).

But Redis will outperform Memcached, as soon as the caching gets more complicated/advanced and/or if the server has to serve a lot of cached requests.

In short, starting with Redis as the primary caching mechanism is the best thing to do.

And, do not forget to use Nginx to enforce (optimal) browser caching, that will also help a lot.

By the way, if you have any questions, feel free to start a personal conversation with me (just send me a PM)

Regards.....

 

[Franco]

Make sense, thanks. I may go for a new VM indeed, as soon as I have a chance to plan for it.

Regards

 

[dash]

Hi,

First of all, thanks for so interesting conversation for people involved.
Based on discussed points I've compiled Frequently Asked Question in KB: https://kb.plesk.com/en/128733
The section includes questions regarding apache, ALPN, old browsers support, customisations of cipher list and additional troubleshooting materials.

Regards

 

[trialotto]

@dash,

On the one hand, I am very grateful, surprised and happy with the very to-the-point Q&A in the KB article.

On the other hand, I am getting a little bit annoyed, amongst others for the following reasons:

a) the HTTP/2 cipher suites are too strict (and not really adequate, see next point),

b) the http2_pref utility literally reverts settings applied by the pci_compliance_resolver, with the following notes:

- PCI compliance is not effectively undone by the cipher suite introduced by the http2_pref utility,
- the cipher suite introduced by the http2_pref utility is more "strict", in the sense that PCI compliant settings "become" more "strict" than actually is required

and the "strict" settings for the cypher suite can cause connection issues, which can create confusion when trying to support PCI compliance for a Nginx instance with HTTP/2 support,

c) Nginx is not used to it´s full potential to harness the HTTP/2 protocol power, in the sense that custom Nginx templates are not supported: this is not really necessary AND dangerous, since this also impedes the common security measure of Nginx TLS/SSL hardening,

d) the HTTP/2 protocol itself does not require encryption: support for http URIs (no encryption) and https URIs (encryption via TLS1.2 or higher) is present, with any Plesk instance

- NOT implementing HTTP/2 on Nginx port 80 (not a problem, this is "good" to some extent)
- implementing HTTP/2 on Nginx port 443 (this is good)
- NOT implementing a redirect with common Nginx directive: redirect 301 https://$host$reques_uri;

and the above implies that

- only HTTP/2 support for https requests is provided
- normal http requests are still being served through Nginx port 80, without being redirected to Nginx port 443, on which HTTP/2 protocol is active,

and, in short, HTTP/2 support is only "partially active", which is bad to some extent.

e) the activation of HTTP/2 support on (only) Nginx port 443 is not equivalent to providing HTTP/2 support for a specific domain,

and all of the above is not even an exhaustive summary.

The real PROBLEM is that,

- without a default Nginx configuration that automatically enables a http to https redirect in Nginx (for instance, when http2_pref utility is being run), (and)
- without the possibility to use a custom Nginx template that creates a http to https redirect via Nginx directives (custom templates are simply not allowed with the http2_pref utility),

there simply is a partial implementation of the HTTP/2 protocol.

Why do I call this a problem?

Apart from the fact that the current setup can be a security blackhole, the problem originates from the fact that it is barely possible to create the appropriate Nginx redirect (read: http to https redirect with Nginx directives) with custom Nginx directives (read: those customizations ending up in the vhost_nginx.conf file).

The latter is primarily due to the fact that the vhost_nginx.conf file is equal for both the server block handling https connections and the server block handling http connections.

In my humble opinion, HTTP/2 has gradually become a hype with an early release (in the opinion of many experts on the topic "too early"), with many negative side-effects.

As a result, fast implementation of HTTP/2 has also become a hype to some extent.

And, to be honest, it is good to see HTTP/2 support for Nginx in Plesk (that support is provided with the Nginx binary), but the HTTP/2 implementation can surely be improved.

I am not able to predict the future, but the following scenario´s are feasible:

- the "strict" cipher suite will result in Plesk customers not enabling HTTP/2 support (consider the case of most Android devices: https requests cannot be served via HTTP/2)
- specific kinds of distributed (new, relatively innovative) hack attacks will be able to break servers
- HTTP/2 based requests will overload Apache
- HTTP/2 based requests can lead to "more responses requested by a client implementation" (the "push" part of HTTP/2), which is undesirable if "FPM is served by Nginx"

and so on.

In conclusion, I have mixed emotions about the whole HTTP/2 protocol support within Plesk, even though I am sure that improvements have to be made.

I am open to discuss the whole matter in a private discussion, so send me a PM if you want to.

Regards.......

 

[trialotto]

@dash,

By the way, just read the DevBlog article (https://devblog.plesk.com/2016/04/http2-lets-encrypt-for-wordpress/). Nice!

However, some tips for improvement:

a) it is stated in the DevBlog article that

if ($scheme = http) {

return 301 https://$server_name$request_uri;

}

should be used and that is (essentially) fine, but can result in some problems (of various kinds).

It is better to use the (magical) $host variable, which is equal to (in order of precendence)

- the host name of the request line,
- the host name from the "Host" request header,
- the server name matching the request,

and this essentially provides some "freedom" in URI definition (which "freedom" is sometimes required and/or misused by specific WordPress plugins).

Note that this usage of the $host variable aligns the return directive with the proxy_set_header directive in the Nginx default configuration, which is a good thing.

b) it is better to remove lines of the type

if ($scheme = http) { ... }

from the vhost_nginx.conf file (which file contains the "Additional Nginx directives" specified via the Panel).

It is better to add a custom server block of the type:

server {
listen .... :80;
server_name .... ....;

return 301 https://$host$request_uri;

}

with the above server block replacing the default server block that handles http connections.

This simply prevents that Nginx finds matching patterns, before even matching a URI pattern to the "if ($scheme = http) { ... }" part of the Nginx configuration.

Note that the before mentioned "mismatch" is not very likely to occur for a WordPress instance (at least, if "pretty" permalinks are used), but specific plugins and/or specific WP setups and/or other applications (other than WP) can be subject to this mismatch.


Regards....

 

[TobiasP]

What ciphers should I set/or add to the default, to not block out all the older Safari and Android users?