Open/LibreSSL in FreeBSD
Spil, Bernard
This talk will address the changes required to ports to deal with the changes that LibreSSL introduced (and keeps introducing). Additionally I will talk about the support-lifecycle of both the LibreSSL and OpenSSL projects and the impact on operating systems and other software projects. Lastly I will address making OpenSSL in base private and/or replacing FreeBSD's base OpenSSL with LibreSSL. Following the Heartbleed vulnerability OpenBSD forked OpenSSL into LibreSSL. The portable version of LibreSSL was ported to FreeBSD a day after it was released causing a large number of problems with ports. Meanwhile OpenSSL changed its support-lifecycle and will stop supporting current versions very soon. LibreSSL is being actively developed which induces more changes to ports. The PC-BSD project ran an 'EDGE' build of their packages with LibreSSL which surfaced a number of problems with major ports like Python, OpenLDAP and Apache. After the first major ports were fixed the build surfaced ca 100 packages failing to build for various reasons. I will show some examples of these problems and fixes for them. With the release of LibreSSL 2.3 came the removal of SSLv3. This caused another ca 100 ports to fail due to hard dependencies on SSLv3 methods in the libraries. Again some major ports where affected. I will show an example of this issue and the proper solution to it. Additionally, there are ports that are not linking the desired OpenSSL libraries. Even when WITHOPENSSLPORTS is defined they link to the libraries in /usr/lib. Work is underway trying to make the OpenSSL libraries in base 'private' libraries. I will show the work performed and the effects on a system.
 Good afternoon. Welcome. I'm very happy with the turnout here. I've been working at this for a long time and I was absolutely surprised with a number of people that approached me and told me that we were actually using the stuff that I'm doing because in general you only get some feedback if you break it, but not a lot of stuff if it just works. So I think not hearing things, I'll take that as a good thing for now and I'll just keep with it and do these kinds of silly things. So for you, all of you that do not know me, I've been a long time FreeBSD user probably since 5.3-ish, which was shortly after the 5.0, which I have not experienced, which was very bad. I'm not a developer by profession, I am sorry by education. I am actually a chemical engineer and I'm definitely not a cryptographer. So if you want to know about Chacha and Poly, I know that they exist, but I don't know from front or back of it to see actually what it does. I just make it work. I've been an active contributor in the FreeBSD channel on FreeNote for as long as I can think of, I guess, from the early days and I'm the maintainer of the LibreSSL ports, MariaDB ports, which is a MySQL replacement. Yes, I'm sorry for you too. And I currently have some new ports coming up. I've just been relieved from mentorship as a ports committer. And I have a collection of LibreSSL ports patches because not everything works with LibreSSL out of the box. And I'll come back to that. My day job is an enterprise application integration architect at Philips Lighting. If you ever get offered that job, don't, it's boring. So this is why I do all this stuff in the evenings. And if an emergency patch arrives, that will be happening through the day anyway. And I'm a volunteer at our local fiber cooperative, which is in a bit of trouble, but we'll figure it out. And I do a bit of volunteering for Bits of Freedom, which is kind of the Dutch chapter of EFF, EDRI. So it's all about privacy. And I did a bit of a toolbox, or I've written a bit of the toolbox. So how did we get here? Everybody, I assume, recalls Heartbleed, which was very bad. And in April 2014, our OpenBSD friends decided that it was time to fork OpenSSL and make it a bit saner. So they did. And I started live blogging the flensing, as they call it, of the OpenSSL code. And they removed everything left and right, and TDo's and Joel's and all. If you look at the commit messages, it was hilarious to see what was going on all the way through these first months. They removed all the old platforms, insecure features, and they ended up, oh, sorry, yeah, well, this is an intermittent slide. So Heartbleed was an implementation-specific problem in OpenSSL. But there's also a lot of SSL attacks recently on the protocol itself, which I've listed here. I've stolen this from somebody else's presentation. But in red, I have the stuff in there that is actually deprecated. And thou shalt not use this anymore in 2015 or 16. So you see that a lot of old stuff that you have around in your software ecosystem actually leads to a lot of issues. And not having them anymore provides you benefit because you could strike these ones out. They're just not available anymore. The Core Infrastructure Initiative, this is something which started very shortly after Libre SSL was started. It's my feeling that it was a reaction to the stuff that Libre was doing. It is, I think it's funded by the Linux Foundation. Sorry, I don't have the thing on the screen here, so I'll be looking at that. This machine is too new, so we don't have the graphics driver yet. And they had a security audit by NCC, which uncovered a lot of problems. And I think we had, I think every couple of months, there would be a new OpenSSL patch release where the findings of NCC group were fixed and that led to a lot of emergency patching. I know that Ray Perceval told me that he had sleepless nights because he had to get out and make sure that all his OpenSSL stacks were upgraded again. So where did Libre SSL end up? Well, at least 35% of the code was removed, so that's good. So all of the unsecure and outdated features and platforms have been completely removed. So I'm sorry you cannot try this on BOS or VaxVMS or anything. And the first portable release happened halfway of 2015, and that's where the story starts outside of OpenBSD for the rest of the world. They added new features as well a bit later on, which was LibTLS initially. Which is a wrapper around LibCrypto and LibSSL, but with less food shooting capability, so it tries to do the things smartly and securely for you. So if you can, use it. And they bought back as a showcase for LibTLS the SSLified Netcat, which you all have. In FreeBSD, our Netcat is the OpenBSD Netcat. And if you were to install the Libre SSL ports, you get a Netcat that does SSL as well in addition. So this is going to be fun to merge the current one back into base FreeBSD, because that surely does not have Libre SSL yet. So it also ended up, this is as far as I know it. I've heard that you actually have a Libre SSL binary on OSX. I know they state that OpenELEC, that's a code thing that you can run on an RPI or anything else, uses Libre SSL. Void Linux has Libre SSL integrated. I know for Gen2, well, he can do about anything, so let's forget about them. PCBSD, if anybody runs PCBSD, this runs PCBSD. PCBSD uses Libre SSL from ports for all of the ports. And if you were to find one that still links base OpenSSL, do let me know, now we'll make sure it no longer does. HardenBSD is in the process of starting to migrate completely to Libre SSL. And that's now kind of a proof of concept, and we're making sure that everything's fine and dandy, and then it will be shipped. OpenSense already uses Libre SSL, I believe, in a separate branch, if you want to, for all of the ports, so not for base yet. But HardenBSD is probably going to be the first one where you can have free SSD without OpenSSL. What the command is there, but all the old code, all the OpenSSL code has been replaced with Libre. So I collected some things from OpenSSL in base, so these are the security announcements, which is quite a lot. And this means usually that you have an upgrade of your complete system for an OpenSSL vulnerability. You might notice that there is one which I don't have a number for yet. So you'll be very busy next week somewhere, because there is one of the vulnerabilities has already been published, or it's a scientific paper on vulnerability in the DSA signing, which mostly hits you in OpenSSH. So please go and disable DSA in OpenSSH for now. It's already fixed in Libre SSL, because it was, if it's out in the open, the guys immediately hit it and they roll a new version. So the port, security Libre SSL, was ported within a day after 11th of July 2015 by Zavolot from RSPAMD. So the port was there very early. And currently we are as of yesterday, day before yesterday. FreeBSD is at 236 for the regular port and 241 for the development port. I'm using the development port on my server at home already, not a port, sorry, in base, because you get full IETF compliant Cha-Cha 20 Poly 1305. So I don't know what it is, but I have it. So vulnerabilities, this is something, and I made sure that I listed it here, those counts are outdated. So since they forked, I tallied up all of the things that were coming by and the levels and what you should be able to see is that with Libre SSL, you had none of the high vulnerabilities, you had about half of the medium vulnerabilities, and a lot fewer of the low classified vulnerabilities, which I think was pretty awesome. So you have to patch less and the stuff that you have to patch is actually usually of a lower criticality. Is it that simple? Well, of course not, that would be too easy. So with the first release, I was using it myself. At some point, Chris Moore, he wanted, or sorry, he approached me to see if I were willing to see what would happen if they would switch to the Libre SSL port for PCBSD, and that's when I got my ex-brun capability, because anything I do now folds back into PCBSD. PCBSD will build the whole port tree, and I know exactly what fallout I have because the putery air logs are publicly visible, so I just have to see what changed, what broke, and we roll on from that. The amazing part was that there's also software that broke which you would not actually expect, like the Apache Demon. I discovered that very early because that's something I personally use still. I know I'm a bit old by now. Python wasn't working, OpenL that would fail to build, Curl would fail to build, fail to build, and that surprised me because I would think that they would be upfront with security and everything that is possible because some of these things were pretty stupid. With the advent of Libre SSL 2.3, I went through the same thing again. This is about a year later. They removed SSL V3 completely, which catches out a lot of ports because they just don't have not implemented that even though the no SSL 3 flag has been available in Open SSL for a long time during build. Again, a lot of very large visible projects failing. That is what I've been doing and that tends to be a lot of work and there's a lot of crunch time because you want to get that stuff out there as soon as possible. You turn through all the ports and make sure that they work again. There's a lot of bad examples out there. Somehow, the crappy stuff that people do, it proliferates, perpetuates, people copy the wrong examples. What you see actually is that patching many a time isn't that difficult because actually you'll be just redoing the same thing over and over again for exactly the same way somebody's implemented it. It is almost to the point where you could apply the patch from one project to another project, which was scary. SSL V2.3. If you do build something nowadays with SSL, do please use SSL V2.3 methods that are available in both Open SSL and Libre SSL. It allows you to create SSL connections up to TLS version 1.2. The 2.3 is meaningless. It's just anything. You will find TLS replacements in Libre SSL, but I also believe in Open SSL from 1.1.0, which are exactly the same, but just SSL V2.3 is replaced with TLS and everything just works. Then you have the SSL operations flags, which just allow you to switch off anything you don't like, like TLS V1.1, whatever you wish. One thing that I've been hit with is the version number checking that everybody does. This is bad practice, so you see a lot of projects checking for a specific version number of Open SSL to detect that compression was added to Open SSL. We know that compression is problematic, but if you remove that from the code, you're going to be hit with a lot of projects failing because they failed either during build or even during runtime on something not being available anymore. Do not check version numbers. The last statement, they can, will and should be deprecated at some moment. Be as do your checks proper, check for like a define that is made specifically for a feature or whatever you can do, but don't check the version number. I talked about upstreaming a bit before. Upstreaming is a tedious process that actually takes more work than doing the patching. I have about 200 of these, so you will be connecting with anybody and everybody, and you will be connecting with projects that are just blatantly refusing to add anything that would aid Open SSL, for some unknown reason. So there are those. And we have a lot of old abandoned, un-maintained, whatever you have ports in our ports tree. I think one of the, if this is all stabilized and everything is done, I kind of make, I think I'll make it my personal crusade to kill all that stuff and to start deprecating a hell of a lot of ports in our tree because specifically if you talk about things that use SSL and stuff, you want to have maintained stuff in your ports tree, you don't want to have things that are no longer maintained. That's just a fire hazard. So I still have a huge number of patches to upstream or to find the point where you can upstream too because things don't no longer exist and I felt like trolling through a mord of dead code and stuff. This is really horrible. If you want to have a look at all of the patches, so if you are using it or if you're intending to use it, I have lists with patches usually of all of the things that can fail on the FreeBSD Wiki page. The presentation will be publicly available so you can check later on in the slides. There is a slide with all the links that you can use from the PDF. And if you have time and you're willing to, helping out with the upstreaming would be most welcome because there's a lot of hoops to jump through nowadays. People want you to sign contributor agreements and I'm like, I added two and I added one or two if-defs. So you want me to or shall I tell you what you need to do and then you do it yourself because you don't want to go through the hassle anymore of faxing signed paper. I don't even have a fax for God's sake. So the FreeBSD Ports Tree has another number of interesting problems issues. There's still a lot of ports that don't actually honor the with OpenSSL port flag that you can set in your make.conf. So you would want it to build with OpenSSL from ports but actually it will grab OpenSSL from base. This is currently very nicely apparent if you have a, if you run HED which FreeBSD11 has OpenSSL102H and the port is also 102H. There's a difference however. The base system has SCTP enabled. The port has SCTP disabled. So we saw CMake blow up because actually so it was using the headers from the one and at link time it used the other one which doesn't really match up. You wanted to say something Matt? Yeah, if you fuck the jury for the fault of the one who needed it so far, they'll be okay. Yeah, I know. If I find them, I fix them. This is, it's, and there's been very silly things that you need to go through to actually make software use the correct libraries. Actually the libraries that you want. And mixing base and OpenSSL ports linking in your ports is a recipe for disaster. It will bite you immediately, later on. Funky things happen. Just don't. Just stay out of there. Don't do it. And there's this tiny thing you must rebuild or, well, if you, if you use Poudrier, that's fine. You must rebuild all your ports when you switch to Libre or even if you switch from Libre to Libre Devel because otherwise you'll have funky results. It just, just don't. So I wanted to tell you a bit about the lifespan and the end of life of all of these products. So FreeBSD9, 903 is still supported, right? Till the end of next year, I think? End of this year. Well, that means that we're running an end of an unsupported OpenSSL version for a year. And actually I was checking up on it this morning. 0.9.8 has been productive then for 10 and a half years, which is for a security product pretty long. So we're now in the 10 branch. That is our main, so our main OpenSSL version is 101. That will get security patches up to the end of next year. Sorry, this year, yeah. And then it had about a lifespan of a little less than five years. So we'll be running 10.3 for quite some time with an unsupported OpenSSL version, which is poor practice, I guess. But hey, Red Hat does the work for us, so we just bring in their patches and be done with it. For 11, we have imported 102 now, which has full support until the end of 2019, which is again about five years. And I'm quite sure that we will run out of time by the end of the 11 branch, where we're still on 102, but it's already the end of life. So if you compare that with OpenBSD, thank you guys. They're on the clock. Well, sometimes they'll tell you they'll release a new version at the first of April, but then that is April Fools. So they actually release every first of May and every first of November, and they only ever support two versions of Libra SSL. So this is an issue if you want to run it in base, because you don't have a very stable Libra SSL version going forward. And I'm quite sure that nobody's going to be willing to backport any fixes to earlier Libra SSL versions. I would say don't. So this is what it looks like, and I tried to visualize that a bit. So these are kind of the things where we are vulnerable, we have an unsupported OpenSSL version in the FreeBSD stuff. So you see here in 098 was released 2005, 100, 2010, 101 was released in 2012. So here 2015 was 102, and 110 should already be released, but there's some delay. So that, yeah, they said somewhere in May, but it's June as far as last time I looked. That's what my flight ticket said. Okay, then there's what can you do with it? So I think about two years ago, Adam McDougall, he wanted to have a place where he could build his ports without having to deal with OpenSSL from base completely. That actually is not as straightforward as it looks because we have a without OpenSSL flag for source.conf, but that doesn't build because there's more things that you need to disable which have not been included in the dependency tree for some reason. So you have to set a couple of other things, and you have to disable SSL in Libfetch, which is not very nice. Ultimately, we found out that this is only really useful if you're running in a jail because if you start running this in a live system, you'll get trouble with package and Libfetch because they are very specific in the way that they link the libraries. Then another thing where Alan Jude had been working on, and I kind of stole his patch and tried to make it even better, is to make libraries private. In 3BZ, we have private libraries that are not available for linking against. So on 10x, you will have them in user Libprivate, and in 11, they will be renamed into Libprivate SSL, Libprivate Crypto, or whatever. Yeah. I've tried to use, because all the not all ports will use the correct libraries, and there's a, I've linked here a PR which kind of lists all of these things that have a problem. This, again, gives you trouble with package and Libfetch. That is the consistent thing, and I am told it is absolutely possible, ultimately, to make Libcrito private, but that needs even more work than we've done on it already. So the result was okay, but the problem is that you'll have is package and Libfetch. So then why not replace OpenSSL in base? If OpenBSD can run it in base, why can't we? So I tried this. I was at a hackathon in Croatia with the Libra SSL and OpenBSD devs, and I tried that, but it was a bit fresh on make files, and I didn't know the base system at all at that time because I only did port. So I failed miserably. I had an absolutely great time with these guys if you ever can, and they ask you to come, go. They're the best to hang out with. And Brent Cook, he's the, he does the portable build or the release engineering mostly. He said, well, no, don't, don't do it, don't try to do it a free busy way. Just import our make files and be done with it. And I was, well, not comfortable enough with that yet. But so the other thing that you should take away if the OpenBSD devs tell you, you better do it this way, then you could actually try it and it might work. And then suddenly comes along Sean, and Sean probably had seen my work as well, Sean Webb from HardenBSD, and he had a challenge for me. Can you create for us a configurable Libra SSL in freeBSD or HardenBSD base? And we were discussing a bit with that same possible. So I started at work. And actually, if I listened to Brent Cook, and I follow his advice, then actually it wasn't really all that difficult. So a bit about the base system framework. So everything, they didn't use a source. We have our main make files. So there's two things where I needed to patch up for 10 in BZO and in 11 in source ops. I added a knob with Libra SSL, just like you have with OpenSSL, without OpenSSL. It works exactly in the same way. You have crypto, use a source crypto OpenSSL where the actual sources live for OpenSSL. And then in secure Lib and use a bin, you have the actual make files that will build the stuff from crypto. So these are the ones that I focused on. So for Libra SSL, what did I do? Just unpacked Libra SSL into crypto, just a portable tarble. You unpack it, you rename it, you're done. And I actually did it this week with a 241 release. I rebuilt OpenSSL or Libra SSL in this case and it was all fine. So in secure Lib, Lib Crypto, I just added additional files with a suffix Libra SSL, which is so the ink is the one that gets included everywhere for main variables. And this will actually build Libra SSL, the same for Lib SSL. I added Lib TLS and Netcat. And these make files, basically, they are the ones that I imported from OpenBSD's base system. So pull them from CVS, not from GitHub or anywhere. So really the basic thing. So this is what happens in the background with Libra SSL. So there's default no options. Actually, we now switched in hard and B3, the Libra SSL branch to default yes options Libra SSL because that's the whole point of that treatment. And this is what you need to do to get it to build. This transforms internally all of these transform into make Libra SSL. So that's what you need to check for. And I had to add Lib TLS where possible because that's a library so that should be known to the whole framework. The existing make files, once I, oh, actually this is wrong but never mind you can find the sources, you need to include the correct options make file from share make. And all you need to do is check if it's no, the original make file is just in here verbatim so I don't do anything about the current stuff only if make Libra SSL. So at the end I include the Libra SSL file. So if you don't do anything, you get exactly what you have now. So you get open SSL in the version that is in the base system. So this makes switching extremely easy because you can flip the switch, rebuild your base, you need to rebuild all reports, you need a lot of time but not a lot of effort. So this is why this has gone this way. And also if anything changes in open SSL, the whole thing is still in there. So we just, we put it between the first if and we're fine. So also merging is probably automatic because it's at the beginning and at the end for there's nothing changes so any updates will just merge in with Git. And then once you've done that, you start building, then we get back to 2001 again. In 2001, I have a backup slide if we have too much time but I guess that won't happen. There's a commit in the open SSL file. So you can see that says, yeah, well, we renamed all of the DES methods and they're now no longer lowercase, they're uppercase. And the invocation is different not by reference but with a pointer. And they included a header which is called DES underscore old.h. And they will deprecate that by, what was it, before 100 appears. I can tell you it has now gone in 110 which is not even out. So it's still there. It's 2016 so this happened about 10 years too late. LibTelnet and PPP in our base system have that deprecated stuff in there still. It is trivial to replace with the modern ones but nobody's bothered ever to actually do that so I think I now created PRs for these. And then we have Heimdall in base. For some reason it's still one of the entropy gathering daemon and I think that thing has died long ago. I think for the last 10 years there's not a single system that you can buy that actually uses the PRL entropy gathering daemon but because OpenSSL had the methods everything just assumes that it's there. And in 11 I encountered a bit of the future so did I tell you about version number checks before to see if any features available? There you go. Even in WPA so that's the wireless authentication. They had a check in the latest version, OpenSSL version number. So but these again are pretty simple fixes. There is, sorry, I have however introduced a tiny difference between ports and base. So what we did originally in the port or CHEPCA actually, early on it was difficult if you keep the OpenSSL version number as you find it in a tar bowl, it's defined as version 20000 which kind of freaks out because everything that checks if a version is greater than whatever, two is always greater than one for some reason. So these will all be evaluated to true and I would have, you have things left and right falling over for lack of compression, what have you and it's deteriorated of course with 110. So what Seville did, he added, he patched the version to be 101F which is the time at which LibreSSL forked and then you have kind of a comparable set of features in LibreSSL and that just works. So what happened later on is that LibreSSL also added a LibreSSL version number which makes our life a lot more easy. So if there's any check for OpenSSL version number we just say and not defined LibreSSL version number and usually 9 out of 10 will just go through. I found that this change, I've now, I've not applied that for base because I think it's time that we just use the stuff that we have. The fallout was relatively low and these are all categorized on the wiki so if you want to go in and see how much is affected, they all have their label in a table that says which feature is actually failing. So this is WPA. So that was a check that they had so if it's larger than 101 and I made it like this and then it's fine. I think that's upstreamal worthy so that's not an issue anymore. So that flows back into our base system. LibreBSD? Well, I've created a repo. I've called it LibreBSD but it's not going to be a distribution. Yes? Yes, kind of. So you get a weird logo where I try to merge the what is it the Che Guevara beret with the... So forget about this but it's not going to be a separate distribution. It's going to be probably so it's going to be in hard and busy and PCBs if you want it but I'm not going to maintain. I'm not going to fork. It's just this. So how far along are we? We have 20 minutes left. Excellent. So I need to finalize and polish up the stuff for LibreSSL in base. Actually, it's already further polished and done. Committing and upstreaming the LibreSSL patches upstream. So for ports. So I've been released from mentorship. I think I've been the guy that was mentored longest in the history of ports. So I don't know why that is probably because I'm Mr. Chaos and I make the... It was just coops. Oh. You'll be listening in because it's live streamed. Oh my God. I guess he was. He was seeing this. That is the point. So I can now actually commit all that stuff for the old things that are failing in ports. Anything that doesn't have a maintainer, I should be just committing to the ports very soon. Hard and BSD and PCBs with LibreSSL as the default Lib Crypto provider. I think that will be a very fast thing specifically because PCBs already built fine all the ports with LibreSSL and base is no issue. So Matt Arnol, who is our port manager, he has created something which is uses OpenSSL make. So... Okay. Yeah. Well, it's use OpenSSL. Where did I... Okay. Yes. Typo. I'll fix that. That is about to land in the port stream, I guess. So that means that all of the... It actually is backward compatible. So use OpenSSL equals yes in your port's make file still works, but you should be switching to users equals OpenSSL. And then you can add base, ports, OpenSSL, LibreSSL, and LibreSSLDevail, and even OpenSSLDevail, which is also a port. One thing that I hear pretty consistently out of the port's community is that at some point, FreeBSD intends to switch all ports to default to OpenSSL from ports no longer from base. So the base OpenSSL should be there with the only objective to serve anything that is in the base system. And if you have ports, they all rely on ports OpenSSL. And yeah, well, I added three question marks. I see no reason now seeing how easy it was to do this to have this in base as well. So this is for the not so faint at heart because you'll be bumping the shared Libversion more often, so at least once every half year. You can hold off for another six months, but that's it. So you have a big change every year. But if you run on a home system, I guess you'll be fine. So this is also why PCBSD could manage this because they build their own, the upgrades that you get using the upgrade mechanisms. They have full control so they can just flip it to the next version and everything is fine. And the ironic bit that I found over the past months, I guess, since 1.1.0 was released, is that I've found that OpenSSL benefits greatly from all the work that's been done by OpenBSD, myself, anybody on Libres SL. Because guess what? What happened in version 1.1.0, which is now in beta something, it's the fifth pre-release version? The SSL V3 methods have gone in the default build. So you can re-enable them still, which you cannot in Libres SL, by the way. So it's gone. So they would be facing exactly the same issues as I have with the previous reports three, because the removal of SSL V3. So they don't have to go through that anymore. All the patches are available already, so they have a smooth landing. Same goes for EGD. It is no longer enabled by default in the build. So if somebody re... So the people that still use Vax and BIOS and DOS and whatever, they can still do that. They can enable that and they can use the Pearl entropy gathering demon, because that's a very smart plan. I think... I don't really don't understand that, because if you still run a version... a system that old, are you really going to upgrade to 1.1.0? I would imagine that everything just caves in immediately. You have an immense implosion and your system stops functioning all together. So that does all that I talked about before. After 15 years of promise, they have removed it. And if you check now, I've created myself the OpenSSL developer, more as an exercise to see if I could do that than anything else. And it has a lot of options, but it defaults to what I think is sane and secure, which means that most of the stuff that is questionable has been disabled there as well, enable it at your own... What is it? At your own peril. Yes, absolutely. MD2, you can still have it. So the last slides, I want to thank OpenBSD, the guys that I worked with before aren't here, unfortunately. And I wasn't... Chris is not here. Is he somewhere else, probably? Chris Moore from PCBSD, who... Yeah, we spent massive amounts of compute resources on building the sports. Every time I update Libra's Excel now, he has to rebuild half of the port stream, which is pretty significant. I want to thank HardenBSD, the team for the trust patients in working with me to get this stuff done. And there's this guy, Frogs, who can't be on other channels anymore because he has to go via tours, he's been of a tinfoil hat, I guess. He pushed me to get stuff done very early days. Alan Jude for the patches, for the private libraries, several... Kubilay Kochak or Coops, as we call them, because his original name is a bit difficult for all of us. My two mentors originally. Ooh! I now see I left out Mark Felder, who became my mentor a bit later. And Johannes for their help, pushing and whatever, because I would never have got this done. I hope to give a talk about what it means to actually start doing something with providing back rather than being afraid to provide back because you think you're not good enough, because obviously that is not true. I suck at everything, but still I can do this stuff. Sorry? Oh, no. Oh, yeah. Oh, that, yeah, I think that would be a valuable experience. Yes, he says I should mentor three people before giving the talk. This is the page of links that I promise you and have some backup slides, but let's try... Is there any questions? Yes? Yes, so the question is to the whole crowd, how does, how do formalities deal with open or Libre SSL, for instance, PCI DSS compliance and stuff? Sean, you wanted to comment on that? Yes, sir. Sorry, with a bit of negative impact, but no that that I want to mention. So that so in one of my friends does what happens in metah원� one antiquities, and this one, which is into the network. then should be okay with PCI Yep, okay. Sorry? Yeah, auditors are funky people, right? So they do whatever they want. So you would be okay for PCI, but not for NICAP and common criteria. You may be, yeah, okay. Peter. So you may not be losing anything. I went to kind of go back to a little bit of its content. gymnastics in order to pursue your compliance. And then also the simple act of getting fifth compliance is incredibly kind of assuming a lot of effort and very, very, very expensive. And we are not gonna do that work for it. If someone else wants to assist with getting fifth compliance, please talk to the U.S.S.L. team. I believe there could be some interest there, but it is not a strong-fired response. Can I imagine? I hope that that was recorded. I think for PCI DSS, for instance, it matters. If you're a, so we're a Dutch company and if we process credit card data, we still need to be PCI compliant. Not FIPS, no. But FIPS, that was, it forced you to use insecure things. I don't get that, so. Yeah. I mean, we're not just looking to get to compound influx, and there's other stuff that we call gigabit queens. So if somebody gives out Polnithria hotelangra for you, you need to get to their downtime rent. But if that's about arming some queen, that's best. Hey, small resolute with me. Yeah. That's fine. from level one to five. Yeah. Level one is definitely better than the other. Right? No. Anything else from you? I have some backups, so we could have fun. The whole issue is the marketing export. Yeah. So, you know, it's the long-term that's previously been placed in the cell. So, you don't have to be the longest-in-tile in the cell library that's just like the normal and the long-term, the long-term, the long-term, the long-term, the long-term. No. So, I think if it happens, it would be switchable but defaulting. So, you can always switch to the other one because it's just then, well, it's not a drop-in replacement, but mostly it's a... So, you still get a fully functional base system. So, that would not... Partially, that's a problem. There's a reason that these sources live in crypto because the whole user-source crypto tree would just be removed for export. In the olden days, that's what I told me. Yes, Peter. So, to respond to that, the U.S. removed most of the requirements for export of open-source crypto in, I believe, in 2004. General U.S. regulations about exporting any product still apply. But for anything that is open-source crypto or a easily-purchasable crypto, basically, what you don't need to do is the evil export dance anymore. Yeah. because the reason that we use this is the fact that if you have a project like this which is about using blockchain, you like crazily-modified kernel so that if someone wants to... If we wanted to sell an open-source crypto library that has to be filed against the headers, we don't want to public that, you know? There are structure changes that you have to do. So, it's kind of a non-initial idea. And also, in order to start, by the nature of we were developing the base that's ahead of us, Who will vote for democracy? Yeah, but this is also... They make a point of not having any US citizen work on the crypto code. Okay, any other questions? Yes? So the question is if there's anything that would prevent conflicts in the port street because open NTPD, OB-HTPD and let's scan crypt, which is another port that I created recently, they require LiraSSL. So the issue is that the developed ports actually provide you the features that you need for these as well. So with the new ports framework that I talked about earlier, it should be a lot easier to make it so that the development port satisfies the dependency for the regular one. Does it make any sense to you? Yeah. No, this is getting better with the new USIS framework. That is... It's not there. It is there, but it's not in the tree yet, which is slightly different. It's in review, so it's almost done. So you can... You should expect that in the coming week or weeks. Maybe. Anything else? Please, otherwise I'll show you my backup slides and that's boring. This is the Pearl entropy gathering demon. So 12 years you don't need it anymore, but still it's in there and it's not guarded with anything. So I was very lucky. This is from Apache 2.4, right? This is not something old I dug up from the archives. That is properly new software. We now have 20, but this was at the time that LiraSSL was released. This is the DES deprecation. If you go through it, it's actually... It's not difficult to change. So it's not like you have to do massive things to actually do it. So this has changed and that has changed. I don't see the big deal with not being able to do that and the same goes for the other stuff. So what's your... Why haven't you done this? Why have you left all the deprecated methods in there? How broken open SSL is? This is a famous one where this is old. So in 2004, somebody committed a change and this is the relevant part. It tries to do an OR in an IF check and it uses exclamation marks instead of pipes. So nobody has ever used this because anything that would use this would blow up and it wouldn't compile. You must fix this to get it to compile. What did they do? They fixed it in the source code. They just rip it out. Yes, Sean? Why haven't we solved any of these things with the... So why haven't we changed DES to ROT13? Yeah, well, that would be evil, but it would be fun. That is something that I see Bob back doing. Yes, he is completely capable of such treachery. And there's this one, which is also fun. This is... Oh, I didn't have the registration date. There is a domain registration for Libre SSH.org and that is done by... Pardon? Soar losers. That's what they are. Is there anybody out here in the audience that is running natively or freeBSD but doesn't have a dog-fooding sticker just yet? Yeah, shut up, Peter. I'm waiting for someone to rip their hair. Okay, I grant you that. So, okay. These are the last two. You have no idea of how many have been... Four. Oh, that was it. So I'll make this public. There's a lot of links in here. The important ones are the wiki. So you can find all of the patches in these three on my blog. If I do anything, I make sure that I... Well, I started that but blogging is hard. It takes way more time than I would like. And the LibreBSD stuff, which is currently broken, I would assume, but at least you can find all the bits that you need on my GitHub. So be merry and if you find anything that is not working, let me know. My email address is public. It's everywhere. So there's so many ways that you can contact me and I'm always happy to fix more. Fixing is the only thing I'm good at, obviously. Thank you for your attention. Ooh, we're only two minutes late. This is amazing. Thank you. Thank you.
 Good afternoon. Welcome. I'm very happy with the turnout here. I've been working at this  for a long time and I was absolutely surprised with a number of people that approached me  and told me that we were actually using the stuff that I'm doing because in general you  only get some feedback if you break it, but not a lot of stuff if it just works. So I  think not hearing things, I'll take that as a good thing for now and I'll just keep  with it and do these kinds of silly things. So for you, all of you that do not know me,  I've been a long time FreeBSD user probably since 5.3-ish, which was shortly after the  5.0, which I have not experienced, which was very bad. I'm not a developer by profession,  I am sorry by education. I am actually a chemical engineer and I'm definitely not a cryptographer.  So if you want to know about Chacha and Poly, I know that they exist, but I don't know from  front or back of it to see actually what it does. I just make it work. I've been an active  contributor in the FreeBSD channel on FreeNote for as long as I can think of, I guess, from  the early days and I'm the maintainer of the LibreSSL ports, MariaDB ports, which is a MySQL  replacement. Yes, I'm sorry for you too. And I currently have some new ports coming up.  I've just been relieved from mentorship as a ports committer. And I have a collection  of LibreSSL ports patches because not everything works with LibreSSL out of the box. And I'll  come back to that. My day job is an enterprise application integration architect at Philips  Lighting. If you ever get offered that job, don't, it's boring. So this is why I do all  this stuff in the evenings. And if an emergency patch arrives, that will be happening through  the day anyway. And I'm a volunteer at our local fiber cooperative, which is in a bit  of trouble, but we'll figure it out. And I do a bit of volunteering for Bits of Freedom,  which is kind of the Dutch chapter of EFF, EDRI. So it's all about privacy. And I did  a bit of a toolbox, or I've written a bit of the toolbox.  So how did we get here? Everybody, I assume, recalls Heartbleed, which was very bad. And  in April 2014, our OpenBSD friends decided that it was time to fork OpenSSL and make  it a bit saner. So they did. And I started live blogging the flensing, as they call it,  of the OpenSSL code. And they removed everything left and right, and TDo's and Joel's and  all. If you look at the commit messages, it was hilarious to see what was going on all  the way through these first months. They removed all the old platforms, insecure features,  and they ended up, oh, sorry, yeah, well, this is an intermittent slide. So Heartbleed  was an implementation-specific problem in OpenSSL. But there's also a lot of SSL attacks  recently on the protocol itself, which I've listed here. I've stolen this from somebody  else's presentation. But in red, I have the stuff in there that is actually deprecated.  And thou shalt not use this anymore in 2015 or 16. So you see that a lot of old stuff  that you have around in your software ecosystem actually leads to a lot of issues. And not  having them anymore provides you benefit because you could strike these ones out. They're just  not available anymore. The Core Infrastructure Initiative, this is something which started  very shortly after Libre SSL was started. It's my feeling that it was a reaction to the stuff  that Libre was doing. It is, I think it's funded by the Linux Foundation. Sorry, I don't have  the thing on the screen here, so I'll be looking at that. This machine is too new, so we don't  have the graphics driver yet. And they had a security audit by NCC, which uncovered a  lot of problems. And I think we had, I think every couple of months, there would be a new  OpenSSL patch release where the findings of NCC group were fixed and that led to a lot  of emergency patching. I know that Ray Perceval told me that he had sleepless nights because  he had to get out and make sure that all his OpenSSL stacks were upgraded again. So where  did Libre SSL end up? Well, at least 35% of the code was removed, so that's good. So all  of the unsecure and outdated features and platforms have been completely removed. So  I'm sorry you cannot try this on BOS or VaxVMS or anything. And the first portable release  happened halfway of 2015, and that's where the story starts outside of OpenBSD for the  rest of the world. They added new features as well a bit later on, which was LibTLS initially.  Which is a wrapper around LibCrypto and LibSSL, but with less food shooting capability, so  it tries to do the things smartly and securely for you. So if you can, use it. And they bought  back as a showcase for LibTLS the SSLified Netcat, which you all have. In FreeBSD, our  Netcat is the OpenBSD Netcat. And if you were to install the Libre SSL ports, you get a  Netcat that does SSL as well in addition. So this is going to be fun to merge the current  one back into base FreeBSD, because that surely does not have Libre SSL yet. So it also ended  up, this is as far as I know it. I've heard that you actually have a Libre SSL binary  on OSX. I know they state that OpenELEC, that's a code thing that you can run on an RPI or  anything else, uses Libre SSL. Void Linux has Libre SSL integrated. I know for Gen2, well,  he can do about anything, so let's forget about them.  PCBSD, if anybody runs PCBSD, this runs PCBSD. PCBSD uses Libre SSL from ports for all of  the ports. And if you were to find one that still links base OpenSSL, do let me know,  now we'll make sure it no longer does. HardenBSD is in the process of starting to migrate completely  to Libre SSL. And that's now kind of a proof of concept, and we're making sure that everything's  fine and dandy, and then it will be shipped. OpenSense already uses Libre SSL, I believe,  in a separate branch, if you want to, for all of the ports, so not for base yet. But  HardenBSD is probably going to be the first one where you can have free SSD without OpenSSL.  What the command is there, but all the old code, all the OpenSSL code has been replaced  with Libre. So I collected some things from OpenSSL in base, so these are the security  announcements, which is quite a lot. And this means usually that you have an upgrade of  your complete system for an OpenSSL vulnerability. You might notice that there is one which I  don't have a number for yet. So you'll be very busy next week somewhere, because there  is one of the vulnerabilities has already been published, or it's a scientific paper  on vulnerability in the DSA signing, which mostly hits you in OpenSSH. So please go and  disable DSA in OpenSSH for now. It's already fixed in Libre SSL, because it was, if it's  out in the open, the guys immediately hit it and they roll a new version. So the port,  security Libre SSL, was ported within a day after 11th of July 2015 by Zavolot from RSPAMD.  So the port was there very early. And currently we are as of yesterday, day before yesterday.  FreeBSD is at 236 for the regular port and 241 for the development port. I'm using the  development port on my server at home already, not a port, sorry, in base, because you get  full IETF compliant Cha-Cha 20 Poly 1305. So I don't know what it is, but I have it.  So vulnerabilities, this is something, and I made sure that I listed it here, those counts  are outdated. So since they forked, I tallied up all of the things that were coming by and  the levels and what you should be able to see is that with Libre SSL, you had none of  the high vulnerabilities, you had about half of the medium vulnerabilities, and a lot fewer  of the low classified vulnerabilities, which I think was pretty awesome. So you have to  patch less and the stuff that you have to patch is actually usually of a lower criticality.  Is it that simple? Well, of course not, that would be too easy. So with the first release,  I was using it myself. At some point, Chris Moore, he wanted, or sorry, he approached  me to see if I were willing to see what would happen if they would switch to the Libre SSL  port for PCBSD, and that's when I got my ex-brun capability, because anything I do now folds  back into PCBSD. PCBSD will build the whole port tree, and I know exactly what fallout  I have because the putery air logs are publicly visible, so I just have to see what changed,  what broke, and we roll on from that. The amazing part was that there's also software  that broke which you would not actually expect, like the Apache Demon. I discovered that very  early because that's something I personally use still. I know I'm a bit old by now. Python  wasn't working, OpenL that would fail to build, Curl would fail to build, fail to build, and  that surprised me because I would think that they would be upfront with security and everything  that is possible because some of these things were pretty stupid. With the advent of Libre  SSL 2.3, I went through the same thing again. This is about a year later. They removed SSL  V3 completely, which catches out a lot of ports because they just don't have not implemented  that even though the no SSL 3 flag has been available in Open SSL for a long time during  build. Again, a lot of very large visible projects failing. That is what I've been doing and  that tends to be a lot of work and there's a lot of crunch time because you want to get  that stuff out there as soon as possible. You turn through all the ports and make sure  that they work again. There's a lot of bad examples out there. Somehow, the crappy stuff  that people do, it proliferates, perpetuates, people copy the wrong examples. What you see  actually is that patching many a time isn't that difficult because actually you'll be  just redoing the same thing over and over again for exactly the same way somebody's implemented  it. It is almost to the point where you could apply the patch from one project to another  project, which was scary. SSL V2.3. If you do build something nowadays with SSL, do please  use SSL V2.3 methods that are available in both Open SSL and Libre SSL. It allows you  to create SSL connections up to TLS version 1.2. The 2.3 is meaningless. It's just anything.  You will find TLS replacements in Libre SSL, but I also believe in Open SSL from 1.1.0,  which are exactly the same, but just SSL V2.3 is replaced with TLS and everything just works.  Then you have the SSL operations flags, which just allow you to switch off anything you  don't like, like TLS V1.1, whatever you wish. One thing that I've been hit with is the version  number checking that everybody does. This is bad practice, so you see a lot of projects  checking for a specific version number of Open SSL to detect that compression was added  to Open SSL. We know that compression is problematic, but if you remove that from the code, you're  going to be hit with a lot of projects failing because they failed either during build or  even during runtime on something not being available anymore. Do not check version numbers.  The last statement, they can, will and should be deprecated at some moment. Be as do your  checks proper, check for like a define that is made specifically for a feature or whatever  you can do, but don't check the version number. I talked about upstreaming a bit before.  Upstreaming is a tedious process that actually takes more work than doing the patching. I  have about 200 of these, so you will be connecting with anybody and everybody, and you will be  connecting with projects that are just blatantly refusing to add anything that would aid Open  SSL, for some unknown reason. So there are those. And we have a lot of old abandoned,  un-maintained, whatever you have ports in our ports tree. I think one of the, if this  is all stabilized and everything is done, I kind of make, I think I'll make it my personal  crusade to kill all that stuff and to start deprecating a hell of a lot of ports in our  tree because specifically if you talk about things that use SSL and stuff, you want to  have maintained stuff in your ports tree, you don't want to have things that are no  longer maintained. That's just a fire hazard. So I still have a huge number of patches to  upstream or to find the point where you can upstream too because things don't no longer  exist and I felt like trolling through a mord of dead code and stuff. This is really horrible.  If you want to have a look at all of the patches, so if you are using it or if you're intending  to use it, I have lists with patches usually of all of the things that can fail on the  FreeBSD Wiki page. The presentation will be publicly available so you can check later  on in the slides. There is a slide with all the links that you can use from the PDF. And  if you have time and you're willing to, helping out with the upstreaming would be most welcome  because there's a lot of hoops to jump through nowadays. People want you to sign contributor  agreements and I'm like, I added two and I added one or two if-defs. So you want me  to or shall I tell you what you need to do and then you do it yourself because you don't  want to go through the hassle anymore of faxing signed paper. I don't even have a fax for  God's sake. So the FreeBSD Ports Tree has another number of interesting problems issues. There's  still a lot of ports that don't actually honor the with OpenSSL port flag that you can set  in your make.conf. So you would want it to build with OpenSSL from ports but actually  it will grab OpenSSL from base. This is currently very nicely apparent if you have a, if you  run HED which FreeBSD11 has OpenSSL102H and the port is also 102H. There's a difference  however. The base system has SCTP enabled. The port has SCTP disabled. So we saw CMake  blow up because actually so it was using the headers from the one and at link time it used  the other one which doesn't really match up. You wanted to say something Matt?  Yeah, if you fuck the jury for the fault of the one who needed it so far, they'll be  okay. Yeah, I know. If I find them, I fix them. This is, it's, and there's been very  silly things that you need to go through to actually make software use the correct libraries.  Actually the libraries that you want. And mixing base and OpenSSL ports linking in your ports  is a recipe for disaster. It will bite you immediately, later on. Funky things happen.  Just don't. Just stay out of there. Don't do it. And there's this tiny thing you must  rebuild or, well, if you, if you use Poudrier, that's fine. You must rebuild all your ports  when you switch to Libre or even if you switch from Libre to Libre Devel because otherwise  you'll have funky results. It just, just don't. So I wanted to tell you a bit about the lifespan  and the end of life of all of these products. So FreeBSD9, 903 is still supported, right?  Till the end of next year, I think? End of this year. Well, that means that we're running  an end of an unsupported OpenSSL version for a year. And actually I was checking up on  it this morning. 0.9.8 has been productive then for 10 and a half years, which is for  a security product pretty long. So we're now in the 10 branch. That is our main, so our  main OpenSSL version is 101. That will get security patches up to the end of next year.  Sorry, this year, yeah. And then it had about a lifespan of a little less than five years.  So we'll be running 10.3 for quite some time with an unsupported OpenSSL version, which  is poor practice, I guess. But hey, Red Hat does the work for us, so we just bring in  their patches and be done with it. For 11, we have imported 102 now, which has full support  until the end of 2019, which is again about five years. And I'm quite sure that we will  run out of time by the end of the 11 branch, where we're still on 102, but it's already  the end of life. So if you compare that with OpenBSD, thank you guys. They're on the clock.  Well, sometimes they'll tell you they'll release a new version at the first of April, but then  that is April Fools. So they actually release every first of May and every first of November,  and they only ever support two versions of Libra SSL. So this is an issue if you want  to run it in base, because you don't have a very stable Libra SSL version going forward.  And I'm quite sure that nobody's going to be willing to backport any fixes to earlier  Libra SSL versions. I would say don't. So this is what it looks like, and I tried to  visualize that a bit. So these are kind of the things where we are vulnerable, we have  an unsupported OpenSSL version in the FreeBSD stuff. So you see here in 098 was released  2005, 100, 2010, 101 was released in 2012. So here 2015 was 102, and 110 should already  be released, but there's some delay. So that, yeah, they said somewhere in May, but it's  June as far as last time I looked. That's what my flight ticket said. Okay, then there's  what can you do with it? So I think about two years ago, Adam McDougall, he wanted to  have a place where he could build his ports without having to deal with OpenSSL from base  completely. That actually is not as straightforward as it looks because we have a without OpenSSL  flag for source.conf, but that doesn't build because there's more things that you need  to disable which have not been included in the dependency tree for some reason. So you  have to set a couple of other things, and you have to disable SSL in Libfetch, which  is not very nice. Ultimately, we found out that this is only really useful if you're  running in a jail because if you start running this in a live system, you'll get trouble  with package and Libfetch because they are very specific in the way that they link the  libraries. Then another thing where Alan Jude had been working on, and I kind of stole his  patch and tried to make it even better, is to make libraries private. In 3BZ, we have  private libraries that are not available for linking against. So on 10x, you will have  them in user Libprivate, and in 11, they will be renamed into Libprivate SSL, Libprivate  Crypto, or whatever. Yeah. I've tried to use, because all the not all ports will use the  correct libraries, and there's a, I've linked here a PR which kind of lists all of these  things that have a problem. This, again, gives you trouble with package and Libfetch. That  is the consistent thing, and I am told it is absolutely possible, ultimately, to make  Libcrito private, but that needs even more work than we've done on it already. So the  result was okay, but the problem is that you'll have is package and Libfetch. So then why not  replace OpenSSL in base? If OpenBSD can run it in base, why can't we? So I tried this.  I was at a hackathon in Croatia with the Libra SSL and OpenBSD devs, and I tried that,  but it was a bit fresh on make files, and I didn't know the base system at all at that  time because I only did port. So I failed miserably. I had an absolutely great time  with these guys if you ever can, and they ask you to come, go. They're the best to hang  out with. And Brent Cook, he's the, he does the portable build or the release engineering  mostly. He said, well, no, don't, don't do it, don't try to do it a free busy way. Just  import our make files and be done with it. And I was, well, not comfortable enough with  that yet. But so the other thing that you should take away if the OpenBSD devs tell  you, you better do it this way, then you could actually try it and it might work. And then  suddenly comes along Sean, and Sean probably had seen my work as well, Sean Webb from  HardenBSD, and he had a challenge for me. Can you create for us a configurable Libra  SSL in freeBSD or HardenBSD base? And we were discussing a bit with that same  possible. So I started at work. And actually, if I listened to Brent Cook, and I follow  his advice, then actually it wasn't really all that difficult.  So a bit about the base system framework. So everything, they didn't use a source. We  have our main make files. So there's two things where I needed to patch up for 10 in  BZO and in 11 in source ops. I added a knob with Libra SSL, just like you have with OpenSSL,  without OpenSSL. It works exactly in the same way. You have crypto, use a source crypto  OpenSSL where the actual sources live for OpenSSL. And then in secure Lib and use a bin,  you have the actual make files that will build the stuff from crypto. So these are the ones  that I focused on. So for Libra SSL, what did I do? Just unpacked  Libra SSL into crypto, just a portable tarble. You unpack it, you rename it, you're done.  And I actually did it this week with a 241 release. I rebuilt OpenSSL or Libra SSL in  this case and it was all fine. So in secure Lib, Lib Crypto, I just added  additional files with a suffix Libra SSL, which is so the ink is the one that gets included  everywhere for main variables. And this will actually build Libra SSL, the same for Lib  SSL. I added Lib TLS and Netcat. And these make files, basically, they are the ones that  I imported from OpenBSD's base system. So pull them from CVS, not from GitHub or anywhere.  So really the basic thing. So this is what happens in the background with  Libra SSL. So there's default no options. Actually, we now switched in hard and B3, the Libra  SSL branch to default yes options Libra SSL because that's the whole point of that treatment.  And this is what you need to do to get it to build. This transforms internally all of  these transform into make Libra SSL. So that's what you need to check for. And I had to add  Lib TLS where possible because that's a library so that should be known to the whole framework.  The existing make files, once I, oh, actually this is wrong but never mind you can find  the sources, you need to include the correct options make file from share make. And all  you need to do is check if it's no, the original make file is just in here verbatim so I don't  do anything about the current stuff only if make Libra SSL. So at the end I include the  Libra SSL file. So if you don't do anything, you get exactly what you have now. So you  get open SSL in the version that is in the base system.  So this makes switching extremely easy because you can flip the switch, rebuild your base,  you need to rebuild all reports, you need a lot of time but not a lot of effort. So this  is why this has gone this way. And also if anything changes in open SSL, the whole thing  is still in there. So we just, we put it between the first if and we're fine. So also merging  is probably automatic because it's at the beginning and at the end for there's nothing  changes so any updates will just merge in with Git. And then once you've done that,  you start building, then we get back to 2001 again. In 2001, I have a backup slide if we  have too much time but I guess that won't happen. There's a commit in the open SSL  file. So you can see that says, yeah, well, we renamed all of the DES methods and they're  now no longer lowercase, they're uppercase. And the invocation is different not by reference  but with a pointer. And they included a header which is called DES underscore old.h. And they  will deprecate that by, what was it, before 100 appears. I can tell you it has now gone  in 110 which is not even out. So it's still there. It's 2016 so this happened about 10  years too late. LibTelnet and PPP in our base system have that deprecated stuff in there  still. It is trivial to replace with the modern ones but nobody's bothered ever to actually  do that so I think I now created PRs for these. And then we have Heimdall in base. For some  reason it's still one of the entropy gathering daemon and I think that thing has died long  ago. I think for the last 10 years there's not a single system that you can buy that  actually uses the PRL entropy gathering daemon but because OpenSSL had the methods everything  just assumes that it's there. And in 11 I encountered a bit of the future so did I tell  you about version number checks before to see if any features available? There you go. Even  in WPA so that's the wireless authentication. They had a check in the latest version, OpenSSL  version number. So but these again are pretty simple fixes. There is, sorry, I have however  introduced a tiny difference between ports and base. So what we did originally in the  port or CHEPCA actually, early on it was difficult if you keep the OpenSSL version number as  you find it in a tar bowl, it's defined as version 20000 which kind of freaks out because  everything that checks if a version is greater than whatever, two is always greater than  one for some reason. So these will all be evaluated to true and I would have, you have  things left and right falling over for lack of compression, what have you and it's deteriorated  of course with 110. So what Seville did, he added, he patched the version to be 101F which  is the time at which LibreSSL forked and then you have kind of a comparable set of features  in LibreSSL and that just works. So what happened later on is that LibreSSL also added a LibreSSL  version number which makes our life a lot more easy. So if there's any check for OpenSSL  version number we just say and not defined LibreSSL version number and usually 9 out  of 10 will just go through. I found that this change, I've now, I've not applied that for  base because I think it's time that we just use the stuff that we have. The fallout was  relatively low and these are all categorized on the wiki so if you want to go in and see  how much is affected, they all have their label in a table that says which feature is  actually failing. So this is WPA. So that was a check that they had so if it's larger  than 101 and I made it like this and then it's fine. I think that's upstreamal worthy  so that's not an issue anymore. So that flows back into our base system. LibreBSD? Well,  I've created a repo. I've called it LibreBSD but it's not going to be a distribution. Yes?  Yes, kind of. So you get a weird logo where I try to merge the what is it the Che Guevara  beret with the... So forget about this but it's not going to be a separate distribution.  It's going to be probably so it's going to be in hard and busy and PCBs if you want it  but I'm not going to maintain. I'm not going to fork. It's just this. So how far along  are we? We have 20 minutes left. Excellent. So I need to finalize and polish up the stuff  for LibreSSL in base. Actually, it's already further polished and done. Committing and  upstreaming the LibreSSL patches upstream. So for ports. So I've been released from mentorship.  I think I've been the guy that was mentored longest in the history of ports. So I don't  know why that is probably because I'm Mr. Chaos and I make the... It was just coops.  Oh. You'll be listening in because it's live streamed. Oh my God. I guess he was. He was  seeing this. That is the point. So I can now actually commit all that stuff for the old  things that are failing in ports. Anything that doesn't have a maintainer, I should be  just committing to the ports very soon. Hard and BSD and PCBs with LibreSSL as the default  Lib Crypto provider. I think that will be a very fast thing specifically because PCBs  already built fine all the ports with LibreSSL and base is no issue. So Matt Arnol, who is  our port manager, he has created something which is uses OpenSSL make. So... Okay. Yeah.  Well, it's use OpenSSL. Where did I... Okay. Yes. Typo. I'll fix that. That is about to  land in the port stream, I guess. So that means that all of the... It actually is backward  compatible. So use OpenSSL equals yes in your port's make file still works, but you should  be switching to users equals OpenSSL. And then you can add base, ports, OpenSSL, LibreSSL,  and LibreSSLDevail, and even OpenSSLDevail, which is also a port. One thing that I hear  pretty consistently out of the port's community is that at some point, FreeBSD intends to  switch all ports to default to OpenSSL from ports no longer from base. So the base OpenSSL  should be there with the only objective to serve anything that is in the base system.  And if you have ports, they all rely on ports OpenSSL. And yeah, well, I added three question  marks. I see no reason now seeing how easy it was to do this to have this in base as  well. So this is for the not so faint at heart because you'll be bumping the shared Libversion  more often, so at least once every half year. You can hold off for another six months, but  that's it. So you have a big change every year. But if you run on a home system, I guess  you'll be fine. So this is also why PCBSD could manage this because they build their  own, the upgrades that you get using the upgrade mechanisms. They have full control so they  can just flip it to the next version and everything is fine.  And the ironic bit that I found over the past months, I guess, since 1.1.0 was released,  is that I've found that OpenSSL benefits greatly from all the work that's been done by OpenBSD,  myself, anybody on Libres SL. Because guess what? What happened in version 1.1.0, which  is now in beta something, it's the fifth pre-release version? The SSL V3 methods have gone in the  default build. So you can re-enable them still, which you cannot in Libres SL, by the way.  So it's gone. So they would be facing exactly the same issues as I have with the previous  reports three, because the removal of SSL V3. So they don't have to go through that anymore.  All the patches are available already, so they have a smooth landing. Same goes for  EGD. It is no longer enabled by default in the build. So if somebody re... So the people  that still use Vax and BIOS and DOS and whatever, they can still do that. They can enable that  and they can use the Pearl entropy gathering demon, because that's a very smart plan. I  think... I don't really don't understand that, because if you still run a version... a system  that old, are you really going to upgrade to 1.1.0? I would imagine that everything just  caves in immediately. You have an immense implosion and your system stops functioning  all together. So that does all that I talked about before. After 15 years of promise, they  have removed it. And if you check now, I've created myself the OpenSSL developer, more  as an exercise to see if I could do that than anything else. And it has a lot of options,  but it defaults to what I think is sane and secure, which means that most of the stuff  that is questionable has been disabled there as well, enable it at your own... What is  it? At your own peril. Yes, absolutely. MD2, you can still have it.  So the last slides, I want to thank OpenBSD, the guys that I worked with before aren't  here, unfortunately. And I wasn't... Chris is not here. Is he somewhere else, probably?  Chris Moore from PCBSD, who... Yeah, we spent massive amounts of compute resources on building  the sports. Every time I update Libra's Excel now, he has to rebuild half of the port stream,  which is pretty significant. I want to thank HardenBSD, the team for the trust patients  in working with me to get this stuff done. And there's this guy, Frogs, who can't be  on other channels anymore because he has to go via tours, he's been of a tinfoil hat,  I guess. He pushed me to get stuff done very early days.  Alan Jude for the patches, for the private libraries, several... Kubilay Kochak or Coops,  as we call them, because his original name is a bit difficult for all of us. My two mentors  originally. Ooh! I now see I left out Mark Felder, who became my mentor a bit later. And  Johannes for their help, pushing and whatever, because I would never have got this done.  I hope to give a talk about what it means to actually start doing something with providing  back rather than being afraid to provide back because you think you're not good enough,  because obviously that is not true. I suck at everything, but still I can do this stuff.  Sorry? Oh, no. Oh, yeah. Oh, that, yeah, I think that would be a valuable experience.  Yes, he says I should mentor three people before giving the talk. This is the page of  links that I promise you and have some backup slides, but let's try... Is there any questions?  Yes? Yes, so the question is to the whole crowd, how does, how do formalities deal with  open or Libre SSL, for instance, PCI DSS compliance and stuff? Sean, you wanted to comment on  that?  Yes, sir. Sorry, with a bit of negative impact, but no that that I want to mention. So that  so in one of my friends does what happens in metah원�  one antiquities, and this one, which is  into the network.  then  should be okay with PCI  Yep, okay.  Sorry?  Yeah, auditors are funky people, right?  So they do whatever they want.  So you would be okay for PCI, but not for NICAP and common criteria.  You may be, yeah, okay.  Peter.  So you may not be losing anything.  I went to kind of go back to a little bit of its content.  gymnastics in order to pursue your compliance.  And then also the simple act of getting fifth compliance  is incredibly kind of assuming a lot of effort  and very, very, very expensive.  And we are not gonna do that work for it.  If someone else wants to assist with getting fifth compliance,  please talk to the U.S.S.L. team.  I believe there could be some interest there,  but it is not a strong-fired response.  Can I imagine?  I hope that that was recorded.  I think for PCI DSS, for instance, it matters.  If you're a, so we're a Dutch company  and if we process credit card data,  we still need to be PCI compliant.  Not FIPS, no.  But FIPS, that was, it forced you to use insecure things.  I don't get that, so.  Yeah.  I mean, we're not just looking to get to compound influx,  and there's other stuff that we call gigabit queens.  So if somebody gives out Polnithria hotelangra for you,  you need to get to their downtime rent.  But if that's about arming some queen,  that's best.  Hey, small resolute with me.  Yeah.  That's fine.  from level one to five.  Yeah.  Level one is definitely better than the other.  Right?  No.  Anything else from you?  I have some backups, so we could have fun.  The whole issue is the marketing export.  Yeah.  So, you know, it's the long-term that's previously  been placed in the cell.  So, you don't have to be the longest-in-tile  in the cell library that's just like the normal  and the long-term, the long-term,  the long-term, the long-term, the long-term.  No.  So, I think if it happens, it would be switchable  but defaulting.  So, you can always switch to the other one  because it's just then, well, it's not a drop-in replacement,  but mostly it's a...  So, you still get a fully functional base system.  So, that would not...  Partially, that's a problem.  There's a reason that these sources live in crypto  because the whole user-source crypto tree  would just be removed for export.  In the olden days, that's what I told me.  Yes, Peter.  So, to respond to that,  the U.S. removed most of the requirements  for export of open-source crypto in, I believe, in 2004.  General U.S. regulations about exporting any product  still apply.  But for anything that is open-source crypto  or a easily-purchasable crypto,  basically, what you don't need to do  is the evil export dance anymore.  Yeah.  because the reason that we use this is the fact that if you have a project like this which is about using blockchain,  you like crazily-modified kernel so that if someone wants to...  If we wanted to sell an open-source crypto library  that has to be filed against the headers,  we don't want to public that, you know?  There are structure changes that you have to do.  So, it's kind of a non-initial idea.  And also, in order to start, by the nature of we were developing the base that's ahead of us,  Who will vote for democracy?  Yeah, but this is also...  They make a point of not having any US citizen work on the crypto code.  Okay, any other questions?  Yes?  So the question is if there's anything that would prevent conflicts in the port street  because open NTPD, OB-HTPD and let's scan crypt, which is another port that I created  recently, they require LiraSSL.  So the issue is that the developed ports actually provide you the features that you  need for these as well.  So with the new ports framework that I talked about earlier, it should be a lot easier to  make it so that the development port satisfies the dependency for the regular one.  Does it make any sense to you?  Yeah.  No, this is getting better with the new USIS framework.  That is...  It's not there.  It is there, but it's not in the tree yet, which is slightly different.  It's in review, so it's almost done.  So you can...  You should expect that in the coming week or weeks.  Maybe.  Anything else?  Please, otherwise I'll show you my backup slides and that's boring.  This is the Pearl entropy gathering demon.  So 12 years you don't need it anymore, but still it's in there and it's not guarded with  anything.  So I was very lucky.  This is from Apache 2.4, right?  This is not something old I dug up from the archives.  That is properly new software.  We now have 20, but this was at the time that LiraSSL was released.  This is the DES deprecation.  If you go through it, it's actually...  It's not difficult to change.  So it's not like you have to do massive things to actually do it.  So this has changed and that has changed.  I don't see the big deal with not being able to do that and the same goes for the other  stuff.  So what's your...  Why haven't you done this?  Why have you left all the deprecated methods in there?  How broken open SSL is?  This is a famous one where this is old.  So in 2004, somebody committed a change and this is the relevant part.  It tries to do an OR in an IF check and it uses exclamation marks instead of pipes.  So nobody has ever used this because anything that would use this would blow up and it wouldn't  compile.  You must fix this to get it to compile.  What did they do?  They fixed it in the source code.  They just rip it out.  Yes, Sean?  Why haven't we solved any of these things with the...  So why haven't we changed DES to ROT13?  Yeah, well, that would be evil, but it would be fun.  That is something that I see Bob back doing.  Yes, he is completely capable of such treachery.  And there's this one, which is also fun.  This is...  Oh, I didn't have the registration date.  There is a domain registration for Libre SSH.org and that is done by...  Pardon?  Soar losers.  That's what they are.  Is there anybody out here in the audience that is running natively or freeBSD but doesn't  have a dog-fooding sticker just yet?  Yeah, shut up, Peter.  I'm waiting for someone to rip their hair.  Okay, I grant you that.  So, okay.  These are the last two.  You have no idea of how many have been...  Four.  Oh, that was it.  So I'll make this public.  There's a lot of links in here.  The important ones are the wiki.  So you can find all of the patches in these three on my blog.  If I do anything, I make sure that I...  Well, I started that but blogging is hard.  It takes way more time than I would like.  And the LibreBSD stuff, which is currently broken, I would assume, but at least you can  find all the bits that you need on my GitHub.  So be merry and if you find anything that is not working, let me know.  My email address is public.  It's everywhere.  So there's so many ways that you can contact me and I'm always happy to fix more.  Fixing is the only thing I'm good at, obviously.  Thank you for your attention.  Ooh, we're only two minutes late.  This is amazing.  Thank you.  Thank you.
Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_0_47.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_48_107.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_108_155.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_156_971.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_972_3875.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_3876_4931.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_4932_6035.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_6036_7427.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_7428_11855.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_11856_12167.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_12168_14015.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_14016_14291.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_14292_15383.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_15384_18587.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_18588_22451.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_22452_26063.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_26064_29063.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_29064_32567.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_32568_33587.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_33588_35255.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_35256_36803.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_36804_37019.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_37020_38675.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_38676_39623.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_39624_40907.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_40908_42347.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_42348_43403.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_43404_43463.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_43464_45395.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_45396_45515.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_45516_46523.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_46524_46715.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_46716_46787.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_46788_47015.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_47016_47147.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_47148_48023.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_48024_48551.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_48552_51947.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_51948_52943.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_52944_58151.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_58152_61607.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_61608_64199.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_64200_64247.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_64248_64343.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_64344_64655.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_64656_79175.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_79176_79871.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_79872_79931.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_79932_80639.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_80640_82475.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_82476_83855.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_83856_83903.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_83904_85487.png Open_LibreSSL_in_FreeBSD_JGgoBQ0hVpw_85488_85502.png
Good afternoon. Welcome. I'm very happy with the turnout here. I've been working at this for a long time and I was absolutely surprised with a number of people that approached me and told me that we were actually using the stuff that I'm doing because in general you only get some feedback if you break it, but not a lot of stuff if it just works. So I think not hearing things, I'll take that as a good thing for now and I'll just keep with it and do these kinds of silly things. So for you, all of you that do not know me, I've been a long time FreeBSD user probably since 5.3-ish, which was shortly after the 5.0, which I have not experienced, which was very bad. I'm not a developer by profession, I am sorry by education. I am actually a chemical engineer and I'm definitely not a cryptographer. So if you want to know about Chacha and Poly, I know that they exist, but I don't know from front or back of it to see actually what it does. I just make it work. I've been an active contributor in the FreeBSD channel on FreeNote for as long as I can think of, I guess, from the early days and I'm the maintainer of the LibreSSL ports, MariaDB ports, which is a MySQL replacement. Yes, I'm sorry for you too. And I currently have some new ports coming up. I've just been relieved from mentorship as a ports committer. And I have a collection of LibreSSL ports patches because not everything works with LibreSSL out of the box. And I'll come back to that. My day job is an enterprise application integration architect at Philips Lighting. If you ever get offered that job, don't, it's boring. So this is why I do all this stuff in the evenings. And if an emergency patch arrives, that will be happening through the day anyway. And I'm a volunteer at our local fiber cooperative, which is in a bit of trouble, but we'll figure it out. And I do a bit of volunteering for Bits of Freedom, which is kind of the Dutch chapter of EFF, EDRI. So it's all about privacy. And I did a bit of a toolbox, or I've written a bit of the toolbox. So how did we get here? Everybody, I assume, recalls Heartbleed, which was very bad. And in April 2014, our OpenBSD friends decided that it was time to fork OpenSSL and make it a bit saner. So they did. And I started live blogging the flensing, as they call it, of the OpenSSL code. And they removed everything left and right, and TDo's and Joel's and all. If you look at the commit messages, it was hilarious to see what was going on all the way through these first months. They removed all the old platforms, insecure features, and they ended up, oh, sorry, yeah, well, this is an intermittent slide. So Heartbleed was an implementation-specific problem in OpenSSL. But there's also a lot of SSL attacks recently on the protocol itself, which I've listed here. I've stolen this from somebody else's presentation. But in red, I have the stuff in there that is actually deprecated. And thou shalt not use this anymore in 2015 or 16. So you see that a lot of old stuff that you have around in your software ecosystem actually leads to a lot of issues. And not having them anymore provides you benefit because you could strike these ones out. They're just not available anymore. The Core Infrastructure Initiative, this is something which started very shortly after Libre SSL was started. It's my feeling that it was a reaction to the stuff that Libre was doing. It is, I think it's funded by the Linux Foundation. Sorry, I don't have the thing on the screen here, so I'll be looking at that. This machine is too new, so we don't have the graphics driver yet. And they had a security audit by NCC, which uncovered a lot of problems. And I think we had, I think every couple of months, there would be a new OpenSSL patch release where the findings of NCC group were fixed and that led to a lot of emergency patching. I know that Ray Perceval told me that he had sleepless nights because he had to get out and make sure that all his OpenSSL stacks were upgraded again. So where did Libre SSL end up? Well, at least 35% of the code was removed, so that's good. So all of the unsecure and outdated features and platforms have been completely removed. So I'm sorry you cannot try this on BOS or VaxVMS or anything. And the first portable release happened halfway of 2015, and that's where the story starts outside of OpenBSD for the rest of the world. They added new features as well a bit later on, which was LibTLS initially. Which is a wrapper around LibCrypto and LibSSL, but with less food shooting capability, so it tries to do the things smartly and securely for you. So if you can, use it. And they bought back as a showcase for LibTLS the SSLified Netcat, which you all have. In FreeBSD, our Netcat is the OpenBSD Netcat. And if you were to install the Libre SSL ports, you get a Netcat that does SSL as well in addition. So this is going to be fun to merge the current one back into base FreeBSD, because that surely does not have Libre SSL yet. So it also ended up, this is as far as I know it. I've heard that you actually have a Libre SSL binary on OSX. I know they state that OpenELEC, that's a code thing that you can run on an RPI or anything else, uses Libre SSL. Void Linux has Libre SSL integrated. I know for Gen2, well, he can do about anything, so let's forget about them. PCBSD, if anybody runs PCBSD, this runs PCBSD. PCBSD uses Libre SSL from ports for all of the ports. And if you were to find one that still links base OpenSSL, do let me know, now we'll make sure it no longer does. HardenBSD is in the process of starting to migrate completely to Libre SSL. And that's now kind of a proof of concept, and we're making sure that everything's fine and dandy, and then it will be shipped. OpenSense already uses Libre SSL, I believe, in a separate branch, if you want to, for all of the ports, so not for base yet. But HardenBSD is probably going to be the first one where you can have free SSD without OpenSSL. What the command is there, but all the old code, all the OpenSSL code has been replaced with Libre. So I collected some things from OpenSSL in base, so these are the security announcements, which is quite a lot. And this means usually that you have an upgrade of your complete system for an OpenSSL vulnerability. You might notice that there is one which I don't have a number for yet. So you'll be very busy next week somewhere, because there is one of the vulnerabilities has already been published, or it's a scientific paper on vulnerability in the DSA signing, which mostly hits you in OpenSSH. So please go and disable DSA in OpenSSH for now. It's already fixed in Libre SSL, because it was, if it's out in the open, the guys immediately hit it and they roll a new version. So the port, security Libre SSL, was ported within a day after 11th of July 2015 by Zavolot from RSPAMD. So the port was there very early. And currently we are as of yesterday, day before yesterday. FreeBSD is at 236 for the regular port and 241 for the development port. I'm using the development port on my server at home already, not a port, sorry, in base, because you get full IETF compliant Cha-Cha 20 Poly 1305. So I don't know what it is, but I have it. So vulnerabilities, this is something, and I made sure that I listed it here, those counts are outdated. So since they forked, I tallied up all of the things that were coming by and the levels and what you should be able to see is that with Libre SSL, you had none of the high vulnerabilities, you had about half of the medium vulnerabilities, and a lot fewer of the low classified vulnerabilities, which I think was pretty awesome. So you have to patch less and the stuff that you have to patch is actually usually of a lower criticality. Is it that simple? Well, of course not, that would be too easy. So with the first release, I was using it myself. At some point, Chris Moore, he wanted, or sorry, he approached me to see if I were willing to see what would happen if they would switch to the Libre SSL port for PCBSD, and that's when I got my ex-brun capability, because anything I do now folds back into PCBSD. PCBSD will build the whole port tree, and I know exactly what fallout I have because the putery air logs are publicly visible, so I just have to see what changed, what broke, and we roll on from that. The amazing part was that there's also software that broke which you would not actually expect, like the Apache Demon. I discovered that very early because that's something I personally use still. I know I'm a bit old by now. Python wasn't working, OpenL that would fail to build, Curl would fail to build, fail to build, and that surprised me because I would think that they would be upfront with security and everything that is possible because some of these things were pretty stupid. With the advent of Libre SSL 2.3, I went through the same thing again. This is about a year later. They removed SSL V3 completely, which catches out a lot of ports because they just don't have not implemented that even though the no SSL 3 flag has been available in Open SSL for a long time during build. Again, a lot of very large visible projects failing. That is what I've been doing and that tends to be a lot of work and there's a lot of crunch time because you want to get that stuff out there as soon as possible. You turn through all the ports and make sure that they work again. There's a lot of bad examples out there. Somehow, the crappy stuff that people do, it proliferates, perpetuates, people copy the wrong examples. What you see actually is that patching many a time isn't that difficult because actually you'll be just redoing the same thing over and over again for exactly the same way somebody's implemented it. It is almost to the point where you could apply the patch from one project to another project, which was scary. SSL V2.3. If you do build something nowadays with SSL, do please use SSL V2.3 methods that are available in both Open SSL and Libre SSL. It allows you to create SSL connections up to TLS version 1.2. The 2.3 is meaningless. It's just anything. You will find TLS replacements in Libre SSL, but I also believe in Open SSL from 1.1.0, which are exactly the same, but just SSL V2.3 is replaced with TLS and everything just works. Then you have the SSL operations flags, which just allow you to switch off anything you don't like, like TLS V1.1, whatever you wish. One thing that I've been hit with is the version number checking that everybody does. This is bad practice, so you see a lot of projects checking for a specific version number of Open SSL to detect that compression was added to Open SSL. We know that compression is problematic, but if you remove that from the code, you're going to be hit with a lot of projects failing because they failed either during build or even during runtime on something not being available anymore. Do not check version numbers. The last statement, they can, will and should be deprecated at some moment. Be as do your checks proper, check for like a define that is made specifically for a feature or whatever you can do, but don't check the version number. I talked about upstreaming a bit before. Upstreaming is a tedious process that actually takes more work than doing the patching. I have about 200 of these, so you will be connecting with anybody and everybody, and you will be connecting with projects that are just blatantly refusing to add anything that would aid Open SSL, for some unknown reason. So there are those. And we have a lot of old abandoned, un-maintained, whatever you have ports in our ports tree. I think one of the, if this is all stabilized and everything is done, I kind of make, I think I'll make it my personal crusade to kill all that stuff and to start deprecating a hell of a lot of ports in our tree because specifically if you talk about things that use SSL and stuff, you want to have maintained stuff in your ports tree, you don't want to have things that are no longer maintained. That's just a fire hazard. So I still have a huge number of patches to upstream or to find the point where you can upstream too because things don't no longer exist and I felt like trolling through a mord of dead code and stuff. This is really horrible. If you want to have a look at all of the patches, so if you are using it or if you're intending to use it, I have lists with patches usually of all of the things that can fail on the FreeBSD Wiki page. The presentation will be publicly available so you can check later on in the slides. There is a slide with all the links that you can use from the PDF. And if you have time and you're willing to, helping out with the upstreaming would be most welcome because there's a lot of hoops to jump through nowadays. People want you to sign contributor agreements and I'm like, I added two and I added one or two if-defs. So you want me to or shall I tell you what you need to do and then you do it yourself because you don't want to go through the hassle anymore of faxing signed paper. I don't even have a fax for God's sake. So the FreeBSD Ports Tree has another number of interesting problems issues. There's still a lot of ports that don't actually honor the with OpenSSL port flag that you can set in your make.conf. So you would want it to build with OpenSSL from ports but actually it will grab OpenSSL from base. This is currently very nicely apparent if you have a, if you run HED which FreeBSD11 has OpenSSL102H and the port is also 102H. There's a difference however. The base system has SCTP enabled. The port has SCTP disabled. So we saw CMake blow up because actually so it was using the headers from the one and at link time it used the other one which doesn't really match up. You wanted to say something Matt? Yeah, if you fuck the jury for the fault of the one who needed it so far, they'll be okay. Yeah, I know. If I find them, I fix them. This is, it's, and there's been very silly things that you need to go through to actually make software use the correct libraries. Actually the libraries that you want. And mixing base and OpenSSL ports linking in your ports is a recipe for disaster. It will bite you immediately, later on. Funky things happen. Just don't. Just stay out of there. Don't do it. And there's this tiny thing you must rebuild or, well, if you, if you use Poudrier, that's fine. You must rebuild all your ports when you switch to Libre or even if you switch from Libre to Libre Devel because otherwise you'll have funky results. It just, just don't. So I wanted to tell you a bit about the lifespan and the end of life of all of these products. So FreeBSD9, 903 is still supported, right? Till the end of next year, I think? End of this year. Well, that means that we're running an end of an unsupported OpenSSL version for a year. And actually I was checking up on it this morning. 0.9.8 has been productive then for 10 and a half years, which is for a security product pretty long. So we're now in the 10 branch. That is our main, so our main OpenSSL version is 101. That will get security patches up to the end of next year. Sorry, this year, yeah. And then it had about a lifespan of a little less than five years. So we'll be running 10.3 for quite some time with an unsupported OpenSSL version, which is poor practice, I guess. But hey, Red Hat does the work for us, so we just bring in their patches and be done with it. For 11, we have imported 102 now, which has full support until the end of 2019, which is again about five years. And I'm quite sure that we will run out of time by the end of the 11 branch, where we're still on 102, but it's already the end of life. So if you compare that with OpenBSD, thank you guys. They're on the clock. Well, sometimes they'll tell you they'll release a new version at the first of April, but then that is April Fools. So they actually release every first of May and every first of November, and they only ever support two versions of Libra SSL. So this is an issue if you want to run it in base, because you don't have a very stable Libra SSL version going forward. And I'm quite sure that nobody's going to be willing to backport any fixes to earlier Libra SSL versions. I would say don't. So this is what it looks like, and I tried to visualize that a bit. So these are kind of the things where we are vulnerable, we have an unsupported OpenSSL version in the FreeBSD stuff. So you see here in 098 was released 2005, 100, 2010, 101 was released in 2012. So here 2015 was 102, and 110 should already be released, but there's some delay. So that, yeah, they said somewhere in May, but it's June as far as last time I looked. That's what my flight ticket said. Okay, then there's what can you do with it? So I think about two years ago, Adam McDougall, he wanted to have a place where he could build his ports without having to deal with OpenSSL from base completely. That actually is not as straightforward as it looks because we have a without OpenSSL flag for source.conf, but that doesn't build because there's more things that you need to disable which have not been included in the dependency tree for some reason. So you have to set a couple of other things, and you have to disable SSL in Libfetch, which is not very nice. Ultimately, we found out that this is only really useful if you're running in a jail because if you start running this in a live system, you'll get trouble with package and Libfetch because they are very specific in the way that they link the libraries. Then another thing where Alan Jude had been working on, and I kind of stole his patch and tried to make it even better, is to make libraries private. In 3BZ, we have private libraries that are not available for linking against. So on 10x, you will have them in user Libprivate, and in 11, they will be renamed into Libprivate SSL, Libprivate Crypto, or whatever. Yeah. I've tried to use, because all the not all ports will use the correct libraries, and there's a, I've linked here a PR which kind of lists all of these things that have a problem. This, again, gives you trouble with package and Libfetch. That is the consistent thing, and I am told it is absolutely possible, ultimately, to make Libcrito private, but that needs even more work than we've done on it already. So the result was okay, but the problem is that you'll have is package and Libfetch. So then why not replace OpenSSL in base? If OpenBSD can run it in base, why can't we? So I tried this. I was at a hackathon in Croatia with the Libra SSL and OpenBSD devs, and I tried that, but it was a bit fresh on make files, and I didn't know the base system at all at that time because I only did port. So I failed miserably. I had an absolutely great time with these guys if you ever can, and they ask you to come, go. They're the best to hang out with. And Brent Cook, he's the, he does the portable build or the release engineering mostly. He said, well, no, don't, don't do it, don't try to do it a free busy way. Just import our make files and be done with it. And I was, well, not comfortable enough with that yet. But so the other thing that you should take away if the OpenBSD devs tell you, you better do it this way, then you could actually try it and it might work. And then suddenly comes along Sean, and Sean probably had seen my work as well, Sean Webb from HardenBSD, and he had a challenge for me. Can you create for us a configurable Libra SSL in freeBSD or HardenBSD base? And we were discussing a bit with that same possible. So I started at work. And actually, if I listened to Brent Cook, and I follow his advice, then actually it wasn't really all that difficult. So a bit about the base system framework. So everything, they didn't use a source. We have our main make files. So there's two things where I needed to patch up for 10 in BZO and in 11 in source ops. I added a knob with Libra SSL, just like you have with OpenSSL, without OpenSSL. It works exactly in the same way. You have crypto, use a source crypto OpenSSL where the actual sources live for OpenSSL. And then in secure Lib and use a bin, you have the actual make files that will build the stuff from crypto. So these are the ones that I focused on. So for Libra SSL, what did I do? Just unpacked Libra SSL into crypto, just a portable tarble. You unpack it, you rename it, you're done. And I actually did it this week with a 241 release. I rebuilt OpenSSL or Libra SSL in this case and it was all fine. So in secure Lib, Lib Crypto, I just added additional files with a suffix Libra SSL, which is so the ink is the one that gets included everywhere for main variables. And this will actually build Libra SSL, the same for Lib SSL. I added Lib TLS and Netcat. And these make files, basically, they are the ones that I imported from OpenBSD's base system. So pull them from CVS, not from GitHub or anywhere. So really the basic thing. So this is what happens in the background with Libra SSL. So there's default no options. Actually, we now switched in hard and B3, the Libra SSL branch to default yes options Libra SSL because that's the whole point of that treatment. And this is what you need to do to get it to build. This transforms internally all of these transform into make Libra SSL. So that's what you need to check for. And I had to add Lib TLS where possible because that's a library so that should be known to the whole framework. The existing make files, once I, oh, actually this is wrong but never mind you can find the sources, you need to include the correct options make file from share make. And all you need to do is check if it's no, the original make file is just in here verbatim so I don't do anything about the current stuff only if make Libra SSL. So at the end I include the Libra SSL file. So if you don't do anything, you get exactly what you have now. So you get open SSL in the version that is in the base system. So this makes switching extremely easy because you can flip the switch, rebuild your base, you need to rebuild all reports, you need a lot of time but not a lot of effort. So this is why this has gone this way. And also if anything changes in open SSL, the whole thing is still in there. So we just, we put it between the first if and we're fine. So also merging is probably automatic because it's at the beginning and at the end for there's nothing changes so any updates will just merge in with Git. And then once you've done that, you start building, then we get back to 2001 again. In 2001, I have a backup slide if we have too much time but I guess that won't happen. There's a commit in the open SSL file. So you can see that says, yeah, well, we renamed all of the DES methods and they're now no longer lowercase, they're uppercase. And the invocation is different not by reference but with a pointer. And they included a header which is called DES underscore old.h. And they will deprecate that by, what was it, before 100 appears. I can tell you it has now gone in 110 which is not even out. So it's still there. It's 2016 so this happened about 10 years too late. LibTelnet and PPP in our base system have that deprecated stuff in there still. It is trivial to replace with the modern ones but nobody's bothered ever to actually do that so I think I now created PRs for these. And then we have Heimdall in base. For some reason it's still one of the entropy gathering daemon and I think that thing has died long ago. I think for the last 10 years there's not a single system that you can buy that actually uses the PRL entropy gathering daemon but because OpenSSL had the methods everything just assumes that it's there. And in 11 I encountered a bit of the future so did I tell you about version number checks before to see if any features available? There you go. Even in WPA so that's the wireless authentication. They had a check in the latest version, OpenSSL version number. So but these again are pretty simple fixes. There is, sorry, I have however introduced a tiny difference between ports and base. So what we did originally in the port or CHEPCA actually, early on it was difficult if you keep the OpenSSL version number as you find it in a tar bowl, it's defined as version 20000 which kind of freaks out because everything that checks if a version is greater than whatever, two is always greater than one for some reason. So these will all be evaluated to true and I would have, you have things left and right falling over for lack of compression, what have you and it's deteriorated of course with 110. So what Seville did, he added, he patched the version to be 101F which is the time at which LibreSSL forked and then you have kind of a comparable set of features in LibreSSL and that just works. So what happened later on is that LibreSSL also added a LibreSSL version number which makes our life a lot more easy. So if there's any check for OpenSSL version number we just say and not defined LibreSSL version number and usually 9 out of 10 will just go through. I found that this change, I've now, I've not applied that for base because I think it's time that we just use the stuff that we have. The fallout was relatively low and these are all categorized on the wiki so if you want to go in and see how much is affected, they all have their label in a table that says which feature is actually failing. So this is WPA. So that was a check that they had so if it's larger than 101 and I made it like this and then it's fine. I think that's upstreamal worthy so that's not an issue anymore. So that flows back into our base system. LibreBSD? Well, I've created a repo. I've called it LibreBSD but it's not going to be a distribution. Yes? Yes, kind of. So you get a weird logo where I try to merge the what is it the Che Guevara beret with the... So forget about this but it's not going to be a separate distribution. It's going to be probably so it's going to be in hard and busy and PCBs if you want it but I'm not going to maintain. I'm not going to fork. It's just this. So how far along are we? We have 20 minutes left. Excellent. So I need to finalize and polish up the stuff for LibreSSL in base. Actually, it's already further polished and done. Committing and upstreaming the LibreSSL patches upstream. So for ports. So I've been released from mentorship. I think I've been the guy that was mentored longest in the history of ports. So I don't know why that is probably because I'm Mr. Chaos and I make the... It was just coops. Oh. You'll be listening in because it's live streamed. Oh my God. I guess he was. He was seeing this. That is the point. So I can now actually commit all that stuff for the old things that are failing in ports. Anything that doesn't have a maintainer, I should be just committing to the ports very soon. Hard and BSD and PCBs with LibreSSL as the default Lib Crypto provider. I think that will be a very fast thing specifically because PCBs already built fine all the ports with LibreSSL and base is no issue. So Matt Arnol, who is our port manager, he has created something which is uses OpenSSL make. So... Okay. Yeah. Well, it's use OpenSSL. Where did I... Okay. Yes. Typo. I'll fix that. That is about to land in the port stream, I guess. So that means that all of the... It actually is backward compatible. So use OpenSSL equals yes in your port's make file still works, but you should be switching to users equals OpenSSL. And then you can add base, ports, OpenSSL, LibreSSL, and LibreSSLDevail, and even OpenSSLDevail, which is also a port. One thing that I hear pretty consistently out of the port's community is that at some point, FreeBSD intends to switch all ports to default to OpenSSL from ports no longer from base. So the base OpenSSL should be there with the only objective to serve anything that is in the base system. And if you have ports, they all rely on ports OpenSSL. And yeah, well, I added three question marks. I see no reason now seeing how easy it was to do this to have this in base as well. So this is for the not so faint at heart because you'll be bumping the shared Libversion more often, so at least once every half year. You can hold off for another six months, but that's it. So you have a big change every year. But if you run on a home system, I guess you'll be fine. So this is also why PCBSD could manage this because they build their own, the upgrades that you get using the upgrade mechanisms. They have full control so they can just flip it to the next version and everything is fine. And the ironic bit that I found over the past months, I guess, since 1.1.0 was released, is that I've found that OpenSSL benefits greatly from all the work that's been done by OpenBSD, myself, anybody on Libres SL. Because guess what? What happened in version 1.1.0, which is now in beta something, it's the fifth pre-release version? The SSL V3 methods have gone in the default build. So you can re-enable them still, which you cannot in Libres SL, by the way. So it's gone. So they would be facing exactly the same issues as I have with the previous reports three, because the removal of SSL V3. So they don't have to go through that anymore. All the patches are available already, so they have a smooth landing. Same goes for EGD. It is no longer enabled by default in the build. So if somebody re... So the people that still use Vax and BIOS and DOS and whatever, they can still do that. They can enable that and they can use the Pearl entropy gathering demon, because that's a very smart plan. I think... I don't really don't understand that, because if you still run a version... a system that old, are you really going to upgrade to 1.1.0? I would imagine that everything just caves in immediately. You have an immense implosion and your system stops functioning all together. So that does all that I talked about before. After 15 years of promise, they have removed it. And if you check now, I've created myself the OpenSSL developer, more as an exercise to see if I could do that than anything else. And it has a lot of options, but it defaults to what I think is sane and secure, which means that most of the stuff that is questionable has been disabled there as well, enable it at your own... What is it? At your own peril. Yes, absolutely. MD2, you can still have it. So the last slides, I want to thank OpenBSD, the guys that I worked with before aren't here, unfortunately. And I wasn't... Chris is not here. Is he somewhere else, probably? Chris Moore from PCBSD, who... Yeah, we spent massive amounts of compute resources on building the sports. Every time I update Libra's Excel now, he has to rebuild half of the port stream, which is pretty significant. I want to thank HardenBSD, the team for the trust patients in working with me to get this stuff done. And there's this guy, Frogs, who can't be on other channels anymore because he has to go via tours, he's been of a tinfoil hat, I guess. He pushed me to get stuff done very early days. Alan Jude for the patches, for the private libraries, several... Kubilay Kochak or Coops, as we call them, because his original name is a bit difficult for all of us. My two mentors originally. Ooh! I now see I left out Mark Felder, who became my mentor a bit later. And Johannes for their help, pushing and whatever, because I would never have got this done. I hope to give a talk about what it means to actually start doing something with providing back rather than being afraid to provide back because you think you're not good enough, because obviously that is not true. I suck at everything, but still I can do this stuff. Sorry? Oh, no. Oh, yeah. Oh, that, yeah, I think that would be a valuable experience. Yes, he says I should mentor three people before giving the talk. This is the page of links that I promise you and have some backup slides, but let's try... Is there any questions? Yes? Yes, so the question is to the whole crowd, how does, how do formalities deal with open or Libre SSL, for instance, PCI DSS compliance and stuff? Sean, you wanted to comment on that? Yes, sir. Sorry, with a bit of negative impact, but no that that I want to mention. So that so in one of my friends does what happens in metah원� one antiquities, and this one, which is into the network. then should be okay with PCI Yep, okay. Sorry? Yeah, auditors are funky people, right? So they do whatever they want. So you would be okay for PCI, but not for NICAP and common criteria. You may be, yeah, okay. Peter. So you may not be losing anything. I went to kind of go back to a little bit of its content. gymnastics in order to pursue your compliance. And then also the simple act of getting fifth compliance is incredibly kind of assuming a lot of effort and very, very, very expensive. And we are not gonna do that work for it. If someone else wants to assist with getting fifth compliance, please talk to the U.S.S.L. team. I believe there could be some interest there, but it is not a strong-fired response. Can I imagine? I hope that that was recorded. I think for PCI DSS, for instance, it matters. If you're a, so we're a Dutch company and if we process credit card data, we still need to be PCI compliant. Not FIPS, no. But FIPS, that was, it forced you to use insecure things. I don't get that, so. Yeah. I mean, we're not just looking to get to compound influx, and there's other stuff that we call gigabit queens. So if somebody gives out Polnithria hotelangra for you, you need to get to their downtime rent. But if that's about arming some queen, that's best. Hey, small resolute with me. Yeah. That's fine. from level one to five. Yeah. Level one is definitely better than the other. Right? No. Anything else from you? I have some backups, so we could have fun. The whole issue is the marketing export. Yeah. So, you know, it's the long-term that's previously been placed in the cell. So, you don't have to be the longest-in-tile in the cell library that's just like the normal and the long-term, the long-term, the long-term, the long-term, the long-term. No. So, I think if it happens, it would be switchable but defaulting. So, you can always switch to the other one because it's just then, well, it's not a drop-in replacement, but mostly it's a... So, you still get a fully functional base system. So, that would not... Partially, that's a problem. There's a reason that these sources live in crypto because the whole user-source crypto tree would just be removed for export. In the olden days, that's what I told me. Yes, Peter. So, to respond to that, the U.S. removed most of the requirements for export of open-source crypto in, I believe, in 2004. General U.S. regulations about exporting any product still apply. But for anything that is open-source crypto or a easily-purchasable crypto, basically, what you don't need to do is the evil export dance anymore. Yeah. because the reason that we use this is the fact that if you have a project like this which is about using blockchain, you like crazily-modified kernel so that if someone wants to... If we wanted to sell an open-source crypto library that has to be filed against the headers, we don't want to public that, you know? There are structure changes that you have to do. So, it's kind of a non-initial idea. And also, in order to start, by the nature of we were developing the base that's ahead of us, Who will vote for democracy? Yeah, but this is also... They make a point of not having any US citizen work on the crypto code. Okay, any other questions? Yes? So the question is if there's anything that would prevent conflicts in the port street because open NTPD, OB-HTPD and let's scan crypt, which is another port that I created recently, they require LiraSSL. So the issue is that the developed ports actually provide you the features that you need for these as well. So with the new ports framework that I talked about earlier, it should be a lot easier to make it so that the development port satisfies the dependency for the regular one. Does it make any sense to you? Yeah. No, this is getting better with the new USIS framework. That is... It's not there. It is there, but it's not in the tree yet, which is slightly different. It's in review, so it's almost done. So you can... You should expect that in the coming week or weeks. Maybe. Anything else? Please, otherwise I'll show you my backup slides and that's boring. This is the Pearl entropy gathering demon. So 12 years you don't need it anymore, but still it's in there and it's not guarded with anything. So I was very lucky. This is from Apache 2.4, right? This is not something old I dug up from the archives. That is properly new software. We now have 20, but this was at the time that LiraSSL was released. This is the DES deprecation. If you go through it, it's actually... It's not difficult to change. So it's not like you have to do massive things to actually do it. So this has changed and that has changed. I don't see the big deal with not being able to do that and the same goes for the other stuff. So what's your... Why haven't you done this? Why have you left all the deprecated methods in there? How broken open SSL is? This is a famous one where this is old. So in 2004, somebody committed a change and this is the relevant part. It tries to do an OR in an IF check and it uses exclamation marks instead of pipes. So nobody has ever used this because anything that would use this would blow up and it wouldn't compile. You must fix this to get it to compile. What did they do? They fixed it in the source code. They just rip it out. Yes, Sean? Why haven't we solved any of these things with the... So why haven't we changed DES to ROT13? Yeah, well, that would be evil, but it would be fun. That is something that I see Bob back doing. Yes, he is completely capable of such treachery. And there's this one, which is also fun. This is... Oh, I didn't have the registration date. There is a domain registration for Libre SSH.org and that is done by... Pardon? Soar losers. That's what they are. Is there anybody out here in the audience that is running natively or freeBSD but doesn't have a dog-fooding sticker just yet? Yeah, shut up, Peter. I'm waiting for someone to rip their hair. Okay, I grant you that. So, okay. These are the last two. You have no idea of how many have been... Four. Oh, that was it. So I'll make this public. There's a lot of links in here. The important ones are the wiki. So you can find all of the patches in these three on my blog. If I do anything, I make sure that I... Well, I started that but blogging is hard. It takes way more time than I would like. And the LibreBSD stuff, which is currently broken, I would assume, but at least you can find all the bits that you need on my GitHub. So be merry and if you find anything that is not working, let me know. My email address is public. It's everywhere. So there's so many ways that you can contact me and I'm always happy to fix more. Fixing is the only thing I'm good at, obviously. Thank you for your attention. Ooh, we're only two minutes late. This is amazing. Thank you. Thank you.
Heartbleed, which was very bad. And in April which uncovered a lot of problems. And I think we of NCC group were fixed and that led to a lot of SSL, because it was, if it's out in the open, the ported within a day after 11th of July 2015 by the first release, I was using it myself. At some folds back into PCBSD. PCBSD will build the whole would fail to build, Curl would fail to build, some of these things were pretty stupid. With the during build. Again, a lot of very large visible work again. There's a lot of bad examples out project to another project, which was scary. SSL lot of projects failing because they failed specifically if you talk about things that use the FreeBSD Ports Tree has another number of actually make software use the correct libraries. fixes to earlier Libra SSL versions. I would say things where we are vulnerable, we have an So you see here in 098 was released 2005, 100, way that they link the libraries. Then another have private libraries that are not available for linking against. So on 10x, you will have them in OpenSSL in base? If OpenBSD can run it in base, the portable build or the release engineering affected, they all have their label in a table committing to the ports very soon. Hard and BSD the ports with LibreSSL and base is no issue. So version? The SSL V3 methods have gone in the three, because the removal of SSL V3. So they version... a system that old, are you really created myself the OpenSSL developer, more as an this which is about using blockchain, you like structure changes that you have to do. So, it's changed. I don't see the big deal with not being able to do that and the same goes for the other methods in there? How broken open SSL is? This is