Elyhance,

Just before the return of 5359 you can print out the value of ret to see what the return code from the library was. Could you make this modification to that code:

     ret = wc_SignatureVerify(WC_HASH_TYPE_SHA256, WC_SIGNATURE_TYPE_RSA, in,     
                              inLen, out, (word32)modLen, key, keyLen);     

/* new code */ printf("ret = %d\n", ret);
     
     if (ret != 0)                                                                
         return -5358;  

Also you noted that you ported the RSA test, did you also port the SHA256 test to ensure SHA256 is working properly? Also the random_test should be ported as well to ensure that good entropy is being used on that device.

Let me know the results of printing the ret before the failure point and the results of running the sha256 and random tests too.

Warm Regards,

Kaleb

Hi Elyhance,

If that is indeed the size of the RSA key it would be an issue as our library will by default only allow a minimum of 1024-bit RSA key for security reasons. To work with an RSA key of 799 bits please set this define:

WOLFSSL_MIN_RSA_BITS 792

I indicated 792 because the MIN length must be evenly divisible by 8 and less than 799.

Out of curiosity could you tell us what it is you are working on that uses such a small RSA key? Even 1024-bit keys are suspect anymore as powerful as computers have become. Can you tell us the source of the 800-bit RSA key and why such a small key is being tested with?

Warm Regards,

Kaleb

Hi Elyhance,

How large is the RSA key from the peer? If the key is 4096-bit could you try adding the setting

#define FP_MAX_BITS 8192 /* Needs to be set to 2x the largest RSA key size */

Regards,

Kaleb

Hi jpa,

The -236 error code indicates a Random Number Generator is missing.

It looks like you freed the RNG before calling wc_RsaPrivateDecrypt_ex.

Warm Regards,

Kaleb

Frank42,

Glad to hear I helped clear it up, let me know if you have any further questions or encounter any other issues.

Cheers,

Kaleb

Hi Frank,

Resolved.

If you connect to that IP in a browser it essentially tells you what's wrong with connecting that way (though it might not be obvious)

This means it wants to see the server name indication extension to connect you with the correct host.

Please try configuring wolfSSL like so:

kalebhimes$ ./configure --enable-tls13-draft23 --enable-sni && make 

Then use the -S flag to send the server name indication extension when connecting to 104.28.30.12

kalebhimes$ ./examples/client/client -h 104.28.30.12 -p 443 -d -v 4 -l TLS13-AES128-GCM-SHA256 -S cloudflare.com
SSL version is TLSv1.3
SSL cipher suite is TLS_AES_128_GCM_SHA256
SSL curve name is SECP256R1
HTTP/1.1 400 Bad Request
Server: cloudflare
Date: Fri, 27 Apr 2018 22:46:33 G

Warm Regards,

- K

Hi Frank42,

I can confirm that our site no longer supports TLS 1.3.

A few months back we were using cloud flare to host our site as they were supposed to speed up our page load times. Could flare had support for TLSv1.3. We have since stopped using cloud flare and our site is now back to being hosted by go daddy. Godaddy does not support TLS v1.3 so we can no longer test against it.

Since TLS v1.3 is not yet finalized there are a few different configure options in wolfSSL at the moment:

  --enable-tls13-draft18  TLS v1.3 Draft 18
  --enable-tls13-draft22  TLS v1.3 Draft 22
  --enable-tls13-draft23  TLS v1.3 Draft 23
  --enable-tls13              TLS v1.3 Draft 28

If doing inter-op testing you'll need to check which draft is supported by the site you're testing against and configure wolfSSL accordingly!

Warm Regards,

- K

Update:

Being handled via Zendesk at:

"support <at> wolfssl <dot> zendesk <dot> com"

Hi bendanon,

I sincerely apologize for the delay in getting back to you on this as I had some other tasks come up.

Could you try adding this setting to the C Pre-processor flags in the sgx_t_static.mk

Wolfssl_C_Extra_Flags += -DFP_MAX_BITS=8192 

The cert is using a 3072-bit RSA key which is too large for the default FP_MAX_BITS=4096 in SGX. The FP_MAX_BITS buffer must be at least twice the length of the largest RSA key so for 3072 you could get away with setting it to 6144 but just in case you end up with a 4096-bit RSA key in the future it's best to just set to 8192.

Cheers,

Kaleb

Hi Frank,

The biggest thing that sticks out is the time. Over the course of the connection it looks like from packet 1 to packet 25 of the wireshark you sent a total of 19.85 seconds has expired. Nothing in the wireshark sticks out as an obvious issue in fact everything is progressing normally and then at 20.08 seconds we see 4 reset messages come from the server destined for the client, I honestly think you are just hitting a timeout for the server.

I tested this theory by placing a "sleep(4);" in the default IO Send callback and using our example client to test:

./examples/client/client -M smtp -h 64.233.168.108 -p 587 -d

Sure enough I was able to produce a wireshark very similar to yours just without the spurious re-transmissions. The peer hung up on me after only 12 seconds.

I tried again with sleep(3); and got similar results but the peer kept talking up to 15 seconds. It seems like there may be a threshold between messages that if exceeded too many times the peer aborts the connection.

Options to alleviate this would be to use a faster cipher suite. Have you run the <wolfssl-root>/wolfcrypt/benchmark/benchmark.c application on your device to see which algorithms perform the best on your device? Typically an ECDHE_ECDSA cipher suite will outperform any RSA cipher suites if that is an option for you.

Could you try running the benchmark app and running one of the faster cipher suites to see if you can up your success rate above 2%?

Warm Regards,

Kaleb

Hi eharman,

So sorry you encountered some issues with Arduino, we tried to provide a script for re-arranging our library to make this easier for users and a README to alert them to the need to uncomment the ARDUINO define in <wolfssl-root>/IDE/ARDUINO.
Helpful links for other users that experience your same issues are:

https://github.com/wolfSSL/wolfssl/tree … DE/ARDUINO
https://github.com/wolfSSL/wolfssl/blob … arduino.sh
https://github.com/wolfSSL/wolfssl/blob … /README.md

Regards,

Kaleb