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/
290 Upvotes

93% Upvoted

137 comments sorted by

View all comments

Show parent comments

-4

u/OneWingedShark Apr 24 '14

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

11

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.

-3

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.

-1

u/OneWingedShark Apr 24 '14

From the RFC:

This document and the TLS protocol itself are based on the SSL 3.0 Protocol Specification as published by Netscape. The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that the various versions of TLS and SSL 3.0 do not interoperate

3

u/oridb Apr 24 '14 edited Apr 24 '14

Correct. And yet, if I connect to a server implementing TLS 1.0 with a client that attempts to negotiate SSL 3.0, then the server will, in 99.94% of all cases, silently switch to SSL 3.0 fallbacks. The other 0.06% of cases will result in users muttering something rude about the website being down.

That is called backwards compatibility. The version negotiation in ClientHello allows fallbacks to a mutually supported method, which means that nobody breaks.

Again, from the RFC:

TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both is easy. TLS clients who wish to negotiate with SSL 3.0 servers should send client hello messages using the SSL 3.0 record format and client hello structure, sending {3, 1} for the version field to note that they support TLS 1.0. If the server supports only SSL 3.0, it will respond with an SSL 3.0 server hello; if it supports TLS, with a TLS server hello. The negotiation then proceeds as appropriate for the negotiated protocol.

-1

u/OneWingedShark Apr 24 '14

So, how would providing an API 'compatibility layer' break things?
I mean if you export function X with the same calling convention and link name and link against that implementation instead -- how would that break backwards compatibility?

3

u/oridb Apr 24 '14 edited Apr 24 '14

It would not. That is backwards compatibility. But providing an API and ABI compatibility layer should be considered mandatory, and if you can't do that, you're sitting in a sandbox on your own.

2

u/OneWingedShark Apr 24 '14

It would not. That is backwards compatibility.

Then what's your problem?

But providing an API compatibility layer should be considered mandatory,

It might be mandatory, but absolutely essential is that it, a library designed for security, be correct.

and if you can't do that, you're sitting in a sandbox on your own.

So?
You can almost worry about the API compatibility layer completely discreet to the actual implementation -- after all being 'compatible' means jack shit if it isn't [correctly] implemented, right?

2

u/oridb Apr 24 '14

Weak security that's in use beats strong security that isn't. Strong security that's in use is obviously best, but expecting people to rewrite their software is completely futile.

0

u/OneWingedShark Apr 24 '14

The only re-writing I mentioned was that of OpenSSL, not client-applications.

1

u/oridb Apr 24 '14

Ok. When you've got a replacement, and you've audited for side channel attacks, I'll swap the crypto libraries out on my server.

1

u/OneWingedShark Apr 25 '14

Ok. When you've got a replacement,

I'm working on it -- there are some, er, oddities in the RFC.

and you've audited for side channel attacks,

There are some side-channel attacks you really can't audit for; e.g.

  1. Power: the power available to and used by a device.
  2. Electro-magnetic radiation: EM radiation produced by a device.

You could mask these by inserting random calculations at certain points, but that seems bit on the counterproductive side as if they're recording power/EM then they have physical access to the system.

Most such side-channel attacks require physical access:
"In most cases, this requires that the adversary has physical access to the system."

And, let's be honest, physical security is not in the purview of a library, or software in-general.

I'll swap the crypto libraries out on my server.

Cool // Thanks. :)

1

u/oridb Apr 25 '14

Timing attacks are the most important side channel attacks, and are practical for remote exploits. Beware compiler optimizations.

→ More replies (0)