Re: introduce a function like SSL_CTX_set_security_standards()?

Hi Viktor,

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


----- Original Message -----
> From: "Viktor Dukhovni" <[email protected]>
> To: [email protected]
> 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

-- 
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-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/515432516.5894.1746539192924.JavaMail.zimbra%40halfgaar.net.