Hi,

wolfSSL embedded SSL is agnostic towards blocking.  It doesn't even assume sockets are being used; it could be a memory buffer, a file, or something else entirely.  It uses an I/O abstraction layer to ask for data.  If you are using sockets and you want to ensure that SSL_read() doesn't block make sure the underlying file descriptor is set to non blocking.  If the underlying fd returns EWOULDBLOCK or EAGAIN then wolfSSL_read() will return SSL_FAILURE and wolfSSL_get_error() will return SSL_ERROR_WANT_READ.

Hope that helps,
-Todd

Hi DanC,

That trace has an SSLv3 AES-256bit key.  Technically AES cipher suites are TLS cipher suites.  wolfSSL in SSL v3 mode, which should NOT be used any longer, has enough rounds for the SSL v3 cipher suites.  We won't be enhancing SSL v3, in fact, we are completely phasing it out of our embedded SSL library.

I hope that helps,
-Todd

Hi!

We haven't heard of that problem before on the Raspberry Pi but I'll ask around and see if we can reproduce it.  I don't believe we're overriding any floating point defaults there.

Thanks,
-Todd

How did you create the public key?  My versions of openssl ec don't have a -pubout option like the man page does online.

We'll add a feature request to input OpenSSL DER/PEM format for ECC public keys.

Thanks,
-Todd

Typically a Public Key is retrieved from a Certificate.  How are you getting the public key?  If you have control you can specify the format.  Is this for a specific protocol?

Thanks,
-Todd

Handled off-line.   wolfSSL loops until requirement met.

Yes, wildcards are supported, each wildcard can represent a single name component or fragment but not mulitple names, that is, *.z.com matches y.z.com but not x.y.z.com.

Thanks,
-Todd

Hi Hans-Jürgen,

DoCertificate() uses the domainName buffer supplied to CyaSSL_check_domain_name() to check a direct domain name match with MatchDomainName().  If that check fails, it tries the alt names next with CheckAltNames().  Are you using an older version that didn't have this?

Thanks,
-Todd

Hi Demetri,

Thanks for the report.  There was a constant limiting DHE key exchange at the SSL layer to 2240bits.  It is now expanded to 4096bit: https://github.com/cyassl/cyassl/commit … 61a158c66a

Regards,
-Todd

Hi RM,

It appears the RNG seed isn't unique.   What system are you on?  What defines have you used?  In the bad capture the client is trying to resume, the server wants to create a new session instead but because a bad seed is used (the time?) it appears to the client that session resumption is going forward.  The client complains with an alert which may cause the server problems too.  In short, a unique seed needs to be found.  Does your os or hardware provide anything?

Thanks,
-Todd

Hi,

caCertGen.c is almost correct.  If you change the line

result = SignCert(...);

to

certSz = SignCert(...);

it should work because then the file write will have the correct size.

Regards,
-Todd

Hi Siddarth,

You have 2 options.

1) At build time you can use the XMALLOC and friends macros to point to whatever allocators you do have available, or write you own and point the macros to those.

2) At runtime you can install you own Allocators with CyaSSL_SetAllocators() found in cyassl/ctaocrypt/memory.h .

I hope that helps,
-Todd

Hi,

--host is usually a platform (os and chip) that is used for cross compilation.  If you are on a 64bit machine but trying to build for 32bit try:

./configure C_EXTRA_FLAGS=-m32 LDFLAGS=-m32

Thanks,
-Todd

Hi Gahr,

Thanks for the question, sorry for the delay.

I'd recommend using CyaSSL if possible, we've had more requests and updates for it lately.

The yaSSL API was an experimental API I tried out, no one really used it to my knowledge so I removed it from the default build.  I'd recommend using the OpenSSL compatibility API like the examples do.  If you'd like to try out the yaSSL API you should be able to compile yassl.cpp into your application (if it's still compatible) to get access to the API.

Thanks again,
-Todd

Hi,

Let's start with the basics.  What platform are you on?  What version of wolfSSL embedded SSL are you using?  How did you ./configure wolfSSL?  wolfSSL is using RSA 2048 bit keys.  Are you using the same keys when comparing?  The same cipher suite and protocol version?

How did you benchmark OpenSSL connection time?  Which version of OpenSSL?

If wolfSSL <-> OpenSSL is much faster than wolfSSL <-> wolfSSL then that suggests to me that you may be using different key sizes.

Thanks for the help,
-Todd

16

(3 replies, posted in General Inquiries)

Hi,

No, ease of use and development are the primary reasons.  If you're new to SSL in general, non-blocking, and udp that may be an insurmountable combination.  Each one has a high learning curve.  I prefer to tackle new things one at a time.  So I'd probably do something like:

1) Get a blocking TCP client and server communicating with each other in "plain text"
2) Add TLS security to 1)
3) Add non-blocking support to 2)

And then, maybe

4) Get a blocking UDP client and server communicating with each other
5) Add DTLS to 4)
6) Add non-blocking support to 5)

But that's just my preference.

Good luck,
-Todd

17

(3 replies, posted in General Inquiries)

Hi A.,

Our SSL library CyaSSL can use non blocking sockets for for SSL, TLS, and DTLS.  If you're new to non blocking programming I suggest starting with TLS because tcp sockets are generally easier to use than udp which DTLS is run on.  Our examples can be run in non blocking mode with the -N argument, e.g.,

./examples/server/server -N
./examples/client/client -N

SSL/TLS/DTLS connections don't directly use the public/private key pairs for encrypting messages.  Instead, the public/private key pairs are used to create a master secret during the handshake process that is then run through a PRF to create the encryption keys.  If you wan to directly use the public/private key pairs for encryption you may need to build that functionality yourself.  Though it's much harder than it sounds to create a secure system and we always suggest using TLS version 1.2.  There are a million ways to create a less secure system than that and very few to make a better one.

A third party is typically used in TLS as a Certificate Authority (CA), the CA signs certificates which allows for trusted certificates that you've never seen before as long as you trust the CA.

Key generation / certificate generation and signing can be done on a mobile device though you're going to get more security by having a dedicated specialized service doing that for you.

I hope these suggestions help you along,
-Todd

Thanks for the patch.  I agree with your analysis.  The only change I did was to move the bornOn reset into the locked region to prevent an unlikely race condition.  Here's the commit for your reference: https://github.com/cyassl/cyassl/commit … d0b6716afd

Thanks again.

The proper way to do this is to extend the timeout value that is compared with the bornOn time.  This can be done with:

wolfSSL_set_timeout()

It defaults to 500 seconds, but wolfSSL_set_timeout() can increase that value to whatever you like.

-Todd

You'll need to add --disable-fastmath as well since the mac gcc version no longer handles x86 assembly as well if you have to use i386 (see the note in the README under 2.6.0 ia32).  But that begs the question.  Why are you limiting to i386, is that even a possibility now?

Thanks,
-Todd

Hi Dan,

Access to the sniffer session table is thread safe.  What isn't thread safe, is using the same sniffer session from multiple threads.  For example, say sniffer session A is created by thread X. If 3 new packets come in for session A and threads X, Y, and Z all try to handle those packets concurrently that's a problem.  Ideally, you're main thread would associate an ssl sniffer session (client ip/client port <-> server ip/server port) with a particular thread and use that same thread for the lifetime of the session.  Short of that, the sniffer session would need a lock which isn't ideal in your scenario because once thread X locks the first packet from session A threads Y and Z would be blocked until thread X is done.  That defeats the whole purpose of what you're trying to accomplish.  Does that information help?

-Todd

Thanks for the report!

I just pushed a commit though a little different than yours.  The FreeMutex() needs to be one line up, using ctx->countMutex after freeing ctx will cause a problem on many systems.

Thanks again.

Thanks for the suggestions!  We've added those to the github dev branch.  How are you using the ssl sniffer?  Thanks again.

The wolfSSL embedded ssl sniffer adjusts packet sequences from actual to relative in a couple sports in sniffer.c, search for "rollover".  The sniffer packet buffer holds out of order packets until the full stream can be decoded and it uses relative sequences.  In order to hit the code you're talking about you've traced an SSL connection that sends more than 4GB of data in one direction?  That's potentially a misuse of SSL for a single connection, what's the use case if I may ask?

The "+ 1" is needed because a packet that starts at sequence 2 and goes through sequence 3 uses two bytes, not one.

end(3) - begin(2) + 1

I'm not sure if the packet buffer lists can handle more than 4GB of data, that will require some more testing on our end. 

Thanks for the report.

25

(1 replies, posted in yaSSL (Deprecated) [READ ONLY])

Hi!

Thanks for the heads up.  I just pushed a commit to fix these warnings: https://github.com/cyassl/cyassl/commit … 7cc2d950b2

I tried to verify that this would remove the warnings but the viva64.com site appears to be down temporarily.  I'll do that once it's back up.

Thanks again for letting us know.