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

David Anderson dave at natulte.net
Mon Sep 6 15:22:43 EDT 2010


On Mon, Sep 6, 2010 at 9:16 AM, Thomas DuBuisson <thomas.dubuisson at gmail.com
> wrote:

> Good work Dan!  Would you be interested in providing a build option
> that replaces the OpenSSL dependency with something more stand-alone?
>

I'd be interested with breaking the dependency on OpenSSL, for various
reasons:
 - OpenSSL's API makes it very hard to determine the purity of calls, which
makes IO leak into the entire Haskell API.
 - The API provides basically no way of generating a valid self-signed TLS
certificate. Even C programmers using the API directly have given up, and
tell you to shell out to the `openssl` binary to do that.
 - The HsOpenSSL bindings are incomplete in various ways (notably, lack of
Diffie-Hellman keying support, which forced me to use a ciphersuite that
doesn't guarantee perfect forward secrecy). This I can fix by submitting
patches, but it does add to the other bad stuff right now.

 However, dropping the OpenSSL dependency is harder than it looks:


> Or does ossl perform a significant part of the TLS protocol work for
> you (vs just being used for algorithms)?
>

OpenSSL does all the heavy crypto lifting in my library. secure-sockets in
its current implementation basically takes care of forcing the use of a
single good TLS ciphersuite, ensuring that only explicitly provided certs
are used for authentication (i.e. don't accept random Verisign certs), and
of enforcing two-way authentication (TLS defaults to only authenticating the
server, the server has to forcibly demand authentication material from the
client).

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, from leaking session key
bits to sneaky replay attacks and increased risk of side-channel compromise.

After talking it over with them, for all of TLS's warts, it is a terribly
well designed protocol from the security standpoint, and the recommendation
of my experts was basically to use it until I needed something that TLS
cannot provide, at which point I should start building my own transport
security protocol. So, unless there are crypto experts in the room who fancy
building something better than TLS for the purposes of simple peer-to-peer
security, I'm sticking with TLS for now.

This gives me a choice of the three major TLS implementations: OpenSSL,
GnuTLS, or Mozilla's NSS. Of those three, OpenSSL is regarded as the most
widely used and battle hardened. It also happens that it's the only library
with Haskell FFI bindings :-).

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

So, to sum up: yes I'd like to ditch the OpenSSL dependency, but in the
current state of the world, it seems to me that OpenSSL is the least bad
choice there is. I'd love to be proven wrong through!


> Anyone impatient for the midnight haddocking can see the docs here:
> http://web.cecs.pdx.edu/~dubuisst/secure-sockets-1.0/html/


Or if you prefer the shiny new templates (upgrade your haddock!),
http://natulte.net/random/secure-sockets/ .

- Dave


>
>
> Cheers,
> Thomas
>
> On Sun, Sep 5, 2010 at 10:26 PM, David Anderson <dave at natulte.net> wrote:
> > Hi,
> > I'm happy to announce the first release of secure-sockets, a library
> which
> > aims to simplify the task of communicating securely between two
> > authenticated peers.
> > --------------------------------------------
> > -- What it is
> > --------------------------------------------
> > The API mimicks that of Network.Socket, and introduces the additional
> notion
> > of peer identity, which is distinct from the endpoint address (host and
> > port). Connections can only be established between two peers who know and
> > expect to be communicating with each other.
> > Transport security is implicitly taken care of: an established
> > Network.Secure.Connection implies that each end of the connection
> > successfully authenticated to the other, and that they have setup strong
> > encryption for your data.
> > --------------------------------------------
> > -- What it isn't
> > --------------------------------------------
> > The library leans towards the "zero configuration" end of the spectrum,
> and
> > basically Just Works. This means that if you know exactly what you want
> and
> > need for the cipher, authentication algorithm, key type and length, key
> > exchange protocol, HMAC algorithm, rekeying intervals, random number
> > source... Then secure-sockets is not for you.
> > If on the other hand you just want to replace your current cleartext
> > "cipher" and faith-based "authentication" code with something that gives
> you
> > a good chance of being secure (see caveats in docs), without diving into
> the
> > rich madness that is full blown SSL, then you might want to take a look.
> > This library assumes that both ends of a connection are using it. The
> goal
> > of secure-sockets is not to allow you to connect to any SSL-enabled
> server,
> > or to speak a particular standard flavor of authentication protocol.
> > Internally, secure-sockets uses SSL to achieve its goals, so you might
> get
> > lucky if you do it just right, but that is an implementation detail. The
> > library is designed to help you easily secure communications between two
> > programs whose implementation you control, not between you and anything
> out
> > there.
> > --------------------------------------------
> > -- Links
> > --------------------------------------------
> > Homepage: http://secure-hs.googlecode.com/
> > Hackage page: http://hackage.haskell.org/package/secure-sockets
> > Bug tracker: http://code.google.com/p/secure-hs/issues/list
> > Code repository: https://secure-hs.googlecode.com/hg
> > --------------------------------------------
> > -- Thanks
> > --------------------------------------------
> > I'd like to thank my employer, Google. Not only did they not get mad at
> the
> > idea that I might want to hack on Haskell during working hours (as my
> "20%
> > project"), they also made it very painless for me to open source this
> code
> > when the time came.
> > --------------------------------------------
> > -- Questions?
> > --------------------------------------------
> > Questions, comments, suggestions and patches can be filed in the issue
> > tracker, emailed directly to me, or thrown out on haskell-cafe.
> > Hope you find this code useful!
> > - Dave
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100906/0eb24b34/attachment-0001.html


More information about the Haskell-Cafe mailing list