You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rainer Jung <ra...@kippdata.de> on 2016/01/28 16:14:35 UTC
openssl 1.0.2f released
Since the advisory
https://www.openssl.org/news/secadv/20160128.txt
is currently under heavy load, here's a copy:
OpenSSL Security Advisory [28th Jan 2016]
=========================================
NOTE: SUPPORT FOR VERSION 1.0.1 WILL BE ENDING ON 31ST DECEMBER 2016. NO
SECURITY FIXES WILL BE PROVIDED AFTER THAT DATE. UNTIL THAT TIME
SECURITY FIXES
ONLY ARE BEING APPLIED.
DH small subgroups (CVE-2016-0701)
==================================
Severity: High
Historically OpenSSL usually only ever generated DH parameters based on
"safe"
primes. More recently (in version 1.0.2) support was provided for generating
X9.42 style parameter files such as those required for RFC 5114 support. The
primes used in such files may not be "safe". Where an application is
using DH
configured with parameters based on primes that are not "safe" then an
attacker
could use this fact to find a peer's private DH exponent. This attack
requires
that the attacker complete multiple handshakes in which the peer uses
the same
private DH exponent. For example this could be used to discover a TLS
server's
private DH exponent if it's reusing the private DH exponent or it's using a
static DH ciphersuite.
OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE)
in TLS.
It is not on by default. If the option is not set then the server reuses the
same private DH exponent for the life of the server process and would be
vulnerable to this attack. It is believed that many popular applications
do set
this option and would therefore not be at risk.
OpenSSL before 1.0.2f will reuse the key if:
- SSL_CTX_set_tmp_dh()/SSL_set_tmp_dh() is used and SSL_OP_SINGLE_DH_USE
is not
set.
- SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used, and
both the
parameters and the key are set and SSL_OP_SINGLE_DH_USE is not used.
This is
an undocumted feature and parameter files don't contain the key.
- Static DH ciphersuites are used. The key is part of the certificate and
so it will always reuse it. This is only supported in 1.0.2.
It will not reuse the key for DHE ciphers suites if:
- SSL_OP_SINGLE_DH_USE is set
- SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used and the
callback does not provide the key, only the parameters. The callback is
almost always used like this.
Non-safe primes are generated by OpenSSL when using:
- genpkey with the dh_rfc5114 option. This will write an X9.42 style file
including the prime-order subgroup size "q". This is supported since
the 1.0.2
version. Older versions can't read files generated in this way.
- dhparam with the -dsaparam option. This has always been documented as
requiring the single use.
The fix for this issue adds an additional check where a "q" parameter is
available (as is the case in X9.42 based parameters). This detects the
only known attack, and is the only possible defense for static DH
ciphersuites.
This could have some performance impact.
Additionally the SSL_OP_SINGLE_DH_USE option has been switched on by default
and cannot be disabled. This could have some performance impact.
This issue affects OpenSSL version 1.0.2.
OpenSSL 1.0.2 users should upgrade to 1.0.2f
OpenSSL 1.0.1 is not affected by this CVE because it does not support X9.42
based parameters. It is possible to generate parameters using non "safe"
primes,
but this option has always been documented as requiring single use and
is not
the default or believed to be common. However, as a precaution, the
SSL_OP_SINGLE_DH_USE change has also been backported to 1.0.1r.
This issue was reported to OpenSSL on 12 January 2016 by Antonio Sanso
(Adobe).
The fix was developed by Matt Caswell of the OpenSSL development team
(incorporating some work originally written by Stephen Henson of the OpenSSL
core team).
SSLv2 doesn't block disabled ciphers (CVE-2015-3197)
====================================================
Severity: Low
A malicious client can negotiate SSLv2 ciphers that have been disabled
on the
server and complete SSLv2 handshakes even if all SSLv2 ciphers have been
disabled, provided that the SSLv2 protocol was not also disabled via
SSL_OP_NO_SSLv2.
This issue affects OpenSSL versions 1.0.2 and 1.0.1.
OpenSSL 1.0.2 users should upgrade to 1.0.2f
OpenSSL 1.0.1 users should upgrade to 1.0.1r
This issue was reported to OpenSSL on 26th December 2015 by Nimrod
Aviram and
Sebastian Schinzel. The fix was developed by Nimrod Aviram with further
development by Viktor Dukhovni of the OpenSSL development team.
An update on DHE man-in-the-middle protection (Logjam)
====================================================================
A previously published vulnerability in the TLS protocol allows a
man-in-the-middle attacker to downgrade vulnerable TLS connections
using ephemeral Diffie-Hellman key exchange to 512-bit export-grade
cryptography. This vulnerability is known as Logjam
(CVE-2015-4000). OpenSSL added Logjam mitigation for TLS clients by
rejecting handshakes with DH parameters shorter than 768 bits in
releases 1.0.2b and 1.0.1n.
This limit has been increased to 1024 bits in this release, to offer
stronger cryptographic assurance for all TLS connections using
ephemeral Diffie-Hellman key exchange.
OpenSSL 1.0.2 users should upgrade to 1.0.2f
OpenSSL 1.0.1 users should upgrade to 1.0.1r
The fix was developed by Kurt Roeckx of the OpenSSL development team.
Note
====
As per our previous announcements and our Release Strategy
(https://www.openssl.org/policies/releasestrat.html), support for OpenSSL
version 1.0.1 will cease on 31st December 2016. No security updates for that
version will be provided after that date. Users of 1.0.1 are
advised to upgrade.
Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those
versions
are no longer receiving security updates.
References
==========
URL for this Security Advisory:
https://www.openssl.org/news/secadv/20160128.txt
Note: the online version of the advisory may be updated with additional
details over time.
For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: openssl 1.0.2f released
Posted by jean-frederic clere <jf...@gmail.com>.
On 01/28/2016 08:48 PM, Mark Thomas wrote:
> On 28/01/2016 15:47, Rainer Jung wrote:
>> My first thoughts:
>>
>> - DH small subgroups (CVE-2016-0701)
>>
>> Our native code sets SSL_OP_SINGLE_DH_USE in sslcontext.c (in the native
>> impl of SSLContext.make()). This is true for trunk and 1.1.x. This
>> should suffice to not being exposed to the problem. It is a bit
>> unfortunate though, that the adisory uses lists of conditions without
>> explaining whether one should "and" or "or" them...
>>
>> - SSLv2 doesn't block disabled ciphers (CVE-2015-3197)
>>
>> In trunk (used for 1.2) we always set SSL_OP_NO_SSLv2 unconditionally
>> since r1681982 (2015-05-27). So 1.2 should have no problem here. 1.1
>> does not set the flag, but when using in Tomcat one should be able to
>> mitigat ethe problem by setting SSLProtocol. So 1.1 does likely only
>> have the problem as a library.
>>
>> - An update on DHE man-in-the-middle protection (Logjam)
>>
>> Is about clients, so only relevant to native as a lib, not for Tomcat.
>>
>> So I think we don't *need* a new tcnative. More eyes/thoughts welcome.
>
> Having reviewed the OpenSSL announcement and the tomcta-native code, I
> agree with your assessment.
So I will process with the tomcat6 release process during the week-end
to get a release during next week.
Cheers
Jean-Frederic
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: openssl 1.0.2f released
Posted by Mark Thomas <ma...@apache.org>.
On 28/01/2016 15:47, Rainer Jung wrote:
> My first thoughts:
>
> - DH small subgroups (CVE-2016-0701)
>
> Our native code sets SSL_OP_SINGLE_DH_USE in sslcontext.c (in the native
> impl of SSLContext.make()). This is true for trunk and 1.1.x. This
> should suffice to not being exposed to the problem. It is a bit
> unfortunate though, that the adisory uses lists of conditions without
> explaining whether one should "and" or "or" them...
>
> - SSLv2 doesn't block disabled ciphers (CVE-2015-3197)
>
> In trunk (used for 1.2) we always set SSL_OP_NO_SSLv2 unconditionally
> since r1681982 (2015-05-27). So 1.2 should have no problem here. 1.1
> does not set the flag, but when using in Tomcat one should be able to
> mitigat ethe problem by setting SSLProtocol. So 1.1 does likely only
> have the problem as a library.
>
> - An update on DHE man-in-the-middle protection (Logjam)
>
> Is about clients, so only relevant to native as a lib, not for Tomcat.
>
> So I think we don't *need* a new tcnative. More eyes/thoughts welcome.
Having reviewed the OpenSSL announcement and the tomcta-native code, I
agree with your assessment.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: openssl 1.0.2f released
Posted by Rainer Jung <ra...@kippdata.de>.
My first thoughts:
- DH small subgroups (CVE-2016-0701)
Our native code sets SSL_OP_SINGLE_DH_USE in sslcontext.c (in the native
impl of SSLContext.make()). This is true for trunk and 1.1.x. This
should suffice to not being exposed to the problem. It is a bit
unfortunate though, that the adisory uses lists of conditions without
explaining whether one should "and" or "or" them...
- SSLv2 doesn't block disabled ciphers (CVE-2015-3197)
In trunk (used for 1.2) we always set SSL_OP_NO_SSLv2 unconditionally
since r1681982 (2015-05-27). So 1.2 should have no problem here. 1.1
does not set the flag, but when using in Tomcat one should be able to
mitigat ethe problem by setting SSLProtocol. So 1.1 does likely only
have the problem as a library.
- An update on DHE man-in-the-middle protection (Logjam)
Is about clients, so only relevant to native as a lib, not for Tomcat.
So I think we don't *need* a new tcnative. More eyes/thoughts welcome.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org