I've said this before, but kudos to the OpenBSD Project for shouldering a disproportionate share of the burden of maintaining core bits of our libre/open infrastructure. I can't think of anyone in tech who has not benefited mightily from OpenSSH and who will not benefit mightily from LibreSSL.
This article is a good reminder for me to get off my arse and cut my meager grad-student checks to the EFF and OpenBSD project.
if you can get five people to buy CDs, and maybe two of them get another two or three to buy CDs, you'll have done much more good for the project than cutting a check.
Among the good and bad stories this year, so far, LibreSSL is the good story of the year.
Also happy to hear a bit about the ressl API. To me it sounds like a focused, high-level API that makes it easy to get right and hard to get wrong. So kind of like NaCl. It's clearly the future -- look at the huge amount of software being written for Sodium now, for example. It's huge.
In which you can see the clear focus on usability rather than capability. To examplify how easy it is, he actually implements the API with a go "backend".
I also really like the concept of a simple API where you can't go wrong by default, hope it can make its way into other pieces of software as well.
> In particular, we answer the question "What would the user like to do?" and not "What does the TLS protocol allow the user to do?"
This makes me think of the laudable approach taken by the developers for the Cryptography library for python. Expose functions to users with sane and safe settings to users, and provide the abilities to override the defaults if you really must (but in such a manner that it's extremely clear that you're stepping into dangerous territory)
> Is OpenSSL being notified of security bugs you all find in your pairing down process?
Determining whether a bug can actually be exploited (on what system, under what configuration?) is hard work, and it's harder still to prove a negative. Mostly the OpenBSD devs just fix the bug and move on. If it looks like the typical kind of a bug that could lead to crashes, they release a patch against the previous two releases (assuming the code is present there).
A lot of the bugs they fix turn out to be "security bugs" only long after someone else finds that out on a version of the code running on another system not hardened by the OpenBSD devs.
After 5.6, if any serious bug is found, you can expect to find a patch for it on http://www.openbsd.org/errata56.html ; however, as the code between LibreSSL and OpenSSL diverges, it won't be obvious whether they apply to OpenSSL at all.
What's so surprising? OpenBSD folks don't fall for the next new shiny thing. 10 years from now, something else might take over git, and everyone will jump to it. OpenBSD folks don't care, if what they have works, they stick to it.
OpenBSD is developed as a complete operating system following a cathedral model. LibreSSL is part of the OpenBSD base system (as libssl), which is hosted on CVS. Naturally, so will LibreSSL.
OpenBSD was one of the first open source projects to make their CVS repositories public, you can read more about it in Chuck Cranor and Theo de Raadt's paper on Anonymous CVS.
There is some agonizing done over the rewrite culminating in the need for a redesign of the API. I've wondered why there wasn't a light-weight library that simply implemented the smallest number of protocols to delivered the necessary components for a secure HTTPS connection. You'd have some other library for other protocols, but this one should have the feature of being as light-weight (and small) as possible. Wouldn't that be the cyphersuite of choice for most hosting facilities?
Off-topic, but the markup of that page is really interesting. I've never seen someone do this before:
<h1>LibreSSL: More Than 30 Days Later</h1>
Ted Unangst<p>
[email protected]<p>
LibreSSL was officially announced to the world just about exactly five months
ago. Bob spoke at BSDCan about the first 30 days. For those who weren't there,
I'll quickly rehash some of that material. Also, it's always best to start at
the beginning, but then I'll try to focus on some new material and updates.
It kinda bugs me when time-sensitive articles (like those about software) are published without a date on them. The article does not mention a date when it was written, I assume it was recently. It mentions "2014-09-09 FreeBSD advisory", and the date today is 2014-09-28, so September 2014 is a good bet.
While I agree that C is the wrong language for security-critical applications (and I write this as a mostly C developer myself), I strongly disagree that C++ is a better language. Sure, it has constructors and destructors and pass-by-reference, but that's not enough, and cons/destr's don't fit the common memory usage-model of performance-critical applications (where an SSL library is often used), which use preallocated memory pools.
* they broke features in their releases (no QA/testing?)
* they're making a new API based on requirements of their own programs that doesn't provide many of the OpenSSL features.
* they're using CVS, no public code reviews available. There's no evidence some of the changes were reviewed by someone other than who made the commit. (OpenSSL now does reviews)
* no public audit available.
* they have some hateful note about hipsters on their web page as an excuse after 5 months to not make it readable. So unprofessional it hurts.
* Most changes were done five months ago, with not much at all done for two months.
* The test/ directory has very few changes at all. No extra tests have been added.
* I can't find a release plan, architecture documentation, or any documentation a serious software project should have. (OpenSSL is working on these though)
Finally... their official distribution website doesn't use SSL. That's a major security issue of the face palm variety.
Not. Inspiring. Confidence.
The OpenSSL project on the other hand has been doing some good work. Please see the projects road map from July to see what they are changing. https://www.openssl.org/about/roadmap.html
* Nah, the BSD guys are removing their dependency on OpenSSL, which is terribly broken for a number of reasons. They are not offering to replace OpenSSL for everyone on every platform. That's not their goal. They've said this from the beginning. But not all is lost for you (the non-BSD guy complaining that BSD codes doesn't work outside BSD). Eventually the code will make it downstream. And they've dedicated a lot of thought to how to do that in a more secure manner than OpenSSL. Inspiring.
* They kept the core functionality intact. Were you going to use heartbeats over TCP? Do you know even know what it is? How many of those on-by-default-workarounds were you using? Yeah they removed features. But for crypto code the lack of a rats nest is a feature.
* They are maintaining compatibility with the old API for legacy code and developing a more sane API. Do you have something constructive to say about how an API might look for interop with your favorite flavor of software? Great! To the mailing list with you!
* This was a tear down of code, not a reimplementation from scratch. But yeah, I agree. People should be looking over LibreSSL much more closely than OpenSSL. Sounds like that's something you would be interested in? ;)
* It's open source? And there are discussions on the mailing list? What kind of public audit did you have in mind?
* Don't really think hipster comments have much to do with LibreSSL's quality?
* Can you point to evidence of the claim that not much has been changed in the last two months? Can you point to things you would have liked to see change?
* No extra tests are needed, as they removed features. As features get added, yeah they're going to need to add some tests.
* They don't exactly sit around in conference rooms and write reports for upper management. Have you checked out their mailing list?
Aren't their packages signed and CVS transported over SSL? It's not like the code/packages are compromised. Otherwise, yeah I agree. It would be nice to have secure hateful hipster notes. ;). Kidding aside there's no reason not to add SSL. They should get on that.
I'm thankful that someone is doing something about OpenSSL, which is a blight. I'm sorry I can't personally afford to do more to help. Criticality is a positive thing, especially with regard to crypto/security code. But aren't you being a little smidge cynical?
* It's broken on other platforms, because those platforms are unable to provide sufficient primitives. LibreSSL directly inspired the introduction of a long-needed getrandom(2) syscall in Linux, and the LibreSSL-portable release still works on a decent number of platforms that will definitely be growing. Did you forget this is an early project? If anything, LibreSSL will ensure that other platforms get off their asses and actually do something about security, as OpenBSD has been trying to yell about for so long.
* In case you missed the memo, LibreSSL wasn't stable back then (nor is it still, AFAIK). Of course things will break, it was still development releases and pre-alpha testing. You can't fix a mess without inevitably breaking someone's workflow.
* They're making an API that will improve on the cruft of the old one, and actually be reasonably sane. Being agnostic of implementation internals will mean easier language bindings. They also explicitly stated it's meant to be independent of LibreSSL and can be adapted to other stacks.
* Stop bikeshedding about version control. It gets old. OpenBSD has had probably the most proactive security auditing and code review practices out of any other project in nearly two decades: http://www.openbsd.org/security.html. Code review isn't some magic process, it's a practice that can be done using a variety of methods. No doubt independent audits will emerge as soon as LibreSSL nears sufficient finalization.
The LibreSSL website is only a brochure. It's made to be "unprofessional" on purpose. The developers have a technical, no-bullshit and take-no-prisoners attitude.
And of course, next time we hear of OpenBSD having more difficulties, people will jump about Theo de Raadt being mean. I'm starting to understand where he comes from.
[+] [-] peatmoss|11 years ago|reply
This article is a good reminder for me to get off my arse and cut my meager grad-student checks to the EFF and OpenBSD project.
[+] [-] riffraff|11 years ago|reply
Disproportionate based on/compared to what? (I agree that the openbsd folks do a ton of good, I am just trying to understand your references here)
[+] [-] pyvpx|11 years ago|reply
[+] [-] Panino|11 years ago|reply
Also happy to hear a bit about the ressl API. To me it sounds like a focused, high-level API that makes it easy to get right and hard to get wrong. So kind of like NaCl. It's clearly the future -- look at the huge amount of software being written for Sodium now, for example. It's huge.
[+] [-] rakoo|11 years ago|reply
In which you can see the clear focus on usability rather than capability. To examplify how easy it is, he actually implements the API with a go "backend".
I also really like the concept of a simple API where you can't go wrong by default, hope it can make its way into other pieces of software as well.
[+] [-] ianlevesque|11 years ago|reply
[+] [-] Twirrim|11 years ago|reply
This makes me think of the laudable approach taken by the developers for the Cryptography library for python. Expose functions to users with sane and safe settings to users, and provide the abilities to override the defaults if you really must (but in such a manner that it's extremely clear that you're stepping into dangerous territory)
[+] [-] MoOmer|11 years ago|reply
Is OpenSSL being notified of security bugs you all find in your pairing down process?
[+] [-] clarry|11 years ago|reply
Determining whether a bug can actually be exploited (on what system, under what configuration?) is hard work, and it's harder still to prove a negative. Mostly the OpenBSD devs just fix the bug and move on. If it looks like the typical kind of a bug that could lead to crashes, they release a patch against the previous two releases (assuming the code is present there).
A lot of the bugs they fix turn out to be "security bugs" only long after someone else finds that out on a version of the code running on another system not hardened by the OpenBSD devs.
After 5.6, if any serious bug is found, you can expect to find a patch for it on http://www.openbsd.org/errata56.html ; however, as the code between LibreSSL and OpenSSL diverges, it won't be obvious whether they apply to OpenSSL at all.
[+] [-] bickfordb|11 years ago|reply
[+] [-] X-Istence|11 years ago|reply
[+] [-] segmondy|11 years ago|reply
[+] [-] vezzy-fnord|11 years ago|reply
[+] [-] brynet|11 years ago|reply
http://www.openbsd.org/papers/anoncvs-paper.pdf
http://www.openbsd.org/papers/anoncvs-slides.pdf
It makes sense, if you consider the fact they have been using for the last ~18 years.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] 1ris|11 years ago|reply
[+] [-] sigzero|11 years ago|reply
[+] [-] kchoudhu|11 years ago|reply
[deleted]
[+] [-] Beltiras|11 years ago|reply
[+] [-] rocky1138|11 years ago|reply
<h1>LibreSSL: More Than 30 Days Later</h1> Ted Unangst<p> [email protected]<p>
LibreSSL was officially announced to the world just about exactly five months ago. Bob spoke at BSDCan about the first 30 days. For those who weren't there, I'll quickly rehash some of that material. Also, it's always best to start at the beginning, but then I'll try to focus on some new material and updates.
<h1>openssl</h1>
[+] [-] ForHackernews|11 years ago|reply
> At the moment we are too busy deleting and rewriting code to make a decent web page. No we don't want help making web pages, thank you.
> This page scientifically designed to annoy web hipsters. Donate now to stop the Comic Sans and Blink Tags
[+] [-] _ZeD_|11 years ago|reply
[+] [-] felixrabe|11 years ago|reply
[+] [-] ams6110|11 years ago|reply
A more chronological catalog is at http://www.openbsd.org/papers/
[+] [-] felixrabe|11 years ago|reply
[+] [-] IshKebab|11 years ago|reply
C is clearly the wrong language for something this security critical if that's where your bugs are. C++ solved this many years ago.
[+] [-] AceJohnny2|11 years ago|reply
[+] [-] smosher_|11 years ago|reply
[+] [-] GFK_of_xmaspast|11 years ago|reply
[+] [-] illumen|11 years ago|reply
* it's broken on other platforms
* they broke features in their releases (no QA/testing?)
* they're making a new API based on requirements of their own programs that doesn't provide many of the OpenSSL features.
* they're using CVS, no public code reviews available. There's no evidence some of the changes were reviewed by someone other than who made the commit. (OpenSSL now does reviews)
* no public audit available.
* they have some hateful note about hipsters on their web page as an excuse after 5 months to not make it readable. So unprofessional it hurts.
* Most changes were done five months ago, with not much at all done for two months.
* The test/ directory has very few changes at all. No extra tests have been added.
* I can't find a release plan, architecture documentation, or any documentation a serious software project should have. (OpenSSL is working on these though)
Finally... their official distribution website doesn't use SSL. That's a major security issue of the face palm variety.
Not. Inspiring. Confidence.
The OpenSSL project on the other hand has been doing some good work. Please see the projects road map from July to see what they are changing. https://www.openssl.org/about/roadmap.html
[+] [-] xnull2guest|11 years ago|reply
* They kept the core functionality intact. Were you going to use heartbeats over TCP? Do you know even know what it is? How many of those on-by-default-workarounds were you using? Yeah they removed features. But for crypto code the lack of a rats nest is a feature.
* They are maintaining compatibility with the old API for legacy code and developing a more sane API. Do you have something constructive to say about how an API might look for interop with your favorite flavor of software? Great! To the mailing list with you!
* This was a tear down of code, not a reimplementation from scratch. But yeah, I agree. People should be looking over LibreSSL much more closely than OpenSSL. Sounds like that's something you would be interested in? ;)
* It's open source? And there are discussions on the mailing list? What kind of public audit did you have in mind?
* Don't really think hipster comments have much to do with LibreSSL's quality?
* Can you point to evidence of the claim that not much has been changed in the last two months? Can you point to things you would have liked to see change?
* No extra tests are needed, as they removed features. As features get added, yeah they're going to need to add some tests.
* They don't exactly sit around in conference rooms and write reports for upper management. Have you checked out their mailing list?
Aren't their packages signed and CVS transported over SSL? It's not like the code/packages are compromised. Otherwise, yeah I agree. It would be nice to have secure hateful hipster notes. ;). Kidding aside there's no reason not to add SSL. They should get on that.
I'm thankful that someone is doing something about OpenSSL, which is a blight. I'm sorry I can't personally afford to do more to help. Criticality is a positive thing, especially with regard to crypto/security code. But aren't you being a little smidge cynical?
[+] [-] kome|11 years ago|reply
Are you talking about this http://www.libressl.org/ ? That's one of the most readable webpage ever.
[+] [-] vezzy-fnord|11 years ago|reply
* In case you missed the memo, LibreSSL wasn't stable back then (nor is it still, AFAIK). Of course things will break, it was still development releases and pre-alpha testing. You can't fix a mess without inevitably breaking someone's workflow.
* They're making an API that will improve on the cruft of the old one, and actually be reasonably sane. Being agnostic of implementation internals will mean easier language bindings. They also explicitly stated it's meant to be independent of LibreSSL and can be adapted to other stacks.
* Stop bikeshedding about version control. It gets old. OpenBSD has had probably the most proactive security auditing and code review practices out of any other project in nearly two decades: http://www.openbsd.org/security.html. Code review isn't some magic process, it's a practice that can be done using a variety of methods. No doubt independent audits will emerge as soon as LibreSSL nears sufficient finalization.
The LibreSSL website is only a brochure. It's made to be "unprofessional" on purpose. The developers have a technical, no-bullshit and take-no-prisoners attitude.
And of course, next time we hear of OpenBSD having more difficulties, people will jump about Theo de Raadt being mean. I'm starting to understand where he comes from.
[+] [-] mmagin|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]