On Sun, 04 May 2014 08:34:19 +0000 "Daniele M. via Digitalmars-d" <[email protected]> wrote:
> I have read this excellent article by David A. Wheeler: > > http://www.dwheeler.com/essays/heartbleed.html > > And since D language was not there, I mentioned it to him as a > possible good candidate due to its static typing and related > features. > > However, now I am asking the community here: would a D > implementation (with GC disabled) of OpenSSL have been free from > Heartbleed-type vulnerabilities? Specifically > http://cwe.mitre.org/data/definitions/126.html and > http://cwe.mitre.org/data/definitions/20.html as David mentions. > > I find this perspective very interesting, please advise :) @safe code protects against indexing an array out-of-bounds. So, if OpenSSL had been implemented in D, and its heartbeat feature used @safe code, then heartbleed would not have been possible. As soon as an attempt was made to index passed the end of the array, it would have thrown a RangeError and killed the program. Now, even if OpenSSL had been implemented in D, if it had used @system or @trusted code for its heartbeat feature, then it could have had the bug just as easily in D as it did in C. And given all of the horrible practices in OpenSSL, I very much doubt that having it written in D would have prevented much, because anyone making the choices that the OpenSSL folks have been making would likely have ended up with horrible D code which was mostly @system and probably doing all kinds of things that are inherently risky, forgoeing many of the benefits that D provides. I think that it's safe to say that D makes it easier to catch problems like this, but it doesn't entirely prevent them, and bad programming practices can pretty much always get around protections that the language provides unless the language provides no ways around those protections (which isn't the case in D, because it's a systems language and needs to provide low-level access and features for those programs that need them - it just doesn't use those by default). If I had more time, I'd actually be tempted to write an SSL implementation in D, but even if I were to do an excellent job of it, it would still need to be vetted by security experts to make sure that it didn't have horrible security bugs in it (much as it would be likely that there would be fewer thanks to the fact that it would be writen in D), and I suspect that it's the kind of thing that many people aren't likely to trust because of how critical it is. So, I don't know how good an idea it is at this point for someone to write an implementation of SSL or TLS in D. Certainly, it's the type of thing where we've generally tried to wrap existing C libraries in order to avoid having to spend the time, effort, and expertise on in order to fully implement it ourselves. The Go guys did it, but if I understand correctly, the fellow that did it was one of the OpenSSL developers, so presumably he's already very familiar with all of the ins and outs of SSL, and I don't know if any of us here are (I'm certainly not - if I were doing it, I'd pretty much just have to go off of its associated RFCs, for better or worse). At this point though, if I were looking at using an existing implementation of SSL, I'd probably be looking at GnuTLS rather than OpenSSL given how horrible OpenSSL's codebase is. I don't know that GnuTLS is any better, but it wouldn't be hard for it to be. OpenSSL is horrible both with regards to its implementation and its API, and we'd all be better off if something better replaced it (be it GnuTLS or something else). Unfortunately, even if something better _were_ written in D, it's probably only the D folks who would benefit, since it's not terribly likely at this point that very many folks are going to wrap a D library in order to use it another language. However, regardless of whether we ever end up with an SSL implementation in D, I think that in the long run, D will show itself to be much, much better than C or C++ at writing code that has a low number of security bugs. - Jonathan M Davis
