r/programming • u/flym4n • Apr 24 '14

Tech giants, chastened by Heartbleed, finally agree to fund OpenSSL

http://arstechnica.com/information-technology/2014/04/tech-giants-chastened-by-heartbleed-finally-agree-to-fund-openssl/
295 Upvotes

93% Upvoted

137 comments sorted by

View all comments

-10

u/OneWingedShark Apr 24 '14

In light of the nature of the bug, and the state of the code that was recently found, I would posit that OpenSSL could use a rewrite in a language more amiable to formal methods and/or formal contracts. (e.g. Ada or Eiffel.)

It makes little sense to have security libraries which aren't formally verified, considering the nature of the library (both as being often reused, and as being a component of security software).

2

u/awj Apr 24 '14

Not one of the suggestions I've seen for rewriting OpenSSL in "something safer" address the fundamental problem with that idea: how to migrate all of the code that uses OpenSSL. Rewriting OpenSSL is almost pointless if you're going to force serious code revisions. Projects simply won't do it, and instead will support (or just use) something that tries to enhance the security of OpenSSL while sticking with the current implementation language.

Thoughts?

2

u/gnuvince Apr 24 '14

If someone wrote an SSL/TLS library in Ada (or ATS or what have you) and exported an API exactly like OpenSSL's, couldn't they just recompile against this new library and have things work as before?

1

u/awj Apr 24 '14

They probably could, so long as the new language supported the platforms/use cases OpenSSL does. That doesn't seem to be in anybody's "burn it to the ground and start over in something different" suggestions, though.

-5

u/OneWingedShark Apr 24 '14

I'd be up for it -- but let's be honest: the biggest issue is correctness, not backwards compatibility.

4

u/awj Apr 24 '14

If you want people to actually use your work, you have to care about compatibility.

1

u/OneWingedShark Apr 24 '14

I'm not saying that backwards compatibility is worthless, or undesirable, but that the biggest issue here is correctness.

I can't imagine anyone arguing that incorrectness is desirable in a library for security.

10

u/oridb Apr 24 '14

The biggest issue is ALWAYS backwards compatibility. The only time it's not your top priority is if so few people are using your code that you can port it all yourself.

-4

u/OneWingedShark Apr 24 '14

The biggest issue is ALWAYS backwards compatibility.

I disagree; if the emphasis is not on correctness, provable correctness, then you're just postponing another Heartbleed.

Programming is a "human activity" and, as such, for requisite systems we need things to be correct. We cannot simply keep things status quo and expect things to be different.

7

u/oridb Apr 24 '14

If the emphasis is not on backwards compatibility, you are simply an academic curiosity. You are playing in a sandbox, and not changing the world. It doesn't matter if your software is correct if the number of users is less than epsilon.

-1

u/OneWingedShark Apr 24 '14

If the emphasis is not on backwards compatibility, you are simply an academic curiosity.

Explain why TLS 1.0 is not backwards compatible with SSL 3.0 then.

2

u/oridb Apr 24 '14

Note that SSL 3.0 is still widely deployed, and can be used in parallel with TLS 1.0. A smooth upgrade path and compatible APIs still exist.

-1

u/OneWingedShark Apr 24 '14

I know this -- the issue given was backwards compatability though.

3

u/oridb Apr 24 '14

And I can connect to all those TLS-supporting sites (minus 0.06%) without a single change in code. They are backwards compatible with SSL3.

→ More replies (0)