From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Schantl To: development@lists.ipfire.org Subject: Re: Multiple SSL implementations Date: Mon, 11 Feb 2013 18:41:05 +0100 Message-ID: <51192D31.9010900@ipfire.org> In-Reply-To: <1360578815.28061.105.camel@rice-oxley.tremer.info> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4332397692442027163==" List-Id: --===============4332397692442027163== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, Hello Ben, you are right there are a lot of different SSL implementations out there=20 which are probably doing the same stuff. And of course I totally agree=20 with you that the currently 4 included implementations are to much. To reduce overhead and "pre-designed" troubles on fixed security holes=20 on some implementations, because patches to fix them are available - but=20 for a second or third implementation they are not fixable because of a=20 missing patchset. This result in a potential security risk because some services still can=20 be attacked, because they are linked and using a different SSL library. A first good step, as you already wrote, will be to drop NSS because=20 it's simple to do and as I can see on your git branch, has been done. Currently we are not able to drop polarssl, because PDNS requires it as=20 only supported SSL implementation. Hopefully this will be changed by the=20 developers at a later time. Stefan > Well, it is simple. I made a branch and removed nss in that: > > http://git.ipfire.org/?p=3Dpeople/ms/ipfire-3.x.git;a=3Dshortlog;h=3Drefs/h= eads/remove-nss > > We could merge the branch, if we decide to go into that direction. > > -Michael > > On Mon, 2013-02-11 at 08:25 +0100, Benjamin Schweikert wrote: >> Hi, >> as long as it is "that simple" I agree with you. We should try to >> reduce overhead as much as possbile an concentrate on things which are >> more important. >> >> Ben >> >> 2013/2/10 Michael Tremer : >>> Hello, >>> >>> I think it is time to discuss a thing, that has been stuck in my head >>> for some time now: We have too many SSL implementations in the system. >>> And as we are already discussion what we can remove from the >>> distribution (Xen), I'd like to think about the SSL libraries. >>> >>> IPFire 3 comes with openssl, GnuTLS, nss and polarssl. They all >>> basically implement the same protocols, but they differ a bit in their >>> interfaces, so a lot of projects prefer the one or an other. >>> >>> When we had the Lucky Thirteen problem last week, I had to patch all >>> four libraries. That's redundant work and I don't see any sense in that. >>> I even see this as a security issue, because it is not easy to keep >>> track of security issues in all libraries. >>> >>> I would like to think about how we can get rid of some of these >>> libraries: >>> >>> * openssl >>> We cannot get rid of this one because openssl is widely used and I >>> tend to think that it is the de-facto standard library. >>> A bit of a problem is the GPL-incompatible license. >>> >>> * GnuTLS >>> This is a much better choice in terms of licenses and GnuTLS is >>> also widely used. I'd like to keep it. >>> >>> * nss >>> The reason we have this is that RedHat started to move a lot of >>> their own software to it because nss is FIPS certified. However, >>> this certification is not important to us at this point in time >>> and nss is only used by glibc, apr-util and curl. All of them could >>> be compiler either without nss or with an other SSL library. >>> >>> * polarssl >>> This library came into the distribution very recently and is used >>> by the authoritative powerdns server. As far as I am aware, powerdns >>> cannot use any other library. >>> >>> Conclusively, we can't (or don't want) to get rid of openssl, GnuTLS and >>> polarssl. But nss looks like a candidate for me. Opinions? >>> >>> -Michael >>> >>> _______________________________________________ >>> Development mailing list >>> Development(a)lists.ipfire.org >>> http://lists.ipfire.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development(a)lists.ipfire.org > http://lists.ipfire.org/mailman/listinfo/development --===============4332397692442027163==--