OpenSSL Security Advisory [11 Jun 2015]

[Don Lewis]

On 12 Jun, Michelle Sullivan wrote:
> Andrea Venturoli wrote:
>> On 06/12/15 01:34, Michelle Sullivan wrote:
>>> Roger Marquis wrote:
>>>> The ports-secteam knows about this but posting here in case someone
>>>> wants to
>>>> update ahead of the port, from this morning's Hackernews:
>>>>
>>>>   <https://www.openssl.org/news/secadv_20150611.txt>
>>>>
>>>
>>> *wonders how this will affect 8.x & 9.x* (seems to be no fix for 0.9.8
>>> which 8.4 and 9.3 has 0.9.8zd in base - i expect 8.4 to get ignored as
>>> it EoLs on Jun 30, 2015, but 9.3 EoLs on Dec 31, 2016)
>>>
>>> Michelle
>>>
>>
>> Sorry for jumping in...
>> As I understood it, this new version will just do what one can
>> manually do by tweaking configuration files (i.e. disable weak
>> ciphers/short keys).
>> Is it so?
>>
>> In other words, servers can be secured without applying this patch; on
>> the other hand, simply upgrading makes the job easier and will also
>> fix some daemon you might have forgotten.
>> Am I right?
>>
>> Can someone please confirm or deny?
> 
> Theoretically yes...  In practice I *think* it's no for OpenSSL <=
> 1.0.0  the config options will stop most of the issues but that's not
> the end of the story as DH = 1024 seems to be still present on any
> config that doesn't break most things when using openssl 0.9.8 (which
> could be partly because it doesn't support TLS v1.1 or v1.2... and
> therefore doesn't have the 'secure renegotiation' option/fix which I
> believe is not fixable in TLS 1.0 - which is why SSL Labs now will not
> rate any site not supporting TLS v1.2 over a 'C'.)
> 
> Either way I think it's either manually patch 0.9.8 for DH 2048/4096
> (there are a couple floating around) or more preferably upgrade to
> 1.0.2b in base (which will make a lot of people happy!)

I'm still running 8.4 here (but planning on upgrading to 10.1 in the
next couple of weeks).  I use poudriere to build my own package set with
customized options, and I mentioned a couple weeks ago on
freebsd-security@ that I switched my packages to use the openssl port
instead of openssl from base by adding WITH_OPENSSL_PORT=yes to
make.conf.  The only significant problem that I ran into was with
ftp/curl, which silently continues to link to base openssl if you leave
its GSSAPI option set to the default GSSAPI_BASE.  Choosing one of the
other options fixes that problem.

There were a couple of other ports that I found in the set that I build
that didn't handle WITH_OPENSSL_PORT=yes, but they were easy to fix and
I filed PRs with patches for them.  The last time I looked, there was
only one port that set WITH_OPENSSL_BASE=yes in its Makefile, and that
is not a port that I use.

Of all the binaries and shared libraries installed by my set of
packages, the only ones that still link to base openssl belong to
ports-mgmt/pkg.  Fixing that and avoiding the resulting chicken vs. egg
problem would probably require bundling a private copy of openssl with
pkg.

There are still a number of things in base that use openssl, but in my
case the only significant ones are ssh and fetch.  In one of the replies
in the thread that I started, someone mentioned that it could be a
problem if a port uses libfetch because that shared library is linked to
openssl from base, but none of the ports that I use appear to use
libfetch.

<http://docs.FreeBSD.org/cgi/mid.cgi?201506010138.t511cp2P088983>