info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[Patch]: OpenSSL 1.0.1 protocol selection support (was: TLS library problem after updating "openssl")
70 views
Skip to first unread message
Viktor Dukhovni
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.
> 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.
Wietse Venema
Apr 22, 2012, 3:12:26 PM4/22/12
to
Viktor Dukhovni:
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
> 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.
> 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.
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
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
> > 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
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
Apr 22, 2012, 3:28:43 PM4/22/12
to
Viktor Dukhovni:
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
> 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
>
> > > 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.
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
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
> 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.
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
Apr 22, 2012, 4:13:03 PM4/22/12
to
Viktor Dukhovni:
the need to rush out five inter-operability patches each time
that the OpenSSL team enriches our lives with another protocol.
Wietse
> 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
>
> > 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
the need to rush out five inter-operability patches each time
that the OpenSSL team enriches our lives with another protocol.
Wietse
Viktor Dukhovni
Apr 22, 2012, 4:41:17 PM4/22/12
to
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.
0 new messages