[Patch]: OpenSSL 1.0.1 protocol selection support (was: TLS library problem after updating "openssl")

68 views
Skip to first unread message

Viktor Dukhovni

unread,
Apr 22, 2012, 2:58:25 PM4/22/12
to
On Sun, Apr 22, 2012 at 12:47:41PM -0400, Jerry wrote:

> I am wondering if "openssl 1.0.1a" corrects this problem. I am going to
> install it later today and see what happens.

Please post the results.

> On another note, is there a setting that would force Postfix to NOT use
> "tls1_2 or tls1_1"? I am sure that it is listed somewhere in the
> documentation so I just have to get my ass in gear and read up on it.

The OpenSSL API does not provide an interface to allow older programs
to disable new protocol versions defined in later versions of the API.

Therefore, to disable TLS 1.1 or 1.2 one has to add code that uses
the new constants introduced with OpenSSL 1.0.1.

Proposed patch attached.

--
Viktor.
tls.diff

Wietse Venema

unread,
Apr 22, 2012, 3:12:26 PM4/22/12
to
Viktor Dukhovni:
> The OpenSSL API does not provide an interface to allow older programs
> to disable new protocol versions defined in later versions of the API.
>
> Therefore, to disable TLS 1.1 or 1.2 one has to add code that uses
> the new constants introduced with OpenSSL 1.0.1.
>
> Proposed patch attached.

That will be a solution for Postfix 2.10.

Meanwhile, for earlier Postfix releases, how much of the problem
can be solved by changing from:

mumble_tls_mandatory_protocols = SSLv3, TLSv1

(i.e. the current default) to:

mumble_tls_mandatory_protocols = !SSLv2

I don't mind that the older Postfix versions would not be able to
turn on/off protocols that didn't exist at the time Postfix was
released.

Wietse

Viktor Dukhovni

unread,
Apr 22, 2012, 3:22:47 PM4/22/12
to
On Sun, Apr 22, 2012 at 03:12:26PM -0400, Wietse Venema wrote:

> > Proposed patch attached.
>
> That will be a solution for Postfix 2.10.
>
> Meanwhile, for earlier Postfix releases, how much of the problem
> can be solved by changing from:
>
> mumble_tls_mandatory_protocols = SSLv3, TLSv1
>
> (i.e. the current default) to:
>
> mumble_tls_mandatory_protocols = !SSLv2

The two defaults are equivalent when the protocols known to Postfix
are just SSLv2, SSLv3 and TLSv1 (even if the SSL library implements
additional protocols). Either way, Postfix sets the SSL_OP_NO_SSLv2
flag.

This default, would however also disable TLSv1_1 and TLSv1_2 in
with the 2.10 patch that adds knowledge of those protocols to Postfix,
so it made sense to change the default to be "!SSLv2", which is what
it really means.

So, sure, we can change the default to the equivalent "!SSLv2" in
earlier releases if that simplifies documentation, or otherwise
aids in clarity of "postconf" output.

--
Viktor.

Wietse Venema

unread,
Apr 22, 2012, 3:28:43 PM4/22/12
to
Viktor Dukhovni:
> On Sun, Apr 22, 2012 at 03:12:26PM -0400, Wietse Venema wrote:
>
> > > Proposed patch attached.
> >
> > That will be a solution for Postfix 2.10.
> >
> > Meanwhile, for earlier Postfix releases, how much of the problem
> > can be solved by changing from:
> >
> > mumble_tls_mandatory_protocols = SSLv3, TLSv1
> >
> > (i.e. the current default) to:
> >
> > mumble_tls_mandatory_protocols = !SSLv2
>
> The two defaults are equivalent when the protocols known to Postfix
> are just SSLv2, SSLv3 and TLSv1 (even if the SSL library implements
> additional protocols). Either way, Postfix sets the SSL_OP_NO_SSLv2
> flag.
>
> This default, would however also disable TLSv1_1 and TLSv1_2 in
> with the 2.10 patch that adds knowledge of those protocols to Postfix,
> so it made sense to change the default to be "!SSLv2", which is what
> it really means.

Why do we need to have (expr & TLS_KNOWN_PROTOCOLS) in the code
in the first place? If we get rid of it, then we don't have to
rush out patches each time the OpenSSL team comes out with a
new incompatible protocol.

Wietse

Viktor Dukhovni

unread,
Apr 22, 2012, 3:38:34 PM4/22/12
to
On Sun, Apr 22, 2012 at 03:28:43PM -0400, Wietse Venema wrote:

> Why do we need to have (expr & TLS_KNOWN_PROTOCOLS) in the code
> in the first place? If we get rid of it, then we don't have to
> rush out patches each time the OpenSSL team comes out with a
> new incompatible protocol.

The "TLS_KNOWN_PROTOCOLS" bits are a Postfix tls.h feature, there
is no OpenSSL feature that tells us which of the option bits are
protocols, and which are bug work-arounds, ...

I can't turn off TLSv1_3, without predicting which option bit will
be selected for SSL_OP_NO_TLSv1_3, I don't own that crystal ball. :-)

There are various API design warts in OpenSSL, using the same
bitmask for both bug-workarounds and protocol selection is just
one of the unfortunate "optimizations".

--
Viktor.

Wietse Venema

unread,
Apr 22, 2012, 4:13:03 PM4/22/12
to
Viktor Dukhovni:
> On Sun, Apr 22, 2012 at 03:28:43PM -0400, Wietse Venema wrote:
>
> > Why do we need to have (expr & TLS_KNOWN_PROTOCOLS) in the code
> > in the first place? If we get rid of it, then we don't have to
> > rush out patches each time the OpenSSL team comes out with a
> > new incompatible protocol.
>
> The "TLS_KNOWN_PROTOCOLS" bits are a Postfix tls.h feature, there

Yes, but do we need this? Otherwise I'll rip this out and avoid
the need to rush out five inter-operability patches each time
that the OpenSSL team enriches our lives with another protocol.

Wietse

Viktor Dukhovni

unread,
Apr 22, 2012, 4:41:17 PM4/22/12
to
When OpenSSL adds new protocols we still need new code to support
exclusion of new protocols. Nothing in "TLS_KNOWN_PROTOCOLS" changes
that.

The "TLS_KNOWN_PROTOCOLS" bitmask supports conversion of:

smtp_tls_protocols = TLSv1

to the equivalent (for Postfix 2.9 or earlier)

smtp_tls_protocols = !SSLv2, !SSLv3

With Postfix 2.10 (patched as proposed), the equivalent exclusion
form is:

smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1_1, !TLSv1_2

so the mapping from a set to its complement, naturally depends on
the universal set at hand.

Dropping the inclusion syntax creates a backwards compatibility
problem.

I am not sure why you feel there is an imperative to drop it. If
we don't want to implement features to disable new protocols, we
don't need to make any code changes. If we do want to allow
control over new protocols, we need new code, with our without
TLS_KNOWN_PROTOCOLS.

--
Viktor.

Reply all
Reply to author
Forward
0 new messages