search

binary1248 / SFNUL

Simple and Fast Network Utility Library
Mozilla Public License 2.0
52 stars 4 forks source link

Switch away from tropicssl #1

Closed svenstaro closed 10 years ago

svenstaro commented 10 years ago

It would appear that tropicssl is not really maintained. Last commit was apparently 2011 and it would seem critical to a security library to see it maintained. I suggest using openssl instead as it is maintained and most users will already have it installed anyway.

binary1248 commented 10 years ago

As already stated here, I am aware that TropicSSL is a bit dated. However, if you look at the standards that all these libraries follow, they all date back to long before TropicSSL development halted, and as such using TropicSSL doesn't mean SFNUL misses out on any advances that were made, because... well... not many were made in the last few years...

And not only that, what is more scary is that the counterparts (browsers and other seemingly secure endpoints) sometimes don't even support the full TLS suite yet although they are constantly updated, so trying to make SFNUL more secure by using an actively developed library doesn't bring with it enough advantages to make it worthwhile.

svenstaro commented 10 years ago

I think the security considerations alone should make it worthwhile. I looked at your branch of tropicssl and it would appear that you don't put any recent security fixes in there, only coding fixes. As everybody uses openssl, it is well audited and security fixes appear almost immediately. I think that alone makes it worthwhile. Basically, why would you use such a library like tropicssl if you could easily use openssl instead?

binary1248 commented 10 years ago

Basically, why would you use such a library like tropicssl if you could easily use openssl instead?

That is the problem... OpenSSL doesn't make it easy to integrate it with the rest of the layering philosophy of SFNUL. It needs full control of the network sockets (which run on the POSIX API) to function cleanly. If there was a simple way to fit it into the "bigger picture" I might have considered using it over TropicSSL, but it just didn't fit.

Not only that, but they use a (what I find obnoxious) strange kind of 2-in-1 combined license that is incompatible with the standard GPL and might be annoying to end-users.

I looked at over 10 TLS libraries when building in TLS support, and most of them didn't relinquish control of the underlying input/output enough for me, and many of them had licenses that I didn't find suit the intentions of SFNUL.

svenstaro commented 10 years ago

Are you 100% sure manual socket management with OpenSSL is not possible? I have not looked into that but something tells me it definitely should be possible considering all the different use cases it has to bow to.

binary1248 commented 10 years ago

Actually... looking around again, I found botan. It seems like it is coincidentally exactly what I need according to the requirements stated above and it has a usable license. An added bonus is that it is written with C++11 in mind, so integration should be simple. I assume that it is safe to use and secure, considering the author seems credible according to the FAQ. I will re-evaluate and see if I can replace TropicSSL with botan.

svenstaro commented 10 years ago

Sounds excellent, it seems well maintained and rather feature rich. Nice. :-)

binary1248 commented 10 years ago

Implemented in ed21c94c14d88c388f0928447becaf2921cbde26.