I'd argue it should be downgraded to a B for not providing more security to more people. TLS 1.2 can be configured to provide grade A+ security and many, many people are still using clients that do not support TLS 1.3.

I don't myself but it does depend on the website if the website chooses to support TLS 1.3 as all of their users are using modern browsers then I don't think it should be downgraded on an SSL security website as technically it is equal or more secure than TLS 1.2

Oh, well private web sites are different. SSL Labs is designed to test public web sites that do not dictate which clients people can use.

Currently, Can I Use, estimates global usage of TLS 1.3 at around 84%. If a public website turns off TLS 1.2, then SSL Labs must downgrade it for unnecessarily blocking about 16% of potential visitors.

If a website's traffic through TLS 1.2 is very low (similarly to how TLS 1.1 was) then I don't see an issue with turning off TLS 1.2. As mentioned below Mozilla's Modern TLS configuration already disables TLS 1.2. I think Qualys should prefer security over a smaller amount of users not being able to connect which a website would consider before dropping TLS 1.2 anyway.

System administrators may analyze their own traffic patterns and disable protocols that do not meet their own threshold of support.

Unfortunately, (fortunately?) SSL Labs does not know the traffic patterns to each website and must grade based on general traffic. Generally, more than 15% of the public internet is still using a client that does not support TLS 1.3.

Think of it this way, how could SSL Labs give an A+ to one of the major websites (Google, Facebook, etc) if they turned off TLS 1.2 and cutoff access to about 15% of the world.

TLS 1.2 can be configured to provide excellent security with no known vulnerabilities. The people at Mozilla still recommend their Intermediate TLS configuration with TLS 1.2 and TLS 1.3. Personally, I feel it is reasonable to require a website to provide more security to more people to get an A+ vs an A.

while TLS 1.2 can be configured to provide excellent security, it often isn't. many servers still use RSA key exchange and CBC cipher suites. some even use 3DES. some have catastrophic vulnerabilities in their GCM implementation due to nonce reuse (nonce-disrespect/README.md at master · nonce-disrespect/nonce-disrespect · GitHub). many use DHE cipher suites with insecure DH parameters. all of these issues are fixed in TLS 1.3.

For services that don't need compatibility with legacy clients, such as Windows XP or old versions of OpenSSL. This is the recommended configuration for the vast majority of services, as it is highly secure and compatible with nearly every client released in the last five (or more) years.

I have 7 web sites at home on two Wordpress servers I use Godaddy 5 site SSL certs for two years. It is an hour of work to rekey and change the FortiOS SSL Deep Inspection and all the config files over to new certs. Let's Encrypt still has issues and was just hacked.

I have a blog page that gets more Severity 5 attacks in a day than most corporations see in a month. Security is a priority for my sites. My servers are Ubuntu 20.04. I keep all components for Wordpress and OpenSSL on the latest version. My servers are updated several times a week.

At work, I run a corporate data center. We are under Covid lockdown. My users come in through Citrix to work. Many switched back to Windows 7 x64 because Windows 10 on Citrix is horrible. Citrix and I have been working for 4 weeks on it. First rule of the CISSP is CIA. You need to make your data available. You need to balance vulnerabilities and threats. You can make it so secure that you lose customers and viewers.

It'll be a few hours work upfront to define all your FortiOS configuration as code, which you can then store in a version-controlled git repository. When you get a new certificate, it's as simple as uploading your private and public keys to some secret storage somewhere, and "terraform apply" will do all the grunt work of reconfiguration for you.

So Microsoft stopped giving out bad patches that crashed Windows 7 x64. They now to it to Windows 10. My users are on Firefox and Chrome. Windows 7 x64 is TLS 1.2 compliant. Windows 7x64 has no issues with Citrix. Windows 10 when it connects in TCP mode is slower than a 286. Citrix has been working on a Windows 10 fix for 4+ weeks.

Even my FortiOS 6.4 minimum is TLS 1.2.

Management rather have users functional than adding a bit of security. They are behind a Fortigate 800 series firewall that is fully patched and secure.

Windows 7 x64 with all the security patches and service packs installed should close the holes. Patches on Equifax were missed. I attend many Cyber Security conferences. Most don't have WSUS servers to keep patches on workstations up to date. They patch 90-120 days out. This caused Equifax issue. Many of them are more concerned with DLP from an employee than a severity 2 event from a 13 year old hacker.

My WSUS server brings down every patch from Microsoft. Tells me then they are applied or failed. SQL, Exchange cumulative updates are applied every quarter. All the hardware is patched twice a year from HP and VMWare. I even apply the VMWare Patch Tracker patches.

Microsoft 5x since they said no more Windows 7 patches, dropped Windows 7 patches. Vista they were patching for 3 years. Security patches on critical non-fixed bugs are done by Microsoft. We have new Windows 10 workstations. Work great in the office. They have issues on Citrix. I hope Michigan lifts this Dem-Panic and our Governor is recalled soon.

I keep my Ubuntu servers fully up to date at home. I moved my second Word Press server to Ubuntu 20.04. Every Ubuntu server is now 20.04. When LTS enablement comes out for kernel, I will apply it. I have latest OpenSSL, WP, Apache2, PHP, and MariaDB. I follow Hacker News.

Windows 7 x64 with all the security patches and service packs installed should close the holes. Patches on Equifax were missed. I attend many Cyber Security conferences. Most don't have WSUS servers to keep patches on workstations up to date. They patch 90-120 days out. This caused Equifax issue. Many of them are more concerned with DLP from an employee than a severity 2 event from a 13 year old hacker.

My WSUS server brings down every patch from Microsoft. Tells me then they are applied or failed. SQL, Exchange cumulative updates are applied every quarter. All the hardware is patched twice a year from HP and VMWare. I even apply the VMWare Patch Tracker patches.

there are no security patches for Windows 7 anymore. all security vulnerabilities discovered since January (and several before) have not been and will not be fixed.

here are just a couple examples of vulnerabilities that will not be fixed in Windows 7:

I did some research and found this ciphersuite covers the latest browsers and provide proper security with a limited of TLS 1.2 weak protocols.

If that's your goal, just use ECDHE+AESGCM:ECHDE+CHACHA20:+AES256. non-EC DH is slow, weak at common key sizes, and not needed for modern browsers. CBC suites are weak and not needed by modern browsers.

TLS 1.3 is still not covered by many browsers on phones and tablets.

Chromium, Firefox, and Safari all support it. what browsers on phones and tablets aren't one of those three or based on one of those three?

Here is what isn't supported with my Cipher Suite. Availability and security need to be balanced. My Wordpress servers are behind a Fortinet 60E firewall with FortiOS 6.4. All of the security including SSL Deep Inspection based on the Godaddy cert is installed.

other browsers and newer versions of Safari work on OS X 10.9 and 10.10. that just leaves iOS 6, 7, and 8 unsupported, which means you'd really only be dropping support for the iPhone 3GS, iPod Touch 4th generation, and iPhone 4. do you really know "a lot of users" on those three specific devices?

Safari 5.1 is still around 0.8% of global internet traffic. Internet Explorer 8 is around 0.2%, around the same as Safari 10.1. Safari 9.1 is around 0.1%, Safari 8.0 around 0.05%, versions of Chrome equal or earlier than the last supported one on Windows XP are around 0.15% between them, and older versions of Safari not mentioned earlier collectively make up around 0.1%. In fact, if you want to cover the most popular web browsers that cover just 99% of internet traffic, this is what you have to support:

There are an awful lot of old browsers in that monstrous list, and some are unidentifiable by any known metric. It gets worse when you have a target market that isn't in North America or Western Europe - a very popular browser in India is the Samsung Internet browser, and it's predominantly older versions that are more prevalent.

Every website is different. If there are legal requirements to follow, you must follow them. That's why banks, until recently, supported SSL 3.0, as, despite the technical concerns, there was a legal requirement to support it until the regulations were changed several months after the emergence of POODLE.

You should use analytics to determine your user base's profile and configure your systems to be as secure as possible for that user base. If your analytics show that 99% of your users connect over SSL 3.0 using RC4, disabling SSL 3.0 and RC4 is an absolute guarantee that in a few weeks you won't have a website any longer. That would be highly likely in certain parts of China, for example.

If you want to go the whole hog, automate it. Use analytics to determine what your clients support, query that data, dynamically create a set of configuration parameters that match what you see and modify your configuration on the fly with an automation tool.

Interoperability is a real thing and "security" doesn't trump it - the two must work in tandem. If you prevent a client from connecting to a website with the most secure set of protocols supported by that client, you encourage the client to use demonstrably less secure methods to retrieve the data they need - a phone call, for example, or writing a letter. Worse still for you, those methods cost you far more money than supporting the slightly less secure cipher suite on your website.

Interoperability is a real thing and "security" doesn't trump it - the two must work in tandem. If you prevent a client from connecting to a website with the most secure set of protocols supported by that client, you encourage the client to use demonstrably less secure methods to retrieve the data they need - a phone call, for example, or writing a letter. Worse still for you, those methods cost you far more money than supporting the slightly less secure cipher suite on your website.

there's an easy solution that doesn't require throwing security out completely for the sake of interoperability. don't make those less secure methods an option. if a customer attempts to use one of those methods, instead of giving them sensitive data over a less secure channel, tell them to update their software. if they won't do that, they can take their data-breach-waiting-to-happen business and the inevitable class action lawsuit that will follow elsewhere. "interoperability" with security vulnerabilities is not worth getting sued out of existence, a much higher cost than losing a customer who refuses to be interoperable with any secure methods of communication.

You've just contravened pretty much every piece of disability legislation ever passed since the birth of the internet, especially where the provision of public services is concerned. It would be lovely to be able to tell everyone that it's TLS 1.3 or GTFO, but the real world doesn't work that way. Many screen reader devices support TLS 1.0 and nothing newer and some people have no option but to use them. By not supporting such devices in the provision of a public service, your hypothetical class-action lawsuit just became much, much bigger.

I started doing this in 1982 on DOS and Novell. Every company and corporation I consulted with has old technology. GM still has mainframes. Many still use Windows Server 2008 and 2012 because of older software. Windows XP x64 and Windows 7 32-bit are still used. You go outside the US, UK, and EU you find even older technology.

TLS 1.2 is still necessary and needed. TLS 1.3 is an infant. We just got rid of TLS 1.0 and TLS 1.1 this year, but Microsoft decided not to. Outside the US, UK, and EU still need support for TLS 1.0 and TLS 1.1.

Microsoft Delays End of Support for TLS 1.0 and 1.1

I did take Lily's advice and removed Safari 6-8 and IE 11 on SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:+HIGH:!MEDIUM:!LOW:!CAMELLIA:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!DES:!RC4:!MD5:!RSA:!3DES:!SRP:!DSS:!SHA1:!SHA256:!SHA384

I was watching Security Now with Leo Laporte and Steve Gibson. Steve has been doing security for decades. He found this and has been telling people Linux over Windows 10 because of all the bugs and issues. They released a patch a few months ago that took out your personal files.

I base security on the needs of the client and their customers. What devices to they use to access data to make the customer money. I follow the CISSP guidelines. CISSP even said you can't defend against everything. I would like them to upgrade workstations and servers. Build DMZs for employee devices. My first priority is their firewalls. IPS, Botnets, AV, WAF, EMAIL, etc.

The battle I fight is not on my web server. It is keeping their firewalls on the latest releases. It is keep all the security on the firewall up to date. I spend $400 a year on my Fortinet 60E replacement and upgrade security licenses. My 60E handles attacks very well. I parse off it's syslogs and keep daily track of attacks. I rather stop them at the front door than in my server.

I came to your site to see how to secure my web sites. I am on Ubuntu 20.04, Apache2 2.4.43, PHP 7.4.6, MariaDB 10.4.13, and OpenSSL 1.1.1g. I keep the data center and home patched up. At Work, WSUS does it. At home Ubuntu is done manually.

What George is doing with this fight is working himself out of a job. Employers want users to come in and buy products. He is better off getting a BIA done with management and find out what they want. Most are more concerned with profit over security. Start with the firewall. Fortinet FortiOS 6.2 started TLS 1.3 support. TLS 1.2 is still minimum set on the firewall.

You're contradicting yourself - you don't know what George's requirements are. If he's trying to secure a system used by the NSA, CIA, DOD or other such organisation and the information contained therein is rated Top Secret, then TLS 1.3, and only TLS 1.3, is mandatory. For that use case, he absolutely has a point. A TLS 1.3-only server is not insecure by design and should not be downrated for that.

It doesn't even have to be particularly that. TLS 1.3 is fairly widely adopted even now.

~90% of users support TLS 1.3 at the moment whereas ~98% support TLS 1.2

If you operate a website that gets almost no TLS 1.2 traffic I don't see a reason why you shouldn't be able to disable it, sites should not be downgraded just for only supporting TLS 1.3. I'm not sure what this conversation has turned into but it's not like only 10% of users have TLS 1.3 support right now.

It is your web site and customer base. I keep TLS 1.2 and TLS 1.3 available. Microsoft reversed on 1.0 and 1.1 because of older devices. Do you have a corporate grade firewall with IPS and WAF enabled? Do you have SSL Deep Inspection enabled with your SSL Certificate.

If you don't have any clients using TLS 1.2 why keep it enabled? sure you can have a perfectly secure TLS 1.2 configuration at the moment but why waste time in keeping it up to date when you can just disable it?

SSL Deep Inspection is a FortiOS-specific feature for outbound traffic and is largely incompatible with HSTS. For inbound traffic, it's a pathetic rebranding exercise pretending to be SSL termination at the firewall.

IPS, WAF and similar technologies are beyond the scope of this forum. This forum is about SSL configuration.

HTTP Strict Transport Security (HSTS) Protocol

HSTS is a protocol used by Google and other web browsers to prevent man-in-the-middle attacks.

When performing deep inspection, the FortiGate intercepts the https traffic and would send its own self-signed CA certificate to the browser. If the browser is configured to use HSTS connections, it would refuse the FortiGate CA certificate since it is not on the trusted list for Google servers.

To keep the CA certificate from being refused, the HSTS settings should be cleared from the browser. Instructions for this vary between browsers.

Fortinet said to install the Godaddy certificates on the 60E for SSL Deep Inspection. The certificates must be trusted by Google and other sources on the internet. It has been over a year since you were allowed to used self-signed certificates on the Internet. SSL Deep Inspection is on the VIP policy inbound from SD-WAN to the Web Servers.

Many screen reader devices support TLS 1.0 and nothing newer and some people have no option but to use them.

most screen readers work just fine with TLS 1.2 and 1.3. I've tested web sites with all the currently maintained ones I could find and haven't encountered any that don't at least work with TLS 1.2 and AES GCM. if someone is using outdated software and just hasn't bothered to update for years, sure, they might not have TLS 1.2 support, but the solution there is to simply update the software.

people using ancient ones that don't work anymore have the option to upgrade to newer ones that do work.