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.
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.
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.
As a security conscious dev that has worked in various highly regulated spaces I want to say we really appreciate people like you, because they’re super rare
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 :)
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
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.
Most people would like to forget the last 10 years of tech, which has produced some of the worst, most bloated code in existence, and an ecosystem of software 75% of which could be disposed of tomorrow and the world would be better for it.
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.
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 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.
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.
Lots of people, I certainly don't trust free providers, and I think it's a lot less likely that malware will use a non-free cert, so some people trust those more. Plus there are email, code-signing and other cert types that aren't provided for free.
What does this mean in practice? Do you remove the free providers from your OS & browser trust stores? Does this mean you get warnings every time you visit a site that uses LetsEncrypt (and other free providers)?
I would have that concern, at minimum 100x more with random shitty unreliable SSL providers, than those being run by literal huge nerds and non-profits. Your analysis here is thin and lazy and that's being generous to your analysis.
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?
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. In the case of OpenSSL it can be done by either combining presets (such as "HIGH:!kRSA:!kEDH:!SHA1:!CAMELLIA:!ARIA") and optionally bump up global "SECLEVEL". Which helps avoid issues like accidentally crippling operations when an ECC key(/cert) is used or accidentally disabling stronger ciphersuites than what was left enabled by manually specifying them.
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.
Same reason they recommend the similar directive for nginx:
> all the ciphers in Modern and Intermediate are secure. As such, we let the client choose the most performant cipher suite for their hardware configuration.
The choice between ChaCha20 and AES can be left to the clients with the "PrioritizeChaCha" option. On both OpenSSL and BoringSSL, likely similar options are available with other libraries as well. Anything else such as not enforcing any preference is unnecessary.
This has been around for a long time. Kudos to the folks that built it. It served a need at the time and made a big impact on improving configurations for people that didn't understand the myriad of ways to setup ssl/tls.
This looks like something that's been around forever, but it's the first time I've seen it. xkcd://{{derive_from_context}}
It's a great idea. I've created (or copied) at least half of these output formats, a few of which I remember being annoyingly difficult to surface from the project docs.
But in the moment today, it's mostly interesting to see the different ways of saying the same things in various configuration languages. And thinking that this might be why so many people with different brains find the technology world so obtuse and off-putting.
The joke's on them, of course. We like it this way! (Never wrestle with a pig...)
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)?
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.
[1] - https://securityheaders.com/
[2] - https://www.ssllabs.com/ssltest/
[3] - https://github.com/testssl/testssl.sh
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.
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.
As a security conscious dev that has worked in various highly regulated spaces I want to say we really appreciate people like you, because they’re super rare
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 :)
Why are we still using the term "SSL" anywhere? It feels immediately like someone forgot the last 10 years of tech.
I'm one of the few using "TLS", but it's hard.
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...
SSL was developed by Netscape in the 90s and evolved into TLS. Netscape Navigator essentially evolved into Mozilla.
"They've" been at it from the beginning, so it somehow seems understandable that Mozilla has a lot of "SSL" momentum or carryover.
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.
Most people would like to forget the last 10 years of tech, which has produced some of the worst, most bloated code in existence, and an ecosystem of software 75% of which could be disposed of tomorrow and the world would be better for it.
If OpenSSL were dispoed of,^1 then where would that leave "TLS"
1. For example if software stopped linking to OpenSSL libraries instead of alternatives
"OpenSSL" (the library as well as the binary) is quite "bloated" compared to WolfSSL, LibreSSL, BoringSSL, etc.
If the name "TLS" signifies something meaningful then why do the majority of TLS-implementing projects still include "SSL" in their name
That's the opposite of what happened with TLS.
Surely you mustn't be referring to OpenSSL, which was forked multiple times — under duress — to maintain the safety and security of the web.
TLS != OpenSSL.
I don't concede the rest of your comment, but we don't reach it, because I wasn't making a point about OpenSSL.
TLS is a Microsoftie term. I use SSL out of stubbornness.
https://news.ycombinator.com/item?id=44282378
It's also the official name in the RFC. TLS 1.0 may be the same as SSL 3.0, but TLS 1.1, 1.2 and 1.3 are just TLS 1.1, 1.2 and 1.3.
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.
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.
TLS is basically SSL 4. They only changed the name to signal the backwards incompatibility.
Not quite.
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.
You might as well decry "Hoover" for a vacuum cleaner. I haven't seen a Hoover for way longer than SSL -> TLS. OK I have but I blanked it!
I’m going to xerox this Kleenex.
I think xerox still exits but darn if I haven’t seen one in ages.
The printers still exist, but the branding is deprecated.
Xerox -> Fuji-Xerox -> FUJIFILM Business Innovation
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.
I think the bigger answer is certificate vendors won't stop using the term.
Maybe, but who is actually still buying tls certs from a vendor?
Lots of people, I certainly don't trust free providers, and I think it's a lot less likely that malware will use a non-free cert, so some people trust those more. Plus there are email, code-signing and other cert types that aren't provided for free.
> I certainly don't trust free providers
What does this mean in practice? Do you remove the free providers from your OS & browser trust stores? Does this mean you get warnings every time you visit a site that uses LetsEncrypt (and other free providers)?
What does it mean not to trust Let's Encrypt in this case? What is it you are concerned they will do?
I worry that the CA is somehow compromised (state actor holding private keys, etc).
BTW, all the recent certificate shenanigans have invovled for-profit CAs [1].
[1]: https://sslmate.com/resources/certificate_authority_failures
I still believe in "if it's free, you are the product."
> I worry that the CA is somehow compromised (state actor holding private keys, etc).
"Somehow" is doing a lot work in that sentence.
Operationally, there's no difference between the security procedures and requirements that a for-profit or a non-profit CA must adhere to.
I would have that concern, at minimum 100x more with random shitty unreliable SSL providers, than those being run by literal huge nerds and non-profits. Your analysis here is thin and lazy and that's being generous to your analysis.
Because “OpenSSL” was too lazy to rename themselves to “OpenTLS”
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?
I tend to expand TLS thread-local storage, so SSL is less confusing for me.
Good luck renaming OpenSSL...
Proper configuration of cryptography should not be abdicated to application developers or operators: https://go.dev/blog/tls-cipher-suites
> The Mozilla SSL Configuration Generator is great, and it should not exist.
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. In the case of OpenSSL it can be done by either combining presets (such as "HIGH:!kRSA:!kEDH:!SHA1:!CAMELLIA:!ARIA") and optionally bump up global "SECLEVEL". Which helps avoid issues like accidentally crippling operations when an ECC key(/cert) is used or accidentally disabling stronger ciphersuites than what was left enabled by manually specifying them.
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.
They also have configs for ssh, although without the cool generator.
https://infosec.mozilla.org/guidelines/openssh
Why are they recommending SSLHonorCipherOrder Off ?
Same reason they recommend the similar directive for nginx:
> all the ciphers in Modern and Intermediate are secure. As such, we let the client choose the most performant cipher suite for their hardware configuration.
https://github.com/mozilla/server-side-tls/issues/260#issuec...
https://wiki.mozilla.org/Security/Server_Side_TLS
There's no need for that.
The choice between ChaCha20 and AES can be left to the clients with the "PrioritizeChaCha" option. On both OpenSSL and BoringSSL, likely similar options are available with other libraries as well. Anything else such as not enforcing any preference is unnecessary.
I don’t see any option in this config generator for mTLS (mutual TLS, where you use client certificates in addition to server certificates).
Perhaps it is too niche of a thing. Sadly. It really is quite useful in some situations.
It's a web server base config configurator relating to initial comms. Authentication mechanisms are way out of scope for this.
Well, IMO you need a higher degree of knowledge to deal with client certs. Often you setup your own CA too. Definitely niche.
Their "AWS ELB" seems to be a Classic Load Balancer; probably not the best term to use. The "AWS ALB" is an Application Load Balancer, of course.
I think this existed before the ALB was announced, and doesn’t see that many updates.
A similar too for OpenSSL config would be great
This has been around for a long time. Kudos to the folks that built it. It served a need at the time and made a big impact on improving configurations for people that didn't understand the myriad of ways to setup ssl/tls.
it is amazing that Chrome 80 still hasn’t upgrade its OpenSSL to v1.1.1.
This looks like something that's been around forever, but it's the first time I've seen it. xkcd://{{derive_from_context}}
It's a great idea. I've created (or copied) at least half of these output formats, a few of which I remember being annoyingly difficult to surface from the project docs.
But in the moment today, it's mostly interesting to see the different ways of saying the same things in various configuration languages. And thinking that this might be why so many people with different brains find the technology world so obtuse and off-putting.
The joke's on them, of course. We like it this way! (Never wrestle with a pig...)
why the site's back button doesn't work?
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)?
Great question. Servers should ship with secure defaults.
Thanks Mozilla, I don't know what I would do if I couldn't generate a config for Apache 420 with OpenSSL 69.