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.
