<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/1/2017 2:57 PM, Michael Wojcik
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:B550B44BF8AF314BB00C4E2AC1C1808801A9AE0D84@prvxmb03.microfocus.com">
      <blockquote type="cite">
        <pre wrap="">Yes, compatibility is a concern.  So make the "default to secure" options be new functions.
</pre>
      </blockquote>
      <pre wrap="">That's certainly better than what you proposed in your previous messages.</pre>
    </blockquote>
    <br>
    Sorry, I wasn't trying to propose any particular concrete
    interfaces.  I was trying to speak abstractly:  "a client should be
    able to say 'give me a secure connection to host:port' and have
    sensible and secure things happen with a single call.  Maybe two,
    one to create a handle and the other to actually set up the
    connection (to allow for intervening calls that customize the
    connection)."  (OK, yeah, I did get a bit more concrete later, but I
    never said "change the existing functions".)<br>
    <br>
    <blockquote type="cite"
cite="mid:B550B44BF8AF314BB00C4E2AC1C1808801A9AE0D84@prvxmb03.microfocus.com">
      <pre wrap="">Of course, anyone's free to write their own API on top of what OpenSSL provides, and even make a pull request to contribute it to the project.</pre>
    </blockquote>
    <br>
    If only I had the time.  I do greatly respect the work that people
    do on FOSS projects.  I just wish more would focus on getting the
    common cases to be easy and bulletproof, and less on being all
    things to all people.<br>
    <br>
    <blockquote type="cite"
cite="mid:B550B44BF8AF314BB00C4E2AC1C1808801A9AE0D84@prvxmb03.microfocus.com">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">Looking at it another way:  browsers manage to do it...
</pre>
          </blockquote>
          <pre wrap="">Manage to do what, exactly? And how are browsers a good model for the vast range of OpenSSL applications? They're
 just one type of client that nearly always uses a very particular PKI model.
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">Manage to make reasonably secure connections with a minimum of user hassle.
</pre>
      </blockquote>
      <pre wrap="">
Still just one type of client.</pre>
    </blockquote>
    <br>
    Maybe I just don't have a big enough picture, but in my TLS-related
    work (mostly client LDAP, but some other stuff) I keep coming back
    to a browser as the behavior that I should emulate.<br>
    <br>
    <blockquote type="cite"
cite="mid:B550B44BF8AF314BB00C4E2AC1C1808801A9AE0D84@prvxmb03.microfocus.com">Frankly,
      what I'd like is fewer people using OpenSSL at all. Not
      necessarily fewer applications, but fewer *people*. Cryptography
      and security are inherently difficult; TLS is particularly bad,
      because of its history, configurability, interoperability demands,
      and horrendously broken PKI. It's an area for experts. I'd like
      the barrier to entry to be *higher*, so we'd see fewer people
      posting messages like "I tried to write a server using OpenSSL but
      I don't understand cipher suites".
    </blockquote>
    <br>
    What should they use instead?<br>
    <br>
    What *should* core OpenSSL developers be focused on?<br>
    <br>
    And why should callers have to understand cipher suites at any deep
    level?  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?<br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Jordan Brown, Oracle Solaris</pre>
  </body>
</html>