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> _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
