Re: [exim] OpenSSL IOT woes

Top Page
Delete this message
Reply to this message
Author: Viktor Dukhovni
Date:  
To: exim-users
Subject: Re: [exim] OpenSSL IOT woes
On Mon, Oct 03, 2022 at 07:22:29PM +0100, Jeremy Harris via Exim-users wrote:

> On 03/10/2022 18:08, Jeremy Harris via Exim-users wrote:
> > Could the min/max protocol stuff mentioned in
> > https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html
> > be affecting it?
> > Exim has no SSL_CONF_* calls currently; probably never has in it's
> > history.
>
> Bingo. The value given by SSL_CTX_get_max_proto_version()
> is TLS1_2_VERSION.
>
> If I slam a SSL_CTX_set_max_proto_version() call for SSL_v3
> in right before twiddling the option bits, all is good.


You probably meant "min", rather than "max".

> I conclude:
>
> - the limit value is kept separate from the bitfield
> setting the same essential information, in the library


The bit fields are a legacy interface. The preferred interface is the
new min/max range, which caps the protocol version range above and
below. You can still use the bit fields to create "holes" in that
range, though this is generally a bad idea.

> - this is a poor choice


I disagree.

> - any application written before those limit value APIs
>    were introduced and which did it's own bit-setting
>    (as documented) configuration for TLS versions,
>    will be broken in the same way.  Back-compatibility?
>    What does that mean?


Not broken, just constrained by the range settings in the system-wide
openssl.cnf, which is the whole purpose of that file.

> - the *lack* of documentation that the limit value
>    overrides the bitfield, having made the choice
>    to keep them separate is... words fail me.


There is no override, both sets of restrictions are enforced. The
documentation of SSL_CTX_new(3) reads in part:

    If you want to limit the supported protocols for the version
    flexible methods you can use SSL_CTX_set_min_proto_version(3),
    SSL_set_min_proto_version(3), SSL_CTX_set_max_proto_version(3) and
    SSL_set_max_proto_version(3) functions. Using these functions it is
    possible to choose e.g. TLS_server_method() and be able to negotiate
    with all possible clients, but to only allow newer protocols like
    TLS 1.0, TLS 1.1, TLS 1.2 or TLS 1.3.


    The list of protocols available can also be limited using the
    SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, SSL_OP_NO_TLSv1_1,
    SSL_OP_NO_TLSv1_3, SSL_OP_NO_TLSv1_2 and SSL_OP_NO_TLSv1_3 options
    of the SSL_CTX_set_options(3) or SSL_set_options(3) functions, but
    this approach is not recommended. Clients should avoid creating
    "holes" in the set of protocols they support. When disabling a
    protocol, make sure that you also disable either all previous or all
    subsequent protocol versions. In clients, when a protocol version is
    disabled without disabling all previous protocol versions, the
    effect is to also disable all subsequent protocol versions.


-- 
    Viktor.