Resolved XFrame Options / X-XSS-Protection / X-Content-Type-Options / HSTS

[learning_curve]

BTW As part of this, if anyone is sharp at .htaccess > Nginx conversions, can they figure this one out?

In a simple .htaccess file, it's this:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /

# Re-Direct
  Options +FollowSymlinks
  RewriteCond %{REMOTE_ADDR} !=*IP Address*
  RewriteRule ^(.*)$ https://*New URL* [R=301,L]
</IfModule>

In "converted" Nginx code, it's currently this

if ($remote_addr !~ "=*IP Address*"){
    set $rule_0 1$rule_0;
}
if ($rule_0 = "1"){
    rewrite ^/(.*)$ https://*New URL* permanent;
}

which works but only permanent, as opposed to conditional on the provided IP address (as the .htaccess file is). It's a one off addition / requirement, on one domain and as such, certainly not an area of expertise for us!

 

[learning_curve]

Update: All our other Nginx Proxy / Apache domains have now been corrected by us manually via Additional nginx directives and just like the Nginx only domains that we fixed first, we can achieve everything that's need (A or A+ everywhere and no issues) having completed all that work now. The only outstanding item on all the domains, is HTTP Public Key Pinning, becasue it takes quite a lot of specific extra work first on each domain. We hadn't added this last item anyway before the original reason for starting this thread, but it's the final item needed to finish everything off properly, so we are commited to doing it now

As posted previoulsy, we haven't figured out why this stop working when it was specified server-wide via Nginx until recently, but the most important issue (for us) was restoring normal service (plus enhancement) which is almost done now. Maybe somebody from Plesk can add some comments on this, in due course

 

[mr-wolf]

I've read the public key pinning, but I don't think I will ever implement it.
Especialy not when LetsEncrypt certificates are involved.

I would be more pleased if they also added CA-pinning.
It would make it better maintainable and therefore used instead of ignored by most.
I checked out one of those A+ sites that are published on that site and it was clearly not a real site, but an experiment.

I would consider a CA-pinning scheme if it existed.
It would prevent a rogue site from setting up a LetsEncrypt site (easy to do if they hacked your DNS) while you are only using Comodo Level x
It's of course less secure than the existing implementation, but it's better than using neither.

If I would want to secure my domain I would only need to publish 1 certificate and that would last as long as I would stay with that CA on that level.

If you're paying top dollar for a good certificate and would advertize that in your site, it would mean that a certificate from a DigiNotar-like CA would get rejected. The famous Iran vs Google attack could have been prevented by a CA-public-key-pinning.
If the CA that you have chosen gets hacked you would be lost (with my proposed scheme), but that is highly unlikely.

Knowing that security experts almost always dismiss schemes where they can see a flaw, I don't think we will ever get something like that.
Still I think it's a more pragmatic approach.

What's the use of a highly secured system that no-one wants to use?

EDIT: I may have misunderstood the PKP-specification in that it's already a CA-pinning. Will study some more, but not now....

 

[learning_curve]

I've read the public key pinning, but I don't think I will ever implement it. Especialy not when LetsEncrypt certificates are involved...... EDIT: I may have misunderstood the PKP-specification in that it's already a CA-pinning. Will study some more, but not now....

Yeah, it's a big read c/w detailed prep and with minimal return really in our opinion, but we're going to try just one domain first and then take a view....

 

[virtubox]

I've read the public key pinning, but I don't think I will ever implement it.
Especialy not when LetsEncrypt certificates are involved.

I would be more pleased if they also added CA-pinning.
It would make it better maintainable and therefore used instead of ignored by most.
I checked out one of those A+ sites that are published on that site and it was clearly not a real site, but an experiment.

I would consider a CA-pinning scheme if it existed.
It would prevent a rogue site from setting up a LetsEncrypt site (easy to do if they hacked your DNS) while you are only using Comodo Level x
It's of course less secure than the existing implementation, but it's better than using neither.

If I would want to secure my domain I would only need to publish 1 certificate and that would last as long as I would stay with that CA on that level.

If you're paying top dollar for a good certificate and would advertize that in your site, it would mean that a certificate from a DigiNotar-like CA would get rejected. The famous Iran vs Google attack could have been prevented by a CA-public-key-pinning.
If the CA that you have chosen gets hacked you would be lost (with my proposed scheme), but that is highly unlikely.

Knowing that security experts almost always dismiss schemes where they can see a flaw, I don't think we will ever get something like that.
Still I think it's a more pragmatic approach.


What's the use of a highly secured system that no-one wants to use?

EDIT: I may have misunderstood the PKP-specification in that it's already a CA-pinning. Will study some more, but not now....

HPKP (HTTP Public Key Pinning) isn't easy to understand and pretty hard to deploy because most of letsencrypt client generate a new private key when you renew your certificate. And in case of failure, all your clients may not be able to access to your website until the HPKP max-age is over.
But it's another proof than Let's Encrypt do more to secure internet than any other CA.
If you can use google to translate french, this article is the best one about all new security settings you can use with letsencrypt :
Comment avoir une excellente configuration HTTPS en 2017 ?

 

[G J Piper]

I can verify that a custom configuration file in /etc/nginx/conf.d/ is not able to add headers in Plesk 17.5.3 for some reason.

I'm using nginx as a proxy so Apache configs should never come into play if I need the headers added to static files served by nginx.

The headers are added correctly if the directives are put into "Additional nginx directives" section in Plesk interface, but this doesn't allow you affect all your hosted sites globally like making a custom configuration file. I would like it to work.

 

[learning_curve]

I can verify that a custom configuration file in /etc/nginx/conf.d/ is not able to add headers in Plesk 17.5.3 for some reason...................The headers are added correctly if the directives are put into "Additional nginx directives" section in Plesk interface, but this doesn't allow you affect all your hosted sites globally like making a custom configuration file. I would like it to work.

Thanks @G J Piper Your first sentance was the exact reason for us posting this thread (it used to work perfectly until recently)

Your second sentance is what we have now after manually correctly each domain by adding code into Additional nginx directives as you yourself have indicated. It all works perfectly again but only by setting it up this way...

It may or may not be a bug because, it could just be additional settings / files / permissions etc that are now required and nothing more than that? Hopefully Plesk will advise in due course

 

[mr-wolf]

It may or may not be a bug because, it could just be additional settings / files / permissions etc that are now required and nothing more than that? Hopefully Plesk will advise in due course

What I learned in the process of tinkering with configs in the last week is that what Nginx is proxying for is of influence on what headers can be detected.
Plesk has nothing to do with all this. If it's anything than it's either one of these 3; Nginx, the server for which it is proxying or the sites we are using to detect the headers.

The last suspect is what most of you are not considering.
I have a perl-written SMTP proxy (ASSP) that has a webserver running on localhost.
I'm using Nginx to make that site accessible using https. This means that I can access it on the normal port 443 using virtual hosting.

I had a situation where the Nginx-config would lose all headers according to the detection sites.
If I merely changed the service for which it was proxying for (proxy pass http://127.0.0.1:port) the headers would appear (in that site).
These webservers (not Apache) do nothing with headers.

ASSP needs authentication immediatly upon connecting.
SSLlabs admits that has problems with such sites. They suggest using "always". So we could just be chasing ghosts...
Anyhow...

When I include all the headers in the special config file (/etc/nginx/conf.d/zz090_assp.conf) they magically appear....
Those headers should already be included because they are already assigned outside the server{} by using /etc/nginx/conf.d/aa400_own_tweaks.conf
It seems it doesn't hurt to declare them again in the configuration itself.
On most sites it is not needed.

On 1 site (normal Apache) I had a warning that some headers are added twice.
I investigated this and it turned out that these are headers are defined in a PHP-section of the site itself. I don't think that's a problem either.

This does proof that @virtubox was right that adding headers behind the proxy are getting to the webclient. Somehow this didn't came out of the tests I did myself (but did on his).

As things are now, I think that the way I'm handling it now is the best.
This is of course a personal view which may be changed in the future.
You could copy it or you don't.

 

[learning_curve]

What I learned in the process of tinkering with configs in the last week is that what Nginx is proxying for is of influence on what headers can be detected. Plesk has nothing to do with all this. If it's anything than it's either one of these 3; Nginx, the server for which it is proxying or the sites we are using to detect the headers.The last suspect is what most of you are not considering....

Great post. However, there's a lot of 'if's' in there, very much like our own findings to be fair. FWIW, we have two sites where Nginx is NOT just a proxy o/s i.e there is no use of Apache at all. That made no difference whatsoever to the original problem that we outlined when opening this thread. In addition, the original problem only actually began, after some of the latest (but most welcome) Plesk updates. That could be just pure chance / bad timing / collateral damage as we have said before, but the specific timing or sequence of events is a 100% fact. Foruunately, we have sucessfully circumvented it now by manually switching from one method to another, which we have accurately described in all the previous posts. Until somebody far better qualified than us (from Plesk) says "Well, we've tested this and it's not Plesk at all, but... it maybe X, Y or Z so please check these and advise" there's no incentive (for us) to do any more re-work in the interim, only to then have to do it all again when the results come out! We'll be happy for a while now and are looking more deeply into HPKP meantime. @virtubox What was the answer to our much earlier question to you about Onyx release numbers?

 

[G J Piper]

If the custom configuration files are no longer able to "add headers" successfully, that leads me to believe that some other configuration file has appeared which removes or cancels all the nginx calls to "add headers" before they are actually added.
Could it be that the new Plesk Onyx 7.5.3 "Additional headers" configuration in the "Apache & nginx Settings" has something to do with it?
Does the code of this new capability remove all previously added headers before adding ones in the user interface box (attempting to reduce duplicates maybe)?

 

[learning_curve]

.....Could it be that the new Plesk Onyx 7.5.3 "Additional headers" configuration in the "Apache & nginx Settings" has something to do with it?.......

We guess you mean the configurable "Additional headers" option, on the menu provided at the top of the "Apache & nginx Settings" page? And therefore, if no custom values are entered here, none will be applied, regardless of any later file additions made via /etc/nginx/conf.d/* That's quite a sensible logic call We didn't actually try that specific exceptions / overwrite / priority test and we now have no header related files still located in /etc/nginx/conf.d/* Do you @G J Piper ? If so can you test that theory? That would rapidly explain the recent cease of this previous function...

 

[mr-wolf]

If the custom configuration files are no longer able to "add headers" successfully, that leads me to believe that some other configuration file has appeared which removes or cancels all the nginx calls to "add headers" before they are actually added.

No...

In one of my tests it is proven that by merely changing the service for which it is proxying the headers appear/disappear.
In the conf that I use for proxying ASSP I lost several headers (although they were server-wide defined). Merely changing the port to the one of rslsync, made them reappear.
By also adding these headers into that specific config I can make the headers appear when proxying ASSP.

As both services (ASSP and rslsync) have simple plain http servers I don't believe they do anything with the headers.

As i don't want to add some headers server-wide anyhow, I have no problem using the site-wide nginx directives.

The server-wide directives ARE working, but somehow not on all services.
I have that aa400_own_tweaks.conf and it adds the headers to almost all sites.

Still this could be ALL sites and the problem is not with our servers, but with the sites with which we test them.

By issuing nginx -T you are generating the config that nginx is working with.

All the configs are concatenated in the alphabetical order of the .conf files.
Directives outside the server{} statements are almost certainly executed first before those.

That's why Plesk probably didn't bother to make the ssl.conf a special name.

 

[learning_curve]

....In one of my tests it is proven that by merely changing the service for which it is proxying the headers appear/disappear......

Your set up is very different than ours (obviously we don't know about the setup that @G J Piper uses at the time of adding this post) but our question is: Have you actually tried the very simple test we mentioned? i.e. The content of the "Additional headers" option within the Plesk Panel overwriting the content of any header related files located within /etc/nginx/conf.d/ and if so, what happened? Unlike us (after all our manual domain specific conversions) you still have header related files located within /etc/nginx/conf.d/ that's why we are asking

.....All the configs are concatenated in the alphabetical order of the .conf files.....

Is this actually written somewhere? Yes it does make perfect sense, but it seems a very easy thing to not be aware of, if people were adding multiple files (for different process reasons) which is why we're guessing it must be clearly stated within reference Nginx guidance data or Nginx via Plesk guidance data somewhere? If this is always the case, it's definitely worth knowing

 

[mr-wolf]

Is this actually written somewhere?

To be honest I never checked that, but that's because I'm so sure it is. Besides that I already found out in some distant past when I had some unwanted behavior because I wasn't taking care of it.

You really need to have some control over it because a server_name can be a regular expression.
When you define a duplicate server_name, you will get a warning from nginx, not an error.
It doesn't have to, because the 2nd one will never be executed.
When you use a regular expression instead of a literal name it would not even be able to warn you.

That's why I have my autodiscover defined as last (zz095_autodiscover.conf) to be sure it doesn't clash.

EDIT:
It's written down here.
Read it several times... ;-)

How nginx processes a request

nginx first searches for the most specific prefix location given by literal strings regardless of the listed order. In the configuration above the only prefix location is “/” and since it matches any request it will be used as a last resort. Then nginx checks locations given by regular expression in the order listed in the configuration file. The first matching expression stops the search and nginx will use this location. If no regular expression matches a request, then nginx uses the most specific prefix location found earlier.

 

[G J Piper]

With testing I have been able to determine:
In the "Apache & nginx Settings" in the UI, the "Additional nginx directives" has priority over the "Common Apache settings -> Additional Headers" section.

If you add the same type of header in each, "Additional nginx directives" wins.
If you add different headers in each settings box, both are generated.

However, even with no headers in either box, the special config file I created in "/etc/nginx/conf.d/" with an add_header directive still does NOT add the header.

I did notice that even if no headers are made in the "Common Apache settings -> Additional Headers" section of the UI, it still puts an "add_header X-Powered-By PleskLin;" in the configuration file it uses (/etc/nginx/plesk.conf.d/vhosts/*.conf), which was not placed there in previous versions of Plesk. (and unfortunately no, removing all "add_headers" manually from the settings files does not allow the special conf.d settings add_header to work -- I tried it)

Hope this isn't too complicated of a post -- sorry about the complexity.

 

[learning_curve]

To be honest I never checked that, but that's because I'm so sure it is......EDIT: It's written down here. Read it several times... ;-)

Easily misunderstood yes, but we do see the point

 

[learning_curve]

With testing I have been able to determine:
In the "Apache & nginx Settings" in the UI, the "Additional nginx directives" has priority over the "Common Apache settings -> Additional Headers" section.....

Thank goodness we used "Additional nginx directives" to do all the changes manually to each domain - pure luck, but very happy with that and thanks for posting your test results!

....However, even with no headers in either box, the special config file I created in "/etc/nginx/conf.d/" with an add_header directive still does NOT add the header.....

Nirvana! This is the exact, specific reason that we first addded this thread to the forum

I did notice that even if no headers are made in the "Common Apache settings -> Additional Headers" section of the UI, it still puts an "add_header X-Powered-By PleskLin;" in the configuration file it uses (/etc/nginx/plesk.conf.d/vhosts/*.conf), which was not placed there in previous versions of Plesk. (and unfortunately no, removing all "add_headers" manually from the settings files does not allow the special conf.d settings add_header to work -- I tried it) Hope this isn't too complicated of a post -- sorry about the complexity.

Nope, very useful and clearly written for us thank you.

There is this earlier thread concerning removing the annoying PleskLin detail but it may be out of date by now?

 

[learning_curve]

Your set up is very different than ours ...... but our question is: Have you actually tried the very simple test we mentioned? i.e. The content of the "Additional headers" option within the Plesk Panel overwriting the content of any header related files located within /etc/nginx/conf.d/ and if so, what happened? Unlike us (after all our manual domain specific conversions) you still have header related files located within /etc/nginx/conf.d/ that's why we are asking ....

@mr-wolf One other thing, what about our first question? ^^ Any news on that?

We ask because this may also relate to this ".....It doesn't have to, because the 2nd one will never be executed....." that you posted earlier when kindly answering our other question about a reference point

 

[G J Piper]

Here is the answer:
Nginx add_header configuration pitfall

When Plesk moved the add_header directives into the "server" scope in the configuration files, it nullified the add_header capability upstream from that block. So, there's effectively no way to fix this from what I can tell, unless maybe they move the main configuration file's "include /etc/nginx/conf.d/" into the same server block.

Currently, any special config files containing "add_header" that are created in "/etc/nginx/conf.d/" are then in the main configuration file's "http" block. The "server" block is later included, downstream, which nullifies any "http" block settings for "add_header".

Update: Indeed I was able to test this theory. I was wrong last time when I said I removed the "add_header X-Powered-By PleskLin;" directive from the settings file created by the UI. There are actually TWO "add_header" directives in that file. After manually removing both of them, my custom add_header directives from the "/etc/nginx/conf.d/" directory finally work!

So, finally, a cause of this is Plesk having the "add_header X-Powered-By PleskLin;" added into each vhost's nginx configuration file. (and it is replaced every time there is an update to the UI settings)

If you don't do any "add_header" directives in the UI "Additional headers" section, and you manually delete the "add_header X-Powered-By PleskLin;" from the two places in the vhost config file, and you don't have any add_header directives in the "Additional nginx directives" area, then the custom config file will allow add_header directives.

Since adding the "Additional Headers" option in the UI, the ONLY way I can see for them to fix this would be to have another global setting with a global config file (separate) that is included in parallel to their current add_header directives. Basically inserting an "include /path/to/global/settings/nginx-global.conf" right before or after their add_headers directives the UI inserts into every vhost setting file.

 

[mr-wolf]

I did a

find /etc/nginx -type f -name \*.conf -exec http -il plesklin {} \;


And the only place where it's added is in forwarding sites. Where does Plesk add that header for you?
That may be the reason why more is working on my servers.

You are also referring to a server-wide nginx place to add directives. I don't know of any such place. In the Plesk interface??[/CODE]