While I really enjoy Theo's talks and writings, I wonder if the fact that the VCS is CVS ain't a security issue in itself?
It's been really a long time I haven't used CVS but I remember that attempt to introduce backdoors in projects using Git as a (D)VCS have been caught (it was in the Linux kernel I think). IIRC some attempts were caught precisely because it's hard to fake SHA hashes and so people can't really "mess" with the history of a DVCS like Git: too many people noticed a critical file having no business being modified being, well... Modified.
Once again, it was quite a while ago but I'm pretty certain that both the fact that Git was decentralized and that Git was using cryptographically secure hashes was touted as a "Good Thing" [TM] that helped catch the backdooring attempts.
Git uses SHA-1 hashes, which have not been considered cryptographically secure since 2005.
Git and CVS are both just tools. They each provide a server implementation, but it's uncommon to use either of these for write access in large projects. It's more common to wrap CVS or Git with a different frontend like HTTPS or SSH. My guess is that the OpenBSD guys use OpenSSH.
This team is fanatical about security and process. I am completely comfortable with them using whichever tools they want.
SHA-1 has been shown to not be collision-resistant. Correct me if you've heard otherwise, but I believe SHA-1 is still believed to be second-preimage resistant.
In other words, with fewer than
2 * * 80
trials, an attacker can generate two files that have the same SHA-1 hash. (In the case of C source files, this probably means embedding a nonsense comment in the middle of each file, probably several hundred to several thousand ASCII characters.) If an attacker can get the very carefully constructed benign file past code review and have the ability to modify the repository, they can substitute the very carefully crafted malicious file for the very carefully crafted benign file without changing the root of the Merkle tree.
Assuming that SHA-1 is still second-preimage resistant, it will take an attacker about
2 * * 159
attempts to come up with a file that has the same hash as a legitimate file not carefully constructed by the attacker.
So, the weaknesses in SHA-1 probably mean that exploiting those weaknesses in the context of git still requires a mole in the development team. Though, I wouldn't want to bet my life on nobody noticing a big nonsense comment in the middle of a C file or someone figuring out how to construct a reasonably reviewable C file as the carefully crafted benign file.
In any case, the weaknesses in SHA-1 still likely pose a significant difficulty in forging a git history without planting a mole in the dev team. It's much better than no cryptographic barriers to forgery.
Conversely there are other signing techniques. GPG signed tags is an officially supported method.
Probably more importantly though, Git encourages everyone to have the full repository lying around. Even if you inserted a vulnerability in a master, there would still be thousands of copies of code which could be independently compared to find the exact changes which were made.
I think gpg signs just the sha1 the tag points to (root of merkle tree). Also, when comparing local repo against remote repo during fetch, I think git assumes that as long as the sha1 of a commit did not change, there is no need to compare further. So the substitution will not get propagated to people who do "git pull" but people who do "git clone" will get it.
Linus Torvalds: "the point is the SHA-1, as far as Git is concerned, isn't even a security feature. It's purely a consistency check. The security parts are elsewhere, so a lot of people assume that since Git uses SHA-1 and SHA-1 is used for cryptographically secure stuff, they think that, OK, it's a huge security feature. It has nothing at all to do with security, it's just the best hash you can get."
My reply was not intended as an attack on Git. I use it daily and would choose it 10 times out of 10 vs. CVS for a new project. I just think the assertion that Git 'saved' Linux from some backdooring attempts because it's decentralized and uses cryptographic hashes is wrong; it's not the tools that make this happen, it's the processes around the use of these tools which do that.
I don't know any OpenBSD developers nor do I have any inside knowledge of how their team works, but I know from observation that they are a small team with high standards for code style and quality. They don't just let anyone commit code and appear to be thorough with code review. When procedural/practice problems are identified in the industry, they are proactive about mitigating or fixing those. They have a demonstrated track record of good releases. Basically, I don't see any reason to question their use of CVS.
(first note that I didn't assert anything: I asked question(s) and used "IIRC" etc.)
I found the story back and things are, IMHO, actually quite interesting... If only because the attempt was made after someone ill-intentioned gained access to Linux's CVS repository.
Back then Linux was still using BitKeeper (decentralized) for Linus hadn't created Git yet (so I was not remembering things correctly here). But apparently some people didn't like BitKeeper so there was a CVS clone of the BitKeeper version. And it's in the CVS repo that the attempt took place (after someone hacked his way into the server hosting the CVS repo).
Now even though Linus didn't choose SHA-1 for its cryptographic properties and even if SHA-1 is not SHA-256 nor SHA-3, it still looks like an attacker gaining access to a CVS repo would have a much easier time inserting a backdoor than an attacker gaining access to DVCS using cryptographic hashes (which user KMag here explained nicely).
> Basically, I don't see any reason to question their use of CVS.
Why not ?
With CVS, the security rely on the security of a single server. Anybody with root access to the CVS server can modify history, and nobody would notice.
> Git uses SHA-1 hashes, which have not been considered cryptographically secure since 2005.
That a vast oversimplification. There are still no publicly-known preimage or second-preimage attacks against SHA-1. Even the collision attack in 2005 was limited insofar that it reduced the search from a brute-force 2^80 to 2^69.
Perhaps you're referring to a length extension attack, but I admit I don't know much about those in the context of Git's use of SHA-1.
In terms of C source files, unless the fist C source file being extended is at least 64 petabytes long, a length extension attack is going to embed null bytes in the C source file. I don't know chapter and verse of any of the C standards or GCC/Clang extensions, but I wouldn't be surprised if even string literals and comments including nulls cause problems for both GCC and Clang.
Anyone care to chime in/experiment with ways to embed nulls in C files such that either GCC or Clang will continue compiling code after hitting a null byte in the middle of a file? (I'm not talking about an escaped null in a character or string literal, but actually a 00 showing up in hexdump -C of the source.)
EDIT: I think it's safe to assume people will notice someone trying to sneak a 64-petabyte C source file into the codebase. With apologies to Sweet Brown, aint nobody got time for [downloading] that.
"I am completely comfortable with them using whichever tools they want."
Forgive me for saying so and I doubt you intend it so, but statements like this is what gets us into trouble. At a certain point we need to trust the people that build the foundation for us, but only once we've done our due diligence. Most people, maybe not you since you seem to know more about the team, have not yet.
As far as I read up about this some time ago, it boils down to the following reasons:
- CVS is simple - it's small (fits on a floppy with bsd.rd) and easy to use on exotic/slow architectures
- CVS is preferable for their current contribution workflow (centralized)
- CVS is treated as a tool that, currently, just works (tm)
It seems ever-so-slightly ironic that support for exotic architectures is considered a plus in this case, while support for exotic architectures is being ripped out of the OpenSSL/LibreSSL codebase. (Though probably not deeply ironic, since CVS is comparatively simple.)
It might seem ironic to people who do not understand the difference. OpenSSL includes wrappers and (probably untested since N years ago and therefore broken) code branches to work around bugs in old broken exotic systems that do not get fixed. This sort of code is a maintenance burden if you try to keep it working and just useless if you don't. It is also likely to introduce bugs. Getting rid of it simplifies the code and gets rid of bugs along with it.
OpenBSD's system level support for exotic platforms has more to do with drivers, compiler & tool chain support, boot code, etcetra. These do not create a jungle of ifdefs and workarounds in userspace applications. And if these platforms are broken, they are fixed instead of worked around with more jungle and weed. So support for these things does not add bugs for others.
On the contrary -- getting your software to run on a SPARC64 is more likely to expose flaws in your code.
I understand the point but this comes across as immature. OpenSSL has provided years of free software, supporting thousands of sites and applications.
Of course it has its problems, and there is nothing wrong with adding more competition in this space.
But what this space needs now, more than ever, is professionalism and pride in craft (by which I mean demonstrable unit test coverage, regression testing, fuzz testing and documentation) not silly music video jabs.
They've already done massive amounts of work already - adding missing checks, documenting a metric ton of magic numbers, removing VMS support, fixing year 2038 bugs, removing insecure cypher support, removing less secure replacements for secure OS inbuilts, unused code, and more, see http://opensslrampage.org.
On a side note, I was really hoping for the name to be OpenTLS (consistent with OpenBSD and OpenSSH, which are also OpenBSD maintained projects) or ValhallaTLS
I still can't believe such a fundamental backbone of the web runs on $2000/year. This is a -worldwide- service, and it runs on peanuts. It's flabbergasting. Please donate today if you can.
No. It needs corporate involvement, from Google, Red Hat, Amazon, Verisign etc. Lend minds, not money. By all means fund people to write it, but like it's not you who should be contributing, it's the corporations who rely on it.
Google and Amazon should be donating to LibreSSL, too. They may have no intention of using it in the next few years, but I'm sure they'd like for a solid alternative to be out there, so they can use it just in case they do change their minds, just like Google recently did with the switch from NSS to OpenSSL, just before Heartbleed happened.
It would've been smart of them to donate to OpenSSL starting a few years back, so that by the time they decided to quit NSS, they would've been sure OpenSSL is pretty solid, and would've also discovered the Heartbleed bug much earlier. They could not repeat the same mistake twice by donating to LibreSSL right now.
>OpenSSL has provided years of free software, supporting thousands of sites and applications.
And has done it so poorly that it has been a security nightmare the whole time. Just because something is given away, doesn't mean the world is obligated to be thankful for it. Giving away crap doesn't make it not stink.
Agreed. This is a bit scary. I feel the resources would be better off focusing on merging with the official OpenSSL project rather than forking and _then_ asking for funding, essentially taking any potential funding from the official OpenSSL project.
I get your point, but let's face it, the OpenBSD developers have done more to fix OpenSSL in the last two weeks that the OpenSSL developers done the last two years.
Some of the bug fixes have been pull from OpenSSLs bugtracker, they've just sat there for one or two years. This should make you think about what motivates the OpenSSL developers, my guess would be new crypto algorithms and the math, rather than maintaining a modern and secure crypto library.
Honestly the better solution might be to have the OpenSSL developers commit new code to the OpenBSD fork. For my understanding no one doubts that the OpenSSL developer understand the math and crypto in SSL and TLS, but they aren't the sharpest C programmers. There's no point in ostracising the OpenSSL developers, but maybe they should just focus on the parts that they do really well and let others, like the OpenBSD developer, productize their work.
Count the number of vulnerabilities in OpenSSL over the last few years, relative to the size of its code base. A single vulnerability, albeit bad this year, results in a fork and the attitude of "it had its chance."
LibreSSL inherits all of the undiscovered vulnerabilities in its huge code base. I hope your harsh criticism carries over to its code base once these flaws are discovered here too. That's the beauty of open source.
The problem is that a security software brick is not satisfactory when it works, but when you can be sure there are no problems.
Given the very low quality of the code and the high amount of bloat, few people actually trust it. They have to trust third-parties and external certifications and the word on the street, and this is not enough for that kind of dependency.
Quite frankly unless LibreSSL manages to raise more than 2000$ a year (what the OpenSSL fundation makes, apparently) I fail to see how they hope to avoid encountering the same kind of problems OpenSSL did (and still does). And given that the OpenBSD projects had to beg for donations to reach a 150k$ goal, if memory serves, I doubt they'll be able to sink a tremendous amount of money into LibreSSL.
If you can't pay people to work on the project full time, properly test and audit the code, sooner or later something will go wrong. And then we'll see people over here commenting along the lines of "my god those people are incompetent/irresponsible, they hope to get a free pass because it's free and open source, etc..."
Also, until I see a first release of the lib it's just marketing as far as I'm concerned, after all the OpenBSD foundation announced OpenCVS in 2004...
Well sure, OpenSSH is probably one of the most useful and versatile tools out there, there's no denying that it's a huge achievement.
That being said it's a program with mostly well defined use cases while OpenSSL is a library used in thousands of programs (including OpenSSH) on a variety of hardware and operating systems. The OpenBSD project naturally mostly cares about OpenBSD first and the rest second, which might be a bad thing if we end up with a multitude of forks each supporting a particular OS/architecture, increasing the chances of messing things up. After all, the latest big OpenSSH vulnerability was due to debian-specific patches...
Also, for what it's worth, sloccount tells me the latest snapshot of OpenSSH has about 90 thousand lines of code while OpenSSL has more than 360 thousand. It's a huge, huge library, forking and maintaining it is a tremendous undertaking, even compared to OpenSSH.
Which goes to show that you're not the intended end-consumer of this product and don't know their credentials. They are not newcomers to this space. If their tone is off-putting, maybe you should stop relying on OpenSSH too.
The tone and the footer encouraged me to actually donate even what little I have to this project.
The footer is a smack in the face to all those responsive bootstrap modern crap marketing websites - while this, table based layout, single page html provides more information and works in every device, with every resolution. Everything just included. As it should be.
This page probably took as much time to write as the sentences in the page - instead of fucking around with html initializr responsive themes, colors and oh god make it stop.
> removed MacOS, Netware, OS/2, VMS and Windows build machinery
What are the plans for native Windows support? I don't know what they mean by "The right Portability team in place", but it'd be a joke if the lib would require CygWin or some other external portability scaffolding. And without proper Windows support LibreSSL will simply fragment OpenSSL user base. I guess it's still better than nothing, but it definitely won't be an OpenSSL "replacement."
FWIW the usual OpenBSD story is "get it working, reliable and simple, on (Open)BSD, then add porting shims" (they'll have to add shims for linux anyway if they start using strlcpy)
maybe it's better to switch to NSS, the original SSL library developed by Netscape (now by Mozilla, Google, etc.), that is available under better open source licenses, is used in Firefox, (Chrome), OpenOffice, etc. and has an optional compatible API to OpenSSL: http://en.wikipedia.org/wiki/Network_Security_Services
From the Pros & Cons table, it doesn't seem that NSS is obviously superior to OpenSSL. Both seem to suffer from focus on extra features instead of maintenance and reliability.
The reasoning there is, certainly post-Heartbleed, very scary. Their conclusion boils down to that they want to use the system-provided OpenSSL on Android, rather than shipping NSS.
This might be fine if you're running a Nexus device that still gets updates to the latest Android (Nexus 4 and later?). But for everyone else, that's effectively forcing people to get a new Android phone if they don't want to get stuck with a horribly insecure phone.
In the doc, Google says NSS would need to be added to the base Android image.. so it's not going to be updated any faster than openSSL.
When powering WebView, Chromium on Android uses the Android system-provided OpenSSL library - something not available to applications building with the Android NDK (like Chrome for Android or other Chromium-based Android applications). This helps reduce memory usage by having a single shared library in memory. To accomplish this with NSS, NSS would have to be part of the Android base image - which would still increase memory usage, as most other Android (native) services would still use OpenSSL.
It says "On Android, Chromium uses OpenSSL." in the background section. The question is whether they want to switch other platforms to OpenSSL (or Android to NSS, or keep using both).
"Both seem to suffer from focus on extra features instead of maintenance and reliability."
Unfortunately in the SSL/TLS world, true security is a product of both, as minor flaws in the actual protocol itself are a common enough discovery to make the introduction of new "features" often quite key to the security of the implementation.
I don't see why this product would have a different porting strategy to the usual way OpenBSD projects (such as OpenSSH) handle it - target OpenBSD exclusively in the core project, and support other platforms with ports. Presumably that's what they are going to do here.
Probably none. Windows has its own CSP library which is a little more convenient in a win32 context than OpenSSL or anything POSIX TBH. I think they're doing the right thing here.
There's a ton of Windows software that uses OpenSSL as their security library. Moreover, there is a lot of Windows projects that are written in inherently portable way and using OpenSSL API is the most natural choice for them.
If StartSSL manages to topple OpenSSL and to discourage any further OpenSSL development, then that'd be a very bad thing for a lot developers.
Windows is just a little too different for them to make a proper purge of the project right now. Having Windows support is just a much larger cross-cutting concern than a Unix-like OS, which appears to be the only category of operating system they're currently supporting.
Windows will probably get a port some time later on. Remember that OpenSSH's libssh also has Windows support. It's just not something that fits in their current short term goals of fixing up OpenSSL (I like the term flensing they're using).
Well I disagree. Whilst it's a natural choice for portability, when you port to a proprietary platform such as windows you lose a lot of the support and portability guarantees that POSIX gives you and the calling conventions and standards of many libraries. At this point it's advisable to pick a holistic 3rd party abstraction over this such as something right from APR to Qt that will abstract the platform specific implementation away.
Some people write a lot of stuff plugged into Win32 without considering the CSPs and pull in OpenSSL without thought. Their funeral.
As my father said: "when in France, talk French or hire a translator".
This is all great, but the fact remains that OpenSSL is very widely used on Windows and yanking it out without providing a drop-in replacement option is a bad idea.
We can debate finer nuances of proper abstraction to the death, but it doesn't move a needle for people who already have OpenSSL dependencies in their code.
No one is yanking OpenSSL, this is a fork. OpenSSL is still available and developed and windows apps can continue using it.
If windows (and any other non-OpenBSD OS to be honest) people just HAVE to have LibreSSL instead of OpenSSL on their OS then the donation link is at the bottom of the page.
For right now, it does not matter. Their goal is to fix the project from a security point of view, and it would be impossible if they tied their hands with that during the course of development.
In the future, you can expect the same deal as OpenSSH, OpenNTPD and all the other OpenBSD software that _eventually_ gets ported to other architectures when it reaches a point of stability and safety that it makes sense to do so.
If you follow that through the series of links, you find that it is just an assumption based on one guy who didn't know the project existed thinking unchanged = unmaintained.
Are you sure? There hasn't been a release for 8 years.
I followed the links a while ago after hitting an intialization failure bug that leaves Linux boxes with the incorrect date. I found that neither Arch Linux or Redhat consider OpenNTPD to be supported on Linux.
It would be good if you could explain what I am missing. If there are more recent Linux releases and the information on the Redhat bug tracker is incorrect I would like to know. I'd rather be running OpenNTPD than ntpd.
I don't expect them to support Windows, you misunderstand the whole concern.
The concern is that OpenBSD fellas are fragmenting the project and they are also asserting that OpenSSL team was doing things wrong for a long time. This is not a start of a beautiful friendship. Throw in a bit of crowd lynching (to the tune of "OpenBSD is showing OpenSSL how to do security right") and we can end up with OpenSSL devs showing a finger and throwing in a towel. At best, we'll have to related SSL implementations, devs of which don't really talk to each other. That's the issue.
People have been saying that OpenSSL has been of poor quality [1], that the documentation is bad [2], and the developers don't really listen [3] for years. Heartbleed was just the straw that broke the camel's back. OpenSSL really was one of those pieces of software that was Just Good Enough that people tolerated it, but at the same time, filled them with a desire to punch kittens whenever they had to code with it.
The devs can probably at least be mature enough to use each others code where it is compatible. More to the point, there's really only a couple of full time OpenSSL devs, and the others are more contributors, for whom I'd imagine switching to a better laid out, less buggy, less spaghetti-codey, more practical implementation would be an advantage.
> The concern is that OpenBSD fellas are fragmenting the project and they are also asserting that OpenSSL team was doing things wrong for a long time.
Fragmenting? Aren't they making a separate, alternative implementation?
Either way, the whole open source field is chock-full of "fragmentation", with countless precious little snowflakes rushing to fork and re-implement anything and everything under the sun to get it just the way they want it. I doubt whatever fragmentation might happen with OpenSSL is a cause for concern, especially when the OpenSSL codebase is objectively bad.
> There's a ton of Windows software that uses OpenSSL
And those projects can upgrade to the heartbleed-patched version of OpenSSL and keep going. If LibreSSL eventually makes it to Windows, they can switch.
Ehh, I maintain a few libs that rely on the OpenSSL Windows ports. I'm not too keen on writing a compatibility layer that says "if windows, use the MS version, else use libreSSL!"
I'm fine with them not supporting MSVC in the build, but is it really that much harder to support something like MinGW/MSYS? No need for Cygwin.
The whole point of OpenSSL was that it runs everywhere. If we're going to write a shiny new version, let's at least try to hit the major platforms.
I imagine that's what the supported option is going to be. Given that the OpenSSH documentation explicitly lists Cygwin as the way to run it for windows, similar will probably happen for LibreSSL. The OpenBSD team has always had another team handle porting of their libraries, and they do a pretty good job of it.
Its not a replacement for OpenSSL, OpenSSL will continue to exists as it is, but in a while when libressl is stable enough you can choose on or the other.
While it is funny, I think using Comic Sans is actually more hipstery than ranting against it, which is too mainstream today (the same goes for blink tags).
Ah yes, the kind of professionalism I've come to expect from OpenBSD. They make decent software, but boy could they use some work in the PR department.
>You can have great software without insulting half the internet
You overestimate how many web hipsters there are. And annoying them is not "being an immature brat". It is precisely to discourage their involvement. Because the mentality behind the web fads are precisely why the entire world of software is layers upon layers of shit stacked on top of each other.
libressl.org is the most professional landing page a project could ever have, what more do you want blink tags hero unigs, marketing spots, slideshows??
Every sentence and paragraph on that page is meaningful, unlike _any_ modern web crap app/mvp where visitor has to click and mock about just to find what the hell the page/project is about. Here its in the first sentence and you cant miss it.
And they could make it look decent by replacing Comic Sans with Arial, Times or something similarly simple. You can't tell me they used Comic for any reason but to annoy people.
May be you missed to read the footer of the page.. the last line, Infact they are also trying to make the same point as you said (why not use Arial or Times and get rid of comic sans)
With a PhD in architecture, design and branding, there's something about the extreme simplicity of OpenBSD's web pages that I find really attractive. "Perfection is achieved, not when there's nothing left to add, but when there's nothing left to take away".
I am not sure if anyone noticed the footer of the page. It not the PR's fault or anything to blame PR. Its just a link for donation :).. they are trying to improve the standards of the web by wanting/helping to get rid of comic sans font
Mine doesn't show up in comic sans. However, the link to OpenSSL is to We're Not Gonna Take It (http://www.youtube.com/watch?v=mRCGDUsdRDU)... This all seems like a joke to me.
While most of us just talk, this guys actually did something of great importance. Hell yeah they have all the rights to step on some toes and make fun as they see fit.
I'd always salute doing stuff vs being politically correct.
One annoying thing about OpenSSL is its license. I hope The Better Replacement™ fixes that as well (especially if its name gets to contain the string "Libre"), and it is not going to happen by forking OpenSSL.
They are already placing completely rewritten files under ‘better’ licenses, so the license switch might happen file-by-file over a long period of time.
Is that strategy possible at all? Are there cases tested in courts (both US and EU) that assert that the file-by-file licence replacement really works?
Why wouldn't it? The author of the file will be the copyright holder by the virtue of authoring it. If she does not get rid of it, she still remains the copyright holder. Copyright does not switch owners purely by the virtue of distribution with another piece of work.
The copyright holders can later on relicense the work under something else. Licensing a work under some non-exclusive license does not restrict you from licensing it again in the future under other terms.
This is the problem with any sort of viral license in Free/Open/Libre software. Different people have different notions as to the best way of distributing it. An advertising clause is pretty minor compared to the rights you have to give away to use certain other "Libre" software.
It seems that is is indeed the official site (as linked-to on http://www.openbsdfoundation.org/), just in case there are any doubts…for no reason whatsoever.
Not really considering you have to buy certs if you want people to use your site, it doesn't have any sensitive data on it (not even source code or binaries), and they haven't finished cleaning it up to their standards yet.
StartCom/StartSSL [1] and, to my knowledge, Comodo [2] do offer free (and widely supported) SSL certs. Charges may apply to revoke certificates if a private key is leaked ($25 at StartSSL, IIRC).
As for why SSL should be used everywhere: It improves security and makes eavesdropping more expensive. For the first point, see the BEAST and CRIME attacks. On vulnerable systems, a single unencrypted connection may be used to reveal data from other, encrypted streams. As for the second: if only sensitive data is encrypted, all encrypted streams automatically become "interesting" to a potential eavesdropper. If, however, everything is encrypted, all streams become equal again. The cost of storing all communications becomes much higher, and the ratio of cost and reward of decrypting a single captured stream worsens (as you may either reveal sensitive or non-sensitive data).
If you have to pay for revocation, then it is not free certificate. It is just certificate with fees postponed. It is not the same thing. Not sure how you, but when I buy things I do not consider only initial price, but also additional fees.
If we want SSL used everywhere, browsers need accept self signed certificates in less obtuse way or there need to be other way to get really free ones.
I've been thinking recently about Heartbleed, and I was wondering if by writing C code to implement various network and cryptographic protocols, we're acting as human compilers for something that might be better represented in a more abstract format. I know there's some research on this already (the Austin Protocol Compiler), but does anyone here know of any other serious efforts to take the human out of the equation in terms of implementing protocols in C?
There are efforts by Microsoft Research in this direction:
http://research.microsoft.com/en-us/projects/slam/
They have developed several domain specific languages and specification tools for developing drivers. I think similar methods are applicable to protocols.
The most viable option today seems to be writing code in some language with strong formal guarantees (Agda, Coq) with extracting to Haskell/OCaml for generating C code from there.
I think gpcz was suggesting something more along the lines of an entirely new approach to protocol implementation, like VPRI's TCP/IP stack that Jeff Moser describes[1], rather than just swapping out C for something else while keeping the hand-written aspect.
> Let's say we want to build the TCP/IP stack of an operating system. A traditional implementation might take 10,000 lines of code. What if you rethought the design from the ground up? What if you could make the IP packet handling code look almost identical to the RFC 791 diagram which defines IP?
If the industry as whole could agree on this approach in a move similar to the Dijkstra/structured programming move that happened a few decades back, the sort of verifiable interoperability + security that Meredith Patterson and Sergey Bratus (who you may recognize from Occupy Babel![2]) call for would be closer to reach[3].
C is only used because for cryptography we really need to be close to the CPU and memory, going all assembler is an option actually. Anything higher than that and you have to have formal proofs for your compiler as well as your equations.
Don't listen to him, its just for performance, compatibility and portability. There's many other reasons why you might want to use another language, and some do.
I'm curious what they mean by "free", they put it in bold caps. Since it's a fork of OpenSSL that probably implies that the OpenSSL license remains attached to the code at least until all of the relevant code has either been rewritten or removed.
Some of the commit comments are entertaining:
"Fix some serious pointer-arithmatic-magic-number-unchecked-return eyebleed that I stumbled into here and got stuck with. If modern society can get past selling daughters for cows, surely we can decide to write modern C code in an "application" that is probably 3 lines of shell/python/cgi away from talking to the internet in a lot of places.. (This file still needs a lot more love though)
"oh god yuck" deraadt@
ok tedu@"
It should rename to LibibreSSL instead, so that one can link the library with `-libressl`. Other than that, I appreciate this effort (no pun intended).
Why wouldn't they just make it available for linking as "ibressl" rather than naming the project that? LibibreSSL is unwieldy to put it mildly, and meaningless without the context of the original name.
How so? CVS do make branching and merging rather annoying, but I don't see how reviewing changes becomes difficult. It's a lot easier to track the changes to the entire OpenBSD source three, compared to the Linux kernel.
Git and Mercurial are extremely nice tools, but the flow of patches and branches quickly become rather hard to follow. CVS doesn't have most of the features that newer tools have, so there's stuff you simply can't do, but it is extremely easy to follow the code.
There's many problems that makes it very annoying to review their changes:
- CVS commits are per file. You can't see changes made by a single commit to multiple files.
- CVS cannot rename files. You have to create a new file and remove the old one. So you cannot follow history of the changes.
- CVS is really slow. You cannot clone the repository locally, so it takes a few seconds to show any change, whereas git shows you any commit and logs instantly. And you can't do it offline (for instance if you need to spend a few hours in a train).
- git log / show / diff is so much better than cvs log / diff.
- you can't use things like git blame
- they've lost all openssl.org history. If they were using git, they could have cloned the openssl git repository, and add their commits on top, keeping all history (which is often very useful when you're trying to understand why something has been done like this, or who introduced some change).
I'm not an openssl expert, so I didn't plan to review their changes anyway. But if I had to, using CVS would be the most annoying thing.
> I'm not an openssl expert, so I didn't plan to review their changes anyway
Bad excuse. Now if you said you don't know C at all, that'd be reasonable.
> But if I had to, using CVS would be the most annoying thing.
There's freshbsd, cgit on anoncvs, probably a git repo or two on github. You don't need to touch CVS to view the code and diffs. Blaming the VCS that much is a bunch of lazy excuses. Yes, CVS has its shortcomings. No it doesn't make code review difficult.
Lets assume somehow you as attacker got access to the box where their CVS process is running.
Now you can edit a file, insert a line or change a "uid != 0" to "uid = 0", you also edit the history of the CVS repistory to make it seem that this change was introduced with some patch 3 years ago by Theo. Because its CVS or SVN the history is in the server, and not on every developers computers. Next time the devs build the tar.gz for distribution your bug is in it.
This wont be allowed with Git or Mercurial, because if you try to rewrite the history, well good luck making a SHA-1 collision on source files. That stops it.
I can't speak for them, but I think if you're not sold on git/mercurial then you have CVS and SVN as obvious choices. And those two aren't that different (pros/cons explained: http://www.pushok.com/software/svn-vscvs.html ... edit: that's a very old link)
With close to years of C under my belt, I believe it's a major error, today, to write a critical cryptographic library in C.
OK, do the codecs in C if it's the only way to meet performance requirements. But the rest must be written in a language that's reasonably analyzable statically, and with adequate abstractions. Seriously, have you looked at the filthy mess of leaky abstractions that OpenSSL's BIO system is? How many bugs could be found and/or planted by a 3-letters agency in that crap? Is there anyone who's comfortable with its #ifdef labyrinths?
Finally, I don't think you can retrofit clarity in OpenSSL any better than you could, say, retrofit virus-resilience in a Microsoft OS that hasn't been originally designed for hostile network environments. I used to believe OpenSSL was made messy in order to sell consulting hours, since Snowden I have a more paranoid hypothesis.
Like we always have to ask when somebody says what you have, "What's the alternative?"
Whatever it is, it'll need to be very portable (well beyond just Linux, OS X and Windows), and it'll presumably need a free implementation on each of those platforms, and it'll need to be quite fast, and it'll need to support native compilation, and it'll need to support interoperability with existing code, and it'll need to be "safer" in some way.
At this time, there are very, very few languages that meet every one of those criteria sufficiently. We're looking at C, or C++. Maybe Ada. But that's about it. Rust doesn't cut it yet, and probably won't for some time. Other candidates are lacking severely in one or more of those important areas.
C++ using modern techniques appears to be the only feasible alternative to C today.
They're making a fork of OpenSSL, and removing all the cruft.
Porting it to a completely different language would be an error.
There are several alternatives to OpenSSL available and/or popping up right now. They might or might not be a better choice for new developments. But refactoring OpenSSL (where a lot of currently used software depends upon) is certainly not a dumb decision.
Agreed, there's no realistic way to port OpenSSL to a new language. What I'm saying is, I think a clean-up fork of OpenSSL will divide the workforce per project, without dramatically improving security.
So it's not "dumb", but I expect the net result to be negative. At least a clean reimplementation featuring XXI-th century technologies would have a non-zero chance to produce something great.
> At least a clean reimplementation featuring XXI-th century technologies would have a non-zero chance to produce something great
There are no guarantees of anything working out or being great, regardless of technology. And whatever language/tech you use would require a couple of layers of control. For example, ensuring the low-level features of the language don't betray entropy to statistical analysis, or managing (and ensuring) the virtual memory used is cleaned up properly, or being as efficient as possible lest the crypto become a performance barrier to use.
It's not like high level languages can't implement crypto as well as lower level ones; they can. But it's a lot easier to ensure the various attack vectors are mitigated in a low-level language where there's no glue [outside of that included in your source] to get in the way, obscure, or otherwise subvert the security and performance of the applications using your code. The Heartbleed bug happened because the glue they chose to use was crappy; this was an implementation problem, not a low-level-language problem.
I don't agree at all. I am betting that once LibreSSL is "done" it will get adopted heavily and the community will have a cleaner and more secure code base to work from going forward.
I'm going to quote somebody out of context. Please bear with me...
What I am seeing is that we have a ridiculously upside-down trust
model -- "Trust the developers".
We never asked for people to trust us. We might have "earned some" in
some people's eyes, but if so it has always been false, even before
this. People should trust what they test, but the world has become
incredibly lazy.
We build this stuff by trusting each other as friends, and that is
done on an international level. If anything, the layers and volume of
trust involved in software development should decrease trust. Oh
right, let's hear some of that "many eyes" crap again. [..] All the
many eyes are apparently attached to a lot of hands that type lots of
words about many eyes, and never actually audit code.
If anything, the collaborative model we use should _decrease_ trust,
[..]
Before anyone gets the wrong idea, I'm not trying to attack any individual here. But so many software vulnerabilities, goto fail included, Heartbleed included, have caused such angry response from people. That the bug was trivial. It should've been caught by static analysis, smart compilers, correct review process, careful third party readers, TDD, UFOs, ADHD, <insert favorite tech here>. It is easy to say all that in hindsight, because you are for most part right. So why weren't these techniques used?
You can't blame the developers for everything, they have work on their hands and you are not entitled to anything more from them. You also can't trust developers. If there's sloppy code, someone has to notice it and point it out. Someone has to fix it. If there are sloppy development practices and it is evident that the upstream developers do not care, someone has to notice that and let the world know. Then maybe create a fork and try to do better.
So anyone capable of reviewing code and diffs: please try to do it if you haven't before. Try to do more if you're already doing it. And remeber, you do not have to be an expert programmer to notice a duplicated goto fail line.
Or if you can write tests, why don't you contribute?
How can they know that they have not broken something in their flensing without any automated testing since no tests is one of the big problems with OpenSSL?
Believe it or not, there are other ways to spot problems besides automated testing, which wouldn't catch every problem anyway (that's why we need human audits like the one OpenBSD is doing).
Yes, software existed before TDD and ADHD.
That's not to say tests don't help. If you are interested, why don't you contribute?
It's indeed a great effort. Lets just hope that it delivers what is promising and doesn't bring other sorts of vulnerabilities due to the new implementation/code.
I don't get the point of this fork. Usually when a project is forked, it means that people want to keep the code base but disagree with the way the project is managed.
After heartbleed everybody blamed OpenSSL's bloated code base and it became apparent that many contributions came from volunteers with very few financing.
By forking the project, LibreSSL will keep the problematic code legacy and split the community. Maybe I am missing something, but it looks like opportunism here...
> After heartbleed everybody blamed OpenSSL's bloated code base <
And this is exactly what they are fixing.
OpenSSL's response was to fix heartbleed and move on, not fixing the more broad problem of to much code cruft that led to the bug. IMHO they are right to fork it, OpenSSL's lack of reaction to this is a raise for concern. I am sure Theo( de Raadt) and its team can tackle this, making the code base much much leaner, reducing the risks of bugs similar to heartbleed. And there is really no excuse for OpenSSL to deny that.
Also i think OpenSSL has to much technical debt to be efficient in tackling a cleanup like this.
This is one of the best things that happened in the open source world recently. I like their attitude towards "web hipsters" too. They're serious folks who shut up and write AND READ codes.
It's funny that they do this "donate to stop blinking" thing again. They have been doing it for OpenSSH since 2000. cf. http://www.openssh.com/
I imagine supporting non-POSIX operating systems, or not exactly conforming ones, to have its challenges, but is it really hard to make this stuff working in Linux and Open/NET/Free BSD from day one? It seems to me a better approach to start this way, without to mention that the potential developers base you get if you support Linux ASAP can be larger.
I'm sure that portability is a major goal, but "from day one" isn't. Better to focus on correct, high quality, readable code first and then deal with a portable version. And OpenBSD C code tends more toward generic UNIX than some others, so shimming is less painful than it could be.
There really are a lot of parallels with OpenSSH's history. There were the "Oh, God! Theo forked SSH!", "It's just OpenBSD, who uses that?", and all the rest. Now everyone uses it, and it's a good thing. The wait time for it to be ready and available to all platforms was a small price to pay, well worth it, and quite small in retrospect.
OpenSSH also deliberately trashed cross-platform compatability. This makes it amusing whenever someone flounces off to OpenBSD because they think systemd should have been written portably.
OpenBSD cares about their own first and foremost. OpenSSH has a similar porting team, and has since the beginning, and there have been no problems there.
"OpenBSD cares about their own first and foremost.".
This is their choice, but their impact in the security of IT is much smaller this way because most servers are running Linux. It is surely a great result to have an operating system like OpenBSD that can be proud of the security level reached and the small amount of vulnerabilities over the years, however if you analyze the computer security problem from a vendor-neutral standpoint, there is more at it than the availability of niche secure systems.
I'd disagree. As I wrote in the second half of my post, they do the same thing for OpenSSH, and I don't think anyone will say OpenSSH has had a minimal impact on IT security. One of the reasons they develop this way is that they can work with a known set of functions, etc, which may not be available on other platforms, and then have people who grok portability handle that part of the puzzle. Additionally, functions and libraries that are not used in the OpenBSD world, like PAM integration, can be maintained by people who understand all the security implications of those libraries.
I don't use OpenBSD for my own environments, but at the same time, I can understand why they code the way they do. Everyone ends up a biased toward their platform of choice in how they code, what functions they use, etc, it's just that the OpenBSD team is militantly upfront and open in their biases. Given their track record in creating secure software, and in auditing others' software, I'd argue their end result is appreciable, even if I'm not directly using those results.
I haven't seen an explanation for it, but one reasonable guess would be momentum. If you want to get work done, you don't want to have to wade through red-tape and bureaucracy to get it done. You don't want to work on something with the risk of it being shot-down by the current maintainers. This is not a criticism of the OpenSSL team, it's just a fact of life that it's often easier to "start fresh" than to try to change an already established routine.
I also suspect that part of the reason is because OpenBSD just doesn't work well with others.
Considering the fact that the OpenBSD guys are complaining about the OpenSSL guys competance in their commits I don't think they WANT them near the new fork.
Since libressl.org doesn't seem to contain this information, hopefully someone here perhaps knows more about it: Is it possible to donate specifically to subprojects? As a previous donator to the OpenBSD foundation, being able to do so would hopefully aid receivers of those funds not only use time (timing) as one way to measure the potential success of libressl.
Attitude and font choice aside, I can't help somewhat feel that one could explore better ways to funnel interest, commitment and donations to a project such as this; especially since it sparked as a result of heartbleed.
Managing a flock of web devs and telling them all they're doing it wrong would eat up time that could've been spent on the actual code. So it's not actually help.
I was going to ASK HN, when are we going to see a replacement for OpenSSL; you know, the company that has much more field experience, or even understanding of how SSL operates.
I then thought to myself, that'd be going too far..and nobody is really going to try and make an alternative.
Matthew Green @matthew_d_green Apr 18:
"@MiodVallat @cwlcks Well then I withdraw my earlier comments. What happens in BSD when the system RNG lacks entropy? Does it block?"
"This page scientifically designed to annoy web hipsters. Donate now to stop the Comic Sans and Blink Tags."
They know. I find simple HTML like http://cr.yp.to/ to be refreshing sometimes, albeit not "pretty." But with the font and blink tag (powered by CSS), they've gone out of their way to make it a bit ugly. At least they drew a line and don't have headache-inducing colors or animations.
Edit: To those downvoting, yes, I saw the footer. This doesn't excuse their childish behavior. I will not be donating to this project if this is the level of seriousness they have for it.
You know, what you really care about is them spending time on writing good software, not writing good websites. They don't have time for this, they don't have money for this, and they don't want to spend human CPU on this.
Oh, and while we're at it, the OpenSSL page [0] isn't much better visually speaking. Would you donate to them to make OpenSSL better ?
Ask yourself which hipster start-up is going to do a comprehensive rewrite job on OpenSSL - or, for that matter, which SV VC is going to bung a few million green sheets into something like this (which, if we're honest, we could all do with happening, rather than the next DOA social media start up with a -ly/-able/-r suffix).
If these people are prepared to take this on, then they can use whatever fonts they bloody well like. As a web hipster, I will pay them for punishing my hubris.
Having said that, I can't seem to find a browser in which the blink tags actually, er, blink. Did all the vendors shitcan it on the quiet? I think we should be told.
Why would they need that for a temporary web page? And one that has no need to be accessed via ssl? They threw together a page to give you some information and that is all.
While I really enjoy Theo's talks and writings, I wonder if the fact that the VCS is CVS ain't a security issue in itself?
It's been really a long time I haven't used CVS but I remember that attempt to introduce backdoors in projects using Git as a (D)VCS have been caught (it was in the Linux kernel I think). IIRC some attempts were caught precisely because it's hard to fake SHA hashes and so people can't really "mess" with the history of a DVCS like Git: too many people noticed a critical file having no business being modified being, well... Modified.
Once again, it was quite a while ago but I'm pretty certain that both the fact that Git was decentralized and that Git was using cryptographically secure hashes was touted as a "Good Thing" [TM] that helped catch the backdooring attempts.
Ain't using CVS potentially an issue here?