Hi nile,

Make sure that when you build the wolfssl64.sln in DLL mode you have updated the file wolfssl-root/IDE/WIN/user_settings.h with the define HAVE_ECC. Then make sure your application includes <wolfssl/wolfcrypt/settings.h> with WOLFSSL_USER_SETTINGS in the PreProcessor macros for your project.

Both library and application need to have HAVE_ECC defined.

Regards,

- K

@teja,

Have  you seen our simple non-blocking client example here: https://github.com/wolfSSL/wolfssl-exam … locking.c?

Perhaps give our example a try, (update the domain to the azure endpoint of course) and let us know if it connects OK.

Warm Regards,

K

Hi @

As I had mentioned on https://www.wolfssl.com/forums/topic148 … urn-0.html regarding memory constraints. -125 is an out of memory error:

// From wolfssl-root/wolfssl/wolfcrypt/error-crypt.h

 67     MEMORY_E           = -125,  /* out of memory error */

I realize that didn't turn out to be the initial error (which you resolved by setting up an entropy source) but the same recommendation holds for this error as well. Make sure you have setup sufficient heap/stack. Keep in mind that if you set configTOTAL_HEAP_SIZE to 30k and make your maintask stack size also 30k that task stack gets allocated from the total heap so you'll have no heap left at that point. Make sure to set the configTOTAL_HEAP_SIZE sufficiently large enough to allow for your task(s) stack(s) and also have heap remaining for other pvPortMalloc() calls.

Regards,

K

Z,

A pleasure, and great question by the way! Let us know if there is anything else we can assist with.

Can you tell us a bit about what it is you are working on that's driving this investigation? We love to hear about the new and exciting ways and products wolfSSL is being evaluated for!

Cheers,

K

Hi @zkertesz,

The short answer is parallelization of the decrypts.

The software solution does an encrypt block by block and a decrypt block by block in sequence thus you see similar performance times. There is no way around the encrypt block by block in sequence because you can't encrypt the next block until the current block is finished (this is the whole point of "block chaining").

However when decrypting you can parallelize the decrypts because all blocks are already encrypted and to decrypt a given block you just need the block that preceeded it so let's imagine this scenario:

BlockA -> BlockB -> BlockC -> BlockD ->BlockE

During encryption you have to encrypt in sequence:
BlockA before you can encrypt BlockB, BlockB before BlockC and so on. HOWEVER not with decrypt.

During Decryption you can decypt BlockE using BlockD's encrypted version while at the same time decrypting BlockD with BlockCs' encrypted version while at the same time decrypting BlockC with BlockBs' encrypted version etc. It takes more memory because you load a copy of the encrypted BlockC for decrypting blockD while also loading another copy of encrypted BlockC to decrypt BlockC (hope this all makes sense).

Anyway long story short we could achieve something similar in Software also, we just have not yet added a parallelized software solution where the AESNI and intel hardware have implemented parallelized decrypt.

Hope this helps.

- K

Ulysses,

Can you enable DEBUG_WOLFSSL and send the log now with the changes we've made since your last log that showed there was an issue with the PEM header?

- K

Hi @sebdub79,

Thank you for reaching out to wolfSSL support. Can you tell us a bit of background on this project, what the product is and does?

Can you share what is driving this work?

We have not run into this issue in our own testing but we have not been testing with CISCO either. Can you provide a simple test application that could be compiled with both of the below commands to reproduce the issue for review and testing?

gcc test.c -o run-test -lssl -lcrypto

and

gcc test.c -o run-test -lwolfssl

Warm Regards,

KH

Not sure why it works on linux and not on your device, try this format, let me know if this helps:

const unsigned char tago_cert[] = "-----BEGIN CERTIFICATE-----\
MIIEDzCCAvegAwIBAgIBADANBgkqhkiG9w0BAQUFADBoMQswCQYDVQQGEwJVUzEl\
MCMGA1UEChMcU3RhcmZpZWxkIFRlY2hub2xvZ2llcywgSW5jLjEyMDAGA1UECxMp\
U3RhcmZpZWxkIENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDQw\
NjI5MTczOTE2WhcNMzQwNjI5MTczOTE2WjBoMQswCQYDVQQGEwJVUzElMCMGA1UE\
ChMcU3RhcmZpZWxkIFRlY2hub2xvZ2llcywgSW5jLjEyMDAGA1UECxMpU3RhcmZp\
ZWxkIENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEgMA0GCSqGSIb3\
DQEBAQUAA4IBDQAwggEIAoIBAQC3Msj+6XGmBIWtDBFk385N78gDGIc/oav7PKaf\
8MOh2tTYbitTkPskpD6E8J7oX+zlJ0T1KKY/e97gKvDIr1MvnsoFAZMej2YcOadN\
+lq2cwQlZut3f+dZxkqZJRRU6ybH838Z1TBwj6+wRir/resp7defqgSHo9T5iaU0\
X9tDkYI22WY8sbi5gv2cOj4QyDvvBmVmepsZGD3/cVE8MC5fvj13c7JdBmzDI1aa\
K4UmkhynArPkPw2vCHmCuDY96pzTNbO8acr1zJ3o/WSNF4Azbl5KXZnJHoe0nRrA\
1W4TNSNe35tfPe/W93bC6j67eA0cQmdrBNj41tpvi/JEoAGrAgEDo4HFMIHCMB0G\
A1UdDgQWBBS/X7fRzt0fhvRbVazc1xDCDqmI5zCBkgYDVR0jBIGKMIGHgBS/X7fR\
zt0fhvRbVazc1xDCDqmI56FspGowaDELMAkGA1UEBhMCVVMxJTAjBgNVBAoTHFN0\
YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xMjAwBgNVBAsTKVN0YXJmaWVsZCBD\
bGFzcyAyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEAMAwGA1UdEwQFMAMBAf8w\
DQYJKoZIhvcNAQEFBQADggEBAAWdP4id0ckaVaGsafPzWdqbAYcaT1epoXkJKtv3\
L7IezMdeatiDh6GX70k1PncGQVhiv45YuApnP+yz3SFmH8lU+nLMPUxA2IGvd56D\
eruix/U0F47ZEUD0/CwqTRV/p2JdLiXTAAsgGh1o+Re49L2L7ShZ3U0WixeDyLJl\
xy16paq8U4Zt3VekyvggQQto8PT7dL5WXXp59fkdheMtlb71cZBDzI0fmgAKhynp\
VSJYACPq4xJDKVtHCN2MQWplBqjlIapBtJUhlbl90TSrE9atvNziPTnNvT51cKEY\
WQPJIrSPnNVeKtelttQKbfi3QBFGmh95DmK/D5fs4C8fF5Q=\
-----END CERTIFICATE-----";


// application code starts somewhere:

    const byte* caCert = tago_cert;
    int caSz = sizeof(tago_cert);

    if ((ret = wolfSSL_CTX_load_verify_buffer(wolfctx, caCert, caSz,
         SSL_FILETYPE_PEM)) != SSL_SUCCESS) { /* BUFFER */
        printf("loading the ca chain failed\n");
        printf("Error: (%d): %s\n", ret, wolfSSL_ERR_reason_error_string(ret));
        wolfSSL_CTX_free(wolfctx); wolfctx = NULL;
        return -1;
    }

This is happening on the call:

ret = wolfSSL_CTX_load_verify_buffer(wolfctx, tago_cert, sizeof(tago_cert), SSL_FILETYPE_PEM);

Make sure you include the PEM header in the buffer so it can parse properly when loaded.

Hi @ulysses,

Can you try this with the default wolfSSL example first? I was able to succesffully test this by running the wolfSSL example client from the wolfssl root directory with the below command. NOTE: ~/Downloads/sf-class2-root.crt is the cert I provided a link to the other day.

clean-wolfssl % ./examples/client/client -h api.tago.io -p 443 -A ~/Downloads/sf-class2-root.crt -g

RESULT:

kalebhimes@kalebs-MBP clean-wolfssl % ./examples/client/client -h api.tago.io -p 443 -A ~/Downloads/sf-class2-root.crt -g
peer's cert info:
 issuer : /C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
 subject: /CN=*.tago.io
 altname = tago.io
 altname = *.tago.io
 serial number:06:93:0c:85:14:dc:b7:9a:b1:2c:8b:cc:f6:50:43:e9 
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
SSL curve name is SECP256R1
Session timeout set to 500 seconds
Client Random : 441D4F0391C74FB9A052D190CC8A5CB5019CAEEB3FDE69515BFE71D6F0F932B5
SSL connect ok, sending GET...
HTTP/1.1 404 Not Found
Date: Thu, 09 Jan 2020 19:21:18 GMT
Content-Type: application/json
Content-Length: 43
Connection: cl
ose
Allow: OPTIONS

{"status":false,"message":"Page Not Found"}

- K

@Ulysses,

The -155 no signer error indicates you have the wrong certificate loaded in as the root CA for that server. I just decoded the PEM buffer you are loading and the beginning contents is:

  1 Certificate:
  2     Data:
  3         Version: 3 (0x2)
  4         Serial Number:
  5             06:7f:94:57:85:87:e8:ac:77:de:b2:53:32:5b:bc:99:8b:56:0d
  6         Signature Algorithm: sha256WithRSAEncryption
  7         Issuer: C = US, O = Amazon, CN = Amazon Root CA 1
  8         Validity
  9             Not Before: Oct 22 00:00:00 2015 GMT
 10             Not After : Oct 19 00:00:00 2025 GMT
 11         Subject: C = US, O = Amazon, OU = Server CA 1B, CN = Amazon

We can clearly see this is not a Root CA. This is an intermediate CA or a leaf cert because the subject and issuer lines do not match. You need the trusted root cert that signed the chain for this cert. Load the trusted root with wolfSSL_CTX_load_verify_locations and you should be all set!

Warm Regards,

K