I maintain CURL and libcurl and JBSS-H2 and C-ARES and a few things. I work with Embedded Systems during the day as a consultant and I work for HAX.

This is what I intend to try to cover. I work with libcurl then primarily. The project I spend the most time and effort in. I deal a lot with the TLS-SSR libraries in that project.

I'm going to try to touch on why so many libraries and how they differ. Why you pick one of them or why you don't pick a few of them. And how the situation is with SSH libraries and why they are so few.

So, if you have questions, I'm all willing to get interrupted and answer questions. On the way, I think this is a pretty wide scope. Of course, I won't be able to cover everything. So, if you have anything in particular, I'll leave you out.

I started CURL back in, actually before 1998. I called it CURL 1998, the first release. I made a library out of what CURL did in the year 2000.

CURL speaks a few protocols these days. I think there are 19 if you count them like that. It's a pretty widely used library. We have bindings for just about all languages I know.

And even a few more. It's MIT licensed or MITx licensed. It's very liberal. When we did, or rather when I started CURL, we had HTTPS support.

Back in those days, SS Lee was the only existing library. So, back in those days, we started supporting HTTPS already since day one. Or rather, I think summertime 1998.

Powered by SS Lee. How do they pronounce that? I don't know. That project turned into OpenSSL, as everyone knows. And we've been supporting SSL powered by OpenSSL since then.

And of course, time moves on and code grows and you get a lot more features and you get a lot more contributors. And of course, GNU-TLS grew and became really good at some point. And of course, the contributors made code so that we could do HTTPS with GNU-TLS

instead of OpenSSL that's built like that. And then of course, we supported more of these protocols like FTP, SSL, and later on. A lot more protocols using SSL. And then of course, we have these other new contenders that are relatively new.

Yeah, SSL. And they have this rather convenient, very OpenSSL-like API. So it was very easy to be able to do that. And then, I think primarily because of the Fedora project,

they have decided to switch everything over to NSS from whatever they used before. And that is usually turning code from OpenSSL to NSS. So we support NSS to the plan since 2007.

And since libcurl is fairly portable, it runs on just about every operating system you can imagine. So if you want to run on the OS 400 and you want SSL,

of course you want the QSSL support added in 2007. And then a few later newcomers in the game like the PolarSSL. It's a pretty new library. It has to be very popular recently.

And of course, even more recently in our project, at least, the AXTLS library. So as you can see, there are a lot of SSL libraries right now. So why? Why seven SSL libraries?

And I bet there are more than seven. We support seven libraries right now. I bet we can find more if we just like some of them. And looking at these libraries, they all have fairly different features

and fairly different focus and ideas on what they should provide. And they all have different licensing ideas and development ways. And I'll try to compare these a bit to entertain you

and give you an idea of how it looks. I do want to stress that I'm not involved actually in any of these SSL library developments. I'm a developer who uses these libraries from client side.

I'm aware that a few of these libraries have representatives in here and may have other ideas about these things, but I'll present here. But that, of course, does not exist naturally. And of course, I'm willing to learn and re-evaluate my position.

OpenSSL is kind of the, I would say, the most used, most popular SSL library in existence, at least as a free source. It's very established.

It has a lot of features. There's a lot of debate regarding the license, because the license is not GPL-compatible, so everything that is GPL has problems with the OpenSSL in one way or another.

Lots of GPL projects, they just hide for the problem. A lot of people have some kind of exception to the GPL, only for the purpose of OpenSSL. It's a mess. It has a really quirky API. I believe it is mostly because it was made, OpenSSL is kind of the same API as they had back in 1998,

and they haven't really made anything about it since. It's not easy to program OpenSSL. And the documentation is related.

A funny thing about OpenSSL, in the context of all these other guys, is that they are pretty much the only library who leaves out the common name and the subject alt-name verification from the library, so each application has to do this by themselves.

And very recently we saw how that impacted the entire software industry, when this common group fakebug in the common name code appears, and suddenly you realize that there are 10,000 applications with the same error that everyone more or less put in, listed from everyone else.

So everyone had to adjust that error instead of the single spot within the SSL library, as all the other libraries had the same bug, pretty much, but they could fix it at one spot. And OpenSSL, of course, is big, if you're doing a small embedded system, or whatever. You may think that OpenSSL is a few megabytes big.

You feel less, in my time, of course, after OpenSSL because we supported this like seven years ago. It's primarily used because it's quite a different license

than OpenSSL. This is a GPL, so it's very friendly to GPL, a family of licenses. And it has a big, sorry, it's a very good documentation.

And it's very, I think, a consistent API. So it's a lot easier to get into writing a client doing SSL than you feel less, a lot of the other, actually. When I started to prepare for my talk here,

I asked around about guys. What do you say about comparing SSL libraries? We support seven of them. What's your opinion about PoE and cons and libraries? And I got some very strong emotions against uni-TLS, actually.

And that was mostly based on that it's using libgcrypt as default. I know they support others these days, but libgcrypt, obviously, I haven't really researched this, but they have problems with running these different user IDs or whatever.

So there's a lot of bug reports that you have done, too, and all over the world. NSS then, it's a library. Of course, as everyone else, it comes from Mozilla and Firefox and Thunderbird or whatever. I don't know exactly who used it first,

but it's derived from there. So it's a Mozilla project. They have a completely different idea about how to get certificates and stuff. They have this database-oriented look on the world. So for us who have originated as OpenSSL users, we tend to look at certificates of that as files,

PEM files on the disk we loaded. But you don't do that with NSS. They don't even support many PEM files from disk, which is very quirky when you do the transition. And in the Fedora project, of course, they solved that by doing a fine patch that actually can load PEM files from disk. But the NSS project had exactly that after four years.

It's very Firefox and Mozilla focused. It's so focused on only those projects. I mean, it's not that it isn't used. As I said, Fedora is changing to use this all over. So there are many projects using NSS now.

But the developers and the mindset in this project is very much focused on Firefox and Thunderbird, to the extent that if you're suggesting new features and ideas, a lot of resistance will appear that, well, Firefox and Thunderbird, they don't use this. What do you need SRP for?

We have no interface for SRP. Even though there are potentially hundreds of applications out there who could use it. What is SRP? SRP is TLS authentication protocol. Is NSS still active in the cloud?

Is it very active? Yes, NSS is very active. They're a big project and they move along like all of the other big ones. Well, it's not only Firefox focused, but also on some servers because it has history with Netscape servers and Oracle and Red Hat and are still using it in their server products,

in legacy, in older products, and also, for example, Google Chrome uses it too. Yes, I know a lot of other users, but the impression I get when I communicate and I read stuff on their site, the impression I get is that they are very focused

on these projects. And just look at their website. Where is it? It's like multiple slashes under Mozilla slash slash slash slash slash slash slash NSS. And the entire left column on their site, this has nothing to do about NSS. There are links all over their site. It's actually another reason why the documentation

is hard to get to on NSS because it's hard to navigate on their site. And also, they have this open SSL disease that they have a lot of functions that don't have documentation at all. I mentioned QSSL before. That's why it's become seven,

but it's actually not very interesting to most people because if you run OOS 400 on an AES 400, it's interesting, but if you don't, it's not interesting. And I don't. Yeah, SSL is, we've used it in our project.

We're using, they have an open SSL API, and that's very handy because it's very easy to move code that uses open SSL to use the SSL. It's very fast to just port it to use that and stuff. It has a GPL license,

so it's friendly to GPL projects. The problem I've had with it is that, yes, it emulates the open SSL API, but it doesn't quite work as the open SSL API. So I've had problems with actually getting it to work exactly like open SSL.

I've had, and also therefore, you kind of end up in the weird open SSL problem then because open SSL is not a very good document. So when someone emulates that API, you kind of inherit the problem with the application. There's also, this is a project without

the huge developer community and awareness. I mean, you can find a lot of people discussing your SSL work developing online. Polar SSL is in many aspects, from the user's point of view, very similar to the SSL.

This is another, as you mentioned about the SSL, it's focused more on embedded systems because it's smaller. And Polar SSL basically seems to have the same idea. It's focused on embedded systems. They have a dual license system where you can download the GPL version and use it, and you can buy the commercial license version

for whatever purpose you want. And Polar SSL is not very much used. I think it's getting more popular. So I see more and more projects like OpenLDAT and others who embrace this very much.

I don't think we have that long track record to actually tell how it will run. And then we come to AXTLS. This is the newest one in the family. This has been around for a while. This is developed by one guy, and he's been doing it for, I think, five years.

It's by far the smallest library. It only does TLS, and it's not very good documented, and it has had a lot of problems all the way since I even started trying to get it to work. Now it works. It's seemingly very good.

But it's not widely tested, and it's certainly not any big community or anything around it. When I asked him about the comparison about some of the other libraries, I shouldn't quote him,

but he said something about that and he would cry if any of the other libraries were bigger or smaller than his. So you can always run feature for feature what is important in an SSL library for you if you want to use it in a project.

Is it important that you're GPL compatible, or is it, on the contrary, important that you're not GPL licensed? There are, of course, different use cases for different teams. There are things, specific features like, do you need TLS SRP?

And that's basically just new TLS, I think, that supports it. Do you need TLS 1.2? Or on the opposite, do you need anything else? And SSL v2, I'm old and an extinct thing,

but some people still use it. Back again to the Fedora project, they picked NSS for everything. They picked NSS for a reason, and that's because NSS is licensed, registered, or whatever it is, to do with this FIPS 140. It's kind of a US certificate for doing business with the government.

So if that's important, you need a library that's FIPS 140. And then, of course, there's the ones with embedded focus. If you need a small library, you need some of the big ones.

And if you need to run a Windows, of course, that might also be an issue to consider, because I don't think a lot of you know. So, okay, how do we support them? It's not really that hard, I mean, to explain or to understand.

How do you, as an open source project, support a lot of different versions? Yeah, we have an external API, of course. All our libraries implement these functions, and if all libraries just provide these functions, and when we set up, create a connection with SSL, they just create the functions to deal with sockets,

like read and write. I'm moving ahead a little faster, because I'm going to run out of time. So, yeah, it's really not that hard to actually write the code that supports seven libraries. The hard part, of course, is how do we maintain that it actually continues to work

in the long run? And that's a problem, of course, that all open source projects get with whatever they do. And in CURL, we have a ridiculous amount of build options. So we have this problem all the time, so just adding in that library doesn't really matter to us.

So we try to do test cases, and we do this constant distributed testing, so we have a lot of volunteers running various operating systems, and we have a test script, and then just updates from it run a lot of builds, so it's like the results don't stop doing that.

And of course, it doesn't cover everything, but it's a start, and of course, we always depend on volunteers to set up machines and do the tests and stuff. So, SSH libraries are quite not the same,

and then I'm just based on the amount of libraries that exist, but SSL and the maturity in SSL libraries, as I said, they existed back in 1996 or whatever, 95 when they started.

For low-level C implementation, there are really only two SSH libraries, and none of them leave SSH, and leave SSH to none of them are very mature or have existed for very long. And in comparison, they're very rare. They're not used at all as much,

possibly because SSH is a much less used protocol. That's all I'm saying. We picked libsh2 to base our support, because we support SCP and SFTP. And we picked it basically on two factors.

We wanted a license that was not GPL or LDPL, and we wanted the non-locking operations. Right, and we want the VPN cycle, and it's become a tradition among all the SSL libraries that the application does the actual connect,

handle the socket, and then tells the library about the socket, and then the library then handles it. So that was also an important factor for us, too, when we picked the library that we wanted that kind of mindset.

The other SSL libraries, there aren't that many SSL libraries, and that's a lot of work. There's always a lot of work. And that's a little advantage. I'll try to start actually comparing SSL libraries

from a client side from my point of view, but I hope to get more feedback on this one over time. Of course, comparing stuff is always a bit hard, and you can not just project it, compare it to that, actually. It's your own personal opinion, too.

Well, that's about it for me. I have a question. Have you considered kind of exporting the core SSL library as an Uber SSL library application writers could use so that they could actually switch the actual SSL implementations?

Or is it like a separate library, or it's an internal library? No, yeah, I've considered it, but no, it's not an internal library. I just have an internal API, so all my code internally uses the same fixed API. But my API is very limited and focused only on the functionality

that my library needs internally. And since I've maintained three libraries already, I know the pains. If I was going to release this as a library, it would be a lot of work. And maintaining a library is tiresome and energy consuming, and it's enough already.

One more question. For what it's worth, glib is starting to do that, to abstract API and have it so that multiple SSL libraries can be used through it. My question was, do you feel that what you've gained

out of supporting so many SSL libraries is better than just sticking to one? Is that something a lot of people should do? Excellent question. But I haven't really thought about it, because in my world, it's about all the users who want different things. And either you just say, no, you can have it,

or you say, well, if you bring the code, you can do it. And in my case, it's much more often the latter one. So I said, yeah, if you do the code, if you actually provide the entire code, then sure, we can support it. But of course, it gets more work. But I think the upside is that you actually find more, you actually fix the code better if more people use it,

even if they use it in different backends. And usually also you can debug stuff better since you can switch backends, and you see, does the bug still exist? And if you switch backend or not, then you actually know if it's the backend's fault, or if it's my fault, or whatever. Okay. Time's up. Thank you.