[Haskell-cafe] ANNOUNCE: secure-sockets version 1.0

[David Anderson]

On Mon, Sep 6, 2010 at 12:45 PM, Thomas DuBuisson <
thomas.dubuisson at gmail.com> wrote:

> David said:
> > I'd be interested with breaking the dependency on OpenSSL, for various
> > reasons:
> > [snip]
>
> Can't say I'm surprised by these.  Its unfortunate the situation
> hasn't improved.  I recall a half decent O'Reilly book on OpenSSL but
> if you weren't using it as a cookbook (and wanted a 1-off solution)
> then it wasn't so useful.
>

Exactly. I managed to piece together the behavior I wanted by careful
inclusion and omission from the O'Reilly book, but even it is more a book of
lore and tricks than a real reference manual. Given the shape of the API,
unfortunately I suspect that it's quite hard to get any better.


> > So, a replacement would need to be a complete replacement for TLS. I did
> in
> > fact try to start with this, implementing my own simpler TLS-ish
> protocol,
> > using crypto primitives directly. It took a group of crypto experts about
> 5
> > minutes to punch 3 different holes in the protocol
>
> You could have gone to Hackage and checked your protocols correctness
> using CPSA, not that the side-channel attacks would be discovered by
> such a tool.
>

Interesting. I had seen CPSA announced at one point, but there appears to be
no documentation whatsoever. Did I miss the doc links?


>
> > That said, with the Haskell Crypto API stabilizing, I've been toying with
> > the project of a pure Haskell TLS implementation, which would solve the
> > annoying dependency issue while hanging on to a hardened protocol.
>
> I'm releasing crypto-api-0.1 on Tuesday so if you have any last minute
> comments now is the time!


I'll take a look, but I've been loosely following and don't recall any major
objections.


>


> > However,
> > this is also far from a simple endeavor, especially if the implementation
> is
> > to be hardened against side-channel attacks, which I'm not even sure is
> > possible in Haskell.
>
> Well, to determine if that's possible we'd need a definition of
> side-channel attack which is counter to many definitions of
> side-channel ;-).  Perhaps a list of common ones OpenSSL thinks it
> addresses would give us a good start.
>

The two large families of side-channel attacks that I know of and that have
been popular (== successful) recently are:

 - Simple timing attacks: If code path A takes longer than code path B to
execute, an attacker can use that information to reverse engineer the
outcome of branching tests, and from there possibly recover secret key
material. This is particularly nasty because the attack can be carried out
remotely, by repeatedly executing the protocol in a way that exercises the
vulnerable code path.

 - Cache state attacks: If code path A has different data access patterns
than code path B, it may be possible to deduce which was executed by
examining CPU cache statistics. This attack is more theoretical than
practically useful, because it requires local access to the CPU executing
the crypto code, and that there be little else executing on the system to
pollute the cache stats. But I do recall a couple of publications that
showed OpenSSL being successfully attacked to some extent through CPU cache
analysis.

IMHO the former is the big one that needs to be protected against, I won't
really lose any sleep over the second one just yet.

The definition of a simple timing attack can be basically boiled down to:
any branching in the code must be to two alternatives with equal cost (or
thereabouts, sufficiently close to be indistinguishable from timing noise).

For instance, if comparing two hashes for equality, the code should not exit
early if a difference is found, as that would leak to the attacker the
number of bytes of his hash that were correct. This is incidentally one
component in the successful attack against the Xbox 360's security system:
they were comparing hashes with memcmp(), which exits early on a difference,
enabling an attacker to determine the correct hash for a modded firmware by
brute force.

This is fundamentally at odds with lazy evaluation, the ultimate early exit.
All crypto code needs to be completely strict to resist timing attacks, or
at least very carefully lazy. In a garbage collected language, the code also
needs to take care to avoid allocating significantly more in one branch than
in the other, lest the pauses induced by garbage collection give away hints
as to the chosen code path (though arguably, the GC behavior in a complex
program is sufficiently unguessable for an attacker to not be an issue).

Am I making sense?

Another of my tentative projects was to write a C library that implements
popular crypto building blocks, with a large battery of tests for
correctness and resistance to timing attacks. Getting resistance to timing
attacks is somewhat simpler (though still treacherous) in C, and having such
a library available for protocol builders would be quite valuable. Sadly,
time is a heartless bitch and continually gives less of itself than I would
need to do all these things.

If you start on such a task (Haskell TLS) then perhaps you could drop
> a line to l at h.o or c at h.o?
>

Most certainly. A full TLS stack is not something one attempts alone ;-).

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100906/4e61bf7a/attachment.html