Scenario: OpenSSL in D language, pros/cons

Sun May 4 14:18:22 PDT 2014

On Sunday, 4 May 2014 at 10:23:38 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
> On Sun, 04 May 2014 08:34:19 +0000
> "Daniele M. via Digitalmars-d" <digitalmars-d at puremagic.com> 
> 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.
>
This is what I thought too.

> 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).
>
I should have said: a D implementation of OpenSSL *without* the 
malloc sorcerery, sorry for leaving it out of OP. Reason I'd like 
to ignore that for this discussion is that I consider it a bug. 
And we are all in the post-heartbleed scenario now so it looks 
huge, but Theo De Raadt already said it all, nothing to add on it.

And then comes my next question: except for that malloc-hack, 
would it have been possible to write it in @safe D? I guess that 
if not, module(s) could have been made un- at safe. Not saying that 
a similar separation of concerns was not possible in OpenSSL 
itself, but that D could have made it less development-expensive 
in my opinion.

> 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.
Nobody would expect/trust a single person to do this job :P
Working in an open source project would be best.

> 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).
>
I wasn't aware of this effort, interesting experiment.

> 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).
I would pick LibreSSL:
http://www.libressl.org/

And merge patches as their progress goes on.

> 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.
>
Here I don't completely agree: if we can have a binary-compatible 
implementation done in D, then we would be able to modify 
software to eventually use it as a dependency. I don't see the 
necessary D dependencies as prohibitive here.

> However, regardless of whether we ever end up with an SSL 
> implementation in D,
I started this discussion just for the thought exercise, because 
I think it can give a few positive leads, but nice to see that 
other people too thought about a possible implementation :)

> 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
Thanks for your post Jonathan, however I believe that attempts 
like Go's are what makes a language more real and less 
theoretical. The field test of D on system-level software would 
be in my opinion useful and sometimes I think the sooner the 
better, to eventually modify the evolution of this beautiful 
language (if there's still a viable window for this).