Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/10 04:06 , Sittampalam, Ganesh wrote: While I agree with the potential benefits, I also worry that you will end up making something that is far less well tested in practice. For widely used and fairly low-level libraries like gnutls, openssl and zlib, I'm just skeptical that the benefits outweigh the risks and costs. I see your point, but I would be prepared to trust a clean, typesafe (and especially if it's pure) Haskell implementation over the Cthulhu's-tentacles that is openssl. :) - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky0VikACgkQIn7hlCsL25Wt/QCgneAyuCttwnyrHG4vuC22sNBp Y7gAnAtKUoNekXUb61ISYwnmSkZWJejM =3+oI -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/10 04:41 , Brandon Moore wrote: particular about cryptographic primitives. Some side channel attacks seem to call for a very low-level language, to make it easier to verify that e.g. execution time and the memory access pattern does not depend on the key. It's hard enough to predict execution times for Haskell code at the best of times :) - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky0V4cACgkQIn7hlCsL25V0VwCg1GrZkqrGU0CswG/KSQvHO+hJ B2QAn269l6o58G0AeRlyWV9lRTaFF6K6 =6RTp -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
Vincent Hanquez wrote: On Fri, Oct 08, 2010 at 12:54:48PM +0100, Sittampalam, Ganesh wrote: What's the motivation for this? Well, I wanted to have a tls/ssl module that integrate nicely with haskell. until then the 2 solutions were: - shelling out to curl: that's not great, usually works until you have an error, and then you're greeted with a curl command line error. the control is pretty poor, what if you want a fancy certificate control ? Also you have absolutely no server support in this case, this is client only. - using either gnutls or openssl bindings: there's multiples reasons this is not great. depending on huge C libraries (security wise, platform wise), massive usage of IO even in place where it shouldn't, low hacking potential (adding ciphers/hash, etc). Apart from that, we all know here why programming in haskell is better than doing the same thing in says, C or python. I think it apply even more when the focus of this is a secure library. While I agree with the potential benefits, I also worry that you will end up making something that is far less well tested in practice. For widely used and fairly low-level libraries like gnutls, openssl and zlib, I'm just skeptical that the benefits outweigh the risks and costs. Anyway, it's just a feeling. Please do prove me wrong :-) Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
While I agree with the potential benefits, I also worry that you will end up making something that is far less well tested in practice. For widely used and fairly low-level libraries like gnutls, openssl and zlib, I'm just skeptical that the benefits outweigh the risks and costs. Anyway, it's just a feeling. Please do prove me wrong :-) This certainly isn't a proof by a long shot, but my feeling on at least low-level libraries is exactly the reverse of this. C libraries are usually designed to be extremely stateful (this certainly includes openssl), and because of that any Haskell wrapper for them ends up being heavily IO based. The result of this is that any code that incorporates it ends up being trapped in an IO mess to do essentially pure (yes, I know the arguments about IO being pure, you know what I mean) things. It's precisely these libraries that we need not just implemented in a native way, but designed in a pure, beautiful, simple way for Haskell. While I can see your point about potentially introducing new security holes, and producing much less trusted code, I feel having tidy, pure libraries that we can all integrate into our Haskell is a benefit that far outweighs this. Especially when we have nice things like the type system, which can be used to alleviate many of the security worries. Tom Davie___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
While I can see your point about potentially introducing new security holes, and producing much less trusted code, I feel having tidy, pure libraries that we can all integrate into our Haskell is a benefit that far outweighs this. Especially when we have nice things like the type system, which can be used to alleviate many of the security worries. I agree in general, for code like servers and file formats, but I worry in particular about cryptographic primitives. Some side channel attacks seem to call for a very low-level language, to make it easier to verify that e.g. execution time and the memory access pattern does not depend on the key. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
On Mon, Oct 11, 2010 at 09:06:45AM +0100, Sittampalam, Ganesh wrote: While I agree with the potential benefits, I also worry that you will end up making something that is far less well tested in practice. For widely used and fairly low-level libraries like gnutls, openssl and zlib, I'm just skeptical that the benefits outweigh the risks and costs. Hi Ganesh, You're absolutely right in the fact there's risk involved. Cryptography related things are hard to get right, I won't be denying it. However I'm really not a big fan of the alternative. Having to rely forever on blessed black boxes coded in low level languages, doesn't sound appealing to me. There's the risk that cryptography becomes even more voodoo magic by doing that. This is certainly true for TLS/SSL. a lots of people have no idea how it works, what it does and doesn't do. So hopefully having a clean haskell library will make more people interested, in changing this black-box state; an even bigger hope, is to vulgarize cryptography, instead of making it more opaque ;) Anyway, it's just a feeling. Please do prove me wrong :-) I'll certainly try ;) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
On Mon, Oct 11, 2010 at 09:41, Brandon Moore brandon_m_mo...@yahoo.com wrote: While I can see your point about potentially introducing new security holes, and producing much less trusted code, I feel having tidy, pure libraries that we can all integrate into our Haskell is a benefit that far outweighs this. Especially when we have nice things like the type system, which can be used to alleviate many of the security worries. I agree in general, for code like servers and file formats, but I worry in particular about cryptographic primitives. Some side channel attacks seem to call for a very low-level language, to make it easier to verify that e.g. execution time and the memory access pattern does not depend on the key. I personally think we have to draw the line somewhere regarding what we care about when it comes to security. (Provable) correctness, maintainability through well-structured code are things we are more likely to gain through using high-level languages like Haskell. That is actually a lot of security bundled up in those things. What we lose is low-level control, which would be required to thwart side-channel attacks. On the other hand, I'm not convinced openssl or gnutls deal with side-channel attacks very effectively either. In any case, there is nothing that says we must have only *one* SSL library, based on this discussion there seems to be people in the community who still would prefer a binding to openssl/gnutls. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
On Fri, Oct 08, 2010 at 12:54:48PM +0100, Sittampalam, Ganesh wrote: What's the motivation for this? Well, I wanted to have a tls/ssl module that integrate nicely with haskell. until then the 2 solutions were: - shelling out to curl: that's not great, usually works until you have an error, and then you're greeted with a curl command line error. the control is pretty poor, what if you want a fancy certificate control ? Also you have absolutely no server support in this case, this is client only. - using either gnutls or openssl bindings: there's multiples reasons this is not great. depending on huge C libraries (security wise, platform wise), massive usage of IO even in place where it shouldn't, low hacking potential (adding ciphers/hash, etc). Apart from that, we all know here why programming in haskell is better than doing the same thing in says, C or python. I think it apply even more when the focus of this is a secure library. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
On Fri, Oct 08, 2010 at 02:08:29PM +0200, Christopher Done wrote: Indeed. Easier to install, easier to hack on (for Haskellers). Haskell program coverage, debugging, extending your quickcheck tests, etc. absolutely. I'm certainly hoping to quickcheck all that is quickcheckable. The next thing i want to add to the tests is the TLS startup configuration, to that quickcheck test every possible handshake scenario (certificate, no certificate, block cipher, stream cipher, RSA, DH, DSA, TLS1.2, TLS1.1, TLS1.0, SSL3, etc). There's also the type-system experience, which raise the safety experience massively. I feel much better seeing pure functions and clearly bounded types instead of a pointer to the whole world as it is quite common in gnutls and openssl. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
Vincent Hanquez wrote: On Fri, Oct 08, 2010 at 11:14:01AM +0530, C K Kashyap wrote: Does native mean Haskell only - without FFI? Native means the implementation is in haskell, and the library is not using another implementation (in another language) to do the work: either through FFI as a binding, or as a wrapper to an external program. What's the motivation for this? One thing I can see is that it would make things easier to install on Windows. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
On 8 October 2010 13:54, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com wrote: Vincent Hanquez wrote: On Fri, Oct 08, 2010 at 11:14:01AM +0530, C K Kashyap wrote: Does native mean Haskell only - without FFI? Native means the implementation is in haskell, and the library is not using another implementation (in another language) to do the work: either through FFI as a binding, or as a wrapper to an external program. What's the motivation for this? One thing I can see is that it would make things easier to install on Windows. Indeed. Easier to install, easier to hack on (for Haskellers). Haskell program coverage, debugging, extending your quickcheck tests, etc. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
