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:
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.
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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxx
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
--------------------------------
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@xxxxxxxxxxxxxx
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
