Welcome to the wolfSSL Forums!

2012-11-20 14:29:13

Hi hasa,

It looks like you may be using the wrong CA certificate for www.google.com. The cert chain for www.google.com looks like:

VeriSign Class 3 Public Primary Certification Authority
Thawte SGC CA
www.google.com

I was able to verify that the most current wolfSSL example client could connect to www.google.com using the attached CA file (downloaded directly from the VeriSign website, here: http://www.verisign.com/support/roots.html). Can you see if this certificate works for you?

Thanks,
Chris

2012-11-19 08:55:31

Hi hasa,

The reason that the client fails to connect to www.yassl.com is that we don't currently have SSL setup on our web hosting server. You'll probably get a similar error if you try to connect with HTTPS from your browser as well. For example:

https://www.yassl.com

Because we don't conduct any sort of electronic transactions or transmit personal data, we haven't had the need for it yet. This means that the wolfSSL embedded SSL client is working correctly.

Best Regards,
Chris

2012-11-16 12:35:39

Hi,

Thanks for the suggestions. As you saw, wolfSSL embedded SSL does provide a verify callback that allows the user to override verification then return GOOD if they want in that callback. Is there a reason you would prefer not to use callbacks (other than personal preference)?

Always returning GOOD after wolfSSL_connect() may not be the safest thing to do. It seems like it could make it easier for users to mis-use or mis-understand what is really happening. We'll have to give it some thought.

Do you mind me asking what kind of project you are working on?

Thanks,
Chris

2012-11-16 10:09:54

Hi hasa,

err = -226, record layer version error

This is typically due to the wolfSSL client trying to connect to the target server with a different version of SSL/TLS than what the server supports. By default, the wolfSSL client tries to connect with TLS 1.2, which not all servers support. You can tell the wolfSSL client what SSL/TLS version to connect with by using the "-v" command line option, where:

-v 0 = SSL 3.0
-v 1 = TLS 1.0
-v 2 = TLS 1.1
-v 3 = TLS 1.2

Try switching the SSL version when running the wolfSSL client and see if that clears up the error you are seeing.

Best Regards,
Chris

2012-11-16 09:28:37

Hi md,

Is there any way to have the clients automatically download CA certs or would this
be inherently non secure? (Web browsers, SSH, etc, all seem to be able to download a cert as long as you accept the MD5 fingerprint)

You may be able to do this, yes - but it would need to be done in your application code. CyaSSL doesn't currently provide a way to download CA certificates of specified HTTPS servers. You are able to pass a directory path into the wolfSSL_CTX_load_verify_locations() function, where wolfSSL embedded SSL would then load all certificates in the directory as trusted root certificates.

Which call is the equivalent to this call for memory buffers instead of file based CA cert?

The equivalent call for loading from memory buffers is wolfSSL_CTX_load_verify_buffer(), referenced here: http://yassl.com/yaSSL/Docs-cyassl-manu … rence.html

Best Regards,
Chris

2012-11-15 16:30:24

Hi,

You are seeing the -155 (ASN sig error) because the wolfSSL client doesn't have the correct CA certificates loaded to correctly verify the peer (mikestoolbox.org, google.com). By default, the wolfSSL client application loads our wolfSSL test certificates - which won't work to verify external certificates not signed by the wolfSSL test CA cert. You can do one of two things to resolve this problem:

1) Turn off peer verification when running the example client by adding the "-d" option. For example:

./examples/client/client -h mikestoolbox.org -p 443 -d

2) Load the correct CA certificate that is able to verify the server's certificate using the "-A" option. For example:

./examples/client/client -h mikestoolbox.org -p 443 -A mikesCA.pem

Usually you can download the root CA certificate which has signed a server certificate from a browser such as Firefox. I was able to download the CA certificate for mikestoolbox.org in PEM format through Firefox, which I have attached to this post.

Another thing to keep in mind when connecting to a website with the example wolfSSL client is that you can tell the client to send a simple GET request as well. You can do this by adding the "-g" option to the client. For example:

./examples/client/client -h mikestoolbox.org -p 443 -d -g

To see a full list of command line options available for the wolfSSL client example, use the "--help" command line option:

./examples/client/client --help

Best Regards,
Chris

2012-11-09 16:07:07

Hi,

Support for the MIT GSS-API library is now available for the Android platform - complete with an org.ietf.jgss (RFC 5653) compatible application programming interface, CyaSSL cryptography integration, and NDK sample application.

You may have read our previous blog entry announcing the initial phases of our effort to port the MIT Kerberos libraries and CyaSSL embedded SSL library to the Android platform (see link in Reference section, below). This post described initial availability of the Kerberos libraries to Android through the native NDK framework - enabling Android NDK developers to add Kerberos support to their NDK applications at a native C or C++ programming level. At that time, we also commented on next steps for the project and sought feedback from the community on adding a Java API to make using Kerberos on Android easier and more standardized.

Since that time, we have been hard at work enhancing the project, adding support for a new Java GSS-API wrapper, updating our example code, and adding new features to our sample NDK application.

1. Java GSS-API Wrapper

The addition of a Java wrapper around the native MIT GSS-API took part in two stages - a SWIG-generated (http://www.swig.org/) Java interface, which then in turn was used as a building block for a org.ietf.jgss Java API. The individual layers are visualized in the figure below. Both the SWIG layer and the Java GSS-API layer are able to be used in a Java application to access the underlying MIT Kerberos/GSS-API libraries. The SWIG layer is more tedious to use and less standardized than the Java GSS-API layer, but is closer to the C programming API of the native MIT GSS-API. We suggest that Java developers use the org.ietf.jgss Java interface over using the SWIG layer directly. As the org.ietf.jgss interface followed RFC 5653, Java developers should be able to refer to the standard Java documentation for the org.ietf.jgss package for usage instructions and class descriptions.

Source code for this project has been released under the open source MIT license, and is currently available for download on GitHub. Both the Java Generic Security Services API wrappers (SWIG and Java GSS-API), as well as example client and server applications and build instructions are located in the kerberos-java-gssapi package, at the following GitHub URL:

http://github.com/cconlon/kerberos-java-gssapi

2. Enhanced Example Code

Included in the Java GSS-API package, we have created several example applications to help developers understand how to use this project in their own application. There are two sets of client and server examples provided. The first one is a set of client and server applications which directly use the SWIG-generated Java interface. The second set of applications is a client and server that use the more standardized Java GSS-API interface (org.ietf.jgss).

It is recommended for Java developers to use the Java GSS-API examples, as they demonstrate programming and API usage which is more common in the Java programming language. Before running any of the included examples, the development machine must first have a krb5.conf file and KDC set up correctly to match the principal names used in the examples. For more details about building and running these example applications, please see the README included in the kerberos-java-gssapi package.

3. Sample NDK Application

As one of the main goals of this project was to bring MIT Kerberos/GSS-API support to the Android platform, we have created a sample Android NDK application to serve as an example and reference to Android developers. This sample application provides a GUI wrapper around the MIT Kerberos kinit, klist, kvno, and kdestroy applications. It also provides a sample client using the Java GSS-API interface to connect and communicate with the example server application (from Section 2, above).

This package contains cross-compiled version of the MIT Kerberos libraries, and includes instructions on how to re-compile the Kerberos libraries yourself for the Android platform. For details on how to build and run this example application in the Android emulator, please see the README file located in the NDK application package.

All sources for this sample application are located in the kerberos-android-ndk package, located at the following URL:

http://github.com/cconlon/kerberos-android-ndk

yaSSL and MIT are excited to bring Android developers MIT Kerberos and GSS-API support and look forward to seeing what kinds of applications will use this functionality. If you have any questions, comments, or feedback, we would enjoy to hear it! Please contact us directly at info@yassl.com.

References:

MIT Kerberos: http://web.mit.edu/kerberos/
CyaSSL: http://yassl.com/yaSSL/Products-cyassl.html
kerberos-java-gssapi: http://github.com/cconlon/kerberos-java-gssapi
kerberos-android-ndk: http://github.com/cconlon/kerberos-android-ndk
Initial announcement: http://yassl.com/yaSSL/Blog/Entries/201 … d_SSL.html

Thanks,
Team yaSSL

2012-11-09 15:25:26

Hi Andreas,

Since ChiBios do not has realloc I create my own realloc "XREALLOC"

Another option (if you choose) instead of writing your own realloc() implementation would be to use the fastmath library instead of the normal big integer library. By default wolfSSL/wolfCrypt uses the normal big integer math library, which uses quite a bit of dynamic memory. When building wolfSSL, you are able to enable the fastmath library, which is both faster and uses no dynamic memory (all on the stack). By using fastmath, wolfSSL won't need a realloc implementation at all - just malloc() and free().

When building wolfSSL with ./configure, you can enable the fastmath library with --enable-fastmath. If you're not using ./configure, you can define USE_FAST_MATH and build in tfm.c instead of integer.c. Since the stack memory can be large, we recommend defining TFM_TIMING_RESISTANT when using fastmath.

void *XREALLOC (void *ptr, size_t size) {
void *newptr;
// Allocate new block, returning NULL if not possible.
newptr = XMALLOC (size,0,DYNAMIC_TYPE_BIGINT);
if (newptr == NULL) return NULL;
// Don't copy/free original block if it was NULL.
if (ptr != NULL) {
// Copy the memory, free the old block and return the new block.
XMEMCPY (newptr, ptr, size);
XFREE (ptr,0,DYNAMIC_TYPE_BIGINT);
}
return newptr;
}

It looks like there's a bug in your realloc() implementation. If the size of the original pointer is smaller than the size being passed to realloc(), you will end up accessing memory that doesn't belong to you. If the old pointer is smaller and at the end of a page, trying to read into the next page will result in a segmentation fault if the next page hasn't been committed, has the wrong permissions, etc.

int GenerateSeed(OS_Seed* os, byte* output, word32 sz)
{
int i;
for (i = 0; i < sz; i++ ) {
output[ i ] = chTimeNow() % 256;
}
return 0;
}

Your GenerateSeed() function has very little randomness - for a couple of reasons. The first being that chTimeNow() could return the same value on multiple runs of the application (since chTimeNow() returns the number of milliseconds since the program started). Another problem is that, even on a slow processor (100MHz), given that there are 100,000 instructions available per millisecond it's highly likely that all 32 bytes will have the same value, turning the "random" seed from 2^256 possible values into 256 different values.

Although we don't recommend a specific way to get randomness on an embedded device, the ideal method would be to get it from a good hardware source somewhere.

The wireless embedded system that I am working on is EC32S13

Neat! That sounds interesting. When you're finished with the port, we'd be willing to try to roll your port back into wolfSSL if possible.

Best Regards,
Chris

2012-11-08 10:51:22

Hi,

There are several ways you could test if your SSL application is working correctly. A few of the options include:

1) Test your SSL client/server against the example client and server provided with the wolfSSL embedded ssl download. After compiling wolfSSL, these are located at ./examples/client/client and ./examples/server/server. To see a list of command line options available for the client and server, run either with the --help option. These are documented in Sections 3.3 and 3.4 of the wolfSSL Manual (http://yassl.com/yaSSL/Docs-cyassl-manu … arted.html).

2) If your SSL application is a client, you can try connecting to a publicly-available SSL server somewhere on the Internet. You could test against standard websites like Gmail, Paypal, etc., or use a dedicated "SSL test server". Examples of the later include sites like https://www.mikestoolbox.org/.

Best Regards,
Chris

2012-11-06 16:13:45

Hello Kinetis users!

Our team has now ported and released CyaSSL lightweight SSL for Freescale Kinetis. The newest work is for MQX/RTCS/MFS on Kinetis tower systems. Check our Github repository for the most recent source code:

https://github.com/wolfssl/wolfssl

If you are a Kinetis user, you will also be pleased to know that we support FreeRTOS, Micrium, and bare metal or operating systemless (NO_OS) configurations as well. You will find CyaSSL is optimal for connected home and Smart Grid security applications on Kinetis.

In addition to MQX/RTCS/MFS support, Kinetis onboard Random Number Generator Accelerator (RNGA) support is also available for CyaSSL. If you have a demanding performance requirement for your crypto, then let us know. We can work with you to optimize the following hardware supported algorithms: DES, 3DES, AES, MD5, SHA-1, SHA-256. We are also available to help with SHA-3.

We have bundled several example CodeWarrior projects with CyaSSL for MQX/RTCS/MFS, including a CyaSSL library project, CTaoCrypt test app, and CyaSSL example client. When building CyaSSL for MQX, define FREESCALE_MQX in cyassl/ctaocrypt/settings.h. This in turn defines FREESCALE_K70_RNGA which enables support for the Kinetis H/W RNGA.

You are welcome to contact us with any support or configuration questions at support@yassl.com.

Team yaSSL, from Montana, Idaho, Iowa, Washington, and Oregon. All American Crypto you can Trust.

2012-11-05 17:12:55

Hi,

Thanks for using wolfSSL! It looks like you are on the right track for getting wolfSSL to work with LwIP and your OS (chiBios). Other than TCP/IP stack and file system, other things you may need to modify are:

1) Threading - do you need multi-threaded support, or is single threaded ok? If single threaded is ok, you can define SINGLE_THREADED to disable the mutex layer. If you want multi threading, you'll need to add support for your OS's mutex layer.

2) Memory - does your OS support standard memory functions (malloc, realloc, free)? If not, you'll need to address this by defining your own custom XMALLOC, XFREE, and XREALLOC as some of the other OS ports in settings.h do.

3) Random seed - do you have access to /dev/random? If not, you'll need to write your own GenerateSeed function in ./ctaocrypt/src/random.c.

4) Other things to double check include endianness (wolfSSL defaults to little endian. If your platform is big endian, define BIG_ENDIAN_ORDER), and that you have sizeof long and sizeof long long defined correctly for your platform.

You can find a list of defines and general instructions for building wolfSSL in a non-standard environment in Chapter 2 of the wolfSSL manual (http://yassl.com/yaSSL/Docs-cyassl-manu … yassl.html).

Can you tell me more about your project? What kind of wireless embedded system are you working on?

Best Regards,
Chris

2012-10-10 09:44:22

Do you currently use the Yocto Project or OpenEmbedded? We would like to announce the availability of the “meta-yassl” layer for both Yocto and OpenEmbedded. This layer adds support for the lightweight CyaSSL embedded SSL library to these projects and can be easily added to your existing Yocto or OpenEmbedded setup. The layer can be found on GitHub at the following URL:

https://github.com/cconlon/meta-yassl

If you are not familiar with the Yocto Project, it is an “open source collaboration project that provides templates, tools and methods to help you create custom Linux-based systems for embedded products regardless of the hardware architecture.” You can learn more about Yocto at www.yoctoproject.org or OpenEmbedded at www.openembedded.org.

As a reminder, CyaSSL is open source and dual licensed under both the GPLv2 as well as a standard commercial license. This means you are free to prototype with, test with, or use CyaSSL free of charge under the terms of the GPLv2. If your project will need a commercial license or you would like commercial support direct from yaSSL, please contact us and we’ll be happy to give you more details.

If you have any questions about the new meta-yassl layer, the CyaSSL embedded SSL library, or how we can help you integrate SSL into your project, please contact us at info@yassl.com.

2012-10-09 09:14:51

Hi,

yaSSL and Intel have jointly published a white paper describing how Intel’s AES-NI can be used with the CyaSSL embedded SSL library. This paper provides a brief overview of the Intel AES-NI instructions and demonstrates the performance gains realized when Intel AES-NI is used in place of a more traditional software-only based AES implementation. The CyaSSL embedded SSL library developed by yaSSL, is used as a test bed in the white paper to perform the comparison as it can be built with either traditional AES or AES-NI support at compile time. As a secondary goal to demonstrating Intel AES-NI performance, this paper explains how to determine if a pre-built SSL library (static or shared) offers built-in support for the Intel Advanced Encryption Standard New Instructions.

You can download the white paper directly from the yaSSL website at the following location. If you have any questions about using CyaSSL on Intel hardware, please contact us at info (at) yassl.com.

CyaSSL AES-NI White Paper: http://yassl.com/yaSSL/cyassl-embedded- … apers.html

- Team yaSSL

2012-09-28 12:37:20

Thanks for the wireshark trace. Keep in mind that CyaSSL doesn't currently support renegotiation because we've always felt that it is an insecure feature. This will explain the failure when renegotiation is turned on in your Apache server configuration.

For the trace without renegotiation enabled, are you able to turn on CyaSSL's debugging output and see if it reveals any additional information about the connection? You can enable debugging when building CyaSSL with "./configure --enable-debug" or by defining DEBUG_CYASSL.

Thanks,
Chris

2012-09-28 12:24:56

Hi Luca,

We just pushed a commit related to memory usage with the sniffer. Can you give our most recent GitHub code a try and see if you are still seeing the same problem?

There is an api for dump the buffer status?
Or maybe an api for flush connections not correctly decoded?

We don't currently have these options available in our API, no. We'll have to work on adding early flushing of bad sessions and a way to flag missed packets as fatal.

- Chris

2012-09-27 09:52:51

Hi Luca,

Can you tell us more about your setup, including:

- Are you running in a VM? What OS and version of CyaSSL embedded SSL are you using?
- How many connections are you tracing?
- Are you noticing any missed packets or connection errors?
- How much RAM do you have available?

If you are missing packets, it may be possible that this is causing the sniffer connections to buffer lots of memory (thus the increase in memory you are seeing).

Thanks,
Chris

2012-09-26 08:47:34

Well, the thing is I want to change the default SSL provider on Android. Now, CyaSSL looks like something I could use, but on x86 (I'm simulating the behavior first), I cannot make the examples work with my server.

Are you using the example client from the CyaSSL download (./examples/clilent/client), or are you using the example SSLClient.java from our CyaSSL Java Provider bundle?

Using wireshark I can see something like this ...

Would you be able to attach your wireshark trace, or PM it to me?

Thanks,
Chris

2012-09-25 08:27:37

Hi gquere,

You mention that you want to "change the portion where the random data sent by the server is signed by the client using the client's private key." Can you elaborate on what you are trying to change?

Thanks,
Chris

2012-09-10 18:46:17

Hi Philhippus,

Can you let me know what domain you are using that is longer than 64 characters? The X.509 RFC (http://tools.ietf.org/html/rfc5280) states that the upper bound of the commonName field should be 64 characters:

-- specifications of Upper Bounds MUST be regarded as mandatory
-- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter
-- Upper Bounds
-- Upper Bounds
...
...
ub-common-name-length INTEGER ::= 64

Thanks,
Chris

2012-08-21 15:41:02

The third release of the yaSSL Embedded Web Server is now available for download! Changes in this release include bug fixes, updated CyaSSL support, iOS (Apple TV) build support, better Windows build support, CGI and SSI extension pattern matching and more.

The yaSSL Embedded Web Server is focused on being small, fast, and embeddable. Features include CGI, SSI, IP restrictions, access and error log support, and SSL among others. The CyaSSL embedded SSL library can be used to easily secure ports with SSL/TLS up to TLS 1.2, giving you a secure connection while maintaining small size and fast speed.

If you have any questions, or would like to learn more about the yaSSL Embedded Web Server and how it can help your project, please let us know.

Download yasslEWS 1.0: http://yassl.com/yaSSL/download/downloadForm.php/
yaSSLEWS 1.0 Product Page: http://www.yassl.com/yaSSL/Products-yas … erver.html

2012-08-14 15:10:05

CyaSSL 2.3.0 is Now Available

Version 2.3.0 of the CyaSSL embedded SSL/TLS library has been released and is now available for download. This release contains bug fixes and new features. Changes include the following (with details and comments for each listed below):

- AES-GCM crypto and cipher suites
- “make test” cipher suite checks
- Subject AltName processing
- Command line support for client/server examples
- Sniffer SessionTicket support
- SHA-384 cipher suites
- Verify cipher suite validity when user overrides
- CRL directory monitoring
-DTLS Cookie support, reliability coming soon

AES-GCM

The addition of AES-GCM (Galois/Counter Mode, http://en.wikipedia.org/wiki/Galois/Counter_Mode) cryptography and cipher suites brings the CyaSSL embedded SSL library one step away from being NSA Suite B compliant. The one missing element is ECC - which CyaSSL will be getting in September 2012.

CyaSSL 2.3.0 offers four different implementations of AES-GCM balancing speed versus memory consumption. If available, CyaSSL will use 64-bit or 32-bit math. For embedded applications, there is a speedy 8-bit version that uses RAM-based lookup tables (8KB per session) which is speed comparable to the 64-bit version and a slower 8-bit version that doesn't take up any additional RAM. To enable AES with GCM in CyaSSL, configure the build with the option "--enable-aesgcm". The configure option may be modified with the options "=word32", "=table", or "=small", i.e. "--enable-aesgcm=table".

“make test” Cipher Suite Checks

With the last few releases of CyaSSL, we’ve been working on enhancing CyaSSL’s default test cases which are executed when “make test” is issued from the CyaSSL root directory. With this release, we have added test cases for CyaSSL’s ciphers suites. The cipher suite checks iterate through CyaSSL’s SSL 3.0, TLS 1.0, 1.1, and 1.2 cipher suites (as defined in the /tests/test.conf file), verifying that each suite works correctly. When running “make test” you will now see output similar to the following for each cipher suite tested:

# server SSLv3 RC4-SHA
# client SSLv3 RC4-SHA
trying server command line[1]: SuiteTest -v 0 -l RC4-SHA 
trying client command line[1]: SuiteTest -v 0 -l RC4-SHA 
Client message: hello cyassl!
Server response: I hear you fa shizzle!

Subject AltName Processing

An X.509 certificate may contain a Subject Alternative Name, or “subjectAltName” extension which allows identities to be bound to the subject of the certificate. These names might be included in addition to the existing name in the Subject field of an X.509 certificate, or they may included in place of the standard Subject field of the certificate. Subject Alternative Names may take a variety of formats including an email address, DNS name, IP address, or a URI. This extension is defined in Section 4.2.1.6 of RFC 5280 (http://tools.ietf.org/html/rfc5280).

With this release, CyaSSL now processes Subject Alternative Names in certificates. CyaSSL has a new API function, CyaSSL_X509_get_next_altname() which allows retrieval of the subjectAltNames that have been processed.

Command Line Support for client/server Examples

The CyaSSL example client and server can now be run from the command line with a number of different options. These options allow users to select the Host, Port, SSL version, cipher list, certificate file, key file, CA file, toggle DTLS and pre shared keys, and more. To see the available options, run either ./examples/client/client or ./examples/server/server with the “-?” option:

./examples/client/client -?

The available options will be listed, similar to:

client 2.3.0 NOTE: All files relative to CyaSSL home dir
-?          Help, print this usage
-h <host>   Host to connect to, default 127.0.0.1
-p <num>    Port to connect on, default 11111
-v <num>    SSL version [0-3], SSLv3(0) - TLS1.2(3)), default 3
-l <str>    Cipher list
-c <file>   Certificate file,           default ./certs/client-cert.pem
-k <file>   Key file,                   default ./certs/client-key.pem
-A <file>   Certificate Authority file, default ./certs/ca-cert.pem
-b <num>    Benchmark <num> connections and print stats
-s          Use pre Shared keys
-d          Disable peer checks
-g          Send server HTTP GET
-u          Use UDP DTLS
-m          Match domain name in cert

Sniffer SessionTicket Support

CyaSSL’s Sniffer (or Inspection) functionality has been made more robust by the addition of support for TLS Session Tickets. The SessionTicket TLS extension is defined in RFC 5077 (http://tools.ietf.org/html/rfc5077). This extension enables a TLS server to resume sessions without storing per-client session information on the server side. The server encapsulates the current session state for a specific client into a ticket and forwards it to the client. That client is then able to resume a session if needed by using the previously-obtained ticket from the server.

SHA-384 Cipher Suites

With the addition of GCM support to CyaSSL, we have also added a number of SHA-384 cipher suites. New SHA-384 suites include:

TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384

Verify Cipher Suite Validity when User Overrides

CyaSSL 2.3.0 now checks to make sure that certificates and keys loaded into CyaSSL are valid for specified cipher suites chosen by the user. This added check enhances CyaSSL’s robustness and will prevent errors some users see when hand-picking cipher suites to use while not having all the correct functionality built into CyaSSL.

CRL Directory Monitoring

As you may know, we added initial support for CRL (Certificate Revocation List) with the release of CyaSSL 2.2.0 in May of this year. With this 2.3.0 release, we have added the ability to have CyaSSL actively monitor a specific CRL directory. Example usage can be seen in the CyaSSL example server (./examples/server/server.c) inside of the HAVE_CRL defines:

CyaSSL_EnableCRL(ssl, 0);
CyaSSL_LoadCRL(ssl, crlPemDir, SSL_FILETYPE_PEM, CYASSL_CRL_MONITOR |       
                                                 CYASSL_CRL_START_MON);
CyaSSL_SetCRL_Cb(ssl, CRL_CallBack);

DTLS Cookie Support

CyaSSL has had DTLS support for quite some time, but we’re currently working on making it more functional and robust. With this release, CyaSSL’s DTLS implementation now supports cookies. Cookies are used in DTLS to prevent denial of service attacks. As stated in section 4.2.1 of RFC 4347 (http://tools.ietf.org/html/rfc4347):

“Datagram security protocols are extremely susceptible to a variety of denial of service (DoS) attacks. Two attacks are of particular concern:

An attacker can consume excessive resources on the server by transmitting a series of handshake initiation requests, causing the server to allocate state and potentially to perform expensive cryptographic operations.
An attacker can use the server as an amplifier by sending connection initiation messages with a forged source of the victim. The server then sends its next message (in DTLS, a Certificate message, which can be quite large) to the victim machine, thus flooding it.

In order to counter both of these attacks, DTLS borrows the stateless cookie technique used by Photuris (http://tools.ietf.org/html/rfc4347#ref-PHOTURIS) and IKE (http://tools.ietf.org/html/rfc4347#ref-IKE). When the client sends its ClientHello message to the server, the server MAY respond with a HelloVerifyRequest message. This message contains a stateless cookie generated using the technique of Photuris. The client MUST retransmit the ClientHello with the cookie added. The server then verifies the cookie and proceeds with the handshake only if it is valid. This mechanism forces the attacker/client to be able to receive the cookie, which makes DoS attacks with spoofed IP addresses difficult. “

We’re currently working on adding reliability to our DTLS implementation. This should be rolling out in the near future, so keep an eye on our blog for more news!

To download the open source, GPLv2-licensed version of CyaSSL 2.3.0, please visit our Download Page (http://yassl.com/yaSSL/download/downloadForm.php). If you have any questions or comments or would like more information on commercial versions of CyaSSL, please contact us at info@yassl.com.

For build instructions, a full feature list, API reference, and more, please see the CyaSSL Manual (http://yassl.com/yaSSL/Docs-cyassl-manual-toc.html).

2012-08-10 08:17:56

Hi mpg,

I wanted to let you know that we're planning on releasing our ECC code into open source in September. Keep an eye on our blog and download page in the next month for news about a new release.

Best Regards,
Chris

2012-07-30 08:16:28

Hi,

You can sniff the connection using a tool such as Wireshark (http://www.wireshark.org/). Start a new capture on the correct interface and port, then after you have gathered your desired packets, you are able to decode as SSL to see the SSL messages.

Best Regards,
Chris

2012-07-20 09:23:39

It looks like the leak was fixed last week in our GitHub repo, thanks!

2012-07-19 07:53:04

Hi,

Thanks for the report and the fix - we'll look into it.

Best Regards,
Chris

Welcome to the wolfSSL Forums!

Search options (Page 21 of 25)

Posts found: 501 to 525 of 617

501 Reply by chrisc 2012-11-20 14:29:13

Re: wolfSSL embedded SSL 2.4.0 ASN sig error -155 Error (4 replies, posted in wolfSSL)

502 Reply by chrisc 2012-11-19 08:55:31

Re: VERSION_ERROR -226 record layer version error (3 replies, posted in wolfSSL)

503 Reply by chrisc 2012-11-16 12:35:39

Re: wolfSSL_connect PATCH (1 replies, posted in wolfSSL)

504 Reply by chrisc 2012-11-16 10:09:54

Re: VERSION_ERROR -226 record layer version error (3 replies, posted in wolfSSL)

505 Reply by chrisc 2012-11-16 09:28:37

Re: Dynamic Certs Validation Skipping (1 replies, posted in wolfSSL)

506 Reply by chrisc 2012-11-15 16:30:24

Re: wolfSSL embedded SSL 2.4.0 ASN sig error -155 Error (4 replies, posted in wolfSSL)

507 Topic by chrisc 2012-11-09 16:07:07

Topic: MIT Kerberos GSS-API with CyaSSL Now Available for Android (0 replies, posted in Announcements)

508 Reply by chrisc 2012-11-09 15:25:26

Re: Porting wolfSSL embedded SSL 2.4.0 in LWip TCP/IP stack (4 replies, posted in wolfSSL)

509 Reply by chrisc 2012-11-08 10:51:22

Re: How to check if my SSL is working properly (1 replies, posted in wolfSSL)

510 Topic by chrisc 2012-11-06 16:13:45

Topic: Security on Freescale Kinetis MQX with wolfSSL (0 replies, posted in Announcements)

511 Reply by chrisc 2012-11-05 17:12:55

Re: Porting wolfSSL embedded SSL 2.4.0 in LWip TCP/IP stack (4 replies, posted in wolfSSL)

512 Topic by chrisc 2012-10-10 09:44:22

Topic: New CyaSSL Layer Available for Yocto and OpenEmbedded (0 replies, posted in Announcements)

513 Topic by chrisc 2012-10-09 09:14:51

Topic: White Paper: Implementation and Performance of AES-NI in CyaSSL Embedd (0 replies, posted in Announcements)

514 Reply by chrisc 2012-09-28 12:37:20

Re: Modify CyaSSL embedded SSL random data signing (client authentication) (6 replies, posted in wolfSSL)

515 Reply by chrisc 2012-09-28 12:24:56

Re: sniffer memory leak (9 replies, posted in wolfSSL)

516 Reply by chrisc 2012-09-27 09:52:51

Re: sniffer memory leak (9 replies, posted in wolfSSL)

517 Reply by chrisc 2012-09-26 08:47:34

Re: Modify CyaSSL embedded SSL random data signing (client authentication) (6 replies, posted in wolfSSL)

518 Reply by chrisc 2012-09-25 08:27:37

Re: Modify CyaSSL embedded SSL random data signing (client authentication) (6 replies, posted in wolfSSL)

519 Reply by chrisc 2012-09-10 18:46:17

Re: How to change value of constants without breaking everything? (2 replies, posted in wolfSSL)

520 Topic by chrisc 2012-08-21 15:41:02

Topic: yaSSL Embedded Web Server 1.0 is Now Available (0 replies, posted in Announcements)

521 Topic by chrisc 2012-08-14 15:10:05

Topic: CyaSSL 2.3.0 is Now Available (0 replies, posted in Announcements)

522 Reply by chrisc 2012-08-10 08:17:56

Re: Build failure when --enable-ecc (3 replies, posted in wolfSSL)

523 Reply by chrisc 2012-07-30 08:16:28

Re: Got Alert Fatal (6 replies, posted in wolfSSL)

524 Reply by chrisc 2012-07-20 09:23:39

Re: Memory leak in wolfSSL 2.2.0 (libcurl 7.26.0) (2 replies, posted in wolfSSL)

525 Reply by chrisc 2012-07-19 07:53:04

Re: Memory leak in wolfSSL 2.2.0 (libcurl 7.26.0) (2 replies, posted in wolfSSL)

Posts found: 501 to 525 of 617