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?
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. My original idea was that I could
then configure any number of supporting services on the same port going
forward.
I'd like to remove this 1 time TCP write/read operation. For example, I
cannot see how this will work with Apple's network framework going forward.
I currently have 3 authentication use cases
Server side cert (currently only works in one direction without my
workaround)
Server side cert with GSSAPI (currently only works in one direction
without my workaround)
Client/Server certs (so this one should work either way)
Will PSK allow my service to say, always act as a TLS server without a
server certificate?
Could I then proceed with additional certificate functions (e.g. for
GSSAPI)?
Or should I go back and grovel for another port and use this information to
explain why I need one?
Many thanks in advance for any insights!
Kris
--
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: kw...@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
