326

(1 replies, posted in wolfSSL)

Hi zhbn,

Have you enabled wolfSSL embedded SSL debug logging?  You can do so by either using the --enable-debug option passed to ./configure, or by defining the DEBUG_WOLFSSL preprocessor define when compiling wolfSSL.  Then, in your application code you can call wolfSSL_Debugging_ON() and wolfSSL_Debugging_OFF() to control wolfSSL debug message logging.

You could also check the return value of either wolfSSL_connect() or wolfSSL_accept(), then in the case of failure (SSL_FAILURE), check the specific error code with wolfSSL_get_error().

Best Regards,
Chris

Hi windsp,

wolfSSL embedded SSL currently provides two functions for loading public/private ECC keys into the ecc_key structure:

int ecc_import_x963(const byte* in, word32 inLen, ecc_key* key);
int ecc_import_private_key(const byte* priv, word32 privSz, const byte* pub, word32 pubSz, ecc_key* key);

The first function imports a public ECC key in X9.63 format into the specified ecc_key structure.
The second function imports both the public key in X9.63 format and the private key in RAW format into the specified ecc_key structure.

Best Regards,
Chris

328

(5 replies, posted in wolfSSL)

Also, one quick note.  At the moment, we don't recommend defining STM32_HASH when using wolfSSL for SSL/TLS.  Because of restrictions of the Standard Peripheral library and how its hash API is designed, the wolfSSL STM32 hardware hash integration will only correctly work on a single context at a time.  An SSL connection uses several hash contexts simultaneously.

Best Regards,
Chris

329

(5 replies, posted in wolfSSL)

Hi pcu,

Yes, using session resumption will improve the performance of consecutive connections from the same client.

Have you run the CTaoCrypt benchmarks in your environment?  Looking at CyaSSL performance, this is usually one of the best metrics to compare.  You can find the CTaoCrypt benchmarks in the <cyassl_root>/ctaocrypt/benchmark/benchmark.c file.

With the benchmark.c file, if you will be using your own main() or driver function, you can define NO_MAIN_DRIVER.  You can also define BENCH_EMBEDDED to reduce the benchmark data sizes, making it more reasonable to use on an embedded device.

For the public key benchmarks, if you don't have a file system available, you can define either USE_CERT_BUFFERS_1024 or USE_CERT_BUFFERS_2048 which will use the certificate buffers located in the <cyassl/certs_test.h> header instead of files.

Best Regards,
Chris

Hi Dario,

I tried loading both PEM and DER formats of the root certificate you attached and didn't see any problems.

I have attached the simple test app I was using.  It contains the Thawte root cert in DER format and uses CyaSSL_CTX_load_verify_buffer(), like you mentioned above.  Can you compare the attached to what you are doing on your side?

Thanks,
Chris

Hi cache,

Can you clarify if you are using the client or server, and what endpoint you are trying to connect to?  Also, I'm guessing you are referring to the examples from our SSL Tutorial?

Thanks,
Chris

332

(0 replies, posted in Announcements)

Release 2.9.4 includes important Security Fixes for issues found by Ivan Fratric of the Google Security Team and Suman Jana with security researchers at UT Austin and UC Davis.  CVE details to be posted today for issues with memory corruption, null pointer deference, out of bound read, and unknown certificate extensions.  All users should upgrade immediately.

This release also includes sniffer fixes for corrupted Jumbo Frames, ARM thumb mode assembly fixes, XCode 5.1 support, PIC32 MZ hardware support, a sample I/O pool, and FIPS mode for algorithms including AES, 3DES, SHA-1, SHA-2, HMAC, and RSA.

CyaSSL 2.9.4 can be downloaded from the wolfSSL download page:
http://yassl.com/yaSSL/download/downloadForm.php

Thanks,
Team wolfSSL

A recently-discovered bug in OpenSSL’s implementation of the TLS Heartbeat Extension makes it possible for malicious attackers to potentially recover the private keys and sensitive data that should normally be secured by SSL/TLS. The vulnerability has been recorded as CVE-2014-0160.

We want to assure our users and customers that CyaSSL and wolfSSL products are NOT affected by the Heartbleed bug in any way.  This was a bug specific to OpenSSL’s implementation of the TLS Heartbeat Extension (RFC6520: https://tools.ietf.org/html/rfc6520).  This bug existed in OpenSSL for over two years, with vulnerable versions including OpenSSL 1.0.1 - 1.0.1f (inclusive).

Interested parties can learn more about this bug in OpenSSL at the following links:

http://heartbleed.com/
https://www.openssl.org/news/secadv_20140407.txt
https://cve.mitre.org/cgi-bin/cvename.c … -2014-0160

For additional information or questions about CyaSSL, please contact us at info@wolfssl.com.

334

(1 replies, posted in wolfSSL)

Hi Belen,

Thanks for the report.  This has been fixed in the following commit to our embedded SSL library:

https://github.com/cyassl/cyassl/commit … 3f0859ef82

Thanks,
Chris

Hi Yvan,

Glad you got it figured out!  For future reference, which file did you need to comment out the "#include <time.h>" statement?

Thanks,
Chris

Hi,

From your code snippet, it looks like you may be trying to load a PEM certificate, but using the SSL_FILETYPE_ASN1 type instead of the SSL_FILETYPE_PEM type with CyaSSL_CTX_load_verify_buffer().

Your call to CyaSSL_CTX_load_verify_buffer() is using a "test_cert_pem" buffer, while above, you might have meant to use the "cert_thawte_root" buffer instead?

Best Regards,
Chris

Hi Bill,

By default, wolfSSL will use a BSD-style socket API, but as you mentioned with the use of the custom wolfSSL I/O callback mechanism, wolfSSL can be used without sockets.  We have several users using wolfSSL without sockets - instead using us over alternative transport mediums such as serial links or memory buffers.

The wolfSSL_set_fd() function isn't required when using custom I/O callbacks.  SSL related functions such as wolfSSL_connect(), wolfSSL_accept(), wolfSSL_read(), wolfSSL_write(), etc. take a WOLFSSL session object as a parameter.  wolfSSL embedded SSL handles managing the state of the handshake/connection internally.

Hopefully this helps make things a little clearer.

Best Regards,
Chris

We did add in a client-side session cache which wouldn't have been in the 2.7.0 release.  This could explain the increase in stack usage.  The client session cache is enabled by default, unless NO_CLIENT_CACHE is defined.

The client-side session cache was added to store server ID's.  This allows the SSL library to store the mapping of wolfSSL sessions to server ID's so that applications no longer need to keep their own mappings.

Best Regards,
Chris

Hi p,

Thanks for sending over the file.  I'm looking into it and will get back to you shortly.

Best Regards,
Chris

Hi,

Thanks for the report.  We'll look into this and get back to you.

Best Regards,
Chris

Hi,

wolfSSL should be able to be compiled with LPCxpresso and Code Red toolchain by following the instructions located in Section 2.4 of the wolfSSL Manual (http://yassl.com/yaSSL/Docs-cyassl-manu … yassl.html).

When building for FreeRTOS, the "FREERTOS" define will need to be uncommented in <cyassl_root>/cyassl/ctaocrypt/settings.h.

Best Regards,
Chris

Hi,

When using standard DH, pre-generated parameters can be loaded using one of the following functions from <wolfssl/ssl.h> with an SSL session (WOLFSSL) object:

int wolfSSL_SetTmpDH(WOLFSSL* ssl, const unsigned char* p, int pSz, const unsigned char* g, int gSz);
int wolfSSL_SetTmpDH_buffer(WOLFSSL* ssl, const unsigned char* b, long sz, int format);
int wolfSSL_SetTmpDH_file(WOLFSSL*, const char* f, int format);

Or with one of these, if loading into a SSL context (WOLFSSL_CTX):

int wolfSSL_CTX_SetTmpDH(WOLFSSL_CTX* ctx, const unsigned char* p, int pSz, const unsigned char* g, int gSz);
int wolfSSL_CTX_SetTmpDH_buffer(WOLFSSL_CTX* ctx, const unsigned char* b, long sz, int format);
int wolfSSL_CTX_SetTmpDH_file(WOLFSSL_CTX*, const char* f, int format);

Note that we don't support loading pre-generated ECDH parameters, as wolfSSL currently only supports P-256, and parameters are automatically generated.

Best Regards,
Chris

Hi,

Can you attach (or PM/email) the certificate file in question?

Thanks,
Chris

344

(1 replies, posted in wolfSSL)

Hi,

Thanks for brining this to our attention.  It looks like our cert and key generation code hasn't been modified to work with RSA disabled yet.

Will you need to use certificate and key generation with RSA disabled with our embedded SSL library?

Thanks,
Chris

Hi,

We now have version 2.9.0 released, which may warrant an upgrade - so you are working with the most current version.

Can you verify that your settings.h file from both version match up for the sections which are enabled?

Thanks,
Chris

Hi Eric,

Could you send me a key which demonstrates the problem?

Thanks,
Chris

347

(7 replies, posted in wolfSSL)

Hi,

Yes, the equivalent function for ECC keys to convert from ecc_key to DER-encoded buffer is:

int ecc_export_x963(ecc_key* key, byte* out, word32* outLen);

Where

key = input ecc_key
out = output buffer to hold DER-encoded representation of "key"
outLen = in/out variable specifying size of input buffer then size of DER-encoded key upon function success

Possible return values include:

MP_OKAY upon function success
ECC_BAD_ARG_E if invalid input arguments are given
BUFFER_E if buffer is not large enough

Best Regards,
Chris

Hi Eric,

Can you verify that you have loaded the correct CRL for the issuer (CA) of the certificate you are trying to verify?

Thanks,
Chris

Hi Eric,

You should be able to extract the public key from a DER-encoded X.509 certificate into an RsaKey structure using something similar to this:

int ret;
int derCertSz;
byte derCert[4096];

FILE* file;
RsaKey pubKey;
word32 idx = 0;
DecodedCert cert;

/* open and read DER-formatted cert into buffer */
file = fopen("./client-cert.der", "rb");
if (!file)
    // error reading file

derCertSz = fread(derCert, 1, sizeof(derCert), file);
fclose(file);

/* initialize DecodedCert with DER cert */
InitDecodedCert(&cert, derCert, derCertSz, 0);
ret = ParseCert(&cert, CERT_TYPE, NO_VERIFY, 0);
if (ret != 0)
    // ParseCert failed

/* extract the public key from the cert */
InitRsaKey(&pubKey, 0);
idx = 0;
ret = RsaPublicKeyDecode(cert.publicKey, &idx, &pubKey, cert.pubKeySize);
if (ret != 0)
    // RsaPublicKeyDecode failed

In order to use the InitDecodedCert() and ParseCert() functions, you'll need to add the WOLFSSL_TEST_CERT define to the wolfSSL preprocessor flags (C_EXTRA_FLAGS) when compiling the library, and then to your application ones as well.

After doing the above, you'll have an RsaKey structure containing the public key which you can then use with the RSA functions.

Hope this helps.

Best Regards,
Chris

Hi,

It looks like the Resource Use document didn't attach correctly.  I just sent it over to you in an email.

Thanks,
Chris