In the future, I will not have an initial TCP 1/0 packet (clue) to process.So I have no way to decide if my forked/spawned process should SSL_connector SSL_accept.
For example, I cannot see how this can be done with Apple's network framework(at least not yet). It appears to be so high level as to not allow meto process a TCP packet within a TLS style connection. I realize that this is notan openssl issue. And I do have things working today with Apples securityframework and openssl (with that extra TCP packet clue in place). I am more familiarwith openssl and I'm trying to code everything there first. Also my entire applicationruns on linux so I am able to test all the combinations easily from there. And I'llneed it to work with Apple's networking in the future as their security APIs go away.
Thank you for bearing with me so far!
I don't quite understand what you're attempting to do, or why.
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?
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.
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.
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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
