Order of protocols in MinProtocol
openssl-users at dukhovni.org
Wed Jul 8 16:47:54 UTC 2020
On Wed, Jul 08, 2020 at 05:40:38PM +0100, Matt Caswell wrote:
> > I agree that the situation with MinProtocol in openssl.cnf is
> > unfortunate. But instead of mappings, I would propose a different
> > solution:
> > * Restrict MinProtocol/MaxProtocol to just TLS protocols,
> > i.e. SSL_CTX objects with a TLS-based method.
> > * Introduct new controls: DTLSMinProtocolDTLS, DTLSMaxProtocol,
> > that are similarly restricted to SSL_CTX objects with a DTLS-based
> > method.
> > * Since SSL_CTX_new() takes a required method argument, we are in
> > never in doubt as to which pair of controls to apply to a given
> > context.
> > Thoughts?
> Yes - that could work. Although it begs the question - would it change
> the way SSL_CTX_set_min_proto_version() works? (I assume that currently
> works just fine as is)
No changes in SSL_CTX_set_(min|max)_proto_version() required. The API
remains the same, and a user calling it on a context with a DTLS-based
method, would (as before) pass the appropriate *DTLS* versions.
The only change would be in the .cnf file, where "MinProtocol" and
"MaxProtocol" would now apply only in TLS-based contexts, and new
DTLSMinProtocol and DTLSMaxProtocol only in DTLS-based contexts.
> Another question that throws up is how much of that solution would we
> backport to 1.1.1 since DTLS(Min|Max)Protocol would be a new feature.
I'd be inclined to backport.
> Should we backport it anyway with the justification that it is a "fix"?
> Or do we just backport the bit that means it doesn't get applied to DTLS?
I see it as a bugfix. Yes, at least not misapply TLS limits to DTLS,
but at that point not adding the corresponding DTLS controls feels too
cautious to me.
More information about the openssl-users