Hi Doug,

Thanks for your comments about the SSL tutorial and for bringing the expired certificates to our attention.  I'll put it on our list to take another pass through the tutorial and give it a refresh/update and add in any extra enhancements which may make it easier to use.

If you have any additional feedback on the tutorial, specifically areas you would like to see improved upon, please let me know.  Ideally, we'd like to make it as easy for users to work through as possible.

Best Regards,
Chris

Hi mtilchen,

We have had several users who have cross compiled wolfSSL embedded SSL for ARM platforms using GCC.

Do you know what your stack and heap sizes are set at?  Oftentimes we'll see hard faults like this when one of these is not set high enough.  For reference, I have attached the wolfSSL Resource Use document which shows typical runtime memory usage of wolfSSL per session.

One thing which can also make a difference here is what math library you are using.  WolfSSL let's users choose between two different math libraries - the normal big integer (which it looks like you are using) and the fastmath library. 

By default, wolfSSL uses the normal big integer math library.  This is generally the most portable and generally easiest to get going with.  The negatives to the normal big integer library are that it is slower and it uses a lot of dynamic memory.  The fastmath library on the other hand uses less dynamic memory and moves it to the stack instead, also providing speed improvements (using assembly optimizations where possible).

You can enable fastmath by defining USE_FAST_MATH, and since the stack usage can be high, we also recommend defining TFM_TIMING_RESISTANT as well.

Best Regards,
Chris

Hi Stéphane,

Are you initializing your RsaKey structure with InitRsaKey() before your call to RsaPublicKeyDecode?

Regards,
Chris

Hi Luca,

This makes me think the problem may be unique to your shell or environment.  As the debug build will be larger in file size and use more memory, can you check your shell's available memory?

Thanks,
Chris

Hi Daniel,

I believe that your question was answered by Moises over email.  Is that correct?

Thanks,
Chris

Hi djconcept,

The -208 error is a SOCKET_ERROR_E, or "error state on socket".

We typically use the echoserver (./examples/echoserver/echoserver) to test against browsers, as it handles connections a little different. Browsers usually need to re-try the SSL handshake at least twice, as they need to ask the user to confirm connecting to an "unsecure" site (because our test certificates are self-signed).

It may be that your client (Chrome) is trying to do a second connection attempt, when your server has already shut down.  To see the difference, if you run our example server on your desktop machine (./examples/server/server), then connect through your browser:

https://127.0.0.1:11111

You'll see the inaccessible error from Chrome like you listed above.  If you then try with our echoserver example (./examples/echoserver/echoserver), you should see that it works like expected.

Best Regards,
Chris

Hi Lucas,

It sounds like you are making good progress on porting wolfSSL over to your environment.  You may have found it already, but if not, you can find the wolfSSL Porting Guide here:

http://yassl.com/yaSSL/Docs-cyassl-porting-guide.html

You can write and register your own I/O callbacks for wolfSSL to use.  These callbacks would then integrate down to your LwIP layer.  The callbacks are documented both in the Porting Guide above as well as Section 5.1.2 of the wolfSSL Manual:

http://yassl.com/yaSSL/Docs-cyassl-manu … ility.html

In general, your application will handle setting up and connecting the socket, then hand it over to wolfSSL to do the SSL/TLS handshake and SSL communication from there on out.  Our SSL Tutorial may be helpful to look through (http://yassl.com/yaSSL/Docs-cyassl-manu … orial.html), or our example client and server application located in:

./examples/client/client.c
./examples/server/server.c

Best Regards,
Chris

Hi,

Thanks for the report.  This should be fixed with this commit to our embedded SSL library:

https://github.com/cyassl/cyassl/commit … b9f930331f

Thanks,
Chris

Hi James,

Currently our crypto API for AES (including CTR, but also other modes of operation) requires that the user application pad the input to an AES block size before encryption.  So, at the moment, it's not necessarily a bug, but has been a conscious decision.

As we get more crypto-only users, we may want to consider handling the padding ourselves internally to help improve usability.  Thanks for brining this to our attention, and for the suggested fix.

Best Regards,
Chris

Hi Sivakumar,

The change you mentioned above was intentional.  Since we added support for encrypt/decrypt callbacks, padding is now handled at encrypt or decrypt time.

Are you using the same version of the sniffer as your are of wolfSSL?  If not, can you update both to the most current wolfSSL embedded SSL version?

If both are on the same version of wolfSSL, can you try using our most current version on GitHub and see if you still see the same problem?  wolfSSL on GitHub can be found here: https://github.com/cyassl/cyassl.

Do you mind if I ask what kind of project you are using the sniffer with?

Thanks,
Chris

Hi Nikhil,

This is probably close to the best, unless you have a processor which supports Intel's AES-NI, or you can do further speed optimizations through your compiler.

You can also switch to a faster cipher suite, as long as you don't need to use TLS_RSA_WITH_RC4_128_SHA.  For instance, our HC-128 stream cipher is our fastest cipher available - even faster than RC4.  You can see a relative speed graph here:  http://yassl.com/yaSSL/benchmarks-cyassl.html.

Can you clarify what expected performance you are referring to?

Thanks,
Chris