<div dir="ltr">First, thanks to everyone for all the useful feedback.  I really appreciate it!<div><br></div><div>Let me try to explain my situation again as to why I need a service to do both.</div><div><br></div><div>1. I have a single service listening on a well known port.  it is a backup service that runs on the backup server which will always be</div><div>the TLS_server (will always have a certificate).  The same service runs on multiple backup clients where it acts as the TLS_client,</div><div>listening for connections from the backup server.</div><div>2. In a common mode, a separate backup server process (TLS_server) will connect to it and the backup service needs to act as a TLS_client.<br></div><div>3. In another mode a backup client (TLS_client) will connect the backup service on the backup server and that service needs to act as a TLS_server</div><div></div><div><br></div><div>It sounds like peeking at the port may be the simplest way to determine how it is being connected to.</div><div>As I write this I realize that the service running on all of the other backup clients really only needs 2.</div><div>In this case, the backup client is a TLS_client, but it will be doing the TCP accept.  No need to decide</div><div>which mode to use in this case..  It is the backup server's backup service that needs to do both</div><div>and will always be a linux server, so setting up peek should work well.</div><div><br></div><div>Apple has a network framework (supports TLS 1.3) that I believe will eventually replace the current security framework (supports</div><div>up to TLS 1.2) that I am using today to get the job done.  There is example code here:</div><div><br></div><div><a href="https://developer.apple.com/documentation/network/implementing_netcat_with_network_framework">https://developer.apple.com/documentation/network/implementing_netcat_with_network_framework</a><br></div><div><br></div><div>I have been experimenting with this code.  I could not get it to work on Mojave, but I could get it</div><div>to work on Catalina.  To summarize how I think it works:</div><div><br></div><div>1. You set up all of the connection parameters up front (TCP, TLS, TLS-PSK, UDP, bonjour, etc, etc).</div><div>2. Next, create an endpoint using nw_endpoint_create_host</div><div>3. In the case of a service (listener) call nw_listener_create with the parameters.</div><div><br></div><div>You now have an opaque object and in TLS mode, I do not see a way to access the underlying TCP socket.</div><div>I've just realized that I need to do more testing against my common, but odd case, where my client's</div><div>backup service needs to accept, but process w/o a cert as a TLS_client.  Joy!</div><div><br></div><div>Doing more digging today, I find in  <a href="https://forums.developer.apple.com/thread/116221">https://forums.developer.apple.com/thread/116221</a></div><div><br></div><div>__BEGIN_COMMENTS__</div><div>I've not seen an equivalent way of message peeking<br>Such a mechanism does not exist.<br><br>or even getting the … socket.<br>Nor does that, at least in general.  Network framework was designed to work in conjunction with our user space networking stack, and that stack does not have an underlying socket because sockets are a kernel-only concept.<br><br>Now, on macOS, Network framework does actually talk to the kernel, but that’s just a compatibility measure: We can’t enable the user space networking stack on the Mac while continuing to support Network Kernel Extensions (NKEs).  NKEs have been informally deprecated for a while now, so the expectation is that they’ll be formally deprecated and then removed in future OS releases, at which point macOS will work like all our other OSes in this regard.<br><br>You can learn more about the background to this in:<br><br>WWDC 2017 Session 707 Advances in Networking, Part 1<br><br>WWDC 2018 Session 715 Introducing Network Framework<br><br>All of this is to say that, if you can’t do what you want with Network framework, the time to an enhancement request for the facilities that you need is now.<br></div><div>__END_COMMENTS</div><div><br></div><div>It appears that if you do not keep up with the apple way of doing things on OSX at some point you will be locked out?</div><div><br></div><div>Kris</div><div><br></div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 15, 2019 at 8:10 PM Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org">openssl-users@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Nov 15, 2019 at 03:10:55PM -0700, Kristen Webb wrote:<br>
<br>
> Is there a way for a single program to act as both a TLS client and a TLS<br>
> server after a TCP/IP accept() call?<br>
<br>
Yes, but as you're aware and others have mentioned it has to decide<br>
which somehow.<br>
<br>
> Today, I simply have the TCP connecting process issue a 1 or 0 to indicate<br>
> how it is acting.  This is then used to determine who does SSL_accept and<br>
> SSL_connect and everything works out.<br>
<br>
That's one valid way to do that.  Whoever is the server will need<br>
some sort of server certificte or have a PSK in common with the<br>
client.  The client can also use ia certificate, or authenticate<br>
via GSSAPI after the TLS connection is established, it could also<br>
perform GSSAPI channel binding to the server certificate.<br>
<br>
> Will PSK allow my service to say, always act as a TLS server without a<br>
> server certificate?<br>
<br>
Yes.  And you can even negotiate the PSK via an initial GSSAPI<br>
session establishment.  Then just use a nominal PSK id (say a single<br>
'\0' byte) that signals the just negotiated PSK.  Here you might<br>
have the TCP client also always be the GSSAPI initiator, but tell<br>
the (TCP/GSSAPI) server who will be the TLS server.<br>
<br>
> Could I then proceed with additional certificate functions (e.g. for<br>
> GSSAPI)?<br>
<br>
With that you would not need after-the-fact GSSAPI, because GSSAPI<br>
authentication is implied via the PSK.<br>
<br>
-- <br>
    Viktor.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr">This message is NOT encrypted
<br>--------------------------------
<br>Mr. Kristen J. Webb
<br>Chief Technology Officer
<br>Teradactyl LLC.
<br>2450 Baylor Dr. S.E.
<br>Albuquerque, New Mexico 87106
<br>Phone: 1-<span style="display:inline;font-size:inherit;padding:0pt;color:rgb(80,80,80)">505-338-6000</span>
<br>Email: <a href="mailto:kwebb@teradactyl.com" target="_blank">kwebb@teradactyl.com</a>
<br>Web: <a href="http://www.teradactyl.com" target="_blank">http://www.teradactyl.com</a>
<br>
<br><img src="https://drive.google.com/a/teradactyl.com/uc?id=1AtTRUbNsHoJJEO8vs4zd6D2oON5Evwq4&export=download"><br><br>Providers of Scalable Backup Solutions
<br>   for Unique Data Environments
<br>
<br>--------------------------------
<br>NOTICE TO RECIPIENTS: Any information contained in or attached to this
<br>message is intended solely for the use of the intended recipient(s). If
<br>you are not the intended recipient of this transmittal, you are hereby
<br>notified that you received this transmittal in error, and we request
<br>that you please delete and destroy all copies and attachments in your
<br>possession, notify the sender that you have received this communication
<br>in error, and note that any review or dissemination of, or the taking of
<br>any action in reliance on, this communication is expressly prohibited.
<br>
<br>
<br>Regular internet e-mail transmission cannot be guaranteed to be secure
<br>or error-free. Therefore, we do not represent that this information is
<br>complete or accurate, and it should not be relied upon as such. If you
<br>prefer to communicate with Teradactyl LLC. using secure (i.e., encrypted
<br>and/or digitally signed) e-mail transmission, please notify the sender.
<br>Otherwise, you will be deemed to have consented to communicate with
<br>Teradactyl via regular internet e-mail transmission. Please note that
<br>Teradactyl reserves the right to intercept, monitor, and retain all
<br>e-mail messages (including secure e-mail messages) sent to or from its
<br>systems as permitted by applicable law
</div></div></div></div>