Welcome to the wolfSSL Forums!

2015-09-28 15:48:43

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

2015-09-28 09:46:26

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

2015-09-28 09:40:07

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

2015-09-24 15:13:08

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

2015-09-22 15:36:37

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

2015-09-21 13:57:00

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

2015-09-21 13:48:55

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

2015-09-21 13:37:06

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

2015-09-21 12:55:16

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

2015-09-18 16:04:52

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

2015-09-18 13:17:10

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/

2015-09-03 10:58:17

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

2015-09-03 10:49:37

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

2015-09-01 15:07:22

Hi Risto,

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

Thanks,
Chris

2015-08-25 14:53:56

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

2015-08-25 14:11:57

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

2015-08-24 13:22:35

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

2015-08-17 08:59:52

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

2015-08-11 09:14:49

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

2015-07-31 10:27:50

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

2015-07-22 14:12:29

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

2015-07-22 14:10:40

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

2015-07-22 14:03:15

Hi Jeff,

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

Thanks,
Chris

2015-07-21 14:04:57

As stated in the TLS 1.1 and 1.2 protocol definitions (RFC 4346, RFC 5246), “The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications.” TLS 1.2 is an improvement to the TLS 1.2 standard, but how exactly do they differ? What was changed in TLS 1.2 to warrant a new version of the protocol?

Listed below are the changes made to both version 1.1 and 1.2 of the TLS protocol. TLS 1.2 support is slowly making it’s way into existing projects. The wolfSSL embedded SSL/TLS library fully supports SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2.

A. TLS 1.1
This protocol was defined in RFC 4346 in April of 2006, and is an update to TLS 1.0. The major changes are:
- The Implicit Initialization Vector (IV) is replaced with an explicit IV to protect against Cipher block chaining (CBC) attacks.
- Handling of padded errors is changed to use the bad_record_mac alert rather than the decryption_failed alert to protect against CBC attacks.
- IANA registries are defined for protocol parameters
- Premature closes no longer cause a session to be non-resumable.

RFC 4346: http://tools.ietf.org/html/rfc4346#section-1.1

B. TLS 1.2
This protocol was defined in RFC 5246 in August of 2008. Based on TLS 1.1, TLS 1.2 contains improved flexibility. One of the primary goals of the TLS 1.2 revision was to remove the protocol’s dependency on the MD5 and SHA-1 digest algorithms. The major differences include:
- The MD5/SHA-1 combination in the pseudorandom function (PRF) was replaced with cipher-suite-specified PRFs.
- The MD5/SHA-1 combination in the digitally-signed element was replaced with a single hash. Signed elements include a field explicitly specifying the hash algorithm used.
- There was substantial cleanup to the client's and server's ability to specify which hash and signature algorithms they will accept.
- Addition of support for authenticated encryption with additional data modes.
- TLS Extensions definition and AES Cipher Suites were merged in.
- Tighter checking of EncryptedPreMasterSecret version numbers.
- Many of the requirements were tightened
- Verify_data length depends on the cipher suite
- Description of Bleichenbacher/Dlima attack defenses cleaned up.
- Alerts must be sent in many cases
- After a certificate_request, if no certificates are available, clients now MUST send an empty certificate list.
- TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement cipher suite.
- Added HMAC-SHA256 cipher suites.
- Removed IDEA and DES cipher suites. They are now deprecated.

RFC 5246: http://tools.ietf.org/html/rfc5246

C. Goals of the TLS Protocol

- Cryptographic security: TLS should be used to establish a secure connection between two parties.
- Interoperability: Independent programmers should be able to develop applications utilizing TLS that can successfully exchange cryptographic parameters without knowledge of one another's code.
- Extensibility: TLS seeks to provide a framework into which new public key and bulk encryption methods can be incorporated as necessary. This will also accomplish two sub-goals: preventing the need to create a new protocol (and risking the introduction of possible new weaknesses) and avoiding the need to implement an entire new security library.
- Relative efficiency: Cryptographic operations tend to be highly CPU intensive, particularly public key operations. For this reason, the TLS protocol has incorporated an optional session caching scheme to reduce the number of connections that need to be established from scratch. Additionally, care has been taken to reduce network activity.

Resources:
If you would like to read more about SSL or TLS, here are several resources that might be helpful:
TLS - Wikipedia (http://en.wikipedia.org/wiki/Transport_Layer_Security)
SSL versus TLS - What's the Difference? (http://luxsci.com/blog/ssl-versus-tls-w … rence.html)
Cisco - SSL: Foundation for Web Security (http://www.cisco.com/web/about/ac123/ac … 1/ssl.html)

As always, if you have any questions or would like to talk to the yaSSL team about more information, please contact info@wolfssl.com.

2015-07-21 10:46:28

Added, thanks!

http://www.wolfssl.com/wolfSSL/Community.html

Best Regards,
Chris

Welcome to the wolfSSL Forums!

Search options (Page 9 of 25)

Posts found: 201 to 225 of 617

201 Reply by chrisc 2015-09-28 15:48:43

Re: [SOLVED] RaspberryPI err = -313 (5 replies, posted in wolfSSL)

202 Reply by chrisc 2015-09-28 09:46:26

Re: error -308 with libcurl application after a few minutes delay (3 replies, posted in wolfSSL)

203 Reply by chrisc 2015-09-28 09:40:07

Re: [SOLVED] RaspberryPI err = -313 (5 replies, posted in wolfSSL)

204 Reply by chrisc 2015-09-24 15:13:08

Re: [SOLVED] Using DTLS from python (1 replies, posted in wolfSSL)

205 Reply by chrisc 2015-09-22 15:36:37

Re: [SOLVED] Point to BIGNUM conversion (4 replies, posted in wolfCrypt)

206 Reply by chrisc 2015-09-21 13:57:00

Re: [SOLVED] Point to BIGNUM conversion (4 replies, posted in wolfCrypt)

207 Reply by chrisc 2015-09-21 13:48:55

Re: Get Client Cert from TLS Handshake (4 replies, posted in wolfSSL)

208 Reply by chrisc 2015-09-21 13:37:06

Re: TLS_PSK_WITH_AES_128_CBC_SHA256 not available with DTLS ? (7 replies, posted in wolfSSL)

209 Reply by chrisc 2015-09-21 12:55:16

Re: Build error with last clang "bad math long / long long settings" (3 replies, posted in wolfSSL)

210 Reply by chrisc 2015-09-18 16:04:52

Re: [SOLVED] CA signer not available for verification (10 replies, posted in wolfSSL)

211 Topic by chrisc 2015-09-18 13:17:10

Topic: wolfSSL 3.6.8 is Now Available (0 replies, posted in Announcements)

212 Reply by chrisc 2015-09-03 10:58:17

Re: Get Client Cert from TLS Handshake (4 replies, posted in wolfSSL)

213 Reply by chrisc 2015-09-03 10:49:37

Re: [SOLVED] CA signer not available for verification (10 replies, posted in wolfSSL)

214 Reply by chrisc 2015-09-01 15:07:22

Re: Server-sent legacy intermediate certificates (2 replies, posted in wolfSSL)

215 Reply by chrisc 2015-08-25 14:53:56

Re: [SOLVED] CA signer not available for verification (10 replies, posted in wolfSSL)

216 Reply by chrisc 2015-08-25 14:11:57

Re: [SOLVED] How to build to support "CYASSL_CALLBACKS"? (1 replies, posted in wolfSSL)

217 Topic by chrisc 2015-08-24 13:22:35

Topic: wolfSSL 3.6.6 is Now Available (0 replies, posted in Announcements)

218 Topic by chrisc 2015-08-17 08:59:52

Topic: wolfCrypt Receives FIPS 140-2 Certificate #2425 (0 replies, posted in Announcements)

219 Reply by chrisc 2015-08-11 09:14:49

Re: mp_exptmod error state (2 replies, posted in wolfSSL)

220 Reply by chrisc 2015-07-31 10:27:50

Re: diffie hellman settings not compatible with RFC3526 (1 replies, posted in wolfSSL)

221 Reply by chrisc 2015-07-22 14:12:29

Re: [SOLVED] Is there any way to verify a certificate without SSL? (1 replies, posted in wolfSSL)

222 Reply by chrisc 2015-07-22 14:10:40

Re: how to extra a rsa public key from a certificate (3 replies, posted in wolfSSL)

223 Reply by chrisc 2015-07-22 14:03:15

Re: RSA Signing (3 replies, posted in wolfCrypt)

224 Topic by chrisc 2015-07-21 14:04:57

Topic: A Comparison of TLS 1.1 and TLS 1.2 (0 replies, posted in Announcements)

225 Reply by chrisc 2015-07-21 10:46:28

Re: Verifying SSL Client Certificates? (4 replies, posted in wolfSSL)

Posts found: 201 to 225 of 617