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

Sat Nov 16 15:21:30 UTC 2019

First, thanks to everyone for all the useful feedback.  I really appreciate
it!

Let me try to explain my situation again as to why I need a service to do
both.

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
the TLS_server (will always have a certificate).  The same service runs on
multiple backup clients where it acts as the TLS_client,
listening for connections from the backup server.
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.
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

It sounds like peeking at the port may be the simplest way to determine how
it is being connected to.
As I write this I realize that the service running on all of the other
backup clients really only needs 2.
In this case, the backup client is a TLS_client, but it will be doing the
TCP accept.  No need to decide
which mode to use in this case..  It is the backup server's backup service
that needs to do both
and will always be a linux server, so setting up peek should work well.

Apple has a network framework (supports TLS 1.3) that I believe will
eventually replace the current security framework (supports
up to TLS 1.2) that I am using today to get the job done.  There is example
code here:

https://developer.apple.com/documentation/network/implementing_netcat_with_network_framework

I have been experimenting with this code.  I could not get it to work on
Mojave, but I could get it
to work on Catalina.  To summarize how I think it works:

1. You set up all of the connection parameters up front (TCP, TLS, TLS-PSK,
UDP, bonjour, etc, etc).
2. Next, create an endpoint using nw_endpoint_create_host
3. In the case of a service (listener) call nw_listener_create with the
parameters.

You now have an opaque object and in TLS mode, I do not see a way to access
the underlying TCP socket.
I've just realized that I need to do more testing against my common, but
odd case, where my client's
backup service needs to accept, but process w/o a cert as a TLS_client.
Joy!

Doing more digging today, I find in
https://forums.developer.apple.com/thread/116221

__BEGIN_COMMENTS__
I've not seen an equivalent way of message peeking
Such a mechanism does not exist.

or even getting the … socket.
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.

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.

You can learn more about the background to this in:

WWDC 2017 Session 707 Advances in Networking, Part 1

WWDC 2018 Session 715 Introducing Network Framework

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.
__END_COMMENTS

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?

Kris

On Fri, Nov 15, 2019 at 8:10 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Fri, Nov 15, 2019 at 03:10:55PM -0700, Kristen Webb wrote:
>
> > Is there a way for a single program to act as both a TLS client and a TLS
> > server after a TCP/IP accept() call?
>
> Yes, but as you're aware and others have mentioned it has to decide
> which somehow.
>
> > Today, I simply have the TCP connecting process issue a 1 or 0 to
> indicate
> > how it is acting.  This is then used to determine who does SSL_accept and
> > SSL_connect and everything works out.
>
> That's one valid way to do that.  Whoever is the server will need
> some sort of server certificte or have a PSK in common with the
> client.  The client can also use ia certificate, or authenticate
> via GSSAPI after the TLS connection is established, it could also
> perform GSSAPI channel binding to the server certificate.
>
> > Will PSK allow my service to say, always act as a TLS server without a
> > server certificate?
>
> Yes.  And you can even negotiate the PSK via an initial GSSAPI
> session establishment.  Then just use a nominal PSK id (say a single
> '\0' byte) that signals the just negotiated PSK.  Here you might
> have the TCP client also always be the GSSAPI initiator, but tell
> the (TCP/GSSAPI) server who will be the TLS server.
>
> > Could I then proceed with additional certificate functions (e.g. for
> > GSSAPI)?
>
> With that you would not need after-the-fact GSSAPI, because GSSAPI
> authentication is implied via the PSK.
>
> --
>     Viktor.
>

-- 
This message is NOT encrypted
--------------------------------
Mr. Kristen J. Webb
Chief Technology Officer
Teradactyl LLC.
2450 Baylor Dr. S.E.
Albuquerque, New Mexico 87106
Phone: 1-505-338-6000
Email: kwebb at teradactyl.com
Web: http://www.teradactyl.com

Providers of Scalable Backup Solutions
   for Unique Data Environments

--------------------------------
NOTICE TO RECIPIENTS: Any information contained in or attached to this
message is intended solely for the use of the intended recipient(s). If
you are not the intended recipient of this transmittal, you are hereby
notified that you received this transmittal in error, and we request
that you please delete and destroy all copies and attachments in your
possession, notify the sender that you have received this communication
in error, and note that any review or dissemination of, or the taking of
any action in reliance on, this communication is expressly prohibited.

Regular internet e-mail transmission cannot be guaranteed to be secure
or error-free. Therefore, we do not represent that this information is
complete or accurate, and it should not be relied upon as such. If you
prefer to communicate with Teradactyl LLC. using secure (i.e., encrypted
and/or digitally signed) e-mail transmission, please notify the sender.
Otherwise, you will be deemed to have consented to communicate with
Teradactyl via regular internet e-mail transmission. Please note that
Teradactyl reserves the right to intercept, monitor, and retain all
e-mail messages (including secure e-mail messages) sent to or from its
systems as permitted by applicable law
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20191116/07c63b2a/attachment-0001.html>