Thinking of SSL scan tools like this one [1] which gave me an "F" for how I configure my SSH servers, only allowing for very modern ciphers and kex without backward compatibility.
I wouldn't recommend doing that. You might end up blocking users using a proxy (e.g. for privacy reasons), people on corporate networks, people in China [1], and many other non-traditional browsers (e.g. browsers for the blind, game consoles), users on older versions of curl/wget/lynx, older mobile phones, etc.
TLS 1.2 when correctly configured is still perfectly fine. And users with modern browsers will connect with TLS 1.3. TLS 1.3 also has protections against downgrade attacks.
Another good scanner for SSL is Qualys SSL Server Test [2]. Getting an A+ score there doesn't require disabling TLS 1.2
For secure configuration, you can use Mozilla SSL Configuration Generator [3]
1. https://www.zdnet.com/article/china-is-now-blocking-all-encr...
I think you're trying to use 'perfectly secure' here the way one might say 'perfectly fine', which changes the reading a lot from a first pass.
That said, I agree, there is a subset of TLS 1.2 that is suitable.
Not only it adds 2^(number of ciphers) ways to misconfigure the server with a gaping security leak, but names are obscure and strings are NEVER the same between nginx and the SSLlabs website which advises what is correct, plus who knows whether SSLLabs is a trustworthy website. Also, 6 months later the ciphers might not be up to date. Why do I have to even choose ciphers? Why isn’t this TLS 1.2.1, then 1.2.2, and so on?
It’s like going to Amazon, choosing n resistors by guessing their value, going to m people asking them if it’s 12 ohms, most of them having no clue what they are talking about, and using it for an airport security device that can put people in jail.
Indeed, more choice means more ways to mess things up, more complexity, more bugs and more vulnerabilities.
That's why TLS 1.3 reduces the cipher suite choice to 5 ciphers, down from 37 from TLS 1.2 (in previous versions there were 319 in total) [1]
1. https://owasp.org/www-chapter-london/assets/slides/OWASPLond...
Now, the technical answer as to why there's something to pick from at all goes like this:
TLS is a negotiated protocol. Some HN regulars are convinced negotiation is a bad idea, and indeed they will point to TLS as an example. But the idea is that with a vast population of servers and clients on the Internet it isn't actually practical to hold a flag day (replacing all software on clients and servers immediately) to upgrade TLS. Different clients and servers may have different priorities, so we'd like them to be able to agree each time on something they're both content with. For example on your general purpose laptop there is hardware AES, so AES ciphers are fast and secure, but some cheap devices don't have that, so for them AES is annoyingly slow/ power hungry. As a result they'd prefer ChaCha20 if possible.
How did the list get so long? There's a point around the turn of the century when countries realise oh, this Internet thing is important, and you get a rash of "cryptographic nationalism" where a government that likes to think of itself as important notices the US government made things like DES and it decides it can do that too, resulting in vanity ciphers which are less analysed, less popular, and basically have no reason to exist. TLS 1.2 doesn't explicitly discourage you from supporting these, and OpenSSL is a stamp collector's library, if a cipher exists and you can implement it, why not? So you get this unwieldy list nobody actually needs, and then apps present it to non-experts like "Pick from this list or be doomed".
You can get advice on how to configure web servers from Mozilla, https://ssl-config.mozilla.org/
For other types of TLS server you should seek advice from experts in the appropriate protocol.
In TLS 1.3 they learned from this mistake and discourage cryptographic nationalism, you have a literal handful of choices, all of them are currently believed to be safe, some are likely poor (slow, power hungry) choices on simple hardware, some would be weak if large quantum computers were actually cheap and readily available, rather than horribly expensive and non-existent. So "I don't care, whatever" is thus safe in TLS 1.3 although presumably OpenSSL still expects you to actually pick anyway.
By supporting older protocols on sites, we're enabling this kind of abuse to run rampant. Maybe it's best to just cut them off.
In the end they just get replaced with something worse.
e.g. I think that Google offering censored search in China is a lesser evil than Baidu, which is not only censored, but likely also tracks and reports all your searches to the government
When using older protocol versions, it can be complicated to validate that the TLS implementation you are using has the necessary mitigations in place. It can be complicated to correctly configure TLS to minimize the effects of known attacks. Doing that properly requires a fair amount of research, threat modelling, and risk assessment both for yourself and on behalf of anyone accessing your website or service.
IME, TLSv1.2 is still a big chunk of legitimate web traffic. It has been steadily dropping since standardization, and TLSv1.3 is the majority by a wide margin from what I can see. I wouldn't be surprised to see some websites and services still needing to support it for a couple years more, at least, depending on their target audience.
[1] https://tools.ietf.org/html/rfc7457
[2] https://en.wikipedia.org/wiki/Transport_Layer_Security#Attac...
Wrote some thoughts on why here https://blog.nyman.re/2021/02/07/usability-security.html but in short, it's several magnitudes more likely someone will want to check out my blog using a old device vs someone trying to exploit vulnerabilities in the old protocols.
Google.com still allows TLS1.0/1.1 https://www.ssllabs.com/ssltest/analyze.html?d=google.com&s=...
Although note that I did see a drop of ~2%-3% in traffic after that. I don't directly make any money of these websites (just my personal blog and similar) and most of my viewers are likely to be technical (i.e. not using IE which doesn't support 1.3), so I decided the sacrifice was worth it for another small reduction in needed sysadmin thought+work.