introduce a function like SSL_CTX_set_security_standards()?

[Wiebe Cazemier]

Hello OpenSSL list,

I regularly deal with security audits. Invariably they will say 'old protocols and ciphers enabled'. The current way of dealing with that, both as developer and sysop, require constant attention. For instance, you can change Nginx's ssl_protocols and ssl_ciphers, but at least the former doesn't support disabling only one; you have to hard-code what you enable. So at some point, it's outdated again, like when TLS 1.4, or a completely new protocol is ever introduced. And as stated, security testers always find this, so it's a common reoccurrance that this is not configured. And then there are many programs that don't offer the option to change it at all.

Especially as a software developer, I would like to outsource the decision to OpenSSL. Is it feasible to introduce a function like SSL_CTX_set_security_standards(ctx, level), where 'level' can be 'MANUAL, OUTDATED, DEPRECATED, RECOMMENDED', or something? This could then work in conjunction with things like SSL_CTX_set_min_proto_version(), so that it's still possible to require mininum TLS 1.3 in DEPRECATED mode.

Implementation wise, it could SIGABORT whenever the openssl major version increases and no defaults have been set, so that it's forced to be reevaluated with each major release.

One could even make this level enforceable through openssl.conf. As a sysop, I would love to have that control.

Curious about the response.

Kind regards,

Wiebe

[Dmitry Belyavsky]

You probably may be interested in the solution named "crypto-policies" present in Fedora, CentOS, RHEL and some more systems. It ensures system-wide defaults for cryptographic libraries and correctly written applications via configuration snippets

SY, Dmitry Belyavsky

Dne ne 4. 5. 2025 0:29 uživatel 'Wiebe Cazemier' via openssl-users <openss...@openssl.org> napsal:

--
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-user...@openssl.org.
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/1756347097.65432.1746311371291.JavaMail.zimbra%40halfgaar.net.

[Wiebe Cazemier]

----- Original Message -----
> From: "Dmitry Belyavsky" <bel...@gmail.com>
> To: "Wiebe Cazemier" <wi...@halfgaar.net>
> Cc: openss...@openssl.org
> Sent: Sunday, 4 May, 2025 22:12:21
> Subject: Re: introduce a function like SSL_CTX_set_security_standards()?
>
> You probably may be interested in the solution named "crypto-policies" present
> in Fedora, CentOS, RHEL and some more systems. It ensures system-wide defaults
> for cryptographic libraries and correctly written applications via
> configuration snippets
>
> SY, Dmitry Belyavsky

Hi Dmitry,

Definitely something I can look at, but I was hoping to introduce a common practice between all programmers who use OpenSSL to not just create options for end-users to configure protocols and ciphers, but move more towards sane defaults without knowing anything about them (in other words, not putting it on me as a program writer to keep the protocols and ciphers up-to-date). Having a crypto library that by default enables everything weak is bad practice in my opinion.

This function should then also clearly be named in the SSL_CTX_new() function, so that use is encouraged. Perhaps eventually moving towards setting DEPRECATED as default level.

Regards,

Wiebe

[Matt Caswell]

How is this proposal different to the existing `SSL_CTX_set_security_level()`?

Matt

--
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-user...@openssl.org.

To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/2123895636.581.1746416025044.JavaMail.zimbra%40halfgaar.net.

[Angus Robertson - Magenta Systems Ltd]

> How is this proposal different to the existing
> `SSL_CTX_set_security_level()`?

Those levels are about protocols and key lengths, and don't effect most
ciphers, currently only level 2 is really usable for sites that use
RSA-2048 certificates.

If I read the original post correctly, the suggestions was similar to
the Mozilla recommendations that many follow:

https://wiki.mozilla.org/Security/Server_Side_TLS

With modern, intermediate and backward compatibilities relating the
whether you want older browsers to access web sites, with lists of the
recommended ciphers for each list. Intermediate only has 12 ciphers
for TLS 1.2 and 1.3, whereas OpenSSL has dozens. Modern is TLS 1.3
only so restricting for older browsers.

Not sure if Mozilla is still updating these recommendations, last
change was in 2023.

The OpenSSL library I maintain uses security level and Mozilla ciphers
lists for servers, but having OpenSSL allow restricted cipher suites
would make support so much easier.

Angus

[Michael Richardson]

Matt Caswell <ma...@openssl.org> wrote:
> How is this proposal different to the existing
> `SSL_CTX_set_security_level()`?

That's an integer which seems to have to increase as new protocols are
introduced.

SSL_CTX_set_security_standards() would seem to be, mixing C/shell:

SSL_CTX_set_security_standards() {
SSL_CTX_set_security_level(`cat /etc/openssl/security-level.txt`);
}

[Viktor Dukhovni]

On Sun, May 04, 2025 at 12:29:31AM +0200, 'Wiebe Cazemier' via openssl-users wrote:

> I regularly deal with security audits. Invariably they will say 'old
> protocols and ciphers enabled'.

And you can often give good reasons why insisting on only the
latest/greatest cryptography pixie dust is not a good tradeoff.

For example, with SMTP, the effect of failure to negotiate a mutually
agreeable protocol or underlying parameters (ciphers, key exchange
methods, signature algorithms, ...) is typically fallback to cleartext,
which is unlikely to be better than use of slightly dated, but
ultimately adequate less shiny choices.

Indeed it is a false premise that the way to improve security is to raising the
floor (require only the strongest settings), rather than raising the ceiling (
adding support for and preferring stronger settings). When the protocol
used to negotiate session parameters is not easily subjected to
downgrade attacks (e.g. TLS), raising the floor can be
counterproductive. See, e.g., RFC7435.

> The current way of dealing with that, both as developer and sysop,
> require constant attention.

I don't agree with the premise. In terms of relevant threats, the
typical user is more than adequately protected with *default* settings,
provided he is not using a past end-of-life cryptographic library.
As OpenSSL evolves (issues new releases) itcontinues to raise the
ceiling, which works unless users make the mistake of being needlessly
prescriptive in their configurations (freezing in yesterday;s best
practice). As noted above, the best choice in most cases is *defaults*.
OpenSSL also, from time to time raises the floor, once a particular
outdated algorithm or parameter value is almost never used because
everyone has for some time switched to better alternatives.

> For instance, you can change Nginx's ssl_protocols and ssl_ciphers,
> but at least the former doesn't support disabling only one; you have
> to hard-code what you enable.

Don't do that. There's really no need. Reject incompetent auditors who
don't understand that TLS is as strong as the strongest mutually
supported parameters, and prematurely rejecting slightly dated
parameters is often a bad tradeoff.

> So at some point, it's outdated again, like when TLS 1.4, or a
> completely new protocol is ever introduced. And as stated, security
> testers always find this, so it's a common reoccurrance that this is
> not configured. And then there are many programs that don't offer the
> option to change it at all.

This is not necessary, if you don't make the mistake of choosing
point-in-time settings.

> Especially as a software developer, I would like to outsource the
> decision to OpenSSL.

Default settings adequately meet that goal.

> Is it feasible to introduce a function like
> SSL_CTX_set_security_standards(ctx, level), where 'level' can be
> 'MANUAL, OUTDATED, DEPRECATED, RECOMMENDED', or something? This could
> then work in conjunction with things like
> SSL_CTX_set_min_proto_version(), so that it's still possible to
> require mininum TLS 1.3 in DEPRECATED mode.

In OpenSSL 3.5, unless you load the "legacy" provider, all the supported
TLS 1.2 ciphers are "HIGH", and TLS 1.0 and 1.1 are disabled at the
default security level. TLS 1.3 is negotiated when mutually available,
and the handshake is downgrade resistant.

Any auditor who claims that there's a material security risk with
default settings that can be addressed by raising the ceiling should be
replaced by someone elese who's competent.

> One could even make this level enforceable through openssl.conf. As a
> sysop, I would love to have that control.

Setting system-wide policies is much too crude IMNSHO, it is wrong for
SMTP, for DNSSEC, and other applications where turning up crypto to 11
is pointless to counterproductive.

On Mon, May 05, 2025 at 05:33:45AM +0200, 'Wiebe Cazemier' via openssl-users wrote:

> > You probably may be interested in the solution named "crypto-policies" present
> > in Fedora, CentOS, RHEL and some more systems. It ensures system-wide defaults
> > for cryptographic libraries and correctly written applications via
> > configuration snippets

That sort of thing might make sense in some deployments of an OS with a
10-year support lifetime, where binary compatibility means keepign old
software vaguely current with external policy. I'd recommend instead
using a more agile platform, kept up to date.

> Definitely something I can look at, but I was hoping to introduce a
> common practice between all programmers who use OpenSSL to not just
> create options for end-users to configure protocols and ciphers, but
> move more towards sane defaults without knowing anything about them
> (in other words, not putting it on me as a program writer to keep the
> protocols and ciphers up-to-date). Having a crypto library that by
> default enables everything weak is bad practice in my opinion.
>
> This function should then also clearly be named in the SSL_CTX_new()
> function, so that use is encouraged. Perhaps eventually moving towards
> setting DEPRECATED as default level.
>

I remain sceptical that this is a useful direction.

--
Viktor.

[Wiebe Cazemier]

Hi Viktor,

You make some good points I can't disagree with, but to reply to some:

----- Original Message -----
> From: "Viktor Dukhovni" <openss...@dukhovni.org>
> To: openss...@openssl.org
> Sent: Tuesday, 6 May, 2025 22:23:09
> Subject: Re: introduce a function like SSL_CTX_set_security_standards()?
>

> On Sun, May 04, 2025 at 12:29:31AM +0200, 'Wiebe Cazemier' via openssl-users
> wrote:
>
>> I regularly deal with security audits. Invariably they will say 'old
>> protocols and ciphers enabled'.
>
> And you can often give good reasons why insisting on only the
> latest/greatest cryptography pixie dust is not a good tradeoff.
>
> For example, with SMTP, the effect of failure to negotiate a mutually
> agreeable protocol or underlying parameters (ciphers, key exchange
> methods, signature algorithms, ...) is typically fallback to cleartext,
> which is unlikely to be better than use of slightly dated, but
> ultimately adequate less shiny choices.

I think SMTP is more of an odd ball here, because of its asynchronous nature and need to guarantee delivery between hops. There are plenty of examples where the connection is end-to-end, and software writers and developers are actually in a position to be able to reject connections unless modern encryption is used.

If one is writing software for sensitive communication, being able to tell OpenSSL to raise the floor can actually be desirable. Currently, there seems no way to tell OpenSSL to do so, and you have to resort to "freezing in today's best practices".

>
> Indeed it is a false premise that the way to improve security is to raising the
> floor (require only the strongest settings), rather than raising the ceiling (
> adding support for and preferring stronger settings). When the protocol
> used to negotiate session parameters is not easily subjected to
> downgrade attacks (e.g. TLS), raising the floor can be
> counterproductive. See, e.g., RFC7435.

How do we know a protocol won't be susceptible to downgrade attacks in the future? Not an OpenSSL issue, but even/also SSH had one recently, with terrapin.

>> For instance, you can change Nginx's ssl_protocols and ssl_ciphers,
>> but at least the former doesn't support disabling only one; you have
>> to hard-code what you enable.
>
> Don't do that. There's really no need. Reject incompetent auditors who
> don't understand that TLS is as strong as the strongest mutually
> supported parameters, and prematurely rejecting slightly dated
> parameters is often a bad tradeoff.

People do though. Ubuntu/Debian's Nginx config contains:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE

So, they are indeed frozen in today's best practices.

I see this in multiple places.


Regards,

Wiebe

[Viktor Dukhovni]

On Tue, May 06, 2025 at 03:46:32PM +0200, 'Wiebe Cazemier' via openssl-users wrote:

> > Don't do that. There's really no need. Reject incompetent auditors who
> > don't understand that TLS is as strong as the strongest mutually
> > supported parameters, and prematurely rejecting slightly dated
> > parameters is often a bad tradeoff.
>
>
> People do though. Ubuntu/Debian's Nginx config contains:
>
> ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
>
> So, they are indeed frozen in today's best practices.

File bugs against those systems. They need to support the
OpenSSL "MinProtocol" setting. Postfix has supported this
since version 3.6 (released Feb 24 2016). I might expect
that 9 years later, some of these other software packages
would offer equivalent functionality:

http://www.postfix.org/postconf.5.html#smtp_tls_protocols

--
Viktor.