2010-10-21 12:21:09 UTC
I wanted to ask if there are any plans to support certificate signatures with PSS as specified in RFC 3447 and RFC 4055 in yassl?
#
touskaProject Admin

[Avatar]
2010-10-25 19:09:16 UTC
No specific date as of yet. The more requests we get for it the sooner we'll add it. Or if a potential customer/customer desires it then it gets moved up in priority. What usage scenario requires it?

#
[Avatar]
2010-10-01 14:10:05 UTC
Hi! I would like to ask for help with the following problem: I need to reuse the transport layer (TCP socket, currently) doing several (SSL_new, SSL_connect/accept, sending data to and from, SSL_shutdown, SSL_free) sessions one after the other. If both client and server are wolfSSL only (or openssl only), it works flawlessly. But if the client is wolfSSL and the server is openssl (or vice versa), there are problems after the first session. Thank you in advance, Visibilis
#
touskaProject Admin

[Avatar]
2010-10-01 16:56:56 UTC
wolfSSL doesn't support reuse of the underlying connection in the exact same way that OpenSSL does through the use of SSL_shutdown() in two phases. That is something we can change. But I'm curious. If you know you're going to be reusing the underlying connection why not just leave it open in the first place?
#
visibilis

[Avatar]
2010-10-05 13:42:10 UTC
I need this, for example, because I would like to use an external session cache. The cache should be able to work with OpenSSL, as well. I would like to use the cache along the lines of i2d_SSL_SESSION and d2i_SSL_SESSION. One use case would be to start an ssl session, shut it down, and open a new ssl session using the serialized session from the external cache. All using one underlining connection.
#
touskaProject Admin

[Avatar]
2010-10-05 18:22:45 UTC
That's not going to be possible I think. A session cache is implementation specific, there's no standard for what and how to store it. That is, you can't use the same session cache with OpenSSL, gnuTLS, yaSSL etc... Further, wolfSSL doesn't support an external session cache since it's an embedded SSL library intended for embedded use. That's not say it won't in the future but we haven't had any requests for it yet.
#
visibilis

[Avatar]
2010-10-08 13:43:03 UTC
Thank you for your kind reply. Could you give me a hint what I should do to be able to reuse the underlying connection with wolfSSL? Will you implement it, if I ask you nicely? smile
#
touskaProject Admin

[Avatar]
2010-10-11 21:16:24 UTC
Use wolfSSL on both ends is one solution. Don't call SSL_shutdown on either end may be another. At some point we'll update wolfSSL to handle this situation but we're very busy with customers and potential customers at the moment so I can't give an estimate of when that will be.

2010-09-13 17:20:54 UTC
Hello! How do I create a SHA1 fingerprint from a certificate using CyaSSL? OpenSSL code to do it: X509* x = /* get certificate */; unsigned int n; unsigned char md[EVP_MAX_MD_SIZE]; const EVP_MD* evp_type = EVP_sha1(); X509_digest(x, evp_type, md, &n); or: X509* x = /* get certificate */; int i; const ASN1_ITEM *it = ASN1_ITEM_rptr(X509); const EVP_MD* evp_type = EVP_sha1(); ASN1_VALUE *asn = (ASN1_VALUE *)x; unsigned int n; unsigned char md[EVP_MAX_MD_SIZE]; unsigned char *str = NULL; i = ASN1_item_i2d(asn, &str, it); EVP_Digest(str, i, md, n, evp_type, NULL); I should be able to verify SHA1 hash generated by OpenSSL, so fingerprint generated with CyaSSL should be the same. Thanks!
#
touskaProject Admin

[Avatar]
2010-10-01 17:07:21 UTC
Hi, sorry for the delay, don't think I got a notification for this one. I'm not totally clear on what you're trying to do. Do you just need the hash over every byte of the certificate? If so, that is easy. Read in all the bytes and use ShaUpdate() and ShaFinal(). On the other hand, if you need the hash over just the Subject's Name in the cert there is no easy way to get this currently from CyaSSL. CyaSSL keeps track of this internally but doesn't yet "export" the hash. We can add that if it's something that's needed.

4

(0 replies, posted in wolfSSL (formerly CyaSSL))

#
[Avatar]
2010-07-27 11:31:31 UTC
I am writing client/server that send file using DTLS (wolfSSL). Try with code as in echoserver in example, each time data received, it should re-bind again. Tried not to close socket but still not receive data anymore. Is there able to keep the socket listener?
#
touskaProject Admin

[Avatar]
2010-07-27 16:58:47 UTC
Why are you using DTLS for file transfer? DTLS is typically for streaming applications where missing parts of the data don't matter. If you want the file to be complete you need to use TLS instead. UDP sockets don't listen, though they can connect to an address. Pay close attention to the echoserver and echoclient example. You can run the echoserver in DTLS mode if you build wolfSSL with DTLS with --enable-dtls . Then you can run the echoclient from examples/echoclient with DTLS and exchange a file like this: ./echoclient input where input is a text file with some source code.
#
afelion

[Avatar]
2010-07-28 01:28:32 UTC
in echoserver.c, line 154, server loop: SSL_shutdown(ssl); SSL_free(ssl); CloseSocket(clientfd); #ifdef WOLFSSL_DTLS tcp_listen(&sockfd); SignalReady(args); #endif The socket is re created, and bind on the address again. How to keep the current socket?
#
afelion

[Avatar]
2010-07-29 03:41:11 UTC
Any help? I have problems when handing multi connections to a DTLS server. server: Call recvfrom to listen new connection When a SSL accepted, call SSL_read to retrieve data. If I want to keep that connection for future transfering, the server can not back recvfrom new connections. If I put SSL_read in another thread, and continue bind the socket again, then got error "Address already in use". So how to handle multi clients in UDP server? Thanks in advance.
#
touskaProject Admin

[Avatar]
2010-07-29 04:13:52 UTC
Are you sure you want DTLS? UDP servers are iterative and connectionless. You indicate you want a concurrent connection oriented server, that means TCP and TLS. The example echoserver is iterative, as a UDP server should be. You could try making it concurrent but I think you'll find it much easier to just use TLS instead.
#
afelion

[Avatar]
2010-07-29 04:47:12 UTC
I have read: http://www.net-snmp.org/wiki/index.php/ … tion_Notes and want to do something similar using wolfSSL but have no idea about FIFO BIO.
#
touskaProject Admin

[Avatar]
2010-07-30 03:04:48 UTC
SNMP over UPD makes sense. One questions, one answer... iterative server. No TCP startup or teardown. DTLS over SNMP doesn't make sense, the DTLS handshake has extra steps over TLS negating the benefit of no TCP. And a concurrent server is now needed. The right answer in this case is use TLS. All of the things wrong with DTLS over SNMP are discussed in the link you provide. They're not unique to OpenSSL's implementation, it's just a poor choice. A bad alternative is to have an iterative UDP server get a request, spawn a worker thread with a new port and send that port back to client who then connects with DTLS to the port returned. Many clients, many server worker threads (or whatever). I suggest doing that if you have to use DTLS. wolfSSL doesn't yet allow the user to directly write to the input output buffers. But if you feel like must do that feel free to add the changes. I'll try to help if I can.
#
afelion

[Avatar]
2010-08-22 15:28:35 UTC
Thanks for your answer. Today I have time back to the implementation and have to bother you again. * Server 1. Create an UDP socket, binding on localhost. Create server CTX, SSL. 2. Start new thread, loop forever, using select() to wait new connection: select(fd + 1, &fds, NULL, NULL, NULL); and recvfrom to read UDP connect (echoserver.c) 3. When has a new connection, create new SSL and do SSL_accept. If connection is accepted, and save its SSL, address/port in a connected list 4. Do SSL_read to get data, and call this connection callback to handle the data. 5. Data responded is write to this connection SSL object (SSL_write) 6. Back to select() for new connections. 7. When has another connection (bypass select()), search its address/port in the connected list; if found, get the SSL saved, skip SSL_accept, back to step 4, otherwise, do SSL_accept and add to the list. * Client 1. Create an UDP socket, new client CTX, SSL. 2. Do SSL_connect, if success, start a new thread waiting response data. 3. Send data (SSL_write) in main thread. The above code is worked if I have only ONE client connects to the server, send, recv ok between that client and server. But if I create new client process, SSL_connect always returns error SOCKET_ERROR_E (tried in both Windows, Linux, and NON_BLOCKING mode). Server do not pass the select() waiting for the second client. I used certs files from wolfSSL source, CTX created success * Server: SSL_METHOD *method = DTLSv1_server_method(); SSL_CTX *ctx = SSL_CTX_new(method); SSL_CTX_load_verify_locations(ctx, "ca-cert.pem", 0); SSL_CTX_use_certificate_file(ctx, "server-cert.pem", SSL_FILETYPE_PEM); SSL_CTX_use_PrivateKey_file(ctx, "server-key.pem", SSL_FILETYPE_PEM); * Client: SSL_METHOD *method = DTLSv1_client_method(); SSL_CTX *ctx = SSL_CTX_new(method); SSL_CTX_load_verify_locations(ctx, "ca-cert.pem", 0); Do not know what I missed here sad
#
touskaProject Admin

[Avatar]
2010-08-23 17:56:22 UTC
You don't specify where and when you're calling connect on the server. connect() on a datagram binds that socket with the peer and keeps wolfSSL from reading data from a different peer. To disconnect() on a datagram call connect() again by connecting to an invalid address, such as a null address or an address with the address family set to AF_UNSPEC (the error EAFNOSUPPORT will be harmlessly returned).
#
afelion

[Avatar]
2010-08-25 06:16:58 UTC
That makes a lot of sense. i have connect after recvfrom Do I need to close server socket, then bind and listen again for each new connection? Because if I using udp disconnect: struct sockaddr addr; addr.sa_family = AF_UNSPEC; connect(fd, &addr, 0); when client re send another data, it SSL_connect still return SOCKET_ERROR_E. I have more question: After writing on the socket, client close connection SSL_shutdown(ssl); close(SSL_get_fd(ssl)); SSL_free(ssl); and the server will be receive a data? because on server, I got SSL accept failed
#
afelion

[Avatar]
2010-08-25 06:30:50 UTC
I also test with your example: ./configure --enable-dtls ./make Run echoserver Run echoclient type GET -> return OK type break type quit Run echoclient again, got yassl error: SSL_connect failed
#
afelion

[Avatar]
2010-08-25 08:36:03 UTC
Sorry for my annoy, but I can not edit my previous post. Above error just because of SSL_shutdown send notify to server. I just remove it. One last question (hopefully): how the server identify clients connected to. For example: 1. Client 1 sends data -> Server accepts 2. Client 2 sends data -> Server accepts 3. Client 1 sends another data -> How server know this client and the client at step 1 are identical (same client). For example: client public key?
#
touskaProject Admin

[Avatar]
2010-08-25 22:16:24 UTC
After you type break on the echoclient you end the session with the server and should do a control-c. Trying to send a quit or the SSL_shutdown is a problem, I'll fix the echoclient for that case. The server can identify the client by the client ip address and client port.
#
afelion

[Avatar]
2010-08-26 02:35:24 UTC
"The server can identify the client by the client ip address and client port. " But connecting port is changed each time a client send data to the server, isn't it? The port is selected automatically by OS?
#
touskaProject Admin

[Avatar]
2010-08-26 16:50:26 UTC
Not if the client connect()s which is about the only way it can guarantee that it's only going to get UDP messages from the correct server during the handshake and data transmission. Do you know see why TLS is the better solution here?
#
afelion

[Avatar]
2010-09-09 10:14:39 UTC
As in #8, I said about implementation of my server/client: using select with non blocking socket, Both run ok, but if a client sends 5~10 packages in sequence (no delay) the server SSL_accept got error (-208), then can not listen to any clients. Do you have any suggestions?

5

(0 replies, posted in wolfSSL (formerly CyaSSL))

#
Hi guys, I'm working on my project for the graduation and i've got interested on doing some weird stuff for my iPhone. Since the graduation is in Information Security and I've already worked with wolfSSL embedded SSL in the past, i'm trying to write a new RNG using the accelerometer of the gadget to be one of the sources of entropy. Does anyone there have any idea how to improve the hole thing? In the end, I'll send all the code to you guys... tks []'s
#
touskaProject Admin

[Avatar]
2010-08-26 16:40:56 UTC
Hi, Good idea. I guess my first suggestion is to use an existing RNG and only use your new entropy source as the seed and only in the case where you have enough entropy waiting, otherwise use the devices default entropy source. In terms of determining whether you're actually getting "random data" I'd start with Knuth's TAOCP Volume 2 Chapter 3. -Todd

#
Hi, I'd like to minimize the amount of RAM that is required by wolfSSL client -- hopefully to less than 28KB. Do you think this is possible? I am compiling in a non-standard environment, and am therefore using #defines to control how wolfSSL compiles. Here are the current #defines that I am using: #define NO_HC128 #define NO_DH #define NO_RABBIT #define NO_RC4 #define NO_DES3 #define NO_MD4 #define NO_DSA #define NO_PSK #define NO_CYASSL_SERVER #define SIZEOF_LONG_LONG 8 #define NO_FILESYSTEM #define NO_WRITEV Maybe there are other compile options that I should try? The big memory hog seems to be the SSL structure -- I cannot seem to get it below 40688 bytes in wolfSSL 1.5.4. I saw a suggestion in another form post of using dynamic buffers for the input / output streams. It seems like this wouldn't necessarily guarantee a smaller memory footprint (it would still be possible for wolfSSL to be attempting to receive/send 16K, in which case the same amount of memory would be required, right?). Maybe there is a way to make wolfSSL use the same input and output buffer? Any thoughts that you have will be greatly appreciated. Thank you, Eric
#
touskaProject Admin

[Avatar]
2010-07-19 17:35:33 UTC
Hi Eric, You're right nearly all of the memory is from the in/out buffers, 18,953 each. wolfSSL used to only use dynamic memory but at the request of users and for speedup static buffers were used instead. If you control both ends, or know for sure the max size of each record you will face, you can lower the buffer size by playing with #define BUFFER16K_LEN RECORD_HEADER_SZ + MAX_RECORD_SIZE + \ MAX_COMP_EXTRA + MAX_MTU + MAX_MSG_EXTRA in cyassl_int.h. Which reminds me, MAX_COMP_EXTRA is only used if compression is built in and MAX_MTU is really only used if sniffer mode is being used. That define needs to change to reflect that, you can remove both and save yourself 5k right there. 2 x (1,000 + 1,500). Now RECORD_HEADER_SZ and MAX_MSG_EXTRA (padding + MAC) should stay as they are but that's only 73 bytes. But you can lower MAX_RECORD_SIZE if you're not doing bulk data transfer, it's currently 16,384, the max raw data length of each SSL record. wolfSSL could be changed to only use one buffer for both input and output though it's not set up that way right now. Each buffer makes slightly different assumptions about itself and logic would need to be added to make sure each buffer is emptied before trying to use the other. For example, the client receives 10K from the server, but reads in 5k chunks and wishes to respond after reading the first chunk. Not easily possible with only one buffer. I think it might be best to abstract the input / output buffers. Make each a pointer that can point to a static buffer depending on build options, can share a buffer depending on build options, or even let the user control the buffer (not sure how much at this point). Any other ideas? What do you think? -Todd
#
elsevers

[Avatar]
2010-07-20 01:28:31 UTC
Hi Todd, Thank you for all of your insight! I like your idea of abstracting the input / output buffers and having build options to allow the user to have some control -- I think this would give wolfSSL a lot more portability to memory constrained systems if the user could somehow implement the input / output buffers in serial RAM. My max record size is 1K. However, I am not sure how large MAX_RECORD_SIZE needs to be to complete the SSL handshake (certificates and key exchange, etc). Do you have any thoughts on this? Do you think I can get by with MAX_RECORD_SIZE of 4K? Thanks, Eric
#
touskaProject Admin

[Avatar]
2010-07-20 20:18:43 UTC
Hi Eric, It depends on the servers you're connecting to and the certificates they're sending during the handshake. If the max data record size is 1k the only SSL record that can be bigger than that is the certificate record, which could be infintely large split into 16k SSL records. But typically, 1 - 3 certificates are sent with an average of say 1,250 bytes. So while 4k is probably fine I'd recommend 6k or even 8k to be safe. That still saves you 16k (8k x 2 buffers) + 5k from the other defines above for a saving of 21k. I'll post back after the buffer changes are made. Another idea occurred to me which is to have an option for small static buffers, configurable but defaulting to 1 or 2k, and then using dynamic memory when a larger record comes in for a certificate chain or a large data message. Does that work?
#
elsevers

[Avatar]
2010-07-21 01:16:17 UTC
Hi Todd, Great -- thanks the advice. I think 8k buffers will be sufficiently small for me. I like your latest idea best for the buffers. It seems that this will give the best of both worlds -- high speed for packets < 1 or 2k, and much smaller memory usage in the event of a large packet so long as the send and receive buffers do not simultaneously need to be large. This would certainly work well for my application. Cheers, Eric

#
Hi, I can't seem to get stunnel-4.31 to compile against cyassl-1.4.0. As per README file, I compiled cyassl-1.4.0 with: ./configure --disable-shared --enable-opensslExtra --enable-fastmath --without-zlib make make openssl-links And compiled stunnel-4.31 with: ./configure --with-ssl=/root/diablo/cyassl/cyassl-1.4.0 make I get these errors: prototypes.h:115: error: expected specifier-qualifier-list before ‘ENGINE’ prototypes.h:278: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token I played with <cyassldir>/include/openssl/engine.h and added "#undef HAVE_OSSL_ENGINE_H", thinking that cyassldir's "#undef HAVE_OPENSSL_ENGINE_H" was a typo. That got me a step further, but I ended up with a bunch of errors relating to incomplete type: ctx.c: In function ‘sess_new_cb’: ctx.c:402: error: dereferencing pointer to incomplete type ctx.c:403: error: dereferencing pointer to incomplete type ctx.c:403: error: dereferencing pointer to incomplete type ctx.c: In function ‘sess_get_cb’: Upon inspection, I don't see SSL being completely defined anywhere in the openssl compatibility API. Am I missing something? Just for sanity, I downloaded the stunnel-cyassl.tar.gz file and tried to get that to compile but ended up with the same errors. How did you get that to compile?
#
touskaProject Admin

[Avatar]
2010-02-24 00:21:30 UTC
Hi, I just built CyaSSL 1.4.0 with stunnel 4.31, steps: For CyaSSL 1) ./configure --disable-shared --enable-opensslExtra --enable-fastmath --without-zlib is no longer needed as it is now off by default 2) make 3) make install may need sudo make install, default is /usr/local/cyassl For stunnel 1) ./configure --with-ssl=/usr/local/cyassl 2) Makefile changes a) remove def for HAVE_OSSL_ENGINE_H=1, needs to be cleaned up b) change -lssl -lcrypto to -lcyassl (ideally should work without this change but sometimes system openssl is picked up first and causes linker problems) 3) Move two definitions out of version #ifdef in prototypes.h since stunnel uses them whether defined or not a) ocsp_addr b) ocsp_path These are both in LOCAL_OPTIONS and can just be moved a couple lines above the SSLEAY_VERSION_NUMBER , needs to be cleaned up 4) comment out all calls to cache_transfer() in ctx.c since CyaSSL handles these internally and because CyaSSL uses opaque typedefs that aren't defined at the API level (only internally), needs to be cleaned up -- use function calls instead of deference. Potentially the DEFAULT_STACK_SIZE may need to be increased when using fastmath. On OS X for example, a value of 90,112 fixes stack corruption. Let me know if you have any questions. I'll submit a request to have these changes placed in a new stunnel so that CyaSSL can be used without changes.
#
stevef67

[Avatar]
2010-02-24 02:53:29 UTC
Thank you touska. Got it to compile with those instructions. I would like to get the cache_transfer() working to get remote session caching. All it needs is to be able to get access to ssl->ctx, but the SSL structure is not completely defined at that point in ctx.c. I notice that the SSL typedef is defined in <cyassldir>/include/cyassl_int.h, but is not included in any of the openssl compatibility layer include files. Manually including cyassl_int.h would just throw up errors.
#
touskaProject Admin

[Avatar]
2010-02-24 18:42:50 UTC
Glad it worked, forget to mention commenting out print_stats() too but it looks like you figured that out. It's not quite as simple as just exposing the CTX pointer in SSL. SSL_SESSION has a couple of dereferences too, session_id and session_id_length. And every app that's ported has a couple more... yaSSL started with the goal of the most basic API functions compatibility. Not source and type compatibility which was impossible anyway since yaSSL is in C++. It also gives the user less ways to shoot themselves in the foot. wolfSSL continued this and I believe leaving the type definitions internal is the correct choice. Especially since OpenSSL types are supposed to be used as if the type is incomplete, i.e., dereferencing isn't needed since API calls exist to retrieve those values. In this case, SSL_get_SSL_CTX() and SSL_SESSION_get_id() provide the 3 values (get_id gets both the session and length). Adding those to wolfSSL and getting stunnel to use them is just a matter of coordination. I'm not sure a remote session cache is a great idea. That's exposing the master secret to the wire (or even wireless). Anyone with the master secret can decode the entire session. Seems like a lot of risk. What's wrong with CyaSSL's internal cache? I guess I'm asking why is a remote session cache important?
#
olistudent

[Avatar]
2010-03-27 21:40:00 UTC
Hi. Is there a patched version of stunnel-4.31 with wolfssl support available? Or can anbody of you provide a patch?
#
olistudent

[Avatar]
2010-03-28 10:44:34 UTC
Okay, my colleague was faster. If anybody is interested the patches can be found here: http://trac.freetz.org/browser/trunk/ma … el/patches However not all of them are related to this topic. You should provide the environment variable "OPENSSL_ALTERNATIVE=cyassl" during configure to get it running. Regards Oliver

2009-12-02 10:02:38 UTC
Does this http://www.mozilla.org/projects/securit … y-cbc.html or this http://cve.mitre.org/cgi-bin/cvename.cg … -2003-0078 apply to wolfSSL embedded SSL?
#
touskaProject Admin

[Avatar]
2009-12-03 00:37:41 UTC
The first attack isn't possible with wolfSSL since a general fatal alert is sent in this case instead of a more specific error that could potentially leak timing information. The second one doesn't affect wolfSSL since a MAC computation is done independent of padding errors, preventing the timing attack entirely.
#
sergii

[Avatar]
2009-12-03 09:56:23 UTC
Great! Thanks, Todd!

#
Using wolfSSL, is there a way to "tell" it to try and reuse recently negotiated Session ID?

I am noticing (on the server side, tomcat) that a lot of SessionID objects are cached but never actually reused. When I am doing the same with a standard browser, I notice that the same SessionID objects are reused.

Thanks!
#
touskaProject Admin

[Avatar]
2007-11-20 17:42:43 UTC
Yes, wolfSSL can reuse SessionIDs. The keys are SSL_get_session() and SSL_set_session(), see client.c in wolfSSL Home/examples/client.c, specifically the code under TEST_RESUME idfefs to see usage.

#
yuvalperlov

[Avatar]
2007-11-26 10:39:24 UTC
I am not so clear about the life cycle of the SESSION_ID pointer...

When is it freed? Is it safe to use forever? If I am connecting to many servers or to one server that looses the cached server id from time to time, will memory consumption grow infinitly?

Yuval
#
touskaProject Admin

[Avatar]
2007-11-26 21:02:51 UTC
Sessions are valid for 500 seconds. They are not freed until they are asked for when expired or when the context is freed. You can turn the session cache off by calling SSL_CTX_set_session_cache_mode() with a mode of SSL_SESS_CACHE_OFF.

I'll add SSL_flush_sessions(), which you can call to remove stale sessions.
#
yuvalperlov

[Avatar]
2007-11-27 07:31:41 UTC
Makes sense. However, wouldn't it be best if all this was hidden from me and you would cache the host:port->sessionid internally and try to reuse it within the 500 second limit? I am guessing most if not all users will implement an extremly similar mechanism.
This would also give you more control over freeing them up since you will not have to worry about users keeping a pointer to your internal objects.

Yuval
#
touskaProject Admin

[Avatar]
2007-11-27 20:14:25 UTC
I can see that point. I started trying to push the yaSSL API initially but everyone wanted to use the OpenSSL API as it's become the de facto standard, and they expect similar behavior as well. So with wolfSSL that's the only API I went with. No sure why the design is this way except that maybe the user has a better idea about whether resumption will be necessary, and not all users want to pay for getpeername(), locking the session cache, searching for the match, and comparing the time. That said, I could implement that behavior if the user turns it on, maybe something like SSL_try_resume() before a call to SSL_connect(). Would that be useful?
#
yuvalperlov

[Avatar]
2007-11-27 22:11:22 UTC
I believe the time scale of getting an SSL handshake going, is in an order of magnitude that makes the local function calls and contention negligible. I believe you are right though in making sure the default behavior is as openssl-like as possible. Java has this feature turned on by default and the downside I perceive is that you can't control the cache size and if you have many concurrent clients it can grow to some scary numbers.

Anyway, adding an explicit set-option function to get this behavior will be extremly useful and will result in less wrapper code on our side.

Thanks!
Yuval
#
yuvalperlov

[Avatar]
2007-12-19 10:05:59 UTC
Is there a target version/date for this feature?
#
touskaProject Admin

[Avatar]
2008-01-07 21:47:55 UTC
It's on our list for the next release, approx. Jan 21st.
#
touskaProject Admin

[Avatar]
2008-02-06 18:05:12 UTC
Well, I started implementing a host:port hash table for session IDs until I ran into a problem. A client can, and often does, have multiple connections to the same server (and port). Not only that, but if the client has only one connection at a time but has connected multiple times which session is trying to be resumed. The standard also mentions using session IDs as the key for resumption and I'm not so sure handing these out on a host:port request isn't a security problem.

Any ideas?
#
yuvalperlov

[Avatar]
2008-02-06 21:27:15 UTC
When I am running in "implicit cache mode", how can there be more than one session id? In other words I don't see how the question "which one am I trying to resume" is valid - there is only one session per host:prot no matter how many times I reconnect (provided they are within the cache time).

For concurrent sessions, there seems to be a need to protect the cache with a mutex and arrange it so if two threads are connecting at the same time to the same host:port, one will wait to use the id the other negotiates. However, I think it is good enough to have one override the other for the sake of simplicitly on your side. The cost of one more negotiation in this rare occurance is neglectable (of course the whole cache should be mutexed to avoid memory corruption).

I don't see how this could be a security issue - until you implement this in the library, your users have to implement the exact same mechanism in wrapper code, with the exact same logic - there is no other "key" I can use except the host:port because all other information is opaque for me.
#
touskaProject Admin

[Avatar]
2008-02-06 22:29:32 UTC
Are you saying that concurrent connections always use the same session ID? A web browser with multiple windows, tabs, etc., is going to have several sessions going to the same site from the what I've seen. Same with routers, databases, and set tops, at least as our clients are using it.

I agree that concurrency itself isn't a problem as a mutex will be used.

There may not be a security issue, I don't know. I was just hesitant to include it without more research since the standard recommends using the session ID as the key. This key serves as verification of having gone through the security of the initial connection, without it, we may be opening some hole. I'll look into it some more and see what others have done.

Thanks for the input.
#
yuvalperlov

[Avatar]
2008-12-03 09:11:23 UTC
Does SSL_get_session increment the use count for the session?

If not, how is the SSL_SESSION not freed as part of SSL_free?
Once I reuse it, is it freed up or do I need to free it again?

I didn't notice any indication in client.c for handling this one way or the other.
(Noticed that in openssl there are two versions for this, one that increments the other doesn't)

If the session was not reused, will the connection still succeed or do I have to retry without calling SSL_set_session?
#
yuvalperlov

[Avatar]
2008-12-03 13:13:51 UTC
More on the subject - if I restart the server (Tomcat) between two consecutive hits while trying to reuse the session, it fails and what's more it takes a full minute (exactly 60 seconds) before I get back an error (SOCKET ERROR 208).

Can anyone shed some light on the matter?

Yuval Perlov
#
yuvalperlov

[Avatar]
2008-12-03 13:21:01 UTC
Also, very sorry for repeating the life cycle question ... please disregard
#
touskaProject Admin

[Avatar]
2008-12-03 19:11:24 UTC
There is no use count in wolfSSL's implementation. When a match is found the SESSION pointer's data is copied locally. In wolfSSL 0.9.9x the SESSION pointers are stored on a static list, they aren't freed until they expire, they're flushed, or by calling FreeCyaSSL(). You can reuse them as many times as you like within the timeout.

In wolfSSL 1.0+, not quite ready for release yet, SESSIONS are stored in a compile time fixed size table. They can also be turned off altogether at compile time.

In either version, if the resumption attempt fails, normal connection semantics are automatically employed by the protocol. No action is needed from the user.
#
elsevers

[Avatar]
2009-11-16 01:15:09 UTC
"In either version, if the resumption attempt fails, normal connection semantics are automatically employed by the protocol. No action is needed from the user." Does this mean that if wolfSSL is behaving as a client resuming a session to a server (who has flushed out the session due to a time expiration), that the wolfSSL client (whose cached SSL session is still believed to have not expired) will successfully negotiate the connection without any effort from the user? I am trying to speed up connections to a server that claims to cache sessions for up to 24 hours. However, I have been hesitant to change the value of DEFAULT\_TIMEOUT to reflect this because I do not want to impair my wolfSSL client's ability to connect to other servers that do not have this extended cached-session life. From what you say above, it sounds like I can go ahead and change DEFAULT\_TIMEOUT to 24 hours and I will not notice any ill effects?

2009-11-12 20:17:01 UTC
Hi! We’ve been getting a number of questions about the high profile vulnerabilities in OpenSSL, GnuTLS, NSS and mod_ssl. This vulnerability is based on a potentially insecure SSL early feature that yaSSL chose to never support in the first place. As such, yaSSL was never insecure. More details on the issue can be found below: From CVE: http://cve.mitre.org/cgi-bin/cvename.cg … -2009-3555 “The TLS protocol, and the SSL protocol 3.0 and possibly earlier, as used in Microsoft Internet Information Services (IIS) 7.0, mod_ssl in the Apache HTTP Server 2.2.14 and earlier, OpenSSL before 0.9.8l, GnuTLS 2.8.5 and earlier, Mozilla Network Security Services (NSS) 3.12.4 and earlier, and other products, does not properly associate renegotiation handshakes with an existing connection, which allows man-in-the-middle attackers to insert data into HTTPS sessions, and possibly other types of sessions protected by TLS or SSL, by sending an unauthenticated request that is processed retroactively by a server in a post-renegotiation context, related to a "plaintext injection" attack, aka the "Project Mogul" issue.”

2009-08-27 15:09:21 UTC
Hello all,

I'm using wolfSSL for application i'm building. Atheros embedded board should connect to a PC and exchange information.

My PC runs as server. If I use another PC as client communication is successful. However, when I run the client part from the Atheros board i get FATAL_ERROR (-1) from SSL_connect on the board and SSL_Accept on the server.

I can not use SSL_VERIFY_NONE as the README suggests because i actually use the subject information in my application.

Can point possible problems/solutions. I use wolfSSL 1.0.6 with opensslExtra, without-zlib on Linux (Ubuntu 8.10, i686) and Linux (OpenWRT 8.09, mips).

Thank you very much in advance.

Ivo
#
touskaProject Admin

[Avatar]
2009-08-27 17:33:51 UTC
After you get the -1 from SSL_connect on the board call SSL_get_error(ssl, -1) to see what the actual error in this case is.

Are you using a CA-certificate on the board? How are you loading it?
#
ivovachkov

[Avatar]
2009-08-28 08:20:01 UTC
Thanks Todd.

Following your advice i found out the problem. Apparently after a fresh build and with internet connection the board/linux starts counting time from Epoch ... which makes my certificates invalid. Simple ntpdate fixed the problem.

Moral of the story: Always check what time you 'live' in smile

Thanks again.

12

(0 replies, posted in wolfSSL (formerly CyaSSL))

2009-04-01 16:30:33 UTC
Hello, I noticed in AesSetKey() in aes.c that the key length is restricted to 16, 24 or 32 bytes.

I naively thought that an AES key length might be longer, like 256 or 4096. What have I misunderstood something about AES and/or the ctaocrypt API?
#
touskaProject Admin

[Avatar]
2009-04-01 19:54:10 UTC
The AES standard supports AES-128, AES-192, and AES-256. Those are key sizes in bits, which correspond to byte sizes of 16, 24, and 32 respectively.

Public key algorithms will use longer keys in the thousands of bits to represent huge numbers that are factors of other huge numbers. But block cipher key sizes are the actual length of the key. Even AES-128 has 2 ^ 128 different possible keys!

Hello Guys,

I am trying to add wolfSSL to FreeRTOS. I have FreeRTOS running on STM32 cortex M3 evaluation board. And, I also have a small webserver running on the STM32. Now i am trying to add the wolfSSL into FreeRTOS. I am using "Keil" compiler to run. I am not sure that i can use all the make files and the./configure files to start with.

My question here is, how to port the wolfSSL to a generic micro controller. Without using any ./configure and make files.

Any feedback would be really appreciated.


Regards
Kishore Srimat

#
touskaProject Admin

[Avatar]
2009-02-03 19:12:52 UTC
Are you sure ./configure doesn't work? You might want to try compiling the embedded SSL library, otherwise you can do this:

source files = cyassl/src/*.c and cyassl/ctaocrypt/src/*.c

include files = cyassl/include*.h and cyassl/ctaocrypt/include/*.h

defines:

define BIG_ENDIAN_ORDER if the processor is big endian otherwise wolfSSL defaults to little endian.

define SIZEOF_LONG to its length in bytes and SIZEOF_LONG_LONG too, e.g.,

#define SIZEOF_LONG 4
#define SIZEOF_LONG_LONG 8

define SINGLE_THREADED unless you have a pthreads package available. This is only for locking the session cache and shouldn't affect clients.

Let me know what comes up.

2008-12-04 09:46:40 UTC
I am using wolfssl to connect to a Tomcat server.
If I don't try to reuse the session id everything works fine.
When a session id is no longer valid wolfssl just negotiates a new session id, no problem.
However, when I restart tomcat in between two wolfssl calls (while trying to reuse the ID), the SSL_connect call hangs until the tomcat servers times it out (or in case of a non blocking implementation SSL_connect asks for more data which never arrives).

This does not happen with an apache server however other SSL implementations do not have the same issue with Tomcat.

Can you throw a few ideas about what can be the root cause for this and how can I go about debugging? I'd be happy to troubleshoot and "dive in the code" but will need a few pointers on where to start looking.

Yuval
#
touskaProject Admin

[Avatar]
2008-12-04 20:18:14 UTC
It sounds like the Tomcat server is trying to resume a session even though it no longer has context for it. Unless wolfSSL gets an error from the server it has no idea what's going on, eventually the socket call times it out. Not sure how the other implementations are catching this unless they're setting up their own timers to override the tcp ones. Are you sure the other ones are correctly sending the session ID in the client hello to try and resume?

Can you send me a wireshark trace of the wolfSSL failed connection attempt and also one of a different implementation successfully connecting after a hard reset while trying to resume? That may shed some more light on it for us.

Thanks.

#
I'm trying to get yaSSL building with libcurl but I'm getting some errors:
error: 'BUF_MEM' undeclared (first use in this function)
error: 'ASN1_OBJECT' undeclared (first use in this function)
error: 'X509_EXTENSION' undeclared (first use in this function)

and others. I've scoured the yaSSL code and can't find anything to define these, is this new functionality that just hasn't made it to yaSSL yet or old functionality that has been deprecated?

Thanks for your time.
#
touskaProject Admin

[Avatar]
2008-12-03 22:48:42 UTC
Hi Jeff,

Sorry for the delay, I guess I missed the notice of your post.

The missing functionality is neither new nor deprecated. It's existing OpenSSL functionality that recently made it's way into libcurl. We'll have to update yaSSL to support these features.

2008-09-24 21:00:57 UTC
Does wolfSSL 0.9.9 support EV SSL certificates?

when i try a ssl_connect to loginnet.passport.com i get an ssl_failed error .... in beup (msn for nds).
troubleshooting this gave a error in ssl.c:

" /* get response */
while (ssl->options.serverState < neededState)
teller= ProcessReply(ssl);

if ( (ssl->error = teller) < 0) {
CYASSL_ERROR(ssl->error);
return SSL_FATAL_ERROR;}
"
So i think something goed wrong in cyassl_int.c:

int DoProcessReply(SSL* ssl)
which calls e.g.DoProcessReply
I expect the error to occure in there..

the CYASSL_ENTER("ProcessReply()"); and CYASSL_MSG( functions do not give any info on a nds...

I'm not a c++ guru so i have a problem to find what's wrong.
i traces the ssl traffic with wireshark...

you can download the file there:
http://filetrans.be.getronics.com/downl … mp;lang=en

(until 2008-10-04 )
Can someone please tell me what's going wrong?
Is it the EV SSL cert?
Is it a changed ca?
Is it a cipher which is not supported?
Please explain why you conclude this...

thx
Bas





#
touskaProject Admin

[Avatar]
2008-09-24 21:49:30 UTC
wolfSSL supports the certificate just fine. If you go the examples/client directory you can test this on Linux, Windows, or whatever by typing:

./client loginnet.passport.com 443

The server doesn't like the GET format but the SSL connect works and the encrypted response from the server is printed.

Did you change any other lines in wolfSSL? What error are you getting? You never say. wolfSSL isn't written in C++, it's all C.

From the packet capture it looks like you are shutting down the SSL session before you get a response from the server. The client hello is sent in packet 4 at time .3. The next SSL traffic is the client sending a close notify alert (shutdown) at time .8 packet 15. This is before the server even replies at time 1.1 packet 22.

Are you using non-blocking sockets and not restarting the call to SSL_connect?

#
bashendriks123

[Avatar]
2008-09-26 06:25:26 UTC
i tested the code with a wolfSSL 0.9.9 fresh download to see what i needed to change to get it to work.
First i compiled the cyassl 0.9.9 code with visual express 2008 and tested ./client loginnet.passport.com 443
When i changed the lines :
// if (SSL_CTX_load_verify_locations(ctx, caCert, 0) != SSL_SUCCESS)
// err_sys("can't load ca file");
in client.c it worked ok, otherwise i got an can't load ca file error message.

But when i compiled the code in beup (msn for nds) i had to change ctaocrypt\source\random.c because it doesn't know how to compile sleep:
// if (sz)
// sleep(1);

then i get indeed an "TLSv1 Record Layer: Alert (Level: Warning, Description: Close Notify)" because in ssl_connect i get an error in ssl.c on:
case CLIENT_HELLO_SENT :
neededState = ssl->options.resuming ? SERVER_FINISHED_COMPLETE :
SERVER_HELLODONE_COMPLETE;
/* get response */
while (ssl->options.serverState < neededState)
if ( (ssl->error = ProcessReply(ssl)) < 0) {
CYASSL_ERROR(ssl->error);
==> this line ==> return SSL_FATAL_ERROR;
}
ssl->options.connectState = FIRST_REPLY_DONE;
CYASSL_MSG("connect state: FIRST_REPLY_DONE");

and so the beup program shutsdown the ssl connection.
In cyassl_int.c the int ProcessReply(SSL* ssl)
function/procedure is defined which calls in the same file:
int DoProcessReply(SSL* ssl)
somewhere in these two someting goes wrong....


The ssl connection is being build up from msn.cpp (part of beup) in authenticate:

"static void authenticate() {
int size;
int response, passSock;
sockaddr_in addr;
char *str;
int ip;

debug->append(strRep("MsnAuthTicket"));
sscanf(recBuf, "USR %*s TWN S %s\r\n", buffer3);

passSock = socket(PF_INET, SOCK_STREAM, 0);
addr.sin_family = AF_INET;
addr.sin_port = htons(443);

ip = (strstr(user.account, "msn.com")) ? Msn_IP : Passport_IP;

addr.sin_addr.s_addr = ip;
connect(passSock, (sockaddr*)&addr, sizeof(addr));

urlEncode(user.account, buffer);
urlEncode(user.password, buffer2);

SSL_METHOD* method = 0;
SSL_CTX* ctx = 0;
SSL* ssl = 0;

method = TLSv1_client_method();
ctx = SSL_CTX_new(method);

SSL_CTX_load_verify_locations(ctx, SSL_Certificate, 0);

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

debug->append(strRep("MsnPassConnected"));

==> error occure here ==> if (SSL_connect(ssl) != SSL_SUCCESS) {
debug->append(strRep("MsnSSLConnectFailed"), ErrColor);
notState = State_AuthFailed;
if (loginTab->chkAutoerror.selected) loginTab->connect();
} else {
char redir[25];
strcpy(redir, "/login2.srf");
debug->append(strRep("MsnSSLConnected"));
while (true) {
size = snprintf(recBuf, RecBufSize, Passport_GET, redir, buffer, buffer2, buffer3);
if (SSL_write(ssl, recBuf, size) != size) {
debug->append(strRep("MsnSSLSendFailed"), ErrColor);
notState = State_AuthFailed;
break;
}
recBuf[SSL_read(ssl, recBuf, RecBufSize)] = 0;

response = 0;
sscanf(recBuf, "%*s %d", &response);
if (response == 302) {
str = strstr(recBuf, "Location:");

debug->append("Got a 302 transfer. Support for this is still buggy.");
debug->append("If authentication fails, please report this location to the boards:");
debug->append(str);

notState = State_AuthFailed;
break;
} else break;
}
}

if (notState != State_AuthFailed) {
if (response == 200) {
str = strstr(recBuf, "from-PP");
sscanf(str, "from-PP='%s", buffer3);
*index(buffer3, '\'') = 0;
notState = State_Authenticated;
debug->append(strRep("MsnAuth200"));
} else if (response == 401) {
debug->append(strRep("MsnAuth401"), ErrColor);
notState = State_AuthFailed;
}
}
Print("<<%s", recBuf);

==> shutdown ssl occures there==> SSL_shutdown(ssl);
SSL_free(ssl);
SSL_CTX_free(ctx);
close(passSock);

recBuf[0] = 0;
recSize = 0;
bufferWaiting = false;
}

"


Can you please tell me:
-does the change in random.c have an effect on the alert.notify and if yes any idea how to fix this?
-any idea why the ssl_connect failes?, does it use the correct statements to build up a ssl connection?


With Kind regards,
Bas





#
touskaProject Admin

[Avatar]
2008-09-26 18:12:19 UTC
You shouldn't have to comment out the lines in client.c, that means you're probably running ./client from the wrong directory.

Can you use a different call then sleep() to get the same effect, it probably isn't causing the problem though?

You still don't say what the actual error is. You can either look directly at the value of ssl->error or you need to call SSL_get_error() to get it. Without knowing the actual error it's hard to say what's going on. The code steps are in the right order, though no error checking is being done so something else could be going wrong too.

#
bashendriks123

[Avatar]
2008-09-27 08:29:14 UTC
Well my c knowlegde is not so good, so finding another sleep functon is not so easy but i will try. (if you have a sleep function for me would be great).
I'm compiling on windows and i already have seen some error reflecting on functions which apperently exist in linux code.

When i use error checking then the error of ssl_get_error is a 2 which should be a ssl_read error.
No other errors appear so ssl_connect gives the error.

i will try to read the ssl-> error and getback on that too.

============
char * itoa(int n, char *buff, int radix)
// convert a positive integer n to char *buff
// for instant, this function work with radix <= 10;
// a little change to run with radix > 10
{
int q, r;
int i = 0;
char tmp[33]; // for radix = 2 and 32 bits computer
do{
q = int(n / radix);
r = n % radix;
n = q;
tmp[i++] = 48 + r;
}while(q > 0);
int j;
for(j = 0; j < i; j++){
buff[j] = tmp[i - j - 1];
}
buff[j] = NULL;
return buff;
}

static void authenticate() {
int size, status, erro, ret, ret14;
int response, passSock;
sockaddr_in addr;
char *str;
int ip;
char erro_buf[5];
char erro_buf7[100];
char erro_buf13[100];
char erro_buf14[100];

/* char msg[] = "hello cyassl!";
char reply[1024];
int input;
int msgSz = sizeof(msg);
*/


status = 0;

debug->append(strRep("MsnAuthTicket"));
sscanf(recBuf, "USR %*s TWN S %s\r\n", buffer3);

passSock = socket(PF_INET, SOCK_STREAM, 0);
addr.sin_family = AF_INET;
addr.sin_port = htons(443);

ip = (strstr(user.account, "msn.com")) ? Msn_IP : Passport_IP;

addr.sin_addr.s_addr = ip;
connect(passSock, (sockaddr*)&addr, sizeof(addr));

urlEncode(user.account, buffer);
urlEncode(user.password, buffer2);

SSL_METHOD* method = 0;
SSL_CTX* ctx = 0;
SSL* ssl = 0;

method = TLSv1_client_method();
ctx = SSL_CTX_new(method);

// SSL_CTX_load_verify_locations(ctx, SSL_Certificate, 0);
SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, 0);

ssl = SSL_new(ctx);

if (ssl == NULL) {
debug->append("Could not allocate 'ssl' with SSL_new()\n");
};


//SSL_set_fd - connect the SSL object with a file descriptor
status=SSL_set_fd(ssl, passSock);
if (status==0) {debug->append("Could not connect ssl object with file descriptor");}
else
{debug->append("ssl object connected with file descriptor");};

debug->append("passSock: ");
debug->append(itoa ( passSock, erro_buf7, 10 ));

debug->append(strRep("MsnPassConnected"));

//SSL_connect - initiate the TLS/SSL handshake with an TLS/SSL server
status=SSL_connect(ssl);
ret=status;
debug->append("status (1-10) : ");
debug->append(itoa ( status, erro_buf13, 10 ), ErrColor);

// if (status != SSL_SUCCESS) {
// erro= SSL_get_error (ssl, status);

erro= SSL_get_error(ssl, 0);
debug->append( itoa ( erro, erro_buf, 10 ), ErrColor);

if (erro == 2)
debug->append("... client would read block");
else
if (erro == 3)
debug->append("... client would write block");
else
debug->append("... client neither read nor write");


if (SSL_connect(ssl) != SSL_SUCCESS) {
debug->append(strRep("MsnSSLConnectFailed"), ErrColor);
notState = State_AuthFailed;
if (loginTab->chkAutoerror.selected) loginTab->connect();
} else {
char redir[25];
strcpy(redir, "/login2.srf");
debug->append(strRep("MsnSSLConnected"));
while (true) {
size = snprintf(recBuf, RecBufSize, Passport_GET, redir, buffer, buffer2, buffer3);
if (SSL_write(ssl, recBuf, size) != size) {
debug->append(strRep("MsnSSLSendFailed"), ErrColor);
notState = State_AuthFailed;
break;
}
recBuf[SSL_read(ssl, recBuf, RecBufSize)] = 0;

response = 0;
sscanf(recBuf, "%*s %d", &response);
if (response == 302) {
str = strstr(recBuf, "Location:");

debug->append("Got a 302 transfer. Support for this is still buggy.");
debug->append("If authentication fails, please report this location to the boards:");
debug->append(str);

notState = State_AuthFailed;
break;
} else break;
}
}

if (notState != State_AuthFailed) {
if (response == 200) {
str = strstr(recBuf, "from-PP");
sscanf(str, "from-PP='%s", buffer3);
*index(buffer3, '\'') = 0;
notState = State_Authenticated;
debug->append(strRep("MsnAuth200"));
} else if (response == 401) {
debug->append(strRep("MsnAuth401"), ErrColor);
notState = State_AuthFailed;
}
}
Print("<<%s", recBuf);

SSL_shutdown(ssl);
SSL_free(ssl);
SSL_CTX_free(ctx);
close(passSock);

recBuf[0] = 0;
recSize = 0;
bufferWaiting = false;
}
==================
#
touskaProject Admin

[Avatar]
2008-09-29 05:12:54 UTC
The error you're getting from SSL_connect via SSL_get_error is SSL_ERROR_WANT_READ. This is not just an SSL_read error, this can happen on connect too, like you're getting, because connect reads and writes SSL records. You're getting the error because your socket is non-blocking and the data from the server hasn't arrived yet. Just like the packet capture showed. You need to call SSL_connect again once the data is there. From the man page:

If the underlying BIO is non-blocking, SSL_connect() will also return when the underlying BIO could not satisfy the needs of SSL_connect() to continue the handshake, indicating the problem by the return value -1. In this case a call to SSL_get_error() with the return value of SSL_connect() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. The calling process then must repeat the call after taking appropriate action to satisfy the needs of SSL_connect(). The action depends on the underlying BIO. When using a non-blocking socket, nothing is to be done, but select() can be used to check for the required condition.

The whole page is here: http://openssl.org/docs/ssl/SSL_connect.html

As for Windows code vs. Unix code, if you're compiling for Windows then your compiler needs to define _WIN32, if it's broken (and doesn't) then it will try and compile the Unix code which will obviously not work (like sleep). Which compiler, version, target are you using?
#
bashendriks123

[Avatar]
2008-09-29 07:31:08 UTC
Tod,

thx!!
The ssl connection is made!

I just put the ssl_connect in a while loop.

"//SSL_set_fd - connect the SSL object with a file descriptor
status=SSL_set_fd(ssl, passSock);
if (status==0) {debug->append("Could not connect ssl object with file descriptor");}
else
{debug->append("ssl object connected with file descriptor");};

debug->append("passSock: ");
debug->append(itoa ( passSock, erro_buf7, 10 ));

debug->append(strRep("MsnPassConnected"));

//SSL_connect - initiate the TLS/SSL handshake with an TLS/SSL server
status=SSL_connect(ssl);
ret=status;
debug->append("status (1-10) : ");
debug->append(itoa ( status, erro_buf13, 10 ), ErrColor);

// if (status != SSL_SUCCESS) {
// erro= SSL_get_error (ssl, status);

erro= SSL_get_error(ssl, 0);
debug->append( itoa ( erro, erro_buf, 10 ), ErrColor);

if (erro == 2)
debug->append("... client would read block");
else
if (erro == 3)
debug->append("... client would write block");
else
debug->append("... client neither read nor write");

while (status != SSL_SUCCESS )
// && (erro == 2 || erro == 3)

{
debug->append("in de while loop");
//SSL_connect - initiate the TLS/SSL handshake with an TLS/SSL server
status=SSL_connect(ssl);

erro= SSL_get_error(ssl, 0);
debug->append( itoa ( erro, erro_buf, 10 ), ErrColor);
};


if (SSL_connect(ssl) != SSL_SUCCESS) {
debug->append(strRep("MsnSSLConnectFailed"), ErrColor);
notState = State_AuthFailed;
if (loginTab->chkAutoerror.selected) loginTab->connect();
} else {"

"Which compiler, version, target are you using? "
I' working on winxp sp3, compiling with devkitpro 1.4.7 for nintendo DS so arm 9 (and arm 7) processor.

#
bashendriks123

[Avatar]
2008-09-30 05:58:24 UTC
i'm still not sure if the ssl connection stays ok...
I still see a tls alert message
can anyone see if this is ok or not?

http://filetrans.be.getronics.com/downl … mp;lang=en

with kind regards,
bas hendriks

#
touskaProject Admin

[Avatar]
2008-09-30 20:48:04 UTC
TLS alerts are a normal part of SSL shutdowns, so the question is, did you shutdown the connection? If not, what error did you get? Are you restarting SSL_read() to get all the data you want with non-blocking sockets?

2008-09-16 07:18:56 UTC
I am a newbie in using wolfSSL package.

I have an embedded environment without O.S., so I just use polling method to receive ethernet packets. I have just finish porting wolfSSL to this project, but I found one thing strange in cyassl_int.c, or that code will make the transffered file by wolfSSL incomplete.

In the function ReceiveData() of cyassl_int.c, I need do some modification as follows to avoid data loss:

int ReceiveData(SSL* ssl, byte* output, int sz)
{
... ...
-- if (!ssl->buffers.bufferedData.buffer)
if ( (ssl->error = ProcessReply(ssl)) < 0) {
CYASSL_ERROR(ssl->error);
if (ssl->error == SOCKET_ERROR_E)
{
if (ssl->options.connReset || ssl->options.isClosed)
{
return 0; /* peer reset or closed */
}
}
return ssl->error;
}
... ...
}

In my testing environment, the first encrypted TCP/IP packet contains the HTTP header and a part of HTTP content; if I don't remove the section of code, the part of HTTP header will be decrypted first, and the rest of content will be decrypted after all TCP/IP packets are received. But I will find the last piece of content will be lost finally. If I make that code modification, all HTTP data (include HTTP header and content) will be decrypted just after all TCP/IP packets are received.

I use wolfSSL package on linux as reference with blocking socket IO, and the pattern just looks like the code after modified.

Just want to make a check about the code modification to see if there is still some issue or not.

Thanks for all.
#
touskaProject Admin

[Avatar]
2008-09-16 18:39:23 UTC
Are you sure all of the SSL records were received when you don't remove the line? What SSL error are you getting then or after? If you're not getting one then I can't imagine it wasn't processed. Say 2 SSL records are being sent by 20 tcp packets. If any of the 20 packets aren't processed in the right order there will be a decryption error.

There could be some interaction here between the TCP stack and how wolfSSL is processing SSL records compared to what you might expect. When wolfSSL decrypts an SSL record it puts any unrequested data in a buffer. On the next call to SSL_read (assuming the original code) read will return the buffered data. At this point there could be some TCP packets that have arrived but that wolfSSL hasn't tried to receive yet. Could that be the problem? Are you calling SSL_read again?

Without knowing the SSL_record size, packet size, and your SSL_read parameter size it's hard to say exactly what's happening. Can I access the server and can you show me the SSL_read code you're using?

You can contact me directly ( todd at yassl.com ) if you don't wish to post the server information.

Thanks.

How do i troubleshoot an ssl connection when it's using cyassl?
I cannot use ssl_get_error
I cannot use SSL_set_connect_state
i cannot use BIO options
.....
What can i use and can you please give me an example.
I'm using c++

And is there maybe a way to add extra options to wolfssl?


With kind regards,
Bas Hendriks
#
touskaProject Admin

[Avatar]
2008-09-11 19:09:23 UTC
There are several ways you can troubleshoot a wolfSSL connection; print out error codes, capture SSL packets, connect with an SSL program you know better to see their error code...

Why can't you use SSL_get_error()?

If you wan't C++ and more OpenSSL compatibility you should try yaSSL. SSL_set_connect_state() is there. Otherwise you can manually set your method object on creation with one the functions like TLSv1_client_method().

What BIO options do you need for an SSL connection? If it's non-blocking you can set that on the socket directly.

There are plenty of examples in the examples directory showing clients, servers, non-blocking, testing error-codes, and the like. Please take a look at them.

Feel free to add options to wolfSSL or you can make a case why an option should be in an embedded ssl product. That is, something that can't easily be done another way and provides desired functionality. We're happy to add options but we're also concerned with keeping the product very small, so there's always a trade off.

when will wolfSSL be released with PSK support?
#
touskaProject Admin

[Avatar]
2008-07-21 17:15:35 UTC
The release is being finished up right now. It should be ready this week!

Hello I have few problems to report with cyassl. 0.9.6

Problem 1:

Default setting for SSL_CTX_set_verify per OpenSSL should be SSL_VERIFY_NONE, and this is not what is set in cyassl. See this for refernce: http://publib.boulder.ibm.com/infocente … erify.html


Problem 2:

Using cyassl with HTTP 1.0 connection. In this case client needs to poll until connection is closed. The problem is that on connection end SSL_read should return 0 and in cyassl it always returns error -208.

After some looking through the code I found out that the problem seems to be in recieve function that treats connection closure as error, and connection reset which is the error as not error. This seems to be incorrect.

I would greatly appreciate if you could fix both issues.
#
touskaProject Admin

[Avatar]
2008-05-05 20:28:41 UTC
Hi Boris,

Problem 1: I can't in good conscience default CyaSSL's behavior to SSL_VERIFY_NONE. We only provide a compatibility layer and it's not perfect. In fact, I'd argue our choice is much better. Why have a default behavior for secure sockets that provides no more real security than plain sockets? Why place the burden on the user to do all this checking themselves? And, if you want to mimic OpenSSL behavior we allow this, you just have to be explicit. I haven't heard a good argument to change this policy yet, but feel free to try.

Problem 2: Thanks for the report. You are right, during SSL_read (but not the handshake) socket closure should return 0 and not an error. Even though the standard says this is an error (SSL shutdown should occur first) I'll go along with the OpenSSL man page on this one. But I think socket reset (usually machine reset or network reset and thus not able to do an SSL_shutdown) should also return 0. So I'm going to leave reset as it is unless you can tell me why this is incorrect. I'll check in the closure change by the end of the day.

Thanks for the feedback and reports,
Todd
#
borkraAccepting Donations

[Avatar]
2008-05-06 01:29:53 UTC
Hi Todd,

thanks for fixing issue #2.

Let me try to lay down my case for changing the behavior for both problems.

Problem #1:

Yes you are right default none is insecure. But the problem is if default is not none, you cannot establish SSL connection by default. Certificate was never validated and connection was aborted (and this is a real problem). So as a result I had to spend few hours chasing SSL API trying to figure out why and what is the issue. A lot of people would just cast your library by that time and move on elsewhere. Mimicking OpenSSL brings a lot of value to your library as one could replace existing code using OpenSSL with your stuff in 5 min there is a lot of value in that.

Problem #2:

If connection was reset there is no connection any more, so what SSL_shutdown going to do? Try to reestablish the connection and send a shutdown message? Chances are server will not even link 2 connections together. What's gone is gone...

And after looking into your code SSL_shutdown does not even try to reestablish the connection. So I am completely confused what is the purpose for all of this?

Sockets as far as I know close connection when reset received, so you cannot send anything on this socket any more until connection reestablished.
#
borkraAccepting Donations

[Avatar]
2008-05-06 01:48:35 UTC
Todd,

More on problem #2:

I forgot to mention, that if I am doing HTTPS 1.0 and received 0 - connection closed it means that all data recived, on the other hand if I got error that means I did not get any data or got partial data, my response to this 2 events would be completely different. I 1st case I would process the data in the 2nd case I would ignore it. I hope you see the difference.
#
touskaProject Admin

[Avatar]
2008-05-06 19:21:44 UTC
Connection closed doesn't necessarily mean all data received in SSL. A conforming stack (and user) will call SSL_shutdown after they've sent all data, only then will you know for sure. A socket closure without SSL_shutdown could merely mean an exception handler was called, or the OS was doing cleanup on process shutdown after a fatal error (while data was still buffered to be sent).

The point I was trying to make was that both connection closed and reset are technically errors if the first peer to stop doesn't first send SSL_shutdown(). Though I agree that partial data is an error. I'll try to make sure that CyaSSL always returns an error in this case. BTW, the reason I have reset behave that way is a report from an embedded SSL user asking for more OpenSSL compliance. Is it your understanding that OpenSSL doesn't return 0 on socket reset for an SSL_read?

Thanks for the help.
#
touskaProject Admin

[Avatar]
2008-05-06 19:31:34 UTC
1: Well, that's my failure for not properly (or more easily) documenting the change. Which ever way this ends up, I need to document this behavior better. That's a good point for compliance, but maybe if I have comments at the beginning of the README, around SSL_connect, and in the examples users won't run into this problem in the future. If they do, you're right, I should change it, but I should document just as much about how this is unsafe and how they should use it.

2: I didn't explain SSL_shutdown() very well I think. I was trying to point out that proper SSL shutdown/closure is to call SSL_shutdown(), not close the socket first. I don't try to send an SSL_shutdown if the connection is closed because it's a socket error to try that, it's just to avoid SIGPIPE. But if the connection isn't closed, then I try to send an SSL_shutdown message even if the peer hasn't (which isn't required but is recommended).

See the rest of my comment on the next post, thanks.
#
borkraAccepting Donations

[Avatar]
2008-05-07 04:50:30 UTC
Todd,

regarding SSL_read. I guess I did not explain what I am trying to do correctly.

I am trying to implement HTTPS 1.0 protocol. It is HTTP 1.0 over SSL tunnel.
HTTP 1.0 works as following: you send a request through socket send (1 or many and then wait for reply) reply message is completed when connection is gracefully closed (socket read returns 0, otherwise http transaction failed). You can read RFC 1945 for information on HTTP 1.0.

In the previous messages I described to you how HTTPS 1.0 was implemented using OpenSSL. And it is working flawlessly for years. I am not clear though how do you propose to implement HTTPS 1.0 over cyassl, this connection reset seems to be a problem. As I do not understand how to distinguish graceful connection closure from not graceful one, as per HTTP 1.0 graceful closure signifies the transmission complete event.
#
borkraAccepting Donations

[Avatar]
2008-05-07 06:21:10 UTC
Todd,

Tried your latest CVS code and got a problem. Cannot establish SSL connection. The error happens in the new DoServerKeyExchange. On line

if (messageTotal > sizeof(messageVerify))
    return BUFFER_ERROR;

If you would like to try it yourself the host is: kc-in-f125.google.com
#
touskaProject Admin

[Avatar]
2008-05-07 18:58:22 UTC
Thanks for the report, I've checked in a fix. I'd never seen Ephemeral DH greater than 1024 bit before, I've added support for up to 2240 bit. If people start going to 3072 or higher I guess I'll make the buffer dynamic, I've just tried to avoid doing that with CyaSSL.
#
touskaProject Admin

[Avatar]
2008-05-07 19:03:53 UTC
Fair enough, let's see if the reset on read is really the problem. Can you change a line in ReceiveData() in cyassl_int.c

from:

if (ssl->options.connReset || ssl->options.isClosed)

to:

if (ssl->options.isClosed)


If that better matches OpenSSL behavior then I'll check it in.

Please let me know if that works, thanks.
#
borkraAccepting Donations

[Avatar]
2008-05-07 23:38:36 UTC
Hi Todd,

Yes thank you, change in cyassl_int.c does make it work.

#
Does wolfSSL embedded SSL support SSL_CTX_use_certificate_chain_file()? If not, how to verify a client's certificate that is signed by manufacturer's CA which was signed by a root certificate like VeriSign?

Thanks.

Peter
#
touskaProject Admin

[Avatar]
2007-01-18 18:49:17 UTC
yaSSL supports SSL_CTX_use_certificate_chaing_file(), but only if it follows the specifications in the man page, i.e.,

"The certificates must be in PEM format and must be sorted starting with the subject's certificate (actual client or server certificate), followed by intermediate CA certificates if applicable, and ending at the highest level (root) CA."

Does the actual client's certificate start the chain? If it doesn't, you'll need to call SSL_CTX_use_certificate_file() for each of the files in the chain that aren't the clients. That is, for Verisign and for the manufacturer's CA in your example.

Hope this helps,
Todd
#
touskaProject Admin

[Avatar]
2007-01-18 18:51:52 UTC
Correction: I was talking about wolfSSL supporting SSL_CTX_use_certificate_chain_file().

Todd
#
moises_phoebus

[Avatar]
2007-09-20 14:26:25 UTC
Hi,

I'm having problems with the certificates chain's verification too.

In the ParserCert() I’ve got a "CyaSSL error occurred, error = -155, ASN sign error, confirm failure"
I'm trying to verify a web site's certificate that is signed by "VeriSign Trust Network" that is an intermediate CA certificate signed by "VeriSign, Inc. Class 3 Public Primary Certification Authority".
#
touskaProject Admin

[Avatar]
2007-09-20 17:39:41 UTC
Hi,

You'll need to first load the root certificate, or at least have it first in the chain. In this case, the VeriSing, Inc. Class 3 one. wolfSSL doesn't load any trusted certificates by default, that's up to you. In the wolfSSL examples, the client loads ca-cert.pem as a trusted root and then verifies that the server's cert, server-cert.pem, is signed by a trusted root. You should be able to find the root on the web or export it from a browser.

Regards,
Todd
#
touskaProject Admin

[Avatar]
2007-09-20 17:43:38 UTC
Hi,

You'll also need to load the intermediate certificate "VeriSign Trust Network". Try doing that first.

Thanks,
Todd
#
moises_phoebus

[Avatar]
2007-09-21 11:24:49 UTC
I have only the VeriSing, Inc. Class 3 one.
#
touskaProject Admin

[Avatar]
2007-09-21 19:48:02 UTC
In order to properly verify it you'll need to load the other one as trusted as well. If your browser can get to the site then you should be able to export the certificate from your browser or find it on the Verisign site.
#
moises_phoebus

[Avatar]
2008-02-21 13:30:15 UTC
This is the situation that I have ...

(C1) +Class 3 Public Primary Certification Authority
|
(C2) +-+www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
|
(C3) +--bankline.itau.com.br

C1 is a root CA (certificate authority), C2 is a intermediate CA and C3 is the certificate of a website that I want to verify its authenticity so I can access it safely.

The only certificate I have to load as a trusted CA is C1, the problem is that the wolfSSL verify the certificate chain in a bottom up way, so, when it will check whether C3 is signed by a trusted authority, it does not recognize the signing of C2 as a signature reliable but if he has checked the identity of the C2 before, he would see that it is signed by C1 that is reliable.

Thus, the verification of the certificate chain should be top down, instead to be bottom up, because in recognizing C2 as a trusted CA, C2 should be added to the list of trusted authorities and C3 will be accepted as a trusted certificate.
#
touskaProject Admin

[Avatar]
2008-02-21 19:49:44 UTC
I believe you do need to load both C1 and C2, or at least C2. Without C2 there is no way to verify that C2 signed C3 or that C2 was signed by C1. If you look at your browser's certificates you'll see that most are non-root authorities.
#
moises_phoebus

[Avatar]
2008-02-22 11:27:59 UTC
In firefox and opera browsers i have C1 and don't have C2... and the certificate chain from C1 passing through C2 to verify C3 works
#
touskaProject Admin

[Avatar]
2008-02-22 20:10:47 UTC
If that's the case, then the server is sending C2 to you, otherwise, it's impossible to verify C3 without C2's public key.

I tried to verify this by going to https://bankline.itau.com.br but it redirected me to http://www.itau.com.br/. I also tried connecting on port 443, do you have a different url or ip address that I can test?

Thanks for the help.

#
moises_phoebus

[Avatar]
2008-02-29 13:16:33 UTC
https://bankline.itau.com.br/Wap/homewap.wml
or
https://200.246.143.202/Wap/homewap.wml

WML Browser extension for Firefox...
http://wmlbrowser.mozdev.org/

2007-12-13 06:19:18 UTC
hello:
I had make client certificate , server certificate and ca. my os is linux.
How can I do verify the server certificate use the wolfssl? Could you give me an example?
thanks.


2008-01-07 21:45:23 UTC
Hi,

Sorry for the delay, I missed this post.

The best example is in examples/client/client.c. The call to SSL_CTX_load_verify_locations() sets the CA you wish to verify the server with. An error code from SSL_connect() may indicate a verification error, e.g., out of date or invalid signature.

Hope this helps,
Todd

2008-01-03 10:18:54 UTC
Hello,

I was trying to do an SSL connection from an embedded arm-linux device to a Custom Server using openssl. I did eventually succeed while doing unit tests, but when I added it to the main code repository the application would simply run out of memory (due to openssl's heavy memory footprint).

I accidentally bumped into yassl and this looks like it's going to be my saviour because wow, the footprint is incredibly small.

But I'm having the following problems:

1.) Latest stable download does not successfully make a connection to the Custom Server. The Custom Server ONLY supports two-way authentication. I do not have access to the custom server code. From reading the forum posts, I gathered that the latest stable does not support two-way authentication which is why I downloaded the latest CVS.

2.) I could successfully compile the latest CVS for arm-linux except the files ssl.c and cyassl_int.c were missing includes for error.h from ctaocrypt. On adding error.h includes to the files it compiles alright. However on connecting to the server and hangs at the following point:

result = SSL_connect(ssl);

It looks like the two-authentication is failing at some point. Where could the problem be? I would gladly want to help on two-way authentication testing and support.
#
touskaProject Admin

[Avatar]
2008-01-03 22:07:26 UTC
Hi,

1) Not sure why you're getting the compilation problem. Both ssl.c and cyassl_int.c include cyassl_error.h which includes error.h from ctaocrypt. Maybe I need to be more specific about which error.h in case you have a system one lying around in the path?

2) I was able to duplicate the problem you're having on a new openssl server. I only tested the client against cyassl, yassl, and an older version of openssl. Looks like I'm sending an error alert or have misformated the client certificate send. I'll figure out the problem, submit a fix, and let you know when it's done. Thanks for the report.

-Todd
#
touskaProject Admin

[Avatar]
2008-01-03 22:31:20 UTC
Hi,

Looks like I spoke to soon. I was sending an error alert, but correct in this case because my test wasn't set up correctly. I didn't have the right CA certificate to verify the server's cert.

yaSSL/CyaSSL differ from OpenSSL in the sense that we consider an unverified certificate an error, one that ends the session. The fix, either load the correct CA certificate to verify or explicitly tell yaSSL/CyaSSL to turn off verification errors with:

SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, 0);

The latter is OK for testing but I don't recommend it for real use. Find out which CA certificates you need, find them on the web or export them from your browser, and load them with:

SSL_CTX_load_verify_locations();

I hope this helps and is the problem you are encountering. If not, let me know.

-Todd
#
wirelessmatrix

[Avatar]
2008-01-04 07:20:54 UTC
Hi Todd,

Thanks alot for your response.

Here's the code I'm using to initialize the context:

SSL_CTX *initialize_ctx(char * keyfile, char * password)
{
SSL_METHOD *meth;
SSL_CTX *ctx;

// Create our context...
meth = SSLv3_client_method();
ctx = SSL_CTX_new(meth);

// Load our keys and certificates...
if(!(SSL_CTX_use_certificate_file(ctx, CLIENT_CERT, SSL_FILETYPE_PEM)))
{
general_error("Couldn't read client certificate file!");
return NULL;
}

if (!(SSL_CTX_use_PrivateKey_file(ctx, PRIVATE_KEY, SSL_FILETYPE_PEM))){
general_error("Couldn't read private Key file!");
return NULL;
}

// Load the CAs we trust...
if (!(SSL_CTX_load_verify_locations(ctx, SERVER_CA, 0))){
general_error("Couldn't read CA List/Truststore for the Server!");
return NULL;
}

SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, 0);

return ctx;
}

And here's the main code:

// Build our SSL context...
general_error("Initializing SSL context...");
ctx = initialize_ctx(PRIVATE_KEY, PRIVATE_KEY_PASSWORD);
if(ctx == NULL){
general_error("ctx is NULL. Exiting!");
exit(0);
}

// Connect the TCP socket...
general_error("Performing a TCP connection...");
sock = tcp_connect();
if (sock < 0) {
general_error("Error with socket. Exiting!");
exit(0);
}

// Connect the SSL socket...
general_error("Doing an SSL connection...");
ssl = SSL_new(ctx);
SSL_set_fd(ssl, sock);
result = SSL_connect(ssl);
//result = MakeMasterSecret(ssl);
if (result <= 0){
fprintf(stderr, "SSL connect error number %hd. Exiting!\n", result);
exit(0);
}

wolfSSL compatibility is good and I've hardly changed anything from openssl except remove the SSL_CTX_set_default_passwd_cb and SSL_CTX_set_verify_depth methods. The SERVER_CA is self-signed. I'll try and dig deeper to find out where the problem is. It could also be that wolfSSL fails to authenticate itself correctly to the Server.

#
touskaProject Admin

[Avatar]
2008-01-07 21:40:42 UTC
Hi,

Removing SSL_CTX_set_default_password_cb() -- because we don't support it in wolfSSL yet of course -- could be the problem here. Is the private key file you're using encrypted? We could add this support, it's in yaSSL, we've just left it out for the sake of size and simplicity so far.

If that's not the problem, is the server accessible to the public. That is, could I test it? If you're having problems debugging the embedded device you could try testing the authentication on a linux box. You could modify the examples/client test by changing the yasslIP, yasslPort, cliCert, cliKey, and caCert in examples/test.h and give it a go. Ideally the behavior is exactly the same smile

Let me know what you find.

-Todd

1.
      charlesxu

      [Avatar]
      2007-02-28 02:30:47 UTC
      Hi,

      Does wolfSSL embedded SSL support the optional authenticating the client to the server? Is there any plan to implement it soon if it doesn't.

      Thanks
      Charles
   2.
      touskaProject Admin

      [Avatar]
      2007-03-01 23:51:04 UTC
      wolfSSL doesn't support client certificate authentication. The basic reason is to keep the size small, yaSSL does support this feature. The other reason is that it's usually much simpler to just do a challenge/response once the handshake is complete. If it's important I can probably add the basics of the feature as a build option.

      Regards,
      Todd
   3.
      charlesxu

      [Avatar]
      2007-03-02 17:58:56 UTC
      I am involved in a project of using security connection for client provisioning. It's crucial that the server be able to auhenticate the client. Other features required are DN verification and chained certificates validation.

      Thanks
      Charles
   4.
      panpipi

      [Avatar]
      2007-03-07 19:12:47 UTC
      Coincidently I also involved in a project that needs server to authenticate clients and requires DN verification and chained certificate validation.

      Peter
   5.
      moises_phoebus

      [Avatar]
      2007-10-18 12:54:20 UTC
      It is important to my project... can you add this feature as a build option like you said?
   6.
      touskaProject Admin

      [Avatar]
      2007-10-23 18:43:23 UTC
      OK, after I finish OpenVPN and stunnel support I'll add client certificate authentication as my next free project for wolfSSL.
   7.
      touskaProject Admin

      [Avatar]
      2007-10-29 23:27:25 UTC
      OK, I've checked in initial client authentication support for wolfSSL. It's available from CVS. Feel free to test and let me know what you think.

1.
      kriegaex

      [Avatar]
      2007-10-01 01:14:52 UTC
      Probably I am asking too much, but I would like to know how realistic it would be to use libcyassl as a drop-in replacement for OpenSSL (libcrypto, libssh) in connection with OpenVPN on an embedded platform (mipsel Linux, kernel 2.6.13.1) featuring BusyBox, /dev/urandom etc. The same question applies to stunnel, but I just pushed another thread concerning stunnel anyway.
   2.
      kriegaex

      [Avatar]
      2007-10-01 01:19:21 UTC
      BTW: The lib cross-compiles without any problems for my platform (mipsel-linux-uclibc), the testsuite is also okay:

      $ ./testsuite
      MD5 test passed!
      SHA test passed!
      SHA-256 test passed!
      HMAC test passed!
      ARC4 test passed!
      DES test passed!
      DES3 test passed!
      AES test passed!
      RANDOM test passed!
      RSA test passed!
      OPENSSL test passed!
      Client message: hello wolfssl!
      Server response: I hear you fa shizzle!
      yassl error: can't open input file
   3.
      touskaProject Admin

      [Avatar]
      2007-10-01 19:07:05 UTC
      I'll spend some time this week getting wolfSSL to compile, link, and run with OpenVPN. I'll update this message when it's ready.