In a similar spirit there is also a site to scan security headers of any site [1] and another to verify the TLS settings from the Mozilla SSL Configuration Generator [2] and a git repo with code to scan sites from the command line [3] useful if the site is not reachable on the internet or automated scans to HTML reports.
Honestly, i disagree with the security headers one. Various security headers do different things and should not be applied blindly. While some are always appropriate there are also some that make sense to skip depending on what specificly your site is doing.
Not to mention, when i looked at the hall of fame entries, most had a CSP header, but it was a useless CSP header that was meaningless. It doesn't seem to distinguish between having the header and actually using it correctly.
This was always my pet peeve when working as a penetration tester. We'd run simple tools like this to cover the basics, but so many coworkers would blindly copy paste the issues without considering the site's context and suitability. Not to knock their skills, they'd find real vulnerabilities too. It's just that this stuff was considered beneath them, while I felt that giving a client tailored advice on little details like this is what they were looking for and shows attention to detail.
It's seriously infuriating receiving these "Critical vulnerability reports" customers let other agencies do, and having to justify why you have no Referer-Policy header.
Nice to read that you are reasonable.
Also, they want a strict CSP while serving 10 different ad networks :)
I needed to perform scans internally, and testssl.sh was too slow (minimum 20 seconds with parallelization and all optional scans disabled). So I made my own scanner, for a 60-100x speedup: https://github.com/boppreh/hello_tls . It doesn't do vulnerability assessment, but I was more interested in extracting the configuration.
When doing this, you see that some people feel that you are being pedantic.
And the biggest issue is that it creates confusion.
During calls with customers, when I tell that we're going to setup their TLS certs, they reply, worried: "no, we need SSL certs!".
I see it as another chicken & egg situation: regular people don't know about TLS, and business are afraid of communicating about TLS because they don't want their customer going elsewhere because they don't understand what TLS is and want SSL
There are no TLS certs, it's x509 certs :) SSL certificate is still the name used by everybody though. For the protocol, TLS is correct (apart from SSLv3 which is very deprecated).
actually we wrote this many years ago and left mozilla ans nobody is really updating it other than adding new configs. its not super useful anymore :)
at the time it made sense to us because you couldnt have good SSL configuration everywhere (it was not well supported) so we had trade-offs and created tiers of configs. We barely had TLS coming out, so SSL eas still the name of the game.
nowaday just use the latest TLS defaults and you're golden.
Back in the day, SSL didn't exists. When it came into existence, it was quite an expensive novelty.
It became a generic name that everyone knew for encrypted HTTP connections. It still is a generic name for that, even though the underlying protocol changed name to TLS.
The main answer is a lot of the software on that page predates SSLs deprecation and people (sysadmins especially, because they wrote some bash script 20 years ago and want it to keep working) like backwards compatibility.
The name was changed from SSL to TLS as part of the adoption in IETF. I imagine different people had different motivations, but in part it was a signal that it was going to be controlled by IETF rather than Netscape.
As far as compatibility goes, TLS is backward compatible with SSLv3 [0] in that the client can send a ClientHello that is acceptable to both SSLv3 and TLS servers and the server can select the version to use.
Re: the version number, we're now on TLS 1.3, so I guess that would be SSLv7.
[0] The situation is more complicated with SSLv2, which had a different ClientHello format.
I had to double check my nginx configuration and the variables use SSL in the names even though I define the protocol to be TLS. I have the certbot commands and their naming conventions use SSL. Perhaps you've never actually implemented SSL or TLS and just use the latest tech jargon to fake understanding?
ElGamal says he uses them interchangeably. He says TLS exists for historical reasons, but the essence of the technology is the same. I got into the habit of using SSL/TLS.
Not only is it difficult to make an informed choice, it also incurs a maintenance cost. Cost which is often not paid, resulting in configuration that becomes increasingly sub-optimal as time passes and the SSL/TLS library is updated.
I'm fairly certain that when that generator was made (or article written), OpenSSL and similar already had ciphersuite presets one could use. So it is a bit odd that the generator is not enhancing those.
As an example, in the case of OpenSSL you can combine presets such as "HIGH" with your additional preferences. Such as avoiding non-PFS key exchanges, DoS risks, SHA1 phase out or less frequently used block ciphers. Result being something like "HIGH:!kRSA:!kEDH:!SHA1:!CAMELLIA:!ARIA". Optionally one can also bump up global "SECLEVEL" in OpenSSL's configuration.
Such a combination helps avoid issues like accidentally crippling operations when an ECC key(/cert) is used and someone forgot to allow ECDHE+ECDSA in addition to ECDHE+RSA. Nor does it accidentally disable strong ciphersuites using ChaCha20 that aren't as old.
Same goes for key exchange configuration. Quite a few servers don't have EdDSA available that don't run Windows, I suspect it's because they were set at some point and forgotten. Now such configuration also disables post-quantum hybrid key exchange algorithms.
How do these configs differ to server defaults? If some really bad settings are enabled by default (thus needing this custom config), shouldn't it be better just to have the server-software devs fix the defaults to be 'good enough' (for most)?
Readit News
[1] - https://securityheaders.com/
[2] - https://www.ssllabs.com/ssltest/
[3] - https://github.com/testssl/testssl.sh
Not to mention, when i looked at the hall of fame entries, most had a CSP header, but it was a useless CSP header that was meaningless. It doesn't seem to distinguish between having the header and actually using it correctly.
Nice to read that you are reasonable.
Also, they want a strict CSP while serving 10 different ad networks :)
When doing this, you see that some people feel that you are being pedantic.
And the biggest issue is that it creates confusion. During calls with customers, when I tell that we're going to setup their TLS certs, they reply, worried: "no, we need SSL certs!".
I see it as another chicken & egg situation: regular people don't know about TLS, and business are afraid of communicating about TLS because they don't want their customer going elsewhere because they don't understand what TLS is and want SSL
I went on Cloudflare to try and illustrate this, and it's... complicated https://www.cloudflare.com/application-services/products/ssl...
The path says SSL but most of the page it about TLS, unless sometimes it's SSL...
"They've" been at it from the beginning, so it somehow seems understandable that Mozilla has a lot of "SSL" momentum or carryover.
at the time it made sense to us because you couldnt have good SSL configuration everywhere (it was not well supported) so we had trade-offs and created tiers of configs. We barely had TLS coming out, so SSL eas still the name of the game.
nowaday just use the latest TLS defaults and you're golden.
It became a generic name that everyone knew for encrypted HTTP connections. It still is a generic name for that, even though the underlying protocol changed name to TLS.
The name was changed from SSL to TLS as part of the adoption in IETF. I imagine different people had different motivations, but in part it was a signal that it was going to be controlled by IETF rather than Netscape.
As far as compatibility goes, TLS is backward compatible with SSLv3 [0] in that the client can send a ClientHello that is acceptable to both SSLv3 and TLS servers and the server can select the version to use.
Re: the version number, we're now on TLS 1.3, so I guess that would be SSLv7.
[0] The situation is more complicated with SSLv2, which had a different ClientHello format.
I think xerox still exits but darn if I haven’t seen one in ages.
https://www.fortinet.com/resources/cyberglossary/ssl-vpn
https://news.ycombinator.com/item?id=44282378
Dead Comment
> The Mozilla SSL Configuration Generator is great, and it should not exist.
I'm fairly certain that when that generator was made (or article written), OpenSSL and similar already had ciphersuite presets one could use. So it is a bit odd that the generator is not enhancing those.
As an example, in the case of OpenSSL you can combine presets such as "HIGH" with your additional preferences. Such as avoiding non-PFS key exchanges, DoS risks, SHA1 phase out or less frequently used block ciphers. Result being something like "HIGH:!kRSA:!kEDH:!SHA1:!CAMELLIA:!ARIA". Optionally one can also bump up global "SECLEVEL" in OpenSSL's configuration.
Such a combination helps avoid issues like accidentally crippling operations when an ECC key(/cert) is used and someone forgot to allow ECDHE+ECDSA in addition to ECDHE+RSA. Nor does it accidentally disable strong ciphersuites using ChaCha20 that aren't as old.
Same goes for key exchange configuration. Quite a few servers don't have EdDSA available that don't run Windows, I suspect it's because they were set at some point and forgotten. Now such configuration also disables post-quantum hybrid key exchange algorithms.
https://infosec.mozilla.org/guidelines/openssh
Perhaps it is too niche of a thing. Sadly. It really is quite useful in some situations.