<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Mr. Neugroschl's <span dir="ltr">quest
for a simple solution does bring up -- in my user-oriented
opinion -- a very good follow-on question: "<i>Why cannot a
config file be utilized by openssl to simply give access based
on an allow/deny mechanism that would give users system-wide
control in a single place?".</i><br>
<br>
the benefits of such an implementation are clearly manifold from
the admin side. as a vulnerability arises, a weakness is
revealed, a specific requirement is desired; a user can close
out or enable any use of that avenue in a heartbeat ...
permanently (<i>i.e.</i>, persisting through updates),
temporarily until a patch can be applied or a new release
installed, or when requirements change. this would also greatly
ease using openssl (think "views" in bind: although openssl's
approach does not have to be as "unified" as bind's single
config file) so that openssl could be tailored to different
access methods such as intranet, tunnels, VPN's, et cetera.<br>
<br>
from the dev side i would think this approach would also have
benefits worth exploring. FIPS immediately comes to mind. its
hard-coded approach and protracted separate compliance
certification could be distilled down to checking a hash (or
some such security check) on a special over-riding config file
when FIPS-enabled is encountered. this would also speed access
to standards creators to modify the config file on the fly
instead of interludes that can consume years despite
industry-wide documentation/recognition that something must be
done. then, openssl merely needs to be updated with the new hash
or whatever.<br>
<br>
in fact, openssl could really foster transparency within the
whole auth/encrypt process by creating its own allow/deny master
listing that a user could modify at will without the need to be
conversant at any type of coding. providing a more inclusive and
user-friendly process also could, perhaps, forestall app's from
"going-it-alone" or using other vendors such as experienced with
openssh and lua.<br>
<br>
i DO realize that such a "modular" approach instead of
"all-or-nothing" is not a simple matter from the dev side, but
permitting the user an ability to go <i>a la carte</i>
according to specific needs seems highly attractive. it could
also enable user migration scheduling (think sha1 to sha2, for
instance) to keep pace with internal systems integration,
configuration, and updating.<br>
<br>
there are also matters like the 25519 family which "enjoyed" a
decade in virtual limbo until recently emerging as the
"cats-meow" of speed and security (1. non-NSA/-NIST; 2.
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/draft-ietf-ipsecme-safecurves-03">https://tools.ietf.org/html/draft-ietf-ipsecme-safecurves-03</a>;
and 3. <a class="moz-txt-link-freetext" href="https://ed25519.cr.yp.to">https://ed25519.cr.yp.to</a>). perhaps if more people saw
that it was available via openssl (assuming openssl made it so)
and did earlier experimenting with it the hiatus could have been
foreshortened and everyone would have benefited. i know openssl
cannot include <i>everything</i>, but this particular process
is </span><span dir="ltr"><a
href="https://en.wikipedia.org/wiki/Daniel_J._Bernstein"
title="Daniel J. Bernstein">Daniel J. Bernstein</a> after all
and its "pluses" well-documented and long-known.<br>
<br>
BUDGETING: i cannot image the large-donor base NOT being
enthusiastic re this approach. i also certainly see where
openssl could attract new and more one-time/smaller donors to
such a "crowd funding" project that exhibits a very real and
visible translation of time to money.<br>
<br>
</span>
<pre class="moz-signature" cols="80">Thank you,
Johann v. Preußen
</pre>
On 2016.Sep.24 08:04, Richard Moore wrote:<br>
</div>
<blockquote
cite="mid:CAMp7mVs__N4Rp_PcAD5Mc+Hk3UcodHAc3L9e=AVSLq93Nx2KRA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 23 September 2016 at 17:13, Scott
Neugroschl <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:scott_n@xypro.com" target="_blank">scott_n@xypro.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal">Hi,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">I’m afraid the man page on the
conf file is not particularly clear. I’m looking
at mitigating CVE-2016-2183 (SWEET32), and am not
sure how to disable the DES and 3DES suites in the
conf file.</p>
<p class="MsoNormal">Can someone give me a hand?</p>
<p class="MsoNormal"> </p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;display:inline">
You can't disable them in the openssl config file, you
should do it in the cipher suite configuration of the
affected application.</div>
</div>
<div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;display:inline"><br>
</div>
</div>
<div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;display:inline">Cheers</div>
</div>
<div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;display:inline"><br>
</div>
</div>
<div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;display:inline">Rich.</div>
</div>
<div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;display:inline"></div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>