Date: Mon, 28 Dec 2020 23:07:49 -0800 From: John Kennedy <warlock@phouka.net> To: "Dan Mahoney (Gushi)" <freebsd@gushi.org> Cc: freebsd-ports@freebsd.org Subject: Re: Re-enabling old ciphers in openssl Message-ID: <X%2BrVxVLsAytc/2rh@phouka1.phouka.net> In-Reply-To: <7d31329e-aed5-3b24-a66e-43ef7d3dcbfa@prime.gushi.org> References: <7d31329e-aed5-3b24-a66e-43ef7d3dcbfa@prime.gushi.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 27, 2020 at 03:49:10PM -0800, Dan Mahoney (Gushi) wrote:
> Hey there all.
>
> This is a "don't try this at home" question. This is not something I'm
> asking how to do in the general case, but I'd like to know.
>
> It seems recently (since 1.1.1, OpenSSL has deprecated a number of
> ciphers, and made them a compile-time default disable.) ...
> Ergo, I am wondering what the best way forward is to get a reasonably
> patched version of openssl that has old ciphers turned on (since it is
> still possible at compile-time, the code hasn't been outright removed),
> that I can build *some* subset of ports against.
>
> Here are the questions I can't seem to answer:
>
> 1) There's no make.conf entry to override the openssl ciphers. This needs
> to be done at the port level. (Probably reasonable, I don't think there
> should be an insecure "flavor") But in the interest of making things
> reproducible, is there a "Standard" way to keep this consistent without
> running "make config" every time, or echo'ing options into
> /var/db/ports/security-openssl/options?
If you can submit a patch, the person that maintains OpenSSL may accept it.
If not, you can always have a local-to-your-system patch that permits it.
That would give you a OpenSSL that allows it. Hopefully your window of
support isn't so big that you have to go back and start using obsolete/
dangerous versions of the software, because at some point software support
may get yanked out for those.
Either way, you start out with your own patch.
> 2) I'm unclear as to what to put in make.conf to tell ONE PORT to use the
> openssl from ports, while I want all the others to use base. I know this
> is in some cases askign for trouble, but the nagios plugins are standalone
> binaries. Is there some method in make.conf or on the port command line
> to tell ONE PORT to use a defaults+=ssl-openssl without making it the
> default for ALL PORTS?
Assuming that by default the DEFAULT_VERSIONS for ssl is base, you'd just
want to use the .if syntax for your port. Something like:
.if ${.CURDIR:M*/www/firefox}
DEFAULT_VERSIONS += ssl=openssl
.endif
That shouldn't be a syntax error, but I'm not sure it'll do what you want or
be anywhere near complete enough (I just picked it because you mentioned
firefox). Firefox has a ton of dependencies, and if one of them needs
SSL then you're going to want it running against the same version of SSL
and now you're going to be chasing a lot of nitty-gritty details that will
change over time.
Not sure if poudriere (or whatever you're using to build packages) will
complain about the potential conflicts that setup might imply.
You seemed to want a minimum amount of apps that might be linked against
the less-secure library, so there are going to be some tradeoffs there.
I haven't played with it in a while, but SSL_CTX_set_cipher_list() may
or may not be your friend if the software you're interested in lets you
configure it (so you can exclude bad ciphers where you don't want them,
and include them where you do) but then you still have to hope that
if you're using strength levels (high, medium, low, etc) that the ciphers
you want aren't getting discriminated against in multiple ways. And
who knows how that function would be called across all the packages+ports.
It sounds like you're trying to do your best with the insecure targets,
so I'm not sure if your insecure jump-hosts would be treated the same
(responsibly), then I might not feel too bad if openssl was recompiled
for everything on the box as long as it wasn't weak for incoming traffic.
Weak for outgoing traffic might be considered acceptable since the only
things it would be talking to are the known-weak remote devices.
If it was a multi-purpose host (like you were using it for other admin
purposes, like looking up documentation out on the web) then I'd lean
way more towards jailing those packages somewhere.
> 3) If I do all that, ports seems to lack a standard way to build static
> binaries, which is what I'd really like. Is there an easy way to do this,
> or is it best to work outside the ports system at that point?
Don't know the answer to that one.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?X%2BrVxVLsAytc/2rh>