<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 11/15/2019 17:27, Kristen Webb
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CANPK4Hakj5p88RWG+uZR6kr6Vj8CTUVkcRFwuTt+s5hXre8Zyw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">In the future, I will not have an initial TCP 1/0
        packet (clue) to process.
        <div>So I have no way to decide if my forked/spawned process
          should SSL_connect</div>
        <div>or SSL_accept.</div>
        <div><br>
          <div>For example, I cannot see how this can be done with
            Apple's network framework
            <div>(at least not yet).  It appears to be so high level as
              to not allow me</div>
            <div>to process a TCP packet within a TLS style connection. 
              I realize that this is not</div>
          </div>
          <div>an openssl issue.  And I do have things working today
            with Apples security</div>
          <div>framework and openssl (with that extra TCP packet clue in
            place).  I am more familiar</div>
          <div>with openssl and I'm trying to code everything there
            first.  Also my entire application</div>
          <div>runs on linux so I am able to test all the combinations
            easily from there.  And I'll</div>
          <div>need it to work with Apple's networking in the future as
            their security APIs go away.</div>
          <div><br>
          </div>
          <div>Thank you for bearing with me so far!</div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    <p>I don't quite understand what you're attempting to do, or why.</p>
    <p>I assume (since you're sending the initial packet) that the
      "thing" connecting to the OpenSSL end is under your control (it's
      your code.)  If so, why do you care which "way" the listening end
      comes up?</p>
    <p>By convention if you are doing a listen() on an a socket then
      you're a server.  You don't have to be from an SSL perspective,
      but from a socket perspective you absolutely are.</p>
    <p>So why do you want to select "which way" you do this on the
      TLS/SSL end?  Is it a function of which end has a certificate (or
      whether both do) and which one(s) you care to verify (or not)?  If
      so that can be dealt with through options and who checks what,
      rather than what you're doing now.</p>
    <p>I'm trying to understand the workflow you are attempting to
      implement, and why, because I suspect you may be going about this
      the hard way.<br>
    </p>
    <div class="moz-signature">-- <br>
      Karl Denninger<br>
      <a href="mailto:karl@denninger.net">karl@denninger.net</a><br>
      <i>The Market Ticker</i><br>
      <font size="-2"><i>[S/MIME encrypted email preferred]</i></font>
    </div>
  </body>
</html>