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 conne
On 11/15/2019 17:27, Kristen Webb wrote:
> 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
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Kristen Webb
> Sent: Friday, November 15, 2019 18:27
>
> 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 netwo
I'm curious, its pretty unusual to not know which side of a TCP connection
is the client or server, not just TLS, HTTP, SMTP, etc. Its almost
always the side that makes the accept() call that's the server, but that
doesn't have to be.
Why is it that you do not in this context?
Without it, yo
On 15/11/2019 22:03, Phil Neumiller wrote:
>
> TLS 1.3 doesn't use EC point formats right? I don't know why they are in my
> TLS 1.3 client hello.
No, its not used in TLSv1.3 but is used in TLSv1.2 or below. A
ClientHello is sent before version negotiation takes place so you don't
know what v
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
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
Hi Phil,
Thanks for such a fast response! I am doing the polling today.
I believe I left something very important out of my original question.
I only have 1 well known port to accept all of my connections.
TLS_client_app -> service on portA (needs to be a TLS_server)
TLS_server_app -> service on
Sure, you just need additional threads. Note: accept is a blocking call so
the thread that runs in (i.e. your server side will block until a packet is
received). You can write a polling loop using select, that doesn't block.
The cleanest thing to do is have a thread for client(s) and one for ser
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.
TLS 1.3 doesn't use EC point formats right? I don't know why they are in my
TLS 1.3 client hello.
Extension: ec_point_formats (len=4)
Type: ec_point_formats (11)
Length: 4
EC point formats Length: 3
Elliptic curves point formats (3)
EC point format: uncompressed (0)
Hello again,
maybe i have found the difference in the CMSes generated by OpenSSL and Windows.
This is the keyEncryptionAlgorithm in kari generated on Windows:
keyEncryptionAlgorithm:
algorithm: dhSinglePass-stdDH-sha1kdf-scheme (1.3.133.16.840.63.0.2)
parameter: SEQUENCE:
Hello,
when generating a CMS with OpenSSL 1.1.1d or OpenSSL 1.0.2g using only ECC
Keys, Windows 10 is unable to decrypt the CMS.
All Passwords for keys is "test".
Encrypting:
openssl cms -encrypt -outform PEM -recip bob.pem -in Test.eml -out
opensslencrypted.cms -aes256 -aes128-wrap
Decryptio
> On Nov 15, 2019, at 4:25 AM, Matt Caswell wrote:
>
> It might be nice if we added a new option "-pskmd" or similar which
> enabled you to specify the md from the command line without having to
> have a session file first. However that isn't currently possible.
With a saved session there may ac
On 14/11/2019 22:30, Phil Neumiller wrote:
> Hi Matt,
>
> That works fine for 256 as you mentioned. I trying to speak to a piece of
> hardware that has one supported cipher, i.e. TLS_AES_256_GCM_SHA384. I
> tried the naive approach of
>
> PSK=63ef2024b1
> openssl s_server -accept 4433 -tls
15 matches
Mail list logo