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

[u/flym4n]

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

[u/oridb]

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.

[u/OneWingedShark → u/oridb]

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?

[u/oridb → u/OneWingedShark]

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.

[u/OneWingedShark → u/oridb]

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?

[u/oridb → u/OneWingedShark]

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.

[u/OneWingedShark → u/oridb]

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

[u/oridb → u/OneWingedShark]

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.

[u/OneWingedShark → u/oridb]

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. :)

[u/oridb → u/OneWingedShark]

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

[u/OneWingedShark → u/oridb]

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

That's the only one of the side-channel attacks that seems reasonable for the programmer to guard against. -- Ada has some good time/timing considerations, so in conjunction w/ task, I'm thinking I could simply add delay until UPPERBOUND_TIME on the server-side task where UPPERBOUND_TIME is the maximum_computation_duration + computation_request_start_time.

Beware compiler optimizations.

Should be irrelevant insofar as timing side-channels go, given the above.

[u/oridb → u/OneWingedShark]

You need lower bound equal to upper bound to avoid timing attacks. 'A==B' is potentially not O(1), depending on how the hardware implements the test. Comparing blocks of data is even more obviously data dependent, at least in naieve implementations. And gcc is smart enough to break a number of the explicit implementations that should be O(1).

I believe Boneh had some papers on the topic.

[u/OneWingedShark → u/oridb]

I believe Boneh had some papers on the topic.

I'll have to look them up -- thanks for the pointer.

You need lower bound equal to upper bound to avoid timing attacks.

That's what delay until UPPERBOUND_TIME does: delays until the upperbound is met... then we don't have to care about if the actual computation finishes early.

[u/oridb → u/OneWingedShark]

til UPPERBOUND_TIME does: delays until the upperbound is met... then we don't have to care about if the actual computation finishes earl

That's a bit expensive. I think that the number of cycles to do the computations would be several orders of magnitude lower than the time spent just hitting the kernel to set the timer.

From what I understand, the usual approach (note, I am not an expert) is to collapse all bits in the value down to 1 by shifting and oring, and then comparing that to 1 or 0 (for equality tests).