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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In the future, I will not have an initial TCP 1/0 packet (clue) to process.
So I have no way to decide if my forked/spawned process should SSL_connect
or SSL_accept.

For example, I cannot see how this can be done with Apple's network framework
(at least not yet).  It appears to be so high level as to not allow me
to process a TCP packet within a TLS style connection.  I realize that this is not
an openssl issue.  And I do have things working today with Apples security
framework and openssl (with that extra TCP packet clue in place).  I am more familiar
with openssl and I'm trying to code everything there first.  Also my entire application
runs on linux so I am able to test all the combinations easily from there.  And I'll
need it to work with Apple's networking in the future as their security APIs go away.

Thank you for bearing with me so far!





On Fri, Nov 15, 2019 at 4:01 PM Phil Neumiller <pneumiller@xxxxxxxxxxxxxxxx> wrote:
Yes, so you accept thread needs to either fork() or spawn another thread to
process the packet and go back into the accept loop for another connection.



-----
Phillip Neumiller
Platform Engineering
Directstream, LLC
--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html


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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux