Satish,

CyaSSL offers both a smaller memory footprint as well as features which yaSSL doesn't have.  For a list of features offered by yaSSL and CyaSSL, please see the two product pages:

yaSSL: http://yassl.com/yaSSL/Products-yassl.html
CyaSSL: http://yassl.com/yaSSL/Products-cyassl.html

Please let us know if you have any additional questions.

Best Regards,
Chris

Hi,

It looks like you may not have a C++ compiler installed on your system.  Can you try installing gcc-c++?

apt-get update 
apt-get install gcc-c++

Regards,
Chris

Edgard,

We recently made a change to the way our examples work.  Before if IPv6 examples/tests were turned on, localhost only was used.  Now link-local (with scope ids) and IPv6 hosts can be used as well.  Can you try our updated code from GitHub (https://github.com/wolfssl/wolfssl)?  We'll have a new stable release out today (wolfSSL 2.6.0) as well if you would like to wait for that.

Thanks,
Chris

Hi Edgard,

It's often easier to test with the example client (./examples/client/client) and server (./examples/server/server), as they offer several command line options for setting host, port, etc.  You can run either with the "-h" option to see a list of commands available to the user.

When running the example server, you'll need to add -b (bind to any interface on server unless localhost only is desired).

Are you connecting to the other machine through a router?  If so, does your router have IPv6 support?  Usually you'll see some kind of setting in your router configuration to enable IPv6 if so.  If not, this could be the cause of not being able to connect across different computers. 

You should still be able to connect over IPv4 though, so there must be something else off as well.  Have you double checked your IP addresses for both machines?  When running using IPv4, are both copies of wolfSSL embedded SSL compiled WITHOUT the "--enable-ipv6" flag?

Thanks,
Chris

Thanks for verifying that the underlying crypto is working correctly.  Are you using the certs/keys that the CTaoCrypt test application generates?  Using these may be a good starting place.  When keygen and certgen are enabled, the CTaoCrypt test app generates

<cyassl_root>/cert.pem
<cyassl_root>/cert.der
<cyassl_root>/key.pem
<cyassl_root>/key.der

The cert generated by certgen is a CA cert, which uses the <cyassl_root>/certs/client-key.pem as the key for cert.pem.  To test interoperability between fastmath and the big integer library I compiled CyaSSL with the big integer library and generated the above cert and key.  I then re-compiled CyaSSL with fastmath enabled, and started the example server like so:

./examples/server/server -k ./certs/client-key.pem -c ./cert.pem -d

The "-d" turns off client certs to simplify our testing.  I then started the example client like so:

./examples/client/client -A ./cert.pem

The client was able to verify the server certificate, also verifying that the big integer library is compatible with fastmath (on our end).  Can you try testing with the cert/key generated by our CTaoCrypt test app?

Thanks,
Chris

Dan,

Thanks for the explanation.  I see what you were doing now - just correcting the value of sslBytes to what it was prior to the core dump.

Let me explain a little bit about how AdjustSequence() works.  For this explanation, assume that we're expecting sequence 1,000, our incoming sequence is 800, with length = 700.  So, when we enter AdjustSequence():

expected = 1000
real = 800

if (real < *expected)

Here we test if the sequence we just got is before what we are currently expecting.  We may have already processed it (or some of it).

if (real + *sslBytes > *expected)

Here we catch the case where the sniffer has already consumed some of the front of the packet.  In this example case, the overlap would be 200 (1000 - 800).

*sslFrame += overlap;                                               
*sslBytes -= overlap;

As a result, we increment the frame pointer at offset 'real' by the overlap amount.  We also decrease the length (sslBytes) by the overlap.  This puts the frame pointer at 1,000 (the expected), and the sslBytes (length) at 500.

if (reassemblyList) {
     word32 newEnd = *expected + *sslBytes;
     if (newEnd > reassemblyList->begin)

Before just going ahead and processing bytes 1,000 - 1,500, we check to see whether the sniffer already has any of those bytes on the reassembly list.  Let's say for this example that the reassembly list already has bytes 1,200 - 1,500.

We detect this case by checking whether newEnd (1,500) is ahead of the beginning of the reassembly list.

*sslBytes -= newEnd - reassemblyList->begin;

If so, we remove the bytes we already have on the reassembly list.  In this example's case this would be:
500 -= 1500 - 1200, which is 200.  This means we have to process bytes 1,000 through 1,200 and then the reassembly list can take over.

if (newEnd > reassemblyList->end)

The sniffer also does a check to catch the case where it has gotten some bytes which are past the end of the reassembly list - thus not on it yet.  In this case, the end of the packet gets placed on the reassembly list.

Hopefully this helps clear things up a little.

- Chris

Hi Belen,

Ok, thanks for letting me know.  We may need to add a CyaSSL_CertManagerLoadCABuffer() function to allow loading CA certs from buffers.  I'll keep you posted.

Thanks,
Chris

Hi Dan,

Can you explain more about how and why you modified the value of "expected" in AdjustSequence()?  I think this might be what's throwing your sslBytes calculations off, thus causing the crash.

If you don't mind me asking, what kind of project are you working on?  If you'd rather not post this info on the forums, feel free to email me directly at support (at) wolfssl (dot) com.

Thanks,
Chris

Hi Ram,

It looks like you are on the right track.

Yes, defining WOLFSSl_USER_IO lets you specify your own I/O callbacks to use with WOLFSSL.

By default WOLFSSL uses /dev/urandom and /dev/random as a random seed.  We recently added support to wolfSSL for the STM32F2 hardware random number generator, which can be enabled by defining STM32F2_RNG.  You can see the implementation in <wolfssl_root>/wolfcrypt/random.c.  I'm not sure if the STM32F1 offers this as well, but it may be similar if so.  Defining NO_DEV_RANDOM will allow you to write your own GenerateSeed() function for wolfSSL to use.

Correct.

These are necessary if you don't have a filesystem or writev semantics available, respectively.

This define builds wolfSSL to use LwIP with the BSD socket API.  In order for this to work, you must have your LwIP stack configured to use the BSD API.  If you go this route, you won't need to define WOLFSSL_USER_IO, as we have already integrated LwIP's BSD API support into wolfSSL internally.

Regarding additional items, I will send you a PM with the wolfSSL Porting Guide.  This guide will outline the areas in wolfSSL which users commonly need to change or adjust when porting wolfSSL to a new platform.  If you don't see the PM come in, please let me know.

Best Regards,
Chris

Hi Moisés,

Thanks for catching those.  I've made the fixes in our manual.

Best Regards,
Chris

Hi Saf,

I'm guessing you are referring to the wolfSSL Java Provider (cyassl-provider-0.1.zip)?  The current provider package was built with a version of wolfSSL prior to wolfSSL 2.0.0rc3, which is why I believe you are seeing the issues above.  Starting with wolfSSL 2.0.0rc3, we changed the wolfSSL API from "InitCyaSSL()" to "CyaSSL_Init()".  This explains the "InitCyaSSL was not declared in this scope" error.

I'm guessing that the autoconf/automake errors you are seeing are being caused by the version differences as well.  Just out of curiosity, what kind of project are you working on?

If you email us at support (at) wolfssl (dot) com, I'll send you a copy of the older wolfSSL version (2.0.0rc2) to try if you would like - just to make sure things are building correctly.  We've made LOTS of enhancements to wolfSSL since 2.0.0rc2.  You can see the changelog here:

http://www.yassl.com/yaSSL/Docs-cyassl-changelog.html

Best Regards,
Chris

Hi,

Thanks for the feedback on our SSL Tutorial.  We're always excited to see people using it to learn about wolfSSL embedded SSL, or integrating SSL into an application.  We also value feedback to make the tutorial easier to understand for future readers.

Which version of wolfSSL were you using?  Were you using 2.5.0 from our website, or our version from GitHub?  If you're using our version from GitHub, you'll need to do:

./autogen.sh

before continuing with:

./configure
make
...

If you were using 2.5.0, which OS are you using to build wolfSSL?

Good feedback, we'll make this change.

The tutorial left off the "-L/usr/local/lib" because "/usr/local/lib" is usually already in the library search path.  It must not be in your library search path by default.  I guess it would be good to add a comment about this in the tutorial.  I'll make sure one gets added.

The tutorial is currently only targeted at a Unix-like environment (as it is based off the example provided in the "Unix Network Programming" book).  Adding Windows support is something that I will add to our list of TODO's for the tutorial when we get time.

Thanks,
Chris C.