601

(5 replies, posted in wolfSSL)

Hi,

Thanks for the bug submission, we've made the fix and checked it in. Bugs can either be submitted here in our forums or by opening a GitHub issue on our wolfSSL GitHub project page (https://github.com/wolfSSL/wolfssl).

What project are you working on?

Regards,
Chris

http://www.yassl.com/images/conferences/rsa2011.jpg

We’ll be exhibiting at the RSA Conference 2011 (http://www.rsaconference.com/2011/usa/index.htm).  Our booth number is 330.  The conference will be held February 14-18 at Moscone in San Francisco.  If you’re planning to be there, please plan to stop by to discuss CyaSSL, our implementation of the TLS 1.2 protocol.  We’ll also be visiting customers in the Bay Area that week, so let us know if you’d like us to set aside some time for you by emailing us at info@yassl.com.

603

(0 replies, posted in Announcements)

http://www.yassl.com/images/conferences/fosdem2011.png

yaSSL will be attending FOSDEM in Brussels, Belgium on February 5-6, 2011.  We will be giving a lightning talk as well as taking an active part in the Security / hardware crypto, Embedded, and MySQL & friends Developer rooms.

As the fosdem.org site states, "FOSDEM is the biggest free and non-commercial event organized by and for the community. Its goal is to provide Free and Open Source developers a place to meet."  We're excited and hope you are too!  

If you are attending and would like to meet up with us, please contact larry@yassl.com to set up a meeting time. There is no registration required for FOSDEM 2011, so if you're going to be in the area, stop by and say hello!

FOSDEM 2011:  http://fosdem.org/2011/

[Migrated from SourceForge forums]


sergio95
(2010-08-20 15:05:42 UTC)

Could wolfSSL embedded SSL library be used to decrypt SSL traffic by providing it with servers private key and SSL messages (ClientHello, ChangeCipherSpec etc..)?

If so, is there an example of such implementation?

Tnx in advance!


touska
(2010-08-20 16:51:28 UTC)

Yes, wolfSSL, since CyaSSL 1.5.0 has has support for sniffing SSL traffic.

Please see the README for the sniffer notes under wolfSSL/sslSniffer/sslSnifferTest/snifftest.c


sergio95
(2010-08-21 03:52:12 UTC)

Tnx!

605

(0 replies, posted in wolfSSL)

[Migrated from SourceForge forums]


xangis
(2010-08-04 19:32:59 UTC)

I'm working on building a standalone test app based on the example code.  What I have so far is this :

int client_test(int argc, char* argv[])
{
   int ret = 0;
   cout << "argc = " << argc << endl;
   for(int i = 0; i < argc; i++)
      cout << "argv[" << i << "] = " << argv << endl;

   if( argc < 3 ) {
       cout << "Not enough arguments supplied.  Usage:  test <servername> <port>" << endl;
       return 0;
   }

#ifdef _WIN32
    WSADATA wsd;
    WSAStartup(0x0002, &wsd);
#endif

    SOCKET_T sockfd = 0;

    cout << "Calling tcp_connect()" << endl;
    int port = atoi(argv[2]);
    if( port <= 0 ) {
        return 0;
        cout << "Invalid port supplied.  Must be a positive integer." << endl;
    }
    tcp_connect(sockfd, argv[1], port);
#ifdef NON_BLOCKING
    tcp_set_nonblocking(sockfd);
#endif

    cout << "Using TLSv1_client_method." << endl;
    SSL_METHOD* method = TLSv1_client_method();
    //printf("Using SSLv3_client_method.\n");
    //SSL_METHOD* method = SSLv3_client_method();
    SSL_CTX*    ctx = SSL_CTX_new(method);
    cout << "Setting certificates." << endl;
    set_certs(ctx);
    SSL* ssl = SSL_new(ctx);
    cout << "Setting SSL socket fd to " << sockfd << endl;
    SSL_set_fd(ssl, sockfd);
#ifdef NON_BLOCKING
    cout << "Calling NonBlockingSSL_Connect." << endl;
    NonBlockingSSL_Connect(ssl, ctx, sockfd);
#else
    ret = SSL_connect(ssl);
    cout << "SSL_connect return value: " << ret << endl;
#endif

    cout << "Showing peer info.\n" << endl;
    showPeer(ssl);

    const char* cipher = 0;
    int index = 0;
    char list[1024];
    strncpy(list, "cipherlist", 11);
    while ( (cipher = SSL_get_cipher_list(ssl, index++)) ) {
        strncat(list, ":", 2);
        strncat(list, cipher, strlen(cipher) + 1);
    }
    cout << list << endl;
    cout << "Using Cipher Suite: " << SSL_get_cipher(ssl) << endl;

    cout << "Sending hello with SSL_write." << endl;
    char msg[] = "hello yassl!";
    if (SSL_write(ssl, msg, sizeof(msg)) != sizeof(msg))
        ClientError(ctx, ssl, sockfd, "SSL_write failed");

    char reply[1024];
    cout << "Reading server response." << endl;
    int input = SSL_read(ssl, reply, sizeof(reply));
    if (input > 0) {
        reply[input] = 0;
        printf("Server response: %s\n", reply);
    }

    cout << "SSL_shutdown." << endl;
    SSL_shutdown(ssl);
    cout << "SSL_free." << endl;
    SSL_free(ssl);
    cout << "tcp_close" << endl;
    tcp_close(sockfd);
    cout << "SSL_CTX_free" << endl;
    SSL_CTX_free(ctx);

    return 0;
}

Whether I run the application against another server on my network with a self-signed certificate, or against mail.google.com, which has a thawte certificate, I get the following result (1039 error from taocrypt):

argc = 3
argv[0] = test
argv[1] = 192.168.1.221
argv[2] = 5001
Calling tcp_connect()
Using hostname 192.168.1.221 port 5001
Calling connect().
Using TLSv1_client_method.
Setting certificates.
Setting SSL socket fd to 684
SSL_connect: Checking errors.
SSL_connect: CONNECT_BEGIN, sending client hello.
SSL_connect: CLIENT_HELLO_SENT, getting states.
SSL_connect: FIRST_REPLY_DONE.  Send verify.
SSL_connect: Sending client key exchange.
SSL_connect: Sending change cipher.
SSL_connect: Sending finished.
SSL_connect: Flushing buffer.
SSL_connect: FINISHED_DONE.  Getting resuming info.
SSL_connect: SECOND_REPLY_DONE.  Verifying state.
SSL_connect: Second reply done.  Calling ShowTCP.
Error: 1039, ThreadID: 3768
SSL_connect: Error, 1039 (1039) returning SSL_FATAL_ERROR.
SSL_connect return value: -1
Showing peer info.
peer's cert info:
 issuer : /C=US/ST=California/L=Mountain View/O=Authentic8/CN=Jay Sorg/emailAddress=jsorg@authentic8.com
 subject: /C=US/ST=California/L=Mountain View/O=Authentic8/CN=Jay Sorg/emailAddress=jsorg@authentic8.com
cipherlist:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:AES256-RMD:AES128-RMD:DES-CBC3-RMD:DHE-RSA-AES256-RMD:DHE-RSA-AES128-RMD:DHE-RSA-DES-CBC3-RMD:DHE-DSS-AES256-RMD:DHE-DSS-AES128-RMD:DHE-DSS-DES-CBC3-RMD:RC4-SHA:RC4-MD5:DES-CBC3-SHA:DES-CBC-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA
Using Cipher Suite: AES256-SHA
Sending hello with SSL_write.
yassl error: SSL_write failed

I see that the error 1039 corresponds to SIG_OTHER_E,  "Bad other signature confirmation", but don't see how it's generated (or how to prevent it from happening).  What should I look into or do differently?

Thank you,
Jason


touska
(2010-08-09 17:28:21 UTC)

You're getting the error 1039 because you haven't loaded the CA certificates to properly verify the server's certificate.  In the client example ca-cert.pem is loaded so that it can verify server-cert.pem.  You'll need to do the same for the sites you wish to connect to.  Please see the note at the top the README file.

[Migrated from SourceForge forums]


xangis
(2010-08-03 20:06:43 UTC)

I can build yaSSL fine on Windows using VS2008.

I created a simple project to get started with using yaSSL, but can't seem to get the build/library settings quite right.

Here are the errors I get when linking:

1>main.obj : error LNK2019: unresolved external symbol "public: __thiscall yaSSL::Client::~Client(void)" (??1Client@yaSSL@@QAE@XZ) referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol "public: int __thiscall yaSSL::Client::Read(void *,int)" (?Read@Client@yaSSL@@QAEHPAXH@Z) referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol "public: int __thiscall yaSSL::Client::Write(void const *,int)" (?Write@Client@yaSSL@@QAEHPBXH@Z) referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol "public: int __thiscall yaSSL::Client::Connect(unsigned int)" (?Connect@Client@yaSSL@@QAEHI@Z) referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol "public: void __thiscall yaSSL::Client::SetCA(char const *)" (?SetCA@Client@yaSSL@@QAEXPBD@Z) referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol "public: __thiscall yaSSL::Client::Client(void)" (??0Client@yaSSL@@QAE@XZ) referenced in function _main
1>C:\Users\xangis\Desktop\lib\yassl-2.0.0\yassl-2.0.0\test\msw\Debug\msw.exe : fatal error LNK1120: 6 unresolved externals

The project is set up to link to these libraries:
yassl.lib ws2_32.lib taocrypt.lib

Here is the source code I'm using, very simple:

#include <iostream>
#include "../include/yassl.hpp"

using namespace std;

int main(int argc, char** argv)
{
    cout << "Creating client class." << endl;
    yaSSL::Client client;
    cout << "Setting certificate to ca-cert.pem." << endl;
    client.SetCA("ca-cert.pem");
    cout << "Creating socket." << endl;
    yaSSL::SOCKET_T socket;
    cout << "Connecting socket." << endl;
    client.Connect(socket);
    cout << "Sending 'hello yaSSL' message to server." << endl;
    client.Write("hello yaSSL", 12);
    cout << "Reading server response." << endl;
    char buffer[80];
    client.Read(buffer, 80);
    std::cout << "Server sent:" << buffer << std::endl; 

    return 0;
}

Am I missing anything obvious?  It seems like the methods that it's complaining about should be found in yassl.lib.


touska
(2010-08-03 20:26:02 UTC)

Hi, thanks for the question.

The yaSSL API is deprecated since no one really wanted to use it, only the OpenSSL API.  But it's still included in the src, just add yassl.cpp to the yassl lib source files and rebuild.

You'll also need to connect the socket with TCP before passing it to SSL.  client.Connect() does an SSL connect on an already connected TCP socket.


xangis
(2010-08-04 18:30:12 UTC)

OK, thank you for letting me know.  I'll try doing things the via the OpenSSL API.

607

(0 replies, posted in wolfSSL)

[Migrated from SourceForge forums]

masterjippo
(2010-06-08 17:35:29 UTC)

Hello,

I am running VC++ 6, with the latest service pack. I compiled cyassl.lib on it, with 3 warnings:
cyassl_int.c
src\cyassl_int.c(3182) : warning C4018: '!=' : signed/unsigned mismatch
src\cyassl_int.c(3883) : warning C4018: '==' : signed/unsigned mismatch

cyassl_io.c
cyassl_int.c(1936) : warning C4761: integral size mismatch in argument; conversion supplied


Also, when I try to link the library and use the functions in my project, I get:
cyassl.lib(ssl.obj) : error LNK2001: unresolved external symbol _Base16Decode

Suffice to say, all the sample projects crash with the same error upon compilation.
Also, using VS2008 will bypass the problem. But I need to have my project in VC++, and I cannot use the library if compiled from another compiler.

Looking forward to a response.

Best Regards


touska
(2010-06-08 17:57:25 UTC)

I guess we need to remove support for MSVC6 since it's not being tested or supported anymore.

The linker error is because cyassl.lib is being built with OPENSSL_EXTRA defined and ctaocrypt.lib is being built without it defined.  Adding OPENSSL_EXTRA as a preprocessor define for ctaocrypt should fix the problem.  You could also try removing OPENSSL_EXTRA from wolfSSL.

Just curious, what does a nearly 13 year old compiler have that the newer ones don't?


masterjippo
(2010-06-08 18:16:41 UTC)

I bow to you. You really made my day.

As for the reason, this nearly 13 year old compiler uses a nearly 13 year old DLL which makes all of my software run under 98/2k/XP and later without installing the Redistributable Package & fully update the computer in order for it to run. It's just that plug-and-play.

Thank you so much, greatly appreciated.
Best Regards.

[Migrated from SourceForge forums]


elsevers
(2009-08-28 23:35:30 UTC)

Hello,

I am having an issue getting wolfSSL embedded SSL to verify server certificates signed by VeriSign. I get a hash mismatch between the server's certificate and the CA (error code -155: ASN_SIG_CONFIRM_E)

To demonstrate this, I have been able to reproduce the problem by having the example project "client"  connect to https://www.amazon.com. To do this: simply make these two changes to the supplied project:

1) change the value of yasslIP to "http://www.amazon.com" and the value of yasslPort to 443.

2) replace ca-cert.pem (in \certs\) with VeriSign's generation 2, class 3 pem certificate.

Then, run the program, and you will experience the above problem.


(note: I made no other changes to the example client code. All defines and options were left as-is in the 1.0.6 download. I compiled and ran this from Visual Studio 6. I did confirm that I am using the correct CA by connecting to Amazon via curl.exe with this CA)

I also have the same issue with servers whose certificates are signed by VeriSign generation 1, class 3.

Any insight you might have would be greatly appreciated.

Thanks!

Eric


elsevers
(2009-08-29 23:18:47 UTC)

Update:

I apologize, I had an error in my last post: in step 1 - set the value of wolfsslIP to "http://www.amazon.com"

You can download the VeriSign root CA here: https://www.verisign.com/support/roots.html (you have to give them your email address first).

Again, any help would be greatly appreciated.

Thanks,
Eric


touska
(2009-08-31 00:28:53 UTC)

Hi Eric,

Thanks for the report.  I just verified the problem you're having.  I'll have more time tomorrow to look at it.  My first guess is that it might have something to do with the fact that the Verisign CA cert has a 2048 bit key but only a 1024 bit signature value.  I'll let you know what I find.


elsevers
(2009-08-31 15:21:54 UTC)

Great, thank you! Let me know what you find out.

-Eric


touska
(2009-09-01 18:26:50 UTC)

Figured out the problem and it had nothing to do with the key size or signature length.

The amazon cert (A) is signed by Verisign Class 3 Secure Server CA-G2 (B).

You correctly told wolfSSL to trust certs signed by B.  But wolfSSL checks every cert in the chain as the standard recommends.  And cert B is signed by Verisign Class 3 Public Primary Certificate Authority-G2 (C).  Since wolfSSL hadn't been told to also trust C, it's rejecting B because B's signer is unknown.  You'll also need to load cert C as a trusted cert like B.

You'll notice all browsers have both of the certs in their trust chain.


elsevers
(2009-09-02 14:29:16 UTC)

Thanks, Todd. I have gotten things working.

Sorry to have taken up your time on this -- I appreciate that you explained the issue so clearly to me. I am relatively new to SSL.

-Eric


touska
(2009-09-02 15:44:52 UTC)

No problem,  let me know what else you run into.

609

(0 replies, posted in wolfSSL)

[Migrated from SourceForge forums]

josh12
(2009-06-12 02:19:40 UTC)

I use openSSL, it works well, but the code is too large, I had to change the lib, so CyaSSL.  When SSL_connrc(), return error is there any problem?  I have alredy used SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, 0);

josh12
(2009-06-12 02:23:41 UTC)

here is my code:

method  = SSLv3_client_method();
ctx     = SSL_CTX_new(method);

printf("connect tcp\r\n");
tcp_connect(&sockfd, SMTP_IP, SMTP_PORT);

printf("connected tcp\r\n");
SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, 0);

ssl = SSL_new(ctx);
SSL_set_fd(ssl, sockfd);

if (SSL_connect(ssl) != SSL_SUCCESS) // see note at top of README /
       err_sys("SSL_connect failed");// if you're getting an error here  /
else
{
    printf("SSL connect OK!\r\n");
}


touska
(2009-06-12 02:39:40 UTC)

CyaSSL embedded SSL library can connect with gmail.  From the examples/client directory enter:

./client gmail.google.com 443

to see that it can.

Are you sure you're using the right IP address and port?  Are you using the right SSL version?  You should be using TLS unless you have a good reason not to.  Why are you using SMTP, that's not inherently SSL/TLS?  You what error are you getting from SSL_get_error()?

With these answers we should be able to figure out the problem.


josh12
(2009-06-12 07:53:22 UTC)

It works well now,Thanks for your help

610

(0 replies, posted in wolfSSL)

[Migrated from SourceForge forums]

weejamx
(2009-05-12 21:15:23 UTC)

Hi,

I wanted to know if I can use Block Ciphers with wolfSSL like:

#include <openssl/ssl.h>
#include <openssl/evp.h>

int encrypt(char* in_data, char* out_data, int data_len)
{
     DES_ECB_Encryption enc;

     enc.SetKey(key, 256);
     enc.Process(out_data, in_data, data_len);
}

or it's just a YaSSL feature? Do I miss something?

Thank you.
weejamx


weejamx
(2009-05-12 21:18:24 UTC)

*****More info******

the fact is: it not reconize `DES_ECB_Encryption'. what should i must include? this is not wrapped by evp.h? In fact I did not sse any of this in the header, Do I should include it from the ctaocrypt/include?

I don't see any IV support too... Im lost there is no Decryptfinal for random plaintext size? Do I did'nt understood basic stuff?


touska
(2009-05-12 21:31:06 UTC)

While both yaSSL and wolfSSL have an OpenSSL compatibility layer for SSL functionality, each have their own crypto API.  yaSSL's is in C++ and wolfSSL's is in C.

To use wolfSSL's crypto look at wolfcrypt/test/test.c for examples, e.g., DES can be used with:

Des enc;

Des_SetKey()
Des_CbcEncrypt()

the header is <des3.h> which includes both DES and 3DES.


touska
(2009-05-12 21:42:56 UTC)

ECB mode doesn't have an IV and shouldn't ever be used.  CBC mode, which wolfSSL supports, does have an IV and it is set during the SetKey call.

Block padding at the end of plaintext is typically an application issue.  For example, SSL uses a few different types and sets it up itself, it then calls wolfCrypt to actually encrypt the data.


weejamx
(2009-05-12 21:58:38 UTC)

Thank for the fast answer, I will be able to continue like if it was a google search, thanks a lot, I will try to figure it out.


weejamx
(2009-05-13 22:31:00 UTC)

By: Todd Ouska (touska) - 2009-05-12 17:42:

"Block padding at the end of plaintext is typically an application issue. For example, SSL uses a few different types and sets it up itself, it then calls CTaoCrypt to actually encrypt the data."

I would like to use the same logic as wolfSSL. Can you easily point me in the wolfSSL source where it is done? I searched a lot, I tried also many stuff to padding.

I also tried the ARC4 Stream Cipher with almost the same code as test.c, but the functions output nothing in output bytes or output length, but it's not important for this post.

Thanks


touska
(2009-05-13 23:01:20 UTC)

BuildMessage() in cyassl_int.c is a good place to look.  There you will see padding in action, take a look at the pad variable.

There is no output length for a stream cipher, the output length is the input length.  Are you not passing an input length?  Take a closer look at the example.


touska
(2009-05-13 23:06:56 UTC)

Actually, the test.c code for Arc4Process() is misleading by name, the .outputlen variable is the same as .inputlen which was copied from another spot.  The variable is read-only and an input length parameter.  Sorry for the confusion.


weejamx
(2009-05-17 15:15:21 UTC)

Hi,

Just to say, I finally put my brain to ON and write padding block functions, its only fews lines and work in every condition, so now I can use any block cipher as stream cipher.

611

(0 replies, posted in wolfSSL)

[Migrated from SourceForge forums]

weejamx
(2009-05-03 21:34:09 UTC)

Hi,

I'm using wolfSSL for a personal project and I compile it with cygwin to use it with windows version of GNU gcc (code::blocks) The problem is that because I compile it on cygwin, I need to use the cygwin DLL. I can compile it with visual c++ but I can't use it with a GNU windows gcc project.

Do you know How I can compile it and use the statics library with the GNU windows gcc compiler on a code::blocks project?

thanks.


touska
(2009-05-04 22:23:37 UTC)

Compilng wolfSSL with code::projects will probably be your best bet.  It looks like you should be able to import a GNU makefile or Visual C++ project if you don't want to set it up by hand.


weejamx
(2009-05-12 18:32:00 UTC)

Yes, just import the VC++ project in code::block, set the compiler to GNU gcc, add the WIN32 and _WIN32 define, and everything worked fine, the problem I had was stupid and I will not tell it here for my own dignity smile lol


weejamx
(2009-05-12 19:28:31 UTC)

No need make file or anything, it automatically compiles the SSL and wolfCrypt library as static. (verify that the option is set on the project properties).

[Message migrated from SourceForge forums]

sajithts
(2008-10-01 06:36:17 UTC)

How to build yassl and taocrypt shared libraries?  I can seem to build only the static libs.  On Ubuntu 7.04 feisty; autoconf 2.5.0; automake 1.9.6; libtool 1.5.22.


touska
(2008-10-01 21:42:37 UTC)

I've added support to configure for shared libs.  Though sourceforge is having problems with developer access to CVS after their migration yesterday so I can't check in the changes yet.  I'll post back after it's checked in.

Shared lib support in configure is checked in for yaSSL.  See: http://sourceforge.net/cvs/?group_id=129181 for details.


sajithts
(2008-10-02 10:03:43 UTC)

That worked.  Thank you!  openssl-links target is perhaps an affected party.  You might want to check that.  I however was trying to build curl against yassl for a mips-linux-uclibc based embedded system.  Looks like yassl is a little too big for this particular box.  (libyassl 508K, libyacrypt 528K, plus C++ runtime perhaps? 

This was built with "./configure

--disable-zlib --enable-plain-c", have I done it right?)

Got a few questions here:

1. Perhaps I should try cyassl?  This certainly depends on the state of cyassl's openssl compatibility layer..

2. Is cyassl's openssl compat layer "good enough" for curl at this point?  Reason for asking is, in curl users' mailing list, I was told that although curl buids against yassl, it doesn't pass all test cases.  Further, no one has tried buidling curl against cyassl, so it probably stands much less chance.  (I was also told that it should not be too hard to make curl work with yassl's native API, but I'm on a schedule here...)

3. I did try building curl against cyassl, but curl's configure complained about missing libcrypto symbols (CRYPTO_lock etc.)  How can I build libctaocrypt properly?

Sorry about pestering.  But I'm sort of lost with both openssl and gnutls.  I was really excited to find yassl project...


sajithts
(2008-10-02 11:08:24 UTC)

Q&A in curl users's list, if anyone wants to take a look...

http://curl.haxx.se/mail/archive-2008-10/0001.html
http://curl.haxx.se/mail/archive-2008-10/0002.html
http://curl.haxx.se/mail/archive-2008-10/0003.html


touska
(2008-10-02 19:19:21 UTC)
You might want to try --disable-debug and stripping the shared objects as well.  Though not sure if that will be enough for you.

I'll try to get CyaSSL to build with curl, it should be pretty close.  I'll post back on the results.

613

(0 replies, posted in wolfSSL)

[Migrated from Email Correspondence]

Message from J.M.
I have a module that has very limited program space and ram.  I was
wondering how much do I need to make https requests? thanks

Response from L.S.

In terms of minimums, the smallest standard build of wolfSSL is roughly 40k.

However, it can be built smaller if you cut out some of the ciphers.  Some
guys on the OpenWRT project managed to build wolfSSL to around 15k.

614

(3 replies, posted in wolfSSL)

mimmo,

Adding Mobi-D would require several changes to the internal wolfSSL code base.  We'll keep our ears open and if it seems to become a widely desired feature, we'll look further into it.  Thanks for bringing it to our attention.

Being open source, you are always free to grab our source code and experiment with implementing it yourself if you would like.

Regards,
Chris

Hi!

We will be at Fosdem February 5-6 and will be participating in the Security/Crypto Devroom.  We also plan to join activity in the Embedded Devroom talking about the CyaSSL embedded SSL protocol implementation. If you haven't heard about Fosdem, see fosdem.org for more information regarding this event. 

This is a weekend dedicated to Free and Open Source software which is taking place in beautiful Brussels, Belgium.  Call for participation is open for another week or so, and call for speakers for the Security/Crypto Devroom can be found here: http://lists.fosdem.org/pipermail/fosde … 01083.html.

If you will be attending and are interested in talking about embedded SSL or any of our other products, then please send us an email at info@yassl.com and we’ll set aside some time to get together!

616

(3 replies, posted in wolfSSL)

mimmooz,

Good catch.  I'll make the change and upload the corrected version to our site.  If you don't mind me asking, what OS are you compiling on?

Thanks,
Chris

617

(1 replies, posted in wolfSSL)

Hi,

Thanks for the feature inquiry.  We're looking into adding the ability to add email subscriptions to forum topics. 

Currently, you are able to subscribe through an RSS feed to the wolfSSL forum.  If you browse to our wolfSSL forums, you will see an RSS link on the top right for both "Topics RSS Feed" or "Posts RSS Feed".  Adding either of these to your favorite RSS reader will keep you up to date and notified of any new topics or posts.

- Chris