#
elsevers

[Avatar]
2007-09-26 22:00:16 UTC
Hello,

I just downloaded the wolfSSL source code and am trying to compile it to implement embedded ssl on a microcontroller. I have some rather... inexperienced questions that I am hoping somebody might have the patience to help me out with:

Should I be using the make files that are included to compile wolfSSL? If so, is there a good makefile application for windows? Is there a list of settings available that I should be aware of when I try to compile wolfSSL for my microcontroller?

Thanks!
Eric
#
touskaProject Admin

[Avatar]
2007-09-28 17:39:49 UTC
Hi Erik,

If you're on Windows you should be able to use the MSVC project files. If you're not using MSVC as your compiler you can probably use ./configure and make but you'll need to install something like cygwin to use those tools on windows.

Regards,
Todd

#
modernx

[Avatar]
2007-06-19 07:03:33 UTC
MS Internet Explorer does not connect to the Server (from examples folder). Exeption on call of sendServerKeyExchange(*ssl): _CrtIsValidHeapPointer "This may be due to a corruption of the heap, and indicates a bug in server.exe or any of the DLLs it has loaded."

In general, I wish to connect yaSSL client and Win32 Server based on MS SSPI.

Excuse for my bad English smile
#
touskaProject Admin

[Avatar]
2007-06-19 22:15:21 UTC
Hello,

I'm not able to reproduce this problem. First of all, you should use the echoserver example when trying to connect with a browser client since most of those clients do a termination and then resumption. The server example only responds to one request and then terminates while the echoserver example stays alive until you send a "quit" command or force quit it.

I tested the example echoserver of yaSSL version 1.6.8 built using GCC and MSVC against IE 6 and 7. Which compiler and version are you using, broswer version? Does the testsuite pass?

1.
      lychen214

      [Avatar]
      2007-05-21 11:21:28 UTC
      Hi

      I use wolfssl as SSL lib. to develop https server. But I encounter some problems. In general all functions work normally except opening a applet web page. Some error messages are showed as below

      Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
      at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
      at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
      at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
      at java.net.HttpURLConnection.getResponseCode(Unknown Source)
      at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source)
      at sun.applet.AppletClassLoader.getBytes(Unknown Source)
      at sun.applet.AppletClassLoader.access$100(Unknown Source)
      at sun.applet.AppletClassLoader$1.run(Unknown Source)
      at java.security.AccessController.doPrivileged(Native Method)
      ... 10 more
      Caused by: java.io.EOFException: SSL peer shut down incorrectly
      at com.sun.net.ssl.internal.ssl.InputRecord.read(Unknown Source)
      ... 23 more

      Could any body help me figure out this problem? Thanks a lot~
   2.
      touskaProject Admin

      [Avatar]
      2007-05-21 19:45:34 UTC
      Hi Eric,

      Are you getting an error on the wolfSSL side, if so, what is it? Do you get the same error/problem when you use the sample server (after changing the address and port of course)?

      Thanks for the input,
      Todd
   3.
      lychen214

      [Avatar]
      2007-05-22 13:04:33 UTC
      Hi Todd

      Thanks for your quick reply.

      I don't get any error messages on the wolfssl side. All those error messages are copied from java console. It seems that it can't finish handshake procedure if using java to connect wolfssl side. The reason seems to be that java fails to get jar or class files due to ssl handshake fail. But I can't exactly point out where the problem is. I try to add some codes to print something on console on the wolfssl side.

      Success case:
      If I succeed to get a web page, it will print
      ACCEPT_BEGIN
      ACCEPT_FIRST_REPLY_DONE
      SERVER_HELLO_DONE
      ACCEPT_SECOND_REPLY_DONE
      ACCEPT_FINISHED_DONE
      ACCEPT_THIRD_REPLY_DONE

      Fail case:
      If I try to get a applet web page, it only print
      ACCEPT_BEGIN
      ACCEPT_FIRST_REPLY_DONE
      SERVER_HELLO_DONE

      Ordinarily the general web page could be displayed successfully.

      I will do more try and post later. If you need any information from me, please let me know it. Thanks a lot~
   4.
      touskaProject Admin

      [Avatar]
      2007-05-23 19:52:22 UTC
      Hi Eric,

      One thing I can think of is that the applet web page is slow to respond with the client key exchange message and that your https server is using a non-blocking socket. In that case, SSL_accpet() will reuturn != SSL_SUCCESS and SSL_get_error() will return SSL_ERROR_WANT_READ and you'll need to restart SSL_accept() when the data is ready. If that's not the case, what is SSL_accept returning and what does SSL_get_error() return.

      Thanks again for the info,
      Todd
   5.
      lychen214

      [Avatar]
      2007-05-24 09:35:06 UTC
      Hi Todd

      After few tests, I found that SSL_get_error always returns PMS_VERSION_ERROR rather than SSL_ERROR_WANT_READ. It only happens when java start handshake with wolfssl side. It seems to have problem to use java as client. I don't know if the information is enough for you. If you need any other information from me, please feel free to let me know.

      ps. wolfssl version is 0.6.2

      Thanks a lot~
   6.
      touskaProject Admin

      [Avatar]
      2007-05-24 18:07:57 UTC
      Hi Eric,

      Try using the newest version, although that's not going to help this problem. If you look at the code in wolfssl_int.c, the error is being set on the line:

      ret = PMS_VERSION_ERROR;

      because the first two elements of the Pre Master Secret don't match the major and minor version numbers of the Client Hello. The standard mandates this. I don't know why the java client is disobeying this. Which SSL/TLS version are you setting up the server with? Do you know which version the client is sending in the Client Hello and which version is being encoded in the Pre Master Secret that isn't matching?

      You can get these answers by breaking on the if statement above the ret = PMS_VERSION_ERROR line and checking chVersion (Client Hello Version) and preMasterSecret[0] and [1].

      You can work around this by commenting out the if statement and error set and always just doing a

      ret = MakeMasterSecret(ssl);

      but I don't know why that should be neccessary.

      Regards,
      Todd
   7.
      lychen214

      [Avatar]
      2007-05-25 06:03:11 UTC
      Hi Todd

      Very thanks for your suggestions. The problem is as you said. But it's my entire fault to use wrong initial function. After changing server initial method from SSLv3_server_method to TLSv1_server_method, the applet page works. Anyway it's a very good experience to use this library and thanks for your help again.

      BR
      Eric

1.
      tlsa

      [Avatar]
      2007-02-21 10:43:05 UTC
      Hello,

      Does yaSSL (or wolfSSL) allow the certificate chain to be inspected when verification fails? This is needed for a web browser's* invalid certificate query box (which asks the user to inspect the certificate chain, in the event of failed verification, and accept or reject the certificate).

      Also, is it possible to determine where verification failed, so that the problem could be highlighted for the user by the web browser?

      If these facilities are not available, are they planned for future releases?

      * NetSurf - http://www.netsurf-browser.org/

      Best regards,

      Michael Drake
   2.
      touskaProject Admin

      [Avatar]
      2007-02-22 22:40:45 UTC
      Hi Michael,

      I'll have to add a callback to allow the user the option to approve of the chain when encountering an error. Currently the verify mode can be set to VERIFY_PEER (on by default) or VERIFY_NONE. If VERIFY_PEER is on and the validation fails than an error code is returned, usually a date problem or no CA certificate to verify the chain.

      I know it's normal to allow users the option to use SSL w/o any verification but I'd try to avoid it if you can since you are basically giving up any guarantee of security at that point and might as well be using http.

      I'll reply to this post when I've added the callback and better chain inspection.

      Regards,
      Todd

#
raphaelhuck

[Avatar]
2006-11-21 14:00:30 UTC
Hi,

On the website, it says "yaSSL also supports an OpenSSL compatibility interface."

However, when I tried to compile with Lighttpd (http://www.lighttpd.net), there are several problems.

The main issue is that the MD5 structures are different ("Md5" instead of "MD5_CTX"), and the functions are renamed ("InitMd5" instead of "MD5_Init",...).

Is there a howto to help users migrate from OpenSSL to wolfSSL ?

Thanks in advance.
#
touskaProject Admin

[Avatar]
2006-11-21 19:06:06 UTC
I haven't written a migration guide yet but it's something I'll start. The OpenSSL compatibility layer is intended to support all of the common SSL functionality, not every single function from SSL, Crypto, PKI, EVP, and X509, because there are thousands and thousands of functions. That said, if something can't build because of only a few missing functions I'll probably add them. yaSSL supports the MD5_CTX stuff so I guess I'll add it to wolfSSL as well as an optional build feature.

1.
      salee88

      [Avatar]
      2006-10-20 23:40:22 UTC
      Hi Todd,
      I found a couple of funcitons in openssl is not supported yet in yassl:

      SSL_CTX_use_certificate_chain_file
      SSL_CTX_ctrl

      Are you planning to implement the above functions soon or there is easy alternative way to get around the functions (ie. write your own). Thanks in advance for your help.

      Sean
   2.
      touskaProject Admin

      [Avatar]
      2006-10-23 17:59:00 UTC
      Hi Sean,

      I'll implement SSL_CTX_use_certificate_chain_file(), though it isn't required for yaSSL since the verification chain is automatically searched. That is, if your certificate A is signed by B and you load A, it gets sent to the peer. The peer already has to have B in order to verify A so there's no reason to also load B and send it to the peer that I can think of. Other implementations that I've tested support this, though many do send the complete chain. That said, it shouldn't be hard to support.

      SSL_CTX_ctrl() is a little more difficult since there's a ton of options and vendor specific controls, not to mention that it isn't supposed to be called directly according to the man page. Is there some specific functionality that you're thinking of, maybe yaSSL already has it, maybe it can be set elsewhere?

      Thanks for the suggestions,
      Todd

#
[Avatar]
2006-10-02 21:06:32 UTC
Hi,

As title.

It seems that most of the X509_ functions used to verify peer certificate are not implemented in wolfSSL, am I correct?

Thanks.

Peter
#
touskaProject Admin

[Avatar]
2006-10-03 18:11:15 UTC
Yes. wolfSSL takes a different approach to certificate verification than other embedded SSL libraries. Verification is on by default so dates, signatures, and names are checked unless you turn verification off. If you don't provide a CA cert or the wrong one for example, a wolfSSL client will fail to connect. Is there a particular X509 function you want?
#
ngustavson

[Avatar]
2006-10-03 19:30:02 UTC
I've done several openssl->wolfssl ports now and typically I have to comment out the cert verification stuff to get it working.

I see the auto cert. checking you mentioned touska.
If they are effectively being implemented, then for openssl compatiblity it would probably be better to implement some kind of stubs for these functions(not just the headers), otherwise you get undefined errors when you try to compile against them.

(at least I do, but I'm compiling directly against the static lib instead of using libtool)

thx,
NZG





#
ngustavson

[Avatar]
2006-10-03 21:08:44 UTC
Also, it would be good if some sort of error message was displayed when a certificate is rejected to to a future date.

I spent a couple hours on that before I realized my clock wasn't set correctly.

BTW.
All and all this is a very nice software package, keep up the good work!

NZG


#
touskaProject Admin

[Avatar]
2006-10-03 22:20:14 UTC
Thanks for the suggestions. I've checked in a change that makes sure certificate errors are propagated all the way back to the caller and I've removed wolfSSL ssl functions from the header that aren't implemented yet.
#
panpipi

[Avatar]
2006-10-04 04:50:26 UTC
"If you don't provide a CA cert or the wrong one for example, a wolfSSL client will fail to connect."

My question is not about absence of CA cert or wrong CA cert but about how to do some "post connection check" like making sure that the server presents a certificate that contains the FQDN of the server's address. For this I may need to iterate thru X.509 extensions and use the extension-specific parsing routines to find all extensions that are "subjectAltName" fields, "dNsName" fields, or just commonName field.

So, probably at least I will need SSL api like:

* SSL_get_peer_certificate()
* X509_get_subject_name()
* X509_NAME_get_text_by_NID

Please correct me if I miss or mistake something here. Thanks.

Peter
#
touskaProject Admin

[Avatar]
2006-10-04 08:21:18 UTC
No mistake, I'll add these. I just wanted to make sure you understood that wolfSSL was doing all the other checks automatically. Not enough people check the chain, dates, and signature (which wolfSSL does) let alone the Domain Name. Maybe I should add a function to do that during verification so that no post check is needed by default?
#
panpipi

[Avatar]
2006-10-04 17:29:18 UTC
It is good with builtin check of Domain Name or whatever field to assure that the server connected is the one a client is wanting to connect with.

Builtin check can be a more compact footprint than the X509_xxx functions plus extra application code to use them.

peter

1.
      panpipi

      2006-09-26 16:39:41 UTC
      When will wolfSSL support DER format of CA certificate? Thanks.
   2.
      touskaProject Admin

      2006-09-26 17:45:52 UTC
      Individual certificates and private keys can be used in either format, DER or PEM. CA certificates on the other hand must be in PEM format, the SSL_CTX_load_verify_locations() function doesn't allow the option to specify which format and assumes PEM. Is there a reason you need CA certificates in DER format?
   3.
      panpipi

      2006-09-26 23:38:57 UTC
      I am new to SSL and X.509. I don't know which of DER and PEM format of CA certificate prevails commercially? If it is PEM, i'm all set; otherwise I will need DER support.

      Please advise. Thanks.
   4.
      touskaProject Admin

      2006-09-27 06:16:30 UTC
      I can show you how to convert DER to PEM if that's all you can find, it's trivial.
   5.
      panpipi

      2006-09-27 19:13:57 UTC
      Thank you.

      Is it by openssl command line?

      Is there any windows executable for the purpose?
   6.
      touskaProject Admin

      2006-09-27 19:53:18 UTC
      The openssl command line utility is the quickest, easiest way to do it. You should be able to use openssl on Windows, either native or through cygwin. I could build an executable to do it if you really need it, I'd just reverse PemToDer.

1.
      panpipi

      [Avatar]
      2006-09-25 11:15:56 MDT
      Is it possible for wolfSSL to export a function that indicates whether an SSL session has incoming message ready for receiving? It would be useful to SSL applications that needs asynchrnous i/o, because wolfSSL buffers message leftover and hides SSL struct in wolfssl_int.c.
   2.
      touskaProject Admin

      [Avatar]
      2006-09-25 13:37:03 MDT
      Sure, I can implement SSL_pending. I should have a patch for you tomorrow for your requests. Is there a reason you're using wolfSSL over yaSSL? I ask because yaSSL is much more mature and feature rich, the only reasons to use wolfSSL are for small size or if your system lacks a c++ compiler. You can still use yaSSL in a C project.
   3.
      panpipi

      [Avatar]
      2006-09-25 14:29:00 MDT
      yes, I use wolfSSL for small size, just like I had to clone expat with 130 lines of C code to save 80 KB code size.
   4.
      ngustavson

      [Avatar]
      2006-09-26 17:02:48 MDT
      I do this:

      /**
      * NZG addition
      * doesn't uses standard s->method because it doesn't exist!
      */
      int SSL_pending(SSL *s) {
      return(s->bufferedData.length?1:0);
      }

      Wput seems to use it.
      Hasn't bitten me....yet.

      NZG

   5.
      panpipi

      [Avatar]
      2006-09-26 17:25:21 MDT
      I did similarly, but still prefer official release.

      thanks.

1.
      ngustavson

      [Avatar]
      2006-09-26 14:42:41 MDT
      I'm cross-compiling yassl for a uClinux system.
      I built wput against it's static library and brought it in.

      I can't get it to establish a connection yet.
      By adding some debug statements I found out that the key exchange was failing in
      cyassl_inc.c at:

      SendClientKeyExchange(SSL* ssl)

      in:

      ret = RsaPublicEncrypt(ssl->preMasterSecret, SECRET_LEN, encSecret,
      sizeof(encSecret), &key, &ssl->rng);

      This happened because
      key->n was larger than sizeof(encSecret)

      specifically
      key->n - 128
      sizof(encSecret) - 96

      As these numbers just so happen to be the byte length of the common 1024 and 768 bit keys respectively, I figured that wolfssl was probably just not providing enough memory for keys > 768 bits.

      Hacking things around, I changed SECRET_LEN to 64 to bump it up to 1024 bits.
      This allowed the key exchange to pass but causes a mac error, so I'm figuring there's another number or table in there that needs to change alongside of SECRET_LEN.

      Am I on the right track?
      Is there an established way to add support for larger keys?
      Am I completely off?

      thx,
      NZG










   2.
      touskaProject Admin

      [Avatar]
      2006-09-26 15:26:09 MDT
      SECRET_LEN needs to stay at 48, per the standard. The bug is the length of encSecret, it shouldn't depend on SECRET_LEN. I just increased it to 256 to handle up to 2048 bit RSA. Thanks for the report.
   3.
      ngustavson

      [Avatar]
      2006-09-26 17:00:21 MDT
      Thank you sir.
      That little tip got my app working.
      More testing is required but it certainly makes for a better nights sleep.
      :-)

      thx,
      NZG

1.
      panpipi

      [Avatar]
      2006-09-25 11:45:34 MDT
      Hi,

      How long can I keep a saved SSL session and need not to worry that it will expire and no more be resumeable?

      Is SSL-resume a standard feature that all SSL servers need to support?

      Thanks.
   2.
      touskaProject Admin

      [Avatar]
      2006-09-25 13:40:27 MDT
      wolfSSL buffers sessions for 500 seconds. Most servers implement session resumption because of the speed and to take some load off of the server. The standard doesn't require it though. If a client attempt at resumption fails you can just create a new session without really having lost anyting, but the gain is big enough that it's worth the try.
   3.
      panpipi

      [Avatar]
      2006-09-25 14:31:43 MDT
      Agreed, but still cannot understand why wolfSSL's resumption needs a new SSL pointer instead of using the old one?

1.
      panpipi

      [Avatar]
      2006-09-23 18:11:00 MDT
      Hi,

      There seems another bug in wolfSSL v0.5.0.

      Here are the steps to reproduce it:

      => client and server uses normal procedure to set up a SSL connection
      => server closes the connection
      => client uses the same SSL* to initiate another connection
      => server crashes at Md5Update()

      Thanks.
   2.
      touskaProject Admin

      [Avatar]
      2006-09-24 19:35:55 MDT
      I'll fix the server crash but this isn't the way to resume an SSL connection on the client side. See the client example code under TEST_RESUME, you could also create a new SSL pointer and do a complete new connection but resuming is much quicker and easier on the server.
   3.
      panpipi

      [Avatar]
      2006-09-25 11:07:59 MDT
      You are right, but a robust server need take care of not only 99 good buys but also the bad buy, isn't it? Thanks.

1.
      panpipi

      [Avatar]
      2006-09-22 16:27:10 UTC
      Hi,

      It seems that I found a serious bug in yaSSL C library.

      When my client calls SSL_Write() with a long msg of length 13173 bytes, the peer server has problem in SSL_Read() to decoding the long msg because the long msg actually arrives at server in 3 pieces.

      It seems SSL_read should buffer msgs till complete SSL packet arrives before it goes on decoding.

      Please help look into this problem if it is one.

      Thanks.

      Peter
   2.
      touskaProject Admin

      [Avatar]
      2006-09-22 19:10:02 UTC
      Yes, that's right. wolfSSL should buffer incomplete messages like yaSSL does, I'll fix this.

      Thanks for the report.
   3.
      panpipi

      [Avatar]
      2006-09-22 21:03:24 UTC
      Hi,

      It is great. Thanks for the prompt response!

      By the way, most functions in the library need some self-protection, eg. verifying input SSL* parameter not null, verifying that incompatible methods parameter of SSL_CTX_new() on either side won't cause core dump. I ignorantly set my SSL server to use TLSv1_client_method() which caused the server to crash in SSL_Accept() or MD5Update().

      Peter

Can any one help me about how can i integrate YaSSl library into my web site

Hi,

The wolfSSL team will be at the ARM TechCon event at the Santa Clara Convention Center this week.  Come by and hear about our new releases for wolfSSL embedded SSL, as well as our new yaSSL embedded web server for resource constrained devices. 

If you need a pass for the exhibits floor, email us at info@yassl.com and we'll send you a free ticket.  If you are a current customer or user with an open question, the bring it on by!  See you there!

Thanks!

LS

Hello yaSSL world!

We're now migrating our forums over from Sourceforge to yaSSL.com.  The instructive posts from the Sourceforge forums will gradually be moved over to this site.  Let us know if you have feedback on these forums on how we can improve your experience.

Thanks!

LS

42

(0 replies, posted in wolfSSL)

Hi!

We're concluding a great week in London, meeting wolfSSL customers at Embedded Live, a trade show about embedded systems.  We'll spend one more day in London and then we're off to Dublin and then back to USA.  If you're a yaSSL user in Dublin let us know if you'd like to meet up on Saturday.