<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 12/2/2017 6:35 AM, Michael Wojcik
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:B550B44BF8AF314BB00C4E2AC1C1808801A9AE12C2@prvxmb03.microfocus.com">My
personal priority list for OpenSSL is bug fixes and code cleanup
(static and dynamic analysis of the 1.1.x codebase would be good,
and one of these days I'll get around to doing it myself), and
continuing the TLSv1.3 implementation until that standard finally
settles down. (I'm not much of a TLSv1.3 fan, but customers will
demand it.) If there's spare time, the docs always need work.
PKCS#12 support could be improved (though maybe it's better in
1.1.x).
</blockquote>
<br>
I would never, ever, object to putting bug fixes at the top of the
list.<br>
<br>
But at the same time we're talking about trying to prevent bugs in
the callers, and that's valuable too.<br>
<br>
<blockquote type="cite"
cite="mid:B550B44BF8AF314BB00C4E2AC1C1808801A9AE12C2@prvxmb03.microfocus.com">
<pre wrap="">A better question might be "why are the common cases common at all?". Why are so many people writing code that calls the OpenSSL API?</pre>
</blockquote>
<br>
Because they know they need a secure connection, and they know that
that means TLS/SSL, and they know that the leading library for
TLS/SSL is OpenSSL, and nothing says "you should be using libFOO
instead". You look for the key under the street light, because
that's where the light is.<br>
<br>
<blockquote type="cite"
cite="mid:B550B44BF8AF314BB00C4E2AC1C1808801A9AE12C2@prvxmb03.microfocus.com">[Emulating
a browser is] fine for some things, but it doesn't help with
servers and it falls over for non-interactive use (or even
interactive but non-GUI), or for anything where PKI gets more
complicated.
</blockquote>
<br>
And yet it's probably better than 95% of what you'll get from
non-experts rolling their own.<br>
<br>
My work is almost entirely non-interactive during production. So
far, I've been pretty happy with a model that says "emulate a
browser during initial interactive configuration, then use those
settings during production and light a yellow light when anything
goes wrong".<br>
<br>
(And yes, of course browsers aren't servers... there I'd say
"Emulate Apache httpd".)<br>
<br>
<blockquote type="cite"
cite="mid:B550B44BF8AF314BB00C4E2AC1C1808801A9AE12C2@prvxmb03.microfocus.com">
<blockquote type="cite">
<pre wrap="">What should they use instead [of OpenSSL]?
</pre>
</blockquote>
<pre wrap="">Libraries and programs written by people who *do* understand cryptography.</pre>
</blockquote>
<br>
It seems like our only disagreement is in who should supply those
libraries, whether OpenSSL should supply one or should leave it to
others.<br>
<br>
<blockquote type="cite"
cite="mid:B550B44BF8AF314BB00C4E2AC1C1808801A9AE12C2@prvxmb03.microfocus.com">
<pre wrap="">Why do programmers need to be in control of so much of their own software stacks?</pre>
</blockquote>
<br>
Totally agreed, they shouldn't. They need to be guided into doing
the right thing. It should be hard to do the wrong thing.
Everybody will be happier.<br>
<br>
<blockquote type="cite"
cite="mid:B550B44BF8AF314BB00C4E2AC1C1808801A9AE12C2@prvxmb03.microfocus.com">
<blockquote type="cite">
<pre wrap="">Why should they need to know any more than "there are multiple algorithms, and new algorithms are introduced
occasionally, and old algorithms are defeated occasionally, but you may need old algorithms for interoperability, so
you need to have a way to select which algorithms you accept"? That's pretty much the limits of my mental model;
what am I missing?
</pre>
</blockquote>
<pre wrap="">
Urgh. I don't really have room (or permission) to post all of Ivan Ristic's /Bulletproof TLS/ book here.
Let's try this. "The C language has various operators and standard library functions, and new functions are introduced occasionally, and old functions are deprecated occasionally, but you may have code that uses old functions, so you need to pick what functions you'll use." Is that a good mental model for writing C programs?
</pre>
</blockquote>
<p>I have a simplistic viewpoint, but the operators in C are mostly
distinct and do different things, while the cipher suites all do
the same things, differing only internally. I don't know, nor do
I want to know, how algorithm X is different from algorithm Y, or
what key lengths are considered adequate this week. If I write my
application to incorporate any of that knowledge, it will be wrong
next year. My application needs to not care which algorithms it's
using, and to be trivially adaptable (preferably at runtime) as
the situation changes over the years. Anything that I know about
the actual algorithms will probably make that picture worse, not
better. As you say, those decisions need to be made by people who
*do* understand these things... which excludes 99% of developers.</p>
<p>Thanks for the thoughtful discussion. I really appreciate it.<br>
</p>
<pre class="moz-signature" cols="72">--
Jordan Brown, Oracle Solaris</pre>
</body>
</html>