This attack is based on the weak keys that the outdated stream cipher RC4 can sometimes generate.  Simply put, stop using RC4 in TLS connections.  In fact, wolfSSL (formerly CyaSSL) recently turned off the RC4 algorithm at build time.  This will be the default starting with the upcoming 3.4.6 release.  There has certainly been a pattern in the attacks that we’ve seen on TLS in the last few years; older Protocol versions, older modes, and older key sizes.  We suggest using TLS 1.2 with AEAD ciphers and forward secrecy.  Some people can’t get away with that in the interest of interoperability but it’s certainly the safest way forward that we can think of.  Please contact us with any questions.

Feel free to visit our website at wolfssl.com or email us at info@wolfssl.com.

252

(1 replies, posted in wolfSSL)

Hi Mahris,

I have attached the wolfSSL Secure Renegotiation User Guide.  Please note that we strongly recommend not using Secure Renegotiation unless it is a strong requirement in your project.  See note at the top of the document for more info.

Best Regards,
Chris

253

(1 replies, posted in General Inquiries)

Hi,

We generate our certificate buffers in the certs_test.h file using the gencertbuf.pl script located in the CyaSSL package root directory.

You should be able to add ECC certificates to gencertbuf.pl in DER format like we have done for the RSA-based ones.  Once the script is run, it will place them into the certs_test.h header file.

If you have problems with that, feel free to let us know and we can help out.

Thanks,
Chris

wolfSSL will be exhibiting at the upcoming 2015 Embedded World conference in Nürnberg, Germany.  The conference will be held February 24-26, 2015 at NürnbergMesse GmbH.  The wolfSSL booth will be in Hall 5, booth 5-246g. We will be talking about the CyaSSL embedded SSL library, wolfCrypt cryptography engine, and best practices for securing connected devices and applications.

Embedded World 2015
Exhibition Centre Nuremberg
Tuesday, 24 - Thursday, 26 February 2015

wolfSSL Booth: Hall 5 / 5-246g

If you are attending Embedded World, we welcome you to stop by our booth.  If you would like to set up a specific meeting time, please email us at info@wolfssl.com.

255

(0 replies, posted in Announcements)

In a matter of weeks, hundreds of Open Source developers will gather in Brussels, Belgium for FOSDEM 2015. FOSDEM is a two day event organized by volunteers to promote the widespread use of Open Source software, and is considered by many to be “the best open source conference in Europe” [1].

wolfSSL will be attending FOSDEM this year and will have a stand in the “AW” building. The wolfSSL stand will have information about several of wolfSSL’s open source projects including the CyaSSL lightweight SSL/TLS library and wolfCrypt cryptography engine. Members of the wolfSSL team will be on hand to answer developers’ questions first hand.

If you or your team is considering integrating CyaSSL or wolfCrypt with a project and would like to set up a time to sit down and talk at FOSDEM, let us know at info@wolfssl.com and we can pencil you into our schedule while in Brussels. We enjoy working with Open Source projects, and offer them free support from our technical staff when working with CyaSSL or wolfCrypt.

FOSDEM 2015
ULB Solbosch Campus
Brussels, Belgium
January 31 - February 1, 2015

wolfSSL Booth: AW-11
https://fosdem.org/2015/stands/

We look forward to seeing you there!

[1] https://fosdem.org/2015/about/

We added this to our desired feature list, but probably won't get to it until we finish our name change.  We're in the process of changing the "CyaSSL" product name to "wolfSSL".

Thanks,
Chris

wolfSSL does support handling a SSL 2.0 Client Hello, to handle the situation where the connection can be upgraded to something >= SSL 3.0 during the SSL/TLS handshake.

This "Old Hello" processing was enabled by default in versions of wolfSSL prior to 3.3.0.  Starting with 3.3.0, we disabled this functionality at compile time by default.  To re-enable this functionality, you would need to define OLD_HELLO_ALLOWED when compiling wolfSSL.

Is there any way to get the version at runtime instead of compile-time?

Not at the moment, no.  Is this a feature that you need?

Thanks,
Chris

Hi Ray,

wolfSSL embedded SSL has never supported SSL 2.0.  It was considered insecure at the time we began writing wolfSSL as a project, thus left it out.

In <wolfSSL/version.h>, you can find the version of wolfSSL installed with either the LIBWOLFSSL_VERSION_STRING or LIBWOLFSSL_VERSION_HEX define.  For example in 3.3.0, version.h includes:

#define LIBWOLFSSL_VERSION_STRING "3.3.0"
#define LIBWOLFSSL_VERSION_HEX 0x03003000

Best Regards,
Chris

259

(8 replies, posted in wolfSSL)

Hi,

Can you try opening and building the <wolfssl_root>/wolfssl.sln solution file?  This should build the wolfSSL library and all example applications as well.

Thanks,
Chris

260

(8 replies, posted in wolfSSL)

Hi,

Usually we see a socket error (-308) when the peer encountered an error of some sort. Have you tried connecting to a different server to see if the problem is consistent?  When porting to a new platform, we usually test against the wolfSSL example server (<wolfssl_root>/examples/server/server) running on a desktop machine somewhere.  This will allow you to turn on debugging on the server side (./configure --enable-debug) and see more information about why the connection is failing on the server side.

Thanks,
Chris

Hi Johan,

The maximum amount of memory allocated by a SINGLE call to XMALLOC() will be a little over 17kB (17kB + 102 bytes).

Best Regards,
Chris

Hi,

Can you clarify if you are looking for the total heap usage?  Or the heap usage for a single connection?  In either case, I think our Resource Use document will be helpful.  It should be attached to this post.

It sounds like you already found our memory abstraction layer (XMALLOC, XREALLOC, etc.).  There are a few more details on this in Section 5.1.1.1 of the CyaSSL Manual:

http://yassl.com/yaSSL/Docs-cyassl-manu … ility.html

Best Regards,
Chris

Hi dhryoo,

I'm not sure I understand your question.  Could you clarify?  The order of loading the certs and keys should be the same, no matter if the client certificate is different than our example one.

Thanks,
Chris

264

(7 replies, posted in wolfSSL)

Hi Marcus,

We have a couple of different functions in <cyassl/ctaocrypt/ecc.h> that can be used for reading in public and/or private keys:

/* import public ECC key in ANSI X9.63 format */
int ecc_import_x963(const byte* in, word32 inLen, ecc_key* key);

/* ecc private key import, public key in ANSI X9.63 format, private raw */
int ecc_import_private_key(const byte* priv, word32 privSz, const byte* pub, word32 pubSz, ecc_key* key);

/* Import raw ECC key */
int ecc_import_raw(ecc_key* key, const char* qx, const char* qy, const char* d, const char* curveName);

Best Regards,
Chris

265

(0 replies, posted in Announcements)

We're happy to announce the release of CyaSSL version 3.3.0. CyaSSL version 3.3.0 offers:

  • Secure countermeasures for Handshake message duplicates, CHANGE CIPHER without FINISHED, and fast forward attempts added to our source code.  Thanks to Karthikeyan Bhargavan from the Prosecco team at INRIA Paris-Rocquencourt for the report.  This is an important fix and all users should update!

  • Complete testing for FIPS 140-2 version submitted to NIST.  FIPS 140-2 source code now available.

  • Removes SSLv2 Client Hello processing for enhanced security, can be enabled with OLD_HELLO_ALLOWED

  • Protocol level control:  User can now control TLS protocol down-cycling to a minimum downgrade version with CyaSSL_SetMinVersion().  For example, you could reject handshakes at a protocol level less than TLS 1.1.

  • Small stack improvements at TLS/SSL layer, to benefit environments with limited available stack.

  • TLS Master Secret generation and Key Expansion are now exposed at the API level

  • Adds client side Secure Renegotiation, * not recommended, ever! *

  • Client side session ticket support.  This feature is not fully tested with Secure Renegotiation, so don’t use Secure Renegotiation.

  • Allows up to 4096-bit DHE at TLS Key Exchange layer

  • Handles non standard SessionID sizes in Hello Messages

  • PicoTCP Support added

  • TLS Sniffer now supports SNI Virtual Hosts

  • TLS Sniffer now handles non HTTPS protocols using STARTTLS

  • TLS Sniffer can now parse records with multiple messages

  • TI-RTOS updates or enhances support

  • Fix for ColdFire optimized fp_digit read only in explicit 32bit case

  • Added ADH Cipher Suite ADH-AES128-SHA for EAP-FAST

Stay up to date with what is happening with wolfSSL, you can follow our blog at http://www.wolfssl.com/yaSSL/Blog/Blog.html

If you have any questions please feel free to contact us anytime at info@wolfSSL.com or (425)245-8247.
We look forward to hearing from you!

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

Thank You!
wolfSSL

Hi Eason,

To generate a CSR with wolfSSL, you'll need to define WOLFSSL_CERT_REQ, which will make the wc_MakeCertReq() function available.  Example usage can be found in <wolfssl_root>/wolfcrypt/test/test.c in the rsa_test() function.

Best Regards,
Chris

Hi,

We originally wrote SetAltNamesBuffer() for an application where we needed to copy altNames from an existing certificate over to a new one.  It is set up to take a raw DER-encoded buffer, as you would find in an existing cert.

It would take a little exploration if that would work in your case or not.  It sounds like you are trying to generate certificates here, whereas your first question dealt with verifying them.  Is that correct?

Thanks,
Chris

268

(1 replies, posted in General Inquiries)

Hi,

"Mutual authentication" involves both sides of the SSL/TLS connection sending a certificate chain during the handshake and verifying the peer's chain.  CyaSSL does mutual authentication when:

1.  The client has loaded a client certificate, private key, and CA cert to verify the server chain, and has enabled peer verification with CyaSSL_CTX_set_verify() or SSL_CTX_set_verify().

2.  The server has loaded a server certificate, private key, and CA cert to verify the client chain.  Peer verification is turned on by default on the CyaSSL server side, unless specifically disabled by the application.

The CyaSSL example client and server do mutual authentication by default, and are a good examples to reference.  These are located in <cyassl_root>/examples/client/client.c and <cyassl_root>/examples/server/server.c.

Best Regards,
Chris

Hi,

We don't currently support this functionality, but will add it to our desired feature list.

Our current AltName processing takes place in the CheckAltNames(), located in <cyassl_root>/src/internal.c.

Do you mind if I ask what kind of project you are working on?

Best Regards,
Chris

Hi,

Can you also verify that you are cross compiling correctly, and that you are using "--host=" instead of "--target="?  You can reference section 2.6 of the CyaSSL Manual for a simple description of how to cross compile.

http://www.yassl.com/yaSSL/Docs-cyassl- … yassl.html

Thanks,
Chris

Hi,

This looks like a problem with the compiler setup, as the configure system thinks that the compiler doesn't work.  Have you checked with someone from Freescale about this, or asked on their forums?

I would recommend starting with a simple "Hello World" application, and see if you can compile that using the cross compiler in question.  After that works, you could move to trying to cross compile CyaSSL.

Best Regards,
Chris

272

(1 replies, posted in wolfCrypt)

Hi Amit,

Please see my response in your other topic:
http://www.yassl.com/forums/topic603-er … -keys.html

Thanks,
Chris

273

(3 replies, posted in wolfSSL)

Hi Amit,

Can you show how you generated your test key?  And if you could send the test key to us, that would be helpful as well.

We have successfully tested loading our own ECC key (./certs/ecc-key.der) in buffer form with CyaSSL_CTX_use_PrivateKey_buffer().  Have you tried loading our test key?

Thanks,
Chris

274

(2 replies, posted in wolfSSL)

Hi Sainath,

How are you compiling your application?  Are you linking against the wolfSSL library, ie:

gcc main.c -lcyassl

Best Regards,
Chris

Hi Amit,

I just emailed you the Resource Use document.

Best Regards,
Chris