• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved HSTS doesn't work anymore

@mr-wolf You had intersting hand selected ciphers. After I returned in the end back to my configuration like the last months with A+ but without OSCP stapling I tested your ciphers. YOUR ciphers are in the left side of the screenshot.
They are really not bad, but
they get less rating in SSLLABS, because they support less protocols. You looked too much on the red colored things. These are no errors. In this special case of handshakes RED MEANS GOOD. RED is better because its safer.
0,5% (375%) is not much less than 380 percent but it's a lil more secure.
BOTH sides, your ciphers and also the recommened ones by PLESK and @UFHH tested on the right side have A
Both tested with the same domain 5 minutes difference.

As I said and tested earlier.
It's not the ciphers that will get you from A to A+
It's the HSTS that does that. Without HSTS you will have no A+ there.

I have A+ on all sites (after adding the parameter always)

I used ciphers that were suggested by Igor and they generated support calls from clients not being able to see a https-site with their old browser.
I then used the Mozilla page (which I got from Igor as well, thanks) and didn't use modern on purpose.

When seeing that some ciphers that generated warnings (the word "warning") were used with browsers that didn't support SNI it wasn't of much use to keep them in. So I removed these.
To be honest I didn't give these ciphers and warnings much thought.
There is no use in using ciphers that are used by IE6 on XP when that browser can't connect anyhow because it does not support virtual hosting on https.

Never had a support call since regarding this subject.
 
Last edited:
As I said and tested earlier.
It's not the ciphers that will get you from A to A+
It's the HSTS that does that. Without HSTS you will have no A+ there.

I have A+ on all sites (after adding the parameter always)

I used ciphers that were suggested by Igor and they generated support calls from clients not being able to see a https-site with their old browser.
I then used the Mozilla page (which I got from Igor as well, thanks) and didn't use modern on purpose.

When seeing that some ciphers that generated warnings (the word "warning") were used with browsers that didn't support SNI it wasn't of much use to keep them in. So I removed these.
To be honest I didn't give these ciphers and warnings much thought.
There is no use in using ciphers that are used by IE6 on XP when that browser can't connect anyhow because it does not support virtual hosting on https.

Never had a support call since regarding this subject.

You are right about ssllabs, Non-commercial website like CryptCheck provide better report with up-to-date security consideration.
But in my opinion , there is no reason to use old SSL/TLS configuration for compatibility with old browser. TLS 1.2 was released in 2008, and TLS 1.3 is already available with Nginx 1.13.
Massive infections with ransomware on outdated operating systems during the last month show the issue doesn't come from our server configuration.
 
Massive infections with ransomware on outdated operating systems during the last month show the issue doesn't come from our server configuration.
I don't know what you're implying here and what's the link with the current subject.
Maybe the use of "old" software.
what you find "old" may not be regarded as "old" by many.

A friend of mine is working for a company that had its Microsoft's Active Directory and most of their modern OS's destroyed because of an exploit of SMB 1.0.
Only "Windows Server 2016" has SMB 1.0 turned off by default. That was the only server that survived.
Almost all clients, including Windows 10 got infected. I'm talking about 5000+ machines.

The root cause here is the NSA not abiding the law.
They find exploits in OS's and of course they want to use them to their full extent, but there comes a moment when they have to report these exploits to the vendor to minimize the risks of others finding that exploit and therefore hurting the country (or community of law abiding citizens) they are supposed to be protecting.
The law exists already exists for that and they are now exposed.

Not only did they fail reporting these exploits. These outbreaks of ransomware are directly caused by the NSA not guarding their exploits well enough and by failing to do so they got leaked. It's quite possible that these exploits would never have been found by others than the NSA.

Microsoft should of course have written their software better, but leaks are a given factor.
The NSA is good in finding these leaks and they are not there to help Microsoft. But in the longer run they need to report it before others find these as well.
 
Last edited:
The root cause here is the NSA not abiding the law.
They find exploits in OS's and of course they want to use them to their full extent, but there comes a moment when they have to report these exploits to the vendor to minimize the risks of others finding that exploit and therefore hurting the country (or community of law abiding citizens) they are supposed to be protecting.
The law exists already exists for that and they are now exposed.

I was talking about all computers running with outdated and unsupported Windows version, which are the only reason to keep older TLS version than v1.2.

For newer version like Windows 10, patched for this vulnerability was released on the March 14 , when wannacry attack began on Friday, 12 May 2017.
If NSA was using illegally exploits like SMB, it's system administrator job to secure their private network and to keep up -to -date their computers.

Another reason to use modern TLS configuration : Even the NSA haven't found a way to decrypt connection with TLSv1.2 with ECDSA certificates and Elliptic Curve Diffie-Hellman Exchange. Source : SafeCurves: Introduction
 
You are basing your info on published articles.
The firm my friend is working for had all their servers patched and was still successfully attacked last June.
Microsoft indeed claimed that their software was patched for these exploits. Fact remains that all servers were destroyed with the exception of Windows Server 2016.
All their software was "up-to-date".

Only Server 2016 has SMB 1.0 turned off by default.
The patching of SMB 1.0 seems therefore not to be adequate enough.

Patched Windows Server 2008R2 and Windows Server 2012 is not considered "old software".

If NSA was using illegally exploits like SMB, it's system administrator job to secure their private network and to keep up -to -date their computers.
I don't understand this sentence.
The system administrators just apply patches that Microsoft provides.

The NSA is not being illegal by discovering and using exploits (although not against their own citizens).
They are obliged by law to report these exploits after some time to Microsoft, Cisco and others.

That obligation was created to prevent the situation we're now in.
 
Official CVE report :
NVD - CVE-2017-0145
Microsoft bulletins :
Microsoft Security Bulletin MS17-010 - Critical Information
https://support.microsoft.com/en-us/help/4013389/title


The system administrators just apply patches that Microsoft provides.

Running a network with 5000 windows computer without VLAN, firewall or access policy groups doesn't require the help of NSA exploits to get in trouble.
It was already recommended to disable SMB in 2016. There are vulnerabilities on all operating systems, including linux, that's why system administrator job is to implement all configuration to secure their network.
 
Running a network with 5000 windows computer without VLAN, firewall or access policy groups doesn't require the help of NSA exploits to get in trouble.
It was already recommended to disable SMB in 2016. There are vulnerabilities on all operating systems, including linux, that's why system administrator job is to implement all configuration to secure their network.
You're right there.
Still, towards that company Microsoft is still claiming it couldn't have happened with all patches in place.
 
but have you added DNS records for IPv6 ?
I forgot to answer ths question.
I have only the AAAA record for domain, webmail, mail, ipv6, but not for ns1 and ns2 because I created my own nameservers only with two IPv4.
This was for reason that it is not possible to add correctly additional Ipv6 in Plesk IP-Pool. You can add them, but after each next reboot nginx and httpd (apache) templates will be corrupted. You have also to repair all IPv6 in IP-Pool. Everything seems to work until next reboot. Don't know if this issue is caused by Plesk or provider, or Ubuntu, or a mixture of one or more of these components which have to work together.
So I use IPv6 only for webhosting reasons and thinked about the idea to remove the standard IPv6 totally from Plesk. But I'm afraid because I know that IPv6 seems to have an importance in the virtual/real hosting complex of Plesk. My standard is more or less in sleep modus...seems to be...:)

As I said and tested earlier.
It's not the ciphers that will get you from A to A+
It's the HSTS that does that. Without HSTS you will have no A+ there.
I know this since half an year because by the help of @UFHH01 I had A+ from the beginning I activated it and it was great all the time.Also with OSCP stapling I had A+ for a short period. I don't know exactly when it started to never display HSTS, but it is around the time I tried to activate DNSSEC, no more since I tried to use own nameserver (DNS) and tried to install additional IPv6.
Yes I think its around the failing Ipv6 which also caused a problems with certificates orphans, webmail issues. Alls come at the same period of time playing with IPv6 setups and DNS.
From the Qualys documentation it's possible that HSTS is activated in my case, but it only won't be displayed. You can watch it. E.g. www.chattergallery.com.
Thanks for help
Greets
 
Last edited:
Why did you never explicitly say you tried the "always" and tested if it gave you A+?
Maybe you did, but I can't see it in any of your posts.
I mentioned it several times.
 
I did it just right now. Not for the first time. It's running on Qualys in this minute I write it. But it has no effect. I also created successfully dhparam. This has nothing to do with HSTS, but I don't why it won't work anymore with the same setup like the last 6 months with A+.
In nginx additional files ssl.conf, gzip.conf, 001_own_additional_ssl_hsts_.conf, zz010_psa_nginx.conf NOTHING changed, except the dhparam since yesterday and the 5th additional file aa500_psa_tweaks which wasn't created by me, it was the system.
2 hours ago I fully reinstalled PSA with patches, updates. Nothing takes effect here.
Okay I activated OSCP stapling...could this the reason, I think also no.
The reason must be somewhere else. PHP 7.1.7 I have compression on the flow, but this is also obsolet for this problem with HSTS.
No reason why.

ssl_session_timeout 10m;
ssl_session_cache shared:SSL:50m;

ssl_dhparam /etc/dhparam/dhparam4096.pem;

add_header X-Frame-Options SAMEORIGIN;
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options nosniff;
add_header Strict-Transport-Security 'max-age=15768000;includeSubDomains' always;

gzip on;
gzip_disable "MSIE [1-6]\\.(?!.*SV1)";
gzip_proxied any;
gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript image/x-icon image/bmp image/svg+xml image/gif image/jpeg application/atom+xml application/javascript image/png image/tiff image/x-ms-bmp application/font-woff application/json application/msword application/pdf application/postscript application/rtf application/vnd.apple.mpegurl application/vnd.ms-excel application/vnd.ms-fontobject application/vnd.ms-powerpoint application/vnd.wap.wmlc application/vnd.google-earth.kml+xml application/vnd.google-earth.kmz application/x-7z-compressed application/x-cocoa application/x-java-archive-diff application/x-perl application/x-rar-compressed application/x-shockwave-flash application/x-tcl application/x-x509-ca-cert application/xhtml+xml application/xspf+xml application/zip application/octet-stream audio/midi audio/mpeg audio/ogg audio/x-m4a audio/x-realaudio video/3gpp video/mp2t video/mp4 video/mpeg video/quicktime video/webm video/x-flv video/x-m4v video/x-mng video/x-ms-asf video/x-ms-wmv video/x-msvideo;
gzip_vary on;

ssl_session_timeout 10m;
ssl_session_cache shared:SSL:50m;

ssl_dhparam /etc/dhparam/dhparam4096.pem;

add_header X-Frame-Options SAMEORIGIN;
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options nosniff;
add_header Strict-Transport-Security 'max-age=15768000;includeSubDomains' always;

server_names_hash_max_size 1136;

#ATTENTION!
#
#DO NOT MODIFY THIS FILE BECAUSE IT WAS GENERATED AUTOMATICALLY,
#SO ALL YOUR CHANGES WILL BE LOST THE NEXT TIME THE FILE IS GENERATED.
include /etc/nginx/plesk.conf.d/server.conf;
include /etc/nginx/plesk.conf.d/webmails/*.conf;
include /etc/nginx/plesk.conf.d/vhosts/*.conf;
include /etc/nginx/plesk.conf.d/forwarding/*.conf;
include /etc/nginx/plesk.conf.d/wildcards/*.conf;
 
According to the site Analyse your HTTP response headers that was posted in this thread by virtubox you are not providing any of the required headers at all and they are giving you an F.

https://schd.io/4lGd


I'm getting a B on that site (https://schd.io/44fk).
The security features that I need to put in place to reach an even higher level are only possible if we are also responsible for the content.
But let's be pragmatic...it's not a bank...

Oh... speaking of banks
I thought it was a good opportunity to test the banks in my country:

C https://schd.io/4lGm ASN bank
C https://schd.io/cAI ING bank
D https://schd.io/4lGu ABN AMRO bank
E https://schd.io/1aI Rabobank

It didn't surprise me much as most also don't provide decent SPF, DKIM and DMARC for their mail.
The hypocrites do have a big budget for making commercials to make the public aware of cybercrime.
 
Back
Top