[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!

[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.

[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.

[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.

[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.