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

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

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

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

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