Re: [Haskell-cafe] ANNOUNCE: secure-sockets version 1.0
On Wed, Sep 8, 2010 at 1:05 PM, Mads Lindstrøm wrote: > Hi David > > On Mon, 2010-09-06 at 13:50 -0700, David Anderson wrote: > > > > > > > - 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. > > > > > > I do not know much about cryptography, so I may be writing nonsense > here, but it seems to me that it should not be too hard insuring that > all wrongly encrypted data takes equally long to process. One could use > an algorithm like: > > * make interrupt/timer that will finish in one second > * process data from client > * If data is correctly encrypted, stop interrupt/timer and return > information to the client > * If data is wrongly encrypted, prepare error-result, (busy) wait for > interrupt/timer to finish, return result to client > > That will mean that all clients, that uses a wrong key, will take one > second to finish. But as clients, with a correct key, finishes fast I do > not see any problems. > > What am I missing here? > Not much, that is an acceptable option. It's also nice in the sense that it tarpits the attacker, slowing him down (assuming the server only allows one in-flight auth attempt per IP or something to that effect). The downside is that you're keeping resources open longer than necessary for attacking connections, which makes it easier to DoS the service. Normally, a failed authentication should kill the connection as quickly as possible, to not waste resources on attackers. You are correct though that inserting a long-ish delay on failure is a good way to screw with timing attacks, but it does need to be balanced against increasing the risk of resource exhaustion attacks. And either way, it would be nice to have crypto primitives that are tamper-resistant by themselves, rather than rely solely on the application designer to implement attack resistance. - Dave > > /Mads > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: secure-sockets version 1.0
Hi David On Mon, 2010-09-06 at 13:50 -0700, David Anderson wrote: > > > - 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. > > I do not know much about cryptography, so I may be writing nonsense here, but it seems to me that it should not be too hard insuring that all wrongly encrypted data takes equally long to process. One could use an algorithm like: * make interrupt/timer that will finish in one second * process data from client * If data is correctly encrypted, stop interrupt/timer and return information to the client * If data is wrongly encrypted, prepare error-result, (busy) wait for interrupt/timer to finish, return result to client That will mean that all clients, that uses a wrong key, will take one second to finish. But as clients, with a correct key, finishes fast I do not see any problems. What am I missing here? /Mads ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: secure-sockets version 1.0
On Mon, Sep 6, 2010 at 2:08 PM, Thomas DuBuisson wrote: > >> 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? > > There's lots of documentation: > > $ cabal unpack cpsa > $ cd cpsa* > $ cd doc > $ ls *.pdf -- or you might have to build from .tex, I can't recall. Right, I discovered that shortly after sending my email and making a fool of myself. > > The two large families of side-channel attacks that I know of and that > have > > been popular (== successful) recently are: > > ... timing and cache miss attacks ... > > Am I making sense? > > So much sense it's painful. (that's a 'yes') > > > 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. > > But how does that prevent a timing-based information flow if the > consuming Haskell application is the one performing the branch? Are > you assuming all information flow in the Haskell program is so > high-level its not cryptographically important, thus protecting these > low-level primitives is sufficient? Good question. No, not necessarily. In theory all the code of a program that performs crypto, including the "user code" that generates the data being encrypted (in the case of a transport protocol) needs to be hardened against side-channel analysis. In practice, aside from greatly increasing the cost of developing the software, there is somewhat less to be gained: when considering attacks against higher level protocols, it usually comes down to finding a design flaw (e.g. "TLS renegociations are not cryptographically bound to the enclosing channel, allowing an attacker to inject arbitrary prefixes to victim transmissions") or a direct implementation error (e.g. "OpenSSL omits to check the well-formedness of the server certificate in certain situations, leading to arbitrary code execution"). Timing attacks additionally require that you are aiming squarely at a fairly small piece of code, to avoid confounding your measurements with other changes in codepath. In theory it is possible to perform a timing attack on large pieces of code, but in practical attacks it comes down to varying the execution path of a small subset of the whole stack, while keeping the rest as constant as possible. And the small building blocks of protocols are, roughly speaking, basic crypto ops and comparisons. So, if you can ensure that those have good timing properties, you're in rather good shape. An attacker might still be able to time the higher level protocol, but the outcome would be useless, e.g., "If I present an invalid cert, the server responds with latency A, whereas a valid cert results in latency B" vs. "latency is a function of the key bits, a function that I can use to compute a valid key!". Of course, I'm handwaving slightly. Of course, in a perfect world, the higher level protocol should be treated with the same attention to timing attacks as the basic blocks. However, it seems to me that in the real world, basic crypto blocks are more susceptible to timing attacks, whereas high level protocols are more susceptible to design flaws or simple implementation errors. Haskell is a strong ally to eliminate the latter kinds of flaws, while C is a better ally to produce code that executes with specific timing properties. At least, this is my perception of the situation, and the reasoning behind having a C library for basic blocks, but implementing high level protocols in Haskell. Perhaps more experienced Haskell hackers will disagree (much to my delight, if it means I can write more Haskell and less C!). Also, if you feel any of these > tests would fit into the Test.Crypto module (or a submodule) then > please feel free to send in a patch or start some discussion. > Once I reach the point of implementing crypto code, I'll certainly add to the common test suite rather than roll my own. - Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: secure-sockets version 1.0
>> 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? There's lots of documentation: $ cabal unpack cpsa $ cd cpsa* $ cd doc $ ls *.pdf -- or you might have to build from .tex, I can't recall. > The two large families of side-channel attacks that I know of and that have > been popular (== successful) recently are: > ... timing and cache miss attacks ... > Am I making sense? So much sense it's painful. (that's a 'yes') > 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. But how does that prevent a timing-based information flow if the consuming Haskell application is the one performing the branch? Are you assuming all information flow in the Haskell program is so high-level its not cryptographically important, thus protecting these low-level primitives is sufficient? Also, if you feel any of these tests would fit into the Test.Crypto module (or a submodule) then please feel free to send in a patch or start some discussion. Cheers, Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: secure-sockets version 1.0
On Mon, Sep 6, 2010 at 12:45 PM, Thomas DuBuisson < thomas.dubuis...@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 l
Re: [Haskell-cafe] ANNOUNCE: secure-sockets version 1.0
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. > 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. > 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! > 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. If you start on such a task (Haskell TLS) then perhaps you could drop a line to l...@h.o or c...@h.o? Cheers, Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: secure-sockets version 1.0
On Mon, Sep 6, 2010 at 9:16 AM, Thomas DuBuisson 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 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
Re: [Haskell-cafe] ANNOUNCE: secure-sockets version 1.0
On Mon, Sep 6, 2010 at 9:16 AM, Thomas DuBuisson wrote: > Good work Dan! Sorry! David. Good work David. Not sure where "Dan" came from. Would you be interested in providing a build option > that replaces the OpenSSL dependency with something more stand-alone? > Or does ossl perform a significant part of the TLS protocol work for > you (vs just being used for algorithms)? > > Anyone impatient for the midnight haddocking can see the docs here: > http://web.cecs.pdx.edu/~dubuisst/secure-sockets-1.0/html/ > > Cheers, > Thomas > > On Sun, Sep 5, 2010 at 10:26 PM, David Anderson 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@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: secure-sockets version 1.0
Good work Dan! Would you be interested in providing a build option that replaces the OpenSSL dependency with something more stand-alone? Or does ossl perform a significant part of the TLS protocol work for you (vs just being used for algorithms)? Anyone impatient for the midnight haddocking can see the docs here: http://web.cecs.pdx.edu/~dubuisst/secure-sockets-1.0/html/ Cheers, Thomas On Sun, Sep 5, 2010 at 10:26 PM, David Anderson 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@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: secure-sockets version 1.0
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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
