You are not logged in. Please login or register.
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
ReferenceswolfSSL - Embedded SSL Library → Posts by john
You're welcome.
They intentionally undocumented. ECB mode isn't very secure and we encourage use of the other modes.
Most projects don't use them directly. We try to wrap optional code with preprocessor switches to make the build smaller for resource constrained embedded systems.
Calling AesEncryptDirect() and AesDecryptDirect() provide AES-ECB mode.
No. We don't have our own version of BIOs in the our OpenSSL compatibility layer. If you are using basic BIO features, our BIO shims should work. But, trying to peek and poke the innards of the BIOs will not.
wolfSSL is built on wolfCrypt. If you use dead code stripping and don't call any of the wolfSSL code, you're set.
It sounds like you want to only use our cryptography library, wolfCrypt (formerly CTaoCrypt). The wolfSSL library is an application of wolfCrypt. It doesn't sound like you are using SSL/TLS at all.
Signatures for data are usually a hash of the data, and then that data is encrypted with a private key. The other end takes the same data, hashes it and decrypts the signature with the public key, then compares the two hashes. The DsaVerify() function assumes you have your copy of the hash, and the signed hash (the encrypted hash from the peer), and the key.
You'll need to make a SHA-256 hash of the data first. Then you use DsaVerify().
We have two sections in our manual describing data signing. Chapter 12 gives an overview of how signing works. Chapter 10 covers the wolfCrypt cryptography suite with examples.
XMALLOC()'s three parameters are a size, a heap pointer, and a memory type. With the default setup, the heap pointer (ctx->heap) and the type are not passed to the wolfSSL_Malloc() function. If you want to manage separate heaps, and allocate different types of memory out of different pools or heaps, you supply your own allocator that calls different allocators depending on the type. (We have someone who is using that on an embedded processor to allocate the send and receive buffers from a separate heap for large buffers like that.)
I've used top like that on another project years ago for the same reason. Right now I run the example server, example client, or the build test through Valgrind to check for leaks.
Are you passing FIN packets through to ssl_DecodePacket()? The sniffer-sessions should be freed when FIN is received and processed. Part of freeing the sniffer-session is freeing the sslServer and sslClient objects.
We do not using memory pools.
Which version (or GitHub commit) are you using? Are you doing any filtering of FIN packets, or are you allowing the sniffer (ssl_DecodePacket()) to process them. Our sniffer code releases the sniffer session when a FIN packet is received for a src/dst addr/port quad.
Thank you for the patch. I'll incorporate it when I get a chance to look it over.
Your function privateKey.getEncoded() wrapped the key with some extra information indicating it was an rsa private key. I had to strip that out of the file first. I used the shell command
$ openssl asn1parse -strparse 22 -inform DER -in privateKey.der -out pk.derI then called RsaPrivateKeyDecode() with the new key and it parsed the key file. (I modified server.c to load the private key file.)
An alternate is to advance the idx to the start of the key file after that extra header info.
idx = 26;
RsaPrivateKeyDecode(keyDer, &idx, privateKey, sizeKeyDer);It is a little clunky, but that'll load your file. I'd probably reprocess the file with the openssl command line tool to strip out the headers.
The "-strparse 22" advances the ASN.1 parser to the octet stream that is your key. The idx of 26 goes a little further to the actual start of the key. (The extra four bytes are the octet stream ID and the length.)
Please let me know if this helps.
Thanks again. I have pushed this change to our GitHub repository as commit 05f11c4.
Thanks for the catch! I have pushed this change to our GitHub repository as commit ac716c9.
Hey,
I already got the cookie callback to work./* *Creates a simple pseudo Cookie, easy to find in hexdump */ int MyEmbedGenerateCookie(WOLFSSL* ssl, byte *buf, int sz, void *ctx) { int i; for (i=0; i<sz; i++) buf[i]= 0xDADA; return sz; }I was interested in the arguments and the expected return value. What is delivered in buf? I don't use it, but I'm intrested.
buf is the buffer for the cookie value. sz is the size of that buffer. The return value should be the number of bytes written into buf, which should be less than or equal to sz. Note, in the example you provided, 0xDADA is a 16-bit value, but buf(i) is a byte.
It's also interesting now, that everything works fine with DTLS1.2 but I receive an error when I use DTLS1.0, somewhere at the ChangeCipferSpec message. But that's another story which I won't follow up.
KR
Which error are you getting?
Which version of wolfSSL are you using now?
Try:
$ ./configure --enable-static --disable-shared \
C_EXTRA_FLAGS="-arch i386 -mmacosx-version-min=10.4" \
LDFLAGS="-arch i386"I tried this configure line on the latest pull from GitHub and it passed the make test.
CFLAGS was conflicting with something so we added C_EXTRA_FLAGS to cover the items you want to add. (I'm pretty sure that's why your configure is failing to build.) Note, we don't use ZLIB as a flag but we do have "--with-libz" as an option to add; it is disabled by default.
For the cookie callback, I'd still put in something, even if it just copies zeroes in as the cookie.
The read and write callbacks should be replaced. The read callback moves data from the network device into a buffer that wolfSSL provides for processing. (The network device can be a buffer, or a socket, or whatever. The callback context is data you provide to facilitate your function's work. It will have the socket or pointer to the buffer, etc.) The send callback does the same for writes to the network device.
What are you looking for specifically? How to get DTLS working? The RECVFROM and SENDTO callbacks in src/io.c are the model to follow.
Sorry for the delay in getting back to you. We were at RSA last week and some things got lost between the cracks.
Apparently, there is a case where Cygwin's recv() command will return ECONNABORTED, where usually we see some other error code. It looks like it is happening when we're using non-blocking sockets for a particular set of test cases. I'm adding some handling for that error code. We'll be treating it in our EmbedRecv callback like it was closed. (The fix is in our wolfSSL embedded SSL GitHub repository.)
The word "shizzle" is slang for "sure", as in agreement. "I hear you for sure." The term was popularized by the hip-hop singer Snoop Dogg.
I'm running on OSX 10.8 and use Linux in a VM to run Valgrind. If you know what to ignore, you can still run Valgrind under 10.8, but a lot of Apple's runtime code is going to throw errors. For example, all the errors that look like they come from some of their frameworks. (It looks like their Objective-C framework calling conventions.)
I wouldn't use it for pass/fail testing, but it was still helpful to run it to find a problem.
We are looking into some improvements to DTLS starting this week.
Could you possibly send me the code you are testing with? It will make a good test case. Our TLS will reject a session with an out of order error if the handshake messages are received out of order. In DTLS, we are checking the handshake sequence numbers and rejecting out of order messages, and performing retries as needed. If the sequence number is correct, but the actual message is in the wrong order, we aren't rejecting it as out of order. This looks like something that needs to be fixed. Thank you for catching this.
Are you using wolfSSL embedded SSL as both test server and client? Does the server retry sending its flight?
Since there is a retry mechanism in place for DTLS handshaking, we used it to take care of out of order handshake messages; we drop messages with out of order handshake sequence numbers and wait for the retry mechanism to resend the message when its response wasn't received by the other end. In the case you show, the client should have retried its second Client Hello as it didn't get the expected response from the server.
We are planning on some refactoring in the DTLS code in the near future and will take a look into this.
I have update our DTLS code on GitHub. I am a little new to GitHub, but I think you can send us some pull requests, we can take a look at the patches, and incorporate them into our code upon review.
Do you have an expected timeline for that feature?
Is it a matter of days, weeks or longer?
Days.
Even without the 'timeouts' feature, is there a way to force
wolfSSL to resend last handshake packet(s)? Because without
that loosing even a single handshake packet will block
the whole handshake procedure...
Not at the moment. But, the retry should be there soon.
I also had some other issues:
- WOLFSSL_USER_IO doesn't really work with DTLS, because there is no
way to provide alternative to EmbedGenerateCookie function.
- The '-b' option of the 'server' example doesn't work with DTLSThese issues are minor and easy to change - do you accept patches?
Handling an alternative EmbedGenerateCookie function is something we're going to add at a later date, mostly when someone asks about it. It should take too long to add. Patches are welcome.
Finally, OpenSSL provides an additional 'DTLS listen' function,
which is supposed to respond to 'client hello' messages that don't contain a cookie.
For these requests there is no need to generate a new SSL object
and allocate memory - this is supposed to help with DOS attacks.Is there anything similar in wolfSSL? It looks like the first cookie-less
'hello' message changes the internal state of the SSL object,
so it cannot be used for responding to another cookie-less hello message.This most likely will have to be changed anyway to support the 'timeout' feature,
but I am wondering if that feature is considered?Thanks!
It hasn't been considered, yet. But, that's something I'll look at adding.
We don't have that functionality, yet. I'm currently working on it. I'll let you know when I get it checked into our GitHub repository.
I just downloaded the curl source and tried it myself with the same result.
To fix it I had to modify the file configure.ac and change line 1955 from:
AC_CHECK_LIB(cyassl, InitCyaSSL,to:
AC_CHECK_LIB(cyassl, CyaSSL_Init,After that, you need to run autoconf, and then rerun your
./configure --with-cyassl --without-sslThe output of the configure script should tell you which SSL it is going to use, or if it didn't find any SSL.
wolfSSL - Embedded SSL Library → Posts by john
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.019 seconds (88% PHP - 12% DB) with 4 queries