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

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

Handled off-line.   wolfSSL loops until requirement met.

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

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

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.

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

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.

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.