Hi Kannan,

Do you need to install wolfSSL as an SSL provider at the OS-level in Android, or can you use it at the application level?  Most of our current development regarding using wolfSSL with Android is now being done on our "wolfSSL JNI" product/wrapper.  This allows your application to use wolfSSL from Java.  You can find the wolfSSL JNI manual here:

https://www.wolfssl.com/documentation/w … Manual.pdf

And download it from our website here:

https://wolfssl.com/wolfSSL/Products-wolfssljni.html

Best Regards,
Chris

Glad things are working now  smile

203

(5 replies, posted in wolfSSL)

Thanks for the extra info.

I ran a SSL Server Test on your server:
https://www.ssllabs.com/ssltest/analyze … amp;latest

That server only supports cipher suites with either static RSA or ECDHE.  We recently disabled static key cipher suites unless explicitly enabled.  ECC is disabled by default unless you are compiling wolfSSL on x86_64.  Removing these two things meant that wolfSSL and bitmarket.pl had no common cipher suites.

To resolve this either:

1.  Enable ECC (./configure --enable-ecc)
2.  Enable static key RSA suites (./configure C_EXTRA_FLAGS="-DWOLFSSL_STATIC_RSA"

#1 is preferred, as it will give you ECDHE-RSA suites that provide perfect forward secrecy.

Best Regards,
Chris

Hi csg,

In your debug log, it seems odd that SSL_shutdown() is being called right after SSL_new().  SSL_new() creates a new SSL session, which is then usually followed by SSL_connect() or SSL_read/SSL_write().

My guess is that since the application just created a new SSL session, but hasn't yet established that connection with a peer, SSL_shutdown() is failing to send it's CloseNotify Alert, giving you a Embed Send error.

Best Regards,
Chris

205

(5 replies, posted in wolfSSL)

Hi,

Are you using the same version of wolfSSL on both Pi and OSX?  wolfSSL "3.6-2.8" doesn't sound like one of our versions.

What options were used to compile wolfSSL on the Pi?

Thanks,
Chris

206

(1 replies, posted in wolfSSL)

Hi Ajay,

We don't currently have DTLS support in the Python SWIG wrapper we currently have.  You can find the existing SWIG Python wrapper under the <wolfssl_root>/swig directory.

Best Regards,
Chris

207

(4 replies, posted in wolfCrypt)

Do you need to export the key pair to an OpenSSL specific format, or can you export it to a normal DER or X9.63?  We have the latter functionality in <wolfssl/wolfcrypt/ecc.h>

int wc_ecc_export_x963(ecc_key*, byte* out, word32* outLen);
int wc_ecc_export_x963_ex(ecc_key*, byte* out, word32* outLen, int compressed);
int wc_ecc_export_private_only(ecc_key* key, byte* out, word32* outLen);
int wc_ecc_export_point_der(const int curve_idx, ecc_point* point, byte* out, word32* outLen);

Best Regards,
Chris

208

(4 replies, posted in wolfCrypt)

Hi DL,

wolfSSL doesn't currently have a conversion function for an ecc_point to OpenSSL BIGNUM or octet string formats.

Can you tell me more about the project?  Are you trying to do ECC key pair generation with wolfSSL in your firmware library?

Thanks,
Chris

209

(4 replies, posted in wolfSSL)

Hi cfarrin,

wolfSSL does currently have a function similar to that in <wolfssl/ssl.h>:

WOLFSSL_EVP_PKEY* wolfSSL_X509_get_pubkey(WOLFSSL_X509* x509);

This will return a WOLFSSL_EVP_PKEY structure pointer (ex: mykey), from which you could get the DER formatted public key from mykey->pkey.ptr of size mykey->pkey_sz.

Best Regards,
Chris

Hi Simon,

wolfSSL has several large users of DTLS which drive us to maintain and progress our DTLS implementation.

Using wolfSSL 3.6.6, if you want support for static key PSK cipher suites, you'll need to define WOLFSSL_STATIC_PSK while compiling wolfSSL.  We added a note to the README to explain this:

Note 1)
wolfSSL as of 3.6.6 no longer enables SSLv3 by default.  wolfSSL also no
longer supports static key cipher suites with PSK, RSA, or ECDH.  This means
if you plan to use TLS cipher suites you must enable DH (DH is on  by default),
or enable ECC (ECC is on by default on 64bit systems), or you must enable static
key cipher suites with
    WOLFSSL_STATIC_DH
    WOLFSSL_STATIC_RSA
    or
    WOLFSSL_STATIC_PSK

though static key cipher suites are deprecated and will be removed from future
versions of TLS.  They also lower your security by removing PFS.

When compiling ssl.c wolfSSL will now issue a comipler error if no cipher suites
are available.  You can remove this error by defining WOLFSSL_ALLOW_NO_SUITES
in the event that you desire that, i.e., you're not using TLS cipher suites.

Best Regards,
Chris

Hi,

It sounds like XCode is detecting the sizeof(long long) as 0, which seems incorrect.

If you write a simple app that prints out the sizeof(long long), do you get 0 as well?

Best Regards,
Chris

Your comment about the version made me go back and test using an older version of CyaSSL (3.2.0).  At first using our example client to connect to your server failed with the older version.  In order to get it to work, I needed to:

1.  Define FP_MAX_BITS to 8192 (since two of the certs in the chain use 4096-bit keys)
2.  Compile CyaSSL/wolfSSL with SHA-512 enabled (--enable-sha512).  This enables SHA-384 as well.  One of the chain certificates uses SHA-384 w/ RSA as a Signature Algorithm.

Can you try #2 above and see if it fixes your issue?

Thanks,
Chris

213

(0 replies, posted in Announcements)

Version 3.6.8 of the wolfSSL embedded SSL/TLS library has been released and is now available for download.  Release 3.6.8 of wolfSSL fixes two high severity vulnerabilities.  It also includes bug fixes and new features including:

-Two High level security fixes, all users SHOULD update.

a) If using wolfSSL for DTLS on the server side of a publicly accessible machine you MUST update.
b) If using wolfSSL for TLS on the server side with private RSA keys allowing ephemeral key exchange without low memory optimizations you MUST update and regenerate the private RSA keys.

Please see our recent vulnerability blog post for more details:
https://wolfssl.com/wolfSSL/Blog/Entrie … _DTLS.html

-No filesystem build fixes for various configurations
-Certificate generation now supports several extensions including KeyUsage, SKID, AKID, and Certificate Policies
-CRLs can be loaded from buffers as well as files now
-SHA-512 Certificate Signing generation
-Fixes for sniffer reassembly processing

For more information about using and compiling wolfSSL, please visit the wolfSSL Documentation page or wolfSSL Manual.  If you have questions about the wolfSSL embedded SSL/TLS library, or about using it in your project, please Contact Us.

Download wolfSSL 3.6.8:  https://www.wolfssl.com/

214

(4 replies, posted in wolfSSL)

Hi cfarrin,

When calling wolfSSL_CTX_set_verify(), the optional third parameter allows an application to register a verify callback.  By default, this callback only gets called upon verification failure.  It can be switched to be called every time by defining WOLFSSL_ALWAYS_VERIFY_CB when compiling wolfSSL, ie:

cd wolfssl-3.6.6
./configure <options> C_EXTRA_FLAGS="-DWOLFSSL_ALWAYS_VERIFY_CB"
make

Inside this callback, your application can inspect the peer certificate.  You can look in <wolfssl_root>/wolfssl/test.h, myVerify() for an example.

Best Regards,
Chris

Hi,

It's interesting that you aren't able to connect to https://www.jctixx.de, using the attached certificate above.

On my development machine (OSX), I was able to compile cURL and wolfSSL and connect to the server above using the addtrustexternalcaroot.crt certificate.  I was using:

wolfSSL (current GitHub HEAD: https://github.com/wolfssl/wolfssl)
cURL (curl 7.39.0)

curl --cacert ~/Downloads/addtrustexternalcaroot.crt https://www.jctixx.de

I noticed that several certificates in that server's cert chain used 4096-bit RSA keys.  Do you know what settings have been used to compile wolfSSL/CyaSSL?  If wolfSSL has been compiled to use the fastmath library (USE_FAST_MATH), FP_MAX_BITS in ./wolfssl/wolfcrypt/tfm.h will need to be set to 8192 to accommodate 4096-bit RSA keys.  You can either change this in tfm.h, or add it to the preprocessor flags when compiling wolfSSL.

Thanks,
Chris

Hi Risto,

We don't currently have an option/flag similar to that.  Can you tell me what's driving your question?

Thanks,
Chris

Hi,

I was able to connect to https://ww.jctixx.de using the wolfSSL example client, using the attached CA certificate.

$ cd wolfssl-3.6.6
$ ./configure
$ make
$ ./examples/client/client -h www.jctixx.de -p 443 -A addtrustexternalcaroot.crt -g

Is this the same CA root that you are using when connecting to that site?

Best Regards,
Chris

Hi sungyun,

To compile wolfSSL with support for wolfSSL_connect_ex() and wolfSSL_accept_ex(), you'll need to add WOLFSSL_CALLBACKS to your list of preprocessor defines.  If using the ./configure system, you need to add it to C_EXTRA_FLAGS like so:

cd wolfssl-3.6.6
./configure C_EXTRA_FLAGS="-DWOLFSSL_CALLBACKS"
make

Best Regards,
Chris

219

(0 replies, posted in Announcements)

wolfSSL 3.6.6 Now Available!

Version 3.6.6 of the wolfSSL embedded SSL/TLS library [1] has been released and is now available for download.  Release 3.6.6 of wolfSSL has bug fixes and new features including:

- OpenSSH, stunnel, and lighttpd Compatibility

    OpenSSH [2] compatibility with “--enable-openssh”
    stunnel [3] compatibility with “--enable-stunnel”
    lighttpd [4] web server compatibility with “--enable-lighttpd”

-SSL 3.0 is now disabled by default

We have previously announced our plans to deprecate and remove support for SSL 3.0 in the wolfSSL library [9], encouraged to do so by the POODLE attack.  With this release, we have disabled SSL 3.0 support by default.  Users who still want to use SSL 3.0 can enable it by using the “--enable-sslv3” ./configure option.

-Ephemeral key cipher suites only are now supported by default

    To enable static ECDH cipher suites define WOLFSSL_STATIC_DH
    To enable static  RSA cipher suites define WOLFSSL_STATIC_RSA
    To enable static  PSK cipher suites define WOLFSSL_STATIC_PSK

-Added QSH (Quantum-Safe Handshake) Extension

wolfSSL, in partnership with Security Innovation, has added support for the proposed "Quantum-safe hybrid" ciphersuite [5]. Having this cipher suite supported in the wolfSSL embedded TLS library allows two parties to use any existing ciphersuite and "quantum-safe" any traffic protected by that ciphersuite. This means that an attacker who records the traffic and later develops a quantum computer cannot go back and crack the session.

    Support for QSH extension can be enabled by using the “--enable-ntru” ./configure option.

-SRP is now part of wolfCrypt

SRP is a password authentication and key-exchange protocol suitable for authenticating users and exchanging keys over an untrusted network designed by Thomas Wu at the Computer Science Department of Stanford University.

    Support for SRP in wolfCrypt can be enabled with the “--enable-srp” ./configure option.

-Certificate handshake message fragmentation support

Certificate handshake messages can now be sent fragmented if the record size is smaller than the total message size, no user action required.

-DTLS duplicate message fixes

-Visual Studio project files now support DLL and static builds for 32/64bit

For information on compiling wolfSSL with Visual Studio, reference Chapter 2 of the wolfSSL Manual, or the “Using wolfSSL with Visual Studio” webpage [6].

-Support for new Freesacle I/O

Freescale KSDK [7] and Kinetis Design Studio users can now compile wolfSSL for the new KSDK version of MQX by defining FREESCALE_KSDK_MQX in settings.h or by adding it to the list of preprocessor defines.

- FreeRTOS FIPS support

    This release includes FIPS support for FreeRTOS platforms.

This release contains no high level security fixes that requires an update though we always recommend updating to the latest version of wolfSSL.

For more information about using and compiling wolfSSL, please visit the wolfSSL Documentation page [8] or wolfSSL Manual.  If you have questions about the wolfSSL embedded SSL/TLS library, or about using it in your project, please Contact Us.

Download wolfSSL 3.6.6:  https://www.wolfssl.com/

References:

[1] wolfSSL SSL/TLS Library: https://wolfssl.com/wolfSSL/Products-wolfssl.html
[2] OpenSSH: http://www.openssh.com/
[3] stunnel: https://www.stunnel.org/index.html
[4] lighttpd: http://www.lighttpd.net/
[5] QSH Ciphersuite Blog Post: https://wolfssl.com/wolfSSL/Blog/Entrie … lfSSL.html
[6] Compiling wolfSSL with Visual Studio: http://wolfssl.com/wolfSSL/Docs-wolfssl … tudio.html
[7] Freescale KSDK: http://www.freescale.com/webapp/sps/sit … INETIS-SDK
[8] wolfSSL Documentation: https://wolfssl.com/wolfSSL/Docs.html
[9] Deprecating SSL 3.0 from wolfSSL: http://wolfssl.com/wolfSSL/Blog/Entries … lfSSL.html

The Cryptographic Module Validation Program (CMVP) has issued FIPS 140-2 Certificate #2425 for the wolfCrypt Module developed by wolfSSL Inc. The CMVP was established by the National Institute of Standards and Technology (NIST) to validate FIPS 140-2 cryptographic modules and oversee the independent laboratories performing the cryptographic module testing.

FIPS 140-2 requires the use of validated cryptography in the security systems implemented by federal agencies to protect sensitive information.

The wolfCrypt Module is a comprehensive suite of FIPS Approved algorithms. All key sizes and modes have been implemented to allow flexibility and efficiency. The wolfCrypt Module was initially tested on Linux, iOS, and Android platforms. FreeRTOS and Windows platforms (including Windows Kernel) will soon be included on the FIPS 140-2 certificate.

"The wolfCrypt Module successfully completed the rigorous FIPS 140-2 Level 1 validation process. This process includes verification of proper documentation, configuration management review, algorithm testing, source code review, operational testing, and coordination with the CMVP,” said Marc Ireland, FIPS Program Manager at InfoGard Laboratories.

“wolfSSL customers are using our software FIPS cryptographic module in small embedded devices, network appliances, and large server systems,” said Larry Stefonic, Founder and CEO of wolfSSL Inc. “We are committed to adding new platforms and performing custom FIPS validations to offload the certification testing burden from our customers.”

Important differentiators in the wolfCrypt Module include the implementation of a Default Entry Point and DRBG Health Testing.

wolfCrypt implements a Default Entry Point to meet FIPS 140-2 Implementation Guidance 9.10. Many other software FIPS modules require the calling application to initiate the power-on self-tests. Those previously validated modules do not meet current guidance from the CMVP and unnecessary risk is being forced on the users of those modules.

In May 2015, the CMVP provided strict guidance to all of the Testing Laboratories that Health Testing is required for FIPS Approved DRBGs. During the wolfCrypt FIPS validation process, InfoGard Laboratories verified through source code review and operational testing that the DRBG Health Testing (described in SP800-90A Section 11.3) was implemented to the requirements.

Please contact wolfSSL Inc. (fips@wolfssl.com) to accelerate your FIPS 140-2 project.

Resources:

wolfSSL - https://www.wolfssl.com
CMVP - http://csrc.nist.gov/groups/STM/cmvp/
wolfCrypt FIPS Certificate #2425 - http://csrc.nist.gov/groups/STM/cmvp/do … l.htm#2425
FIPS 140-2 Implementation Guidance - http://csrc.nist.gov/groups/STM/cmvp/do … 1402IG.pdf
SP 800-90A - http://nvlpubs.nist.gov/nistpubs/Specia … -90Ar1.pdf

221

(2 replies, posted in wolfSSL)

Hi Adam,

When getting wolfSSL up and running on a new platform, we recommend running the wolfCrypt test app (or at least the subset of it that is applicable to what you are interested in using). This app is located at <wolfssl_root>/wolfcrypt/test/test.c.  You can define NO_MAIN_DRIVER when compiling test.c into your code, which allows you to call the individual test functions (ex: rsa_test()) from your own main/driver function.

Have you tried this yet?  It may help flush out if the underlying crypto is working correctly.

Thanks,
Chris

Hi sissiok,

Are you including <wolfssl/options.h> in your application, as the first wolfSSL header include?  This makes sure that wolfSSL and your application were compiled with the same preprocessor flags.

I just tested the 2048-bit MODP Group from RFC 3526, and it seemed to work.  I have attached my test app here for reference.  Can you compare this to how you were doing it?

Thanks,
Chris

Hi sissiok,

Yes, we have a CertManager API which allows you to verify a certificate in a standalone manner, separate from an SSL/TLS session.  You can find the API docs for these functions here:

http://wolfssl.com/wolfSSL/Docs-wolfssl … nager.html

Best Regards,
Chris

Hi sissiok,

Are you also:

1) Including <wolfssl/wolfcrypt/asn.h> in your application?

2) Naming the function correctly?  Your error reads 'InitDecode', but the function name is 'InitDecodedCert()'

3)  Are you also compiling wolfSSL with the WOLFSSL_TEST_CERT define added to C_EXTRA_FLAGS during ./configure?

Thanks,
Chris

225

(3 replies, posted in wolfCrypt)

Hi Jeff,

Where are you getting publicKeyDer from that is being used with RsaPublicKeyDecode?

Thanks,
Chris