Can a linux service work as both TLS client and server?

Karl Denninger karl at denninger.net
Sat Nov 16 02:40:41 UTC 2019


On 11/15/2019 17:27, Kristen Webb wrote:
> 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_connect
> or 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 me
> to process a TCP packet within a TLS style connection.  I realize that
> this is not
> an openssl issue.  And I do have things working today with Apples security
> framework and openssl (with that extra TCP packet clue in place).  I
> am more familiar
> with openssl and I'm trying to code everything there first.  Also my
> entire application
> runs on linux so I am able to test all the combinations easily from
> there.  And I'll
> need 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.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20191115/263c2dfc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20191115/263c2dfc/attachment.bin>


More information about the openssl-users mailing list