After spending several frustrating weeks on Open SSL, I've recently and gladly learned that there are some alternatives to it. GnuTLS, NSS and yaSSL are alternatives that I'm aware of. Does anyone have experience with these alternatives that they would be willing to share? Thanks in advance. Brian Wood http://webEbenezer.net (651) 251-9384

Quote:Original post by wood_brian

After spending several frustrating weeks on Open SSL, I've recently and gladly learned that there are some alternatives to it. GnuTLS, NSS and yaSSL are alternatives that I'm aware of. Does anyone have experience with these alternatives that they would be willing to share? Thanks in advance.

One more option --
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/

It's nice to have options, but I would like to get some feedback on these libs.

Brian Wood
http://webEbenezer.net
(651) 251-9384

What's the actual problem you're having with OpenSSL? Because (generally) all encryption libraries will tend to be fiddly and have a lot of complicated small moving parts.

OpenSSL's main flaw, IMHO, is the documentation being... ah... 'casually dressed' shall we say. For actual functionality it did almost all of the things that I ever asked it to, and the one it didn't turned out to be an actual bug which was fixed about two days after I mentioned it to anyone.

Quote:Original post by hplus0603
The Apache stuff is fairly solid from my experience (which is not super deep).

Also, there's Crypto++, which is a wonderful C++ library with more crypto algorithms than you can shake a stick at (including D-H exchange, etc) -- but it's not a high-level SSL/TLS implementation; it's a library that you could use to implement SSL/TLS on top of. In general, though, I recommend against rolling your own, as implementation bugs can compromise security as much or more than weak ciphers.

I had looked at crypto++ also. At first I was hopeful it would be just what I was looking for, but then realized, as you mention, that it isn't a high-level TLS implementation. I'm kind of tempted to roll my own with crypto++, but at least for now I'm not pursuing that option. Thanks.

Brian Wood
http://webEbenezer.net
(651) 251-9384

Quote:Original post by Katie
What's the actual problem you're having with OpenSSL? Because (generally) all encryption libraries will tend to be fiddly and have a lot of complicated small moving parts.

It's been a few weeks since I put that code aside, but I think I was having a problem with SSL_accept. Without OpenSSL I can handle a situation like this:

handle connection request from client A
handle connection request from client B
handle data from either client A or B.

When SSL_accept was added, I think I was getting an SSL_ERROR_WANT_READ. The way I understand it, I would have to do this:

handle connection request from client A (by waiting for data from client A that will satisfy SSL_accept)
handle connection requests or data available

The SSL_accept documentation says when you get SSL_ERROR_WANT_READ
"The calling process then must repeat the call after taking appropriate action to satisfy the needs of SSL_accept(). 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."

I don't want to put off other clients while waiting for data from client A like that.

Quote:
OpenSSL's main flaw, IMHO, is the documentation being... ah... 'casually dressed' shall we say. For actual functionality it did almost all of the things that I ever asked it to, and the one it didn't turned out to be an actual bug which was fixed about two days after I mentioned it to anyone.

I dislike a number of things about it including the API and documentation.


Brian Wood
http://webEbenezer.net
(651) 251-9384

Quote:Original post by wood_brian
handle connection request from client A (by waiting for data from client A that will satisfy SSL_accept)
handle connection requests or data available

The SSL_accept documentation says when you get SSL_ERROR_WANT_READ
"The calling process then must repeat the call after taking appropriate action to satisfy the needs of SSL_accept(). 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."

I don't want to put off other clients while waiting for data from client A like that.

You're looking at things in too-linear of a fashion. You wouldn't wait for client A's data to become available, you would move on to other clients and the next time you got something from client A, you'd call SSL_accept() again. There's no requirement that you block waiting for client A.

Quote:Original post by Dragon88


You're looking at things in too-linear of a fashion. You wouldn't wait for client A's data to become available, you would move on to other clients and the next time you got something from client A, you'd call SSL_accept() again. There's no requirement that you block waiting for client A.

I'd like to find out if other alternatives are as messy in this regard. My thinking is they may not be. I'd rather not build that goldberg machine if I don't have to.

Quote:Original post by wood_brian

Quote:Original post by Dragon88


You're looking at things in too-linear of a fashion. You wouldn't wait for client A's data to become available, you would move on to other clients and the next time you got something from client A, you'd call SSL_accept() again. There's no requirement that you block waiting for client A.

I'd like to find out if other alternatives are as messy in this regard. My thinking is they may not be. I'd rather not build that goldberg machine if I don't have to.

I'm not sure how you're even coming to the conclusion that this is in any way "messy." You should already have an architecture that receives from every client with pending data every cycle, and handles it. This is a very minor, incremental change on top of such an architecture.
If you don't have that sort of architecture, then I contend that your architecture isn't going to scale well anyways, and you should probably redesign.

I'd like to know of other websites/forums to pursue this topic. Some here may think OpenSSL is fine, but I'm not one of them.