 I'm going to try to expand a bit on the previous subject. I intend to talk a little bit about libcurl and a bunch of SSL libraries. And one SSH library. This is me. I hack a lot of the software. I maintain curl and libcurl and SSH2 and CAOS and a few things. Okay. And I work with embedded systems during the day as a consultant and I work for hacks. This is what I intend to try to cover. I work with libcurl done primarily. That's possibly the project I spend the most time and effort in. I deal a lot with the TLS SSL libraries in that project. I'm going to try to touch the subject 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, try to... I'm all willing to get interrupted and answer questions along the way. I think this is a pretty wide scope. Of course I will be able to cover everything. I'll leave out. I started curl back in, actually before 1998. But I called it curl 1998, the first release. And I made a library out of what curl did in the year 2000. And the curl speaks a few portables these days. I think we 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 MIT ex licensed. It's very developed. When we did, or rather when I started curl, we of course immediately wanted HTTPS support. And back in those days SS Lee was the only existing library. So back in those days we started supporting HTTPS already since they won, or rather I think sometime in 1998. Powered by SS Lee. How do they pronounce that? SS Lee. I don't know. That project turned into open SSL, as everyone knows. And we've been supporting SSL Powered by open SSL 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 contributors made code so that we could do HTTPS with GNU TLS instead of open SSL experience like that. And then of course we supported more of these portables like FTP, SSL, later on. A lot of more protocols using SSL. And then of course we had these other new contenders that are relatively new, SSL. And they have this rather convenient, very open SSL like API. So it was very easy to build. And then I think primarily because of the Fedora project they have decided to switch everything over to an SS from whatever they used before and that is usually turning code from open SSL to an SS. So we support an SS to the plan since 2007. And a little curve 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 new cameras in the game like a Polar SSL. It's a pretty new library. It had to be 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. So why? Why seven SSL libraries? There are more than seven. We support seven libraries right now. But we can find more if we want to. 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 licensees and ideas and development ways. I'll try to compare this a bit to entertain you and give you an idea 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 used 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 that I'll present here. But that's of course just natural. And of course I'm willing to learn and re-evaluate my position. OpenSSL is kind of the I would say the most popular SSL library system at least as a free resource. It's very established. It has a lot of features. It has a very... There's a lot of debate regarding the license because the license is not GPL compatible so everything that is GPL has problems with OpenSSL in one way or another. Lots of GPL projects they just hide from the problem. A lot of people have some kind of exception to the GPL only for the purpose of OpenSSL. And 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 really... Yeah. And 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 opening verification from the library so each application has to do this by themselves. And the very reason that we saw how that impacted the entire software industry when this common group think bug in the common name code appears and suddenly you realize that there are 10,000 applications with the same arrow that everyone more or less profiled and listed from everyone else. So everyone had to adjust that arrow to a 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 never feel that's... I might, of course, have to open SSL because we supported this some years ago. It's primarily used because it's quite a different license than OpenSSL. It's an LGPL, so it's very friendly to a LGPL and a family of licenses. And it has a big... Sorry, it's a very good documentation and it's a very, I think, a consistent API. So it's a lot easier to get into writing a client doing SSL than a lot of the other. When I started to prepare for my talk here I asked around about guys... What do you say about comparing SSL libraries? You support seven of them. What's your opinion about pro and cons libraries? I got some very strong emotions against TLS, actually. And that was mostly based on that it's using live G-Crypt as default. I know they support the others these days, but live G-Crypt... Obviously, I haven't really researched this, but they have problems with running and user writing and so on. There's a lot of bug reports that you have done too and they're all over the place. And it says 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. 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 at the world. So for us who have originated as open SSL users, we tend to look at certificates as files, PEM files on your disk reloaded, but you don't do that with an SSL. They don't even support loading PEM files from disk, which is very quirky when you do the transition. In the Fedora project, of course, they sold it by doing a fine patch that actually kind of PEM files from disk, but you can't accept it 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 MSS 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 these. What do you need SRP for? We have no interface for SRP. Even though there are, I mean, potentially hundreds of applications out there who could use it. What is SRP? SRP is a TLS authentication protocol. Is NSS still active with Mozilla? 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 had 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 about the user, 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, bloop, slash, bloop, slash, and NSS, and the entire left column on their site, this has nothing to do with 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. I mentioned QSSL before, but it's actually not very interesting to most people because if you run, oh, it's 400, on an Aegis 400, it's interesting, but if you don't, it's not interesting. And I don't. Yes, SSL is... We've used it in our project, using, they have a open SSL API, and that's very handy because it's very easy to move code. It uses open SSL to use SSL instead. It's very fast to just port it to your standard 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 just any 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 very good document, so when someone emulates that API, you kind of inherit the problem with it. There's also... This is a project without the huge developer community and awareness. You can find a lot of people discussing the SSL or developing online. Polar SSL is, in many aspects, from a user's point of view, very similar to the SSL. This is another... I should mention that about the SSL. It's focused more on embedded systems because it's smaller. 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 a GPL version, use it, and you can buy a 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 OpenL, and others who embrace this very much. But I don't think we've had a long track record to actually tell how it's even grown. And then we come to AX TLS. 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 in the community or anything around it. When I asked him about comparison about some of the other libraries, I shouldn't quote him, but he said something about he would cry if any of the other libraries were smaller than this. So if you can always come feature for feature, what is important in an SSI 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 in specific features like do you need TLS SRP? And that's basically just the new TLS, I think, that supports it. Do you need TLS 1.2, or the opposite? Do you need anything else? And SSL V2, an old and an extinct thing, but some people said you need it. Back again to the Fedora project, who 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, then 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 it will... So, okay. How do we support them? It's not really that hard. I mean, to explain, how do you, as an open-source project, support a lot of different versions? Yeah, we have an internal 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 ring, right? 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 a code that supports seven libraries. The hard part, of course, is how do you maintain that it actually continues to work in the long run? And that's the problem, of course, that all open-source projects get with whatever they do. In Curl, we have a really, a ridiculous amount of build options. So we have this problem all the time, just adding an library doesn't really matter to us. So we do, we try to do test cases, and we do this constant distributed testing. So we have a lot of volunteers running various, we are operating systems, and we have a test script, and then just updates from it, run a lot of builds, some of these active results, and all the stuff doing that. And of course, it doesn't cover everything, but it's a start, and of course we always depend on volunteers to do, to set up machines and the SSH stuff. So SSH libraries are quite not the same, and then I'm just based on the amount of libraries that exist for SSL, and the maturity in SSL libraries, as I said, they existed back in 1996 or whatever, in 1995 when they started, for low-level C implementation, there are really only two SSH libraries, and none of them, SSH, because actually 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 then, because SSH is much less used, as I mentioned before. We picked SSH2 to base our support, plus we support SCP and SFDP, and we picked it basically on two factors. We wanted a license that was not GEPL or LDEPL, and we wanted the non-blocking operations. Right, and we want the... It became a tradition among all the SSH libraries that the application does the actual connect, handle the socket, and then tells the library about the socket and then the library then... So that was also an important factor for us, too. When we picked the library that we wanted, we wanted that kind of mindset. Is that libraries? There aren't that many SSH libraries. That's a lot of work. There's always a lot of work. That's a little web page. I'll try to start to actually compare SSH libraries from a client's side, from the blind point of view, but I hope to get more feedback on this one over time. Of course, comparing stuff is always a bit harder than you think. So that's the objective comparison we have to actually... Oh, 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? 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 I know exactly... Since I've maintained like three libraries already, I know the pains. If I was going to release this as a library, the world would be a lot of work. And maintaining a library is a tiresome 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 starting to stick into one? Is that something a lot of people should do? Excellent question. 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, we 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. 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 that does the bug still exist when you switch backend or not. Then you actually know if it's the backends folder, if it's my folder or whatever. Okay. Time's up. Thank you.