6 ms·

TLS/SSL implementation in Haskell

231 points by dyoder 12y ago

kylemaxwell 12y ago
The response to a subtle weakness in cryptographic software should not be to reimplement the cryptographic implementation from scratch. This inevitably introduces far more problems than it solves.
- thisisdave 12y ago
  I don't think this is a response to a recently-disclosed weakness in OpenSSL. The project has been active for almost four years. Minor edit: almost four years
- chongli 12y ago
  This inevitably introduces far more problems than it solves. Could you elaborate more on this? I fail to see how this is inevitable.
- thinkpad20 12y ago
  You're not wrong, but this clearly wasn't written overnight in respond to the news. There are almost a thousand commits in this repo.
- betterunix 12y ago
  Heartbleed is not exactly a "subtle weakness," it is a gaping hole -- and it is a gaping hole that is only possible in languages with simple pointers and simple pointer arithmetic. In other words, using better languages for the next generation of crypto implementations will prevent this from happening, and then we can all get back to worrying about subtle weaknesses.
- amalcon 12y ago
  Haskell is a particularly odd choice for a project like this, as lazy evaluation makes it difficult to reason about the runtime of various operations under various conditions. Something with a bit more ML in its blood would be better, and for a library that pretty much means OCaml. Edit: I do not at all mean to imply that it is impossible to implement TLS securely in Haskell. Only that there are more natural choices if one wants the advantage of a strong algebraic type system.
  - quasque 12y ago
    Could you elaborate on how lazy evaluation is problematic for such a project?
    - chongli 12y ago
      Nope. This is a common troll whenever any Haskell project is mentioned. It's despicable FUD and just plain wrong. Haskell makes it very easy and lightweight to add strictness annotations to your data structures; far, far easier than it is to add laziness to a strict-by-default language.
    - bvttf 12y ago
      Not him, but I don't think the regular lazy evaluation worry about building up a million thunks and GC hell would be as much of a problem as it being awkward to not have things happen too fast and leave side channel attacks from timing.
    - amalcon 12y ago
      In cryptography, for most operations, you need to be sure that the operation takes the same amount of time for all possible inputs. Otherwise, you leak information. The classic example of this is checking string equality with strncmp(): this takes a different amount of time depending on how similar the strings are. If one string is secret and the other is controlled by an attacker, the attacker can use a clock and multiple attempts to discover the secret. Obviously this particular one isn't relevant to SSL, but there are a number of other possibilities to worry about in most languages, most obviously short-circuiting operations like boolean AND/OR. Lazy evaluation makes every operation short-circuit, so you need to worry about this in every operation. It can be done, but it's harder than it needs to be.
      - automatthew 12y ago
        So we should choose the approach that gives us trivial attacks that reveal 64K straight out of Compton to the approach that may be slightly harder to defend against timing attacks?
- PeterisP 12y ago
  I'd rather say that the long list of overflow-related vulnerabilities would be a good argument to ensure that all crypto libraries are implemented in some kind of a strict language that disallows a large class of vulnerabilities, even if it costs us some time and effort. Seriously, for many languages bugs cause unintended behavior within bounds of implemented logic - such as the recent logic bug that returned an 'okay' response even if the certificate was invalid; however, the fact that ordinary bugs tend to have effects of "read arbitrary memory" or "execute arbitrary code" is a very specific niche of C and friends. In a language appropriate for security, a bug in heartbeat extension would break the heartbeat extension - maybe disable heartbeats not work, maybe cause different heartbeats - but it should be unable to affect the rest of application. In a language appropriate for security, if a single module is secure (i.e., the limited number of API/method calls it exposes are secure), then bugs in all other modules shouldn't be able to affect the insides of that module; so if your app has a tiny core that does some signing w/o exposing the key secrets, then the rest of the app can't touch it even deliberately, much less by an acidental bug.
johnbender 12y ago
Possibly more interesting is a machine checked implementation. http://www.mitls.org/wsgi http://www.mitls.org/wsgi
- dyoder 12y ago
  Very interesting. I was thinking something similar could be done in Haskell.
  - quchen 12y ago
    Haskell is not a theorem prover, and I doubt it can be made one. You can encode some properties of data via the type system, but it's still a general purpose language. Agda on the other hand is a theorem prover, but much less general purpose.
- jude- 12y ago
  From the website, it seems that they proved that their implementation is correct with respect to their formalization of the interfaces in the RFCs. That is, their implementation is logically correct. However, this says nothing about whether or not the implementation is secure. They admit that they don't model time in their proofs, so I doubt their implementation is free of timing attacks. Moreover, its written in F#, so you have to trust your CLI implementation to be bug-free as well.
  - ketralnis 12y ago
    > its written in F#, so you have to trust your CLI implementation to be bug-free as well Is that any different to an implementation in C relying on the processor being bug-free?
    - reidrac 12y ago
      The CLI is running in a processor, isn't it? I guess your argument is that the software using CLI is potentially affected by more bugs ;)
    - 12y ago
krick 12y ago
Nice and everything, but I somehow cannot imagine people massively jump over it. Maybe it's superstitious, I dunno… On the other hand, I undoubtedly agree that we should start making and deploying alternatives in more safe modern languages. In fact, I guess we should start step-by-step rewriting everything that's written in C/C++ and OpenSSL is a good thing to start with. I guess it's a good chance for Rust & friends.
- gizmo686 12y ago
  Crypto poses a unique challenge with the threat of timing attacks. A major benitif of using low level languages is that it is easier to assure that your code takes constant time regardless of the input.
  - betterunix 12y ago
    With the downside being that things like Heartbleed become possible. Dealing with timing attacks in high-level code is not necessarily hard -- Haskell, for example, has strict evaluation.
  - pmahoney 12y ago
    So what candidates are there? While C may make it possible to write code that avoids timing attacks, a quick glance at [1] shows one must avoid memcmp and array lookups based on secret data, neither of which would be prevented by the compiler, and both probably similarly easy mistakes as heartbleed. Can Rust compile to a shared lib the programs can use as easily as a C library? (I think the answer is "not yet", but I'm not sure? At least, I've seen projects for compiling Rust without any runtime library). Today I learned this is possible with Ada [2], but it seems there is some boilerplate to start/stop the runtime. Does Ada provide the necessary low-level control to implement crypto? Are there sufficiently strict dialects of C? NaCl [1] says "There are an increasing number of cases where the C implementations and assembly-language implementations are automatically generated from code that was actually written in another language, such as CAO or qhasm." CAO is a "a domain specific language for describing cryptographic software" [3], while qhasm [4] is a portable assembly seemingly not focused on safety. [1] http://nacl.cr.yp.to/internals.html http://nacl.cr.yp.to/internals.html [2] http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gnat_ugn_unw/Creating-an-Ada-Library-to-be-Used-in-a-Non_002dAda-Context.html#Creating-an-Ada-Library-to-be-Used-in-a-Non_002dAda-Context http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gnat_ugn_unw/Creatin... [3] [PDF] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113.8971&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113... [4] http://cr.yp.to/qhasm.html http://cr.yp.to/qhasm.html
chimeracoder 12y ago
While Haskell mitigates or eliminates some classes of bugs common in C (such as buffer overflow), it also makes it more difficult to guard against side-channel attacks like timing attacks[0], because lazy evaluation makes it more difficult to reason about the actual behavior of the code at runtime. This isn't a dig at either Haskell or C; the point is that all programming languages and environments have their "gotcha!" moments. [0] https://en.wikipedia.org/wiki/Timing_attack https://en.wikipedia.org/wiki/Timing_attack
- pintor 12y ago
  Maybe Rust will provide the right balance between the two.
  - kzrdude 12y ago
    No programming language seems to provide primitives for constant-time algorithms. At this point, gcc and clang should at least provide constant time memcmp primitives; any custom solution not supported by the compiler is not portable and needs to be validated separately for each implementation, each platform, each compiler version.
    - kivikakk 12y ago
      http://golang.org/pkg/crypto/subtle/ http://golang.org/pkg/crypto/subtle/
      - sseveran 12y ago
        Package subtle implements functions that are often useful in cryptographic code but require careful thought to use correctly.
  - awda 12y ago
    whoosh!
- codygman 12y ago
  Perhaps it would be more interesting to discuss how the author of the Haskell TLS/SSL library gets around timing attacks. Actually I have him on twitter... paging @vincenthz. Timing attacks is the first thing I thought of when I saw this implementation so this should be interesting if he can respond.
jcurbo 12y ago
If you're curious (like I was) if anything else in the Haskell ecosystem is using this, this page lists packages that have dependencies on tls in Hackage (the Haskell package repository). There are 26 packages that depend on tls. http://packdeps.haskellers.com/reverse/tls http://packdeps.haskellers.com/reverse/tls Meanwhile, HsOpenSSL (Haskell bindings for OpenSSL) has 22 dependencies: http://packdeps.haskellers.com/reverse/HsOpenSSL http://packdeps.haskellers.com/reverse/HsOpenSSL
pekk 12y ago
and you can still write bugs in Haskell.
- chrisdone 12y ago
  I'll notify the Haskell people straight away, sir.
AaronFriel 12y ago
A number of people are suggesting that this Haskell implementation must be worse than OpenSSL. It probably is. Writing good crypto code is hard. There are probably bugs. Many are saying that one problem with Haskell is that you can't eliminate side-channel attacks due to features of the language. I disagree. There is no common language better than Haskell at encoding invariants in the type system. One could, for example, implement a "biggishnum" library in Haskell using large but fixed size integers and constant-time operations. Free monads are a powerful idea in Haskell[1]. They allow one to easily generalize "interpreters" over sequences of commands. In Haskell, more-so than any other language I've ever used, one can decouple execution from algorithm specification. Free applicative functors generalize further[2]. They define a computational structure that must be fixed a priori. That is, by definition a free applicative functor cannot know the state of the data during its execution. There are some problems with this. Applicative functors have an operation which can lift regular functions into it. That operation would have to be hidden, so that only a kernel was exposed that offered the ability to initialize data, and then perform computations upon it. But it's possible to do this. It is actually not a radical idea to imagine this being done in Haskell. Making a library and a set of primitive operations that can be used by an end user safely, in provably constant time is possible. [1] http://www.haskellforall.com/2012/06/you-could-have-invented-free-monads.html http://www.haskellforall.com/2012/06/you-could-have-invented... [2] http://paolocapriotti.com/assets/applicative.pdf http://paolocapriotti.com/assets/applicative.pdf
- cynicalkane 12y ago
  I'm wondering about a situation where forgetting a strictness annotation is the analogous Haskell situation of forgetting to bounds-check some input. There are lots of ways in Haskell for something not to be evaluated. (No, the simple fixes like 'use strict fields' do not cover all cases.) To put all of them behind a free monad seems like it would be giving up a lot. In C you could have made some 'safe buffer' struct together with some safe set of functions. But people didn't do that.
  - PeterisP 12y ago
    The point is that in Haskell you could reasonably define a 'biggish-num' type where only strict and constant-time operations would be possible - you couldn't forget to make an annotation, you'd have to explicitly ask for the value to become a 'normal number' before being able to make any such operation. In C having such a 'safe buffer' struct would require discipline from you, in Haskell that'd be the natural order of things.
runeks 12y ago
This seems interesting. I'm completely ignorant about Haskell. I see there's some code in a "Benchmarks" folder; I think it would be highly interesting to see a comparison in speed between OpenSSL's SSL implementation and this one (the operations that a web server would normally have to do). Can anyone make that happen? I can't even figure out how to execute Haskell code in Ubuntu 13.04. Seems to me like if the code base is 20 times smaller than OpenSSL, and we can assess whether timing attacks are present or not -- and if they are, replace the timing critical code with C code, perhaps -- that this would be a real alternative to OpenSSL. Am I being unrealistic in thinking this? Not that everyone will adopt it, mind you, but that adopting it would be a wise thing to do?
- kazagistar 12y ago
  sudo apt-get install haskell-platform You can install development packages through the "cabal" command line tool. The REPL environment is "ghci". On one hand, it is a very high performance language with tons of purity, abstraction, and invariants built in to the type system and semantics. On the other hand, certain aspects can be problematic to reason about.
  - runeks 12y ago
    E: Unable to locate package haskell-platform The package seems unavailable for Ubuntu 13.04. I think it's time to install 14.04 for me.
    - prakashk 12y ago
      http://www.ubuntuask.com/q/answers-haskell-platform-on-13-04-298601.html http://www.ubuntuask.com/q/answers-haskell-platform-on-13-04...
- tene 12y ago
  The big difficulty in adopting it in any current codebase is that most current pieces of software are not written in haskell. The huge advantage of projects in C like OpenSSL is that you can produce platform-native shared libraries that can be used easily from any other language. A bit of research shows that it's possible to make shared libraries with haskell, but not quite as straightforward to use them. I have no practical experience about how troublesome it would actually be.
aalpbalkan 12y ago
TLS implementation in Go. http://golang.org/pkg/crypto/tls/ http://golang.org/pkg/crypto/tls/ Go is probably better at this.
- somethingnew 12y ago
  According to Adam Langley, a Go contributor, it can still be side-channeled. https://twitter.com/agl__/status/453370970552532992 https://twitter.com/agl__/status/453370970552532992
  - tptacek 12y ago
    s/Go contributor/primary author of the Golang TLS package/g (Also, he's one of Google's point people on TLS.) JFWIW.
- dscrd 12y ago
  Unfortunately this library can only be used in Go, right?
  - justincormack 12y ago
    You could terminate connections with it and have a local socket to another process. As we have seen putting ssl in another process is helpful for memory isolation...
- wyager 12y ago
  >Go is probably better at this. Why? Go doesn't really offer a whole lot in terms of security, except for better managed memory. I'm not even sure you could reliably eliminate side channel attacks in Go.
  - johntyree 12y ago
    >Go doesn't really offer a whole lot in terms of security, except for better managed memory. What makes it better? Haskell's GC is very advanced.
jacobwcarlson 12y ago
With all due respect, I don't know that TLS/SSL implementation problems will be largely solved by changing programming languages.
- sitkack 12y ago
  Every flaw we have seen in OpenSSL in the last year would definitely have been impossible in a managed language.
  - runeks 12y ago
    Not this one: http://eprint.iacr.org/2014/161.pdf http://eprint.iacr.org/2014/161.pdf
    - sitkack 12y ago
      I think side channel attacks are valid, but in this case they are a red herring. One side channel exploit and what three remote code executions? It sounds like lots of people (sockpuppet echo chamber) are saying if the new language/runtime doesn't fix all possible flaws we should stay with the broken-on-purpose OpenSSL codebase?
      - runeks 12y ago
        > It sounds like lots of people (sockpuppet echo chamber) are saying if the new language/runtime doesn't fix all possible flaws we should stay with the broken-on-purpose OpenSSL codebase? I think it's more likely they are saying that replacing one broken implementation with another broken implementation isn't worth the effort. Sure, remote code execution and reading of arbitrary memory are a lot worse than an attacker figuring out a private key. But if an implementation of a crypto system is not able to conceal the private key, it is completely useless. Seems to me like we may need to, first of all, redesign some algorithms to be easier to implement in constant time (like Ed25519 and symmetric encryption algorithms that avoid S-boxes), and secondly, develop a language that combines both memory safety and the ability to reason about whether an operation runs in constant time. I'm not saying this is something we just do, it's a huge undertaking. I'm saying that it seems to me this may be needed, unless we want to find 5 years down the line, when everyone is using a Haskell TLS implementation, that attackers can retrieve the private key through timing attacks. That would be a fairly large effort put towards writing another TLS implementation that is broken by design.
msie 12y ago
How bad are timing/side-channel attacks, really? I think that half of the people who talk about this are showing off. Some nerdy one-uppance.
- 001spartan 12y ago
  When you're talking about something used to secure as much sensitive data for as many people as TLS/SSL, timing and side channel attacks are very important. Any little flaw can lead to information exposure such that people are put into danger.
- wyager 12y ago
  >How bad are timing/side-channel attacks, really? Bad. They are not something to blow off. They may seem "out there", but they are actually leveraged somewhat frequently. They are particularly dangerous in certain shared-hardware environments (e.g. VPS services like DigitalOceal, AWS, etc), and against physical devices that are supposed to resist data extraction (like smart cards).
- brohee 12y ago
  Extremely bad and practical : http://cr.yp.to/antiforgery/cachetiming-20050414.pdf http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
developer786 12y ago
Totally off topic, but programmers, I REALLY need your help... https://news.ycombinator.com/item?id=7559067 https://news.ycombinator.com/item?id=7559067

231 points by dyoder 12y ago

The response to a subtle weakness in cryptographic software should not be to reimplement the cryptographic implementation from scratch. This inevitably introduces far more problems than it solves.

thisisdave 12y ago
I don't think this is a response to a recently-disclosed weakness in OpenSSL. The project has been active for almost four years. Minor edit: almost four years
chongli 12y ago
This inevitably introduces far more problems than it solves. Could you elaborate more on this? I fail to see how this is inevitable.
thinkpad20 12y ago
You're not wrong, but this clearly wasn't written overnight in respond to the news. There are almost a thousand commits in this repo.
betterunix 12y ago
Heartbleed is not exactly a "subtle weakness," it is a gaping hole -- and it is a gaping hole that is only possible in languages with simple pointers and simple pointer arithmetic. In other words, using better languages for the next generation of crypto implementations will prevent this from happening, and then we can all get back to worrying about subtle weaknesses.
amalcon 12y ago
Haskell is a particularly odd choice for a project like this, as lazy evaluation makes it difficult to reason about the runtime of various operations under various conditions. Something with a bit more ML in its blood would be better, and for a library that pretty much means OCaml. Edit: I do not at all mean to imply that it is impossible to implement TLS securely in Haskell. Only that there are more natural choices if one wants the advantage of a strong algebraic type system.
- quasque 12y ago
  Could you elaborate on how lazy evaluation is problematic for such a project?
  - chongli 12y ago
    Nope. This is a common troll whenever any Haskell project is mentioned. It's despicable FUD and just plain wrong. Haskell makes it very easy and lightweight to add strictness annotations to your data structures; far, far easier than it is to add laziness to a strict-by-default language.
  - bvttf 12y ago
    Not him, but I don't think the regular lazy evaluation worry about building up a million thunks and GC hell would be as much of a problem as it being awkward to not have things happen too fast and leave side channel attacks from timing.
  - amalcon 12y ago
    In cryptography, for most operations, you need to be sure that the operation takes the same amount of time for all possible inputs. Otherwise, you leak information. The classic example of this is checking string equality with strncmp(): this takes a different amount of time depending on how similar the strings are. If one string is secret and the other is controlled by an attacker, the attacker can use a clock and multiple attempts to discover the secret. Obviously this particular one isn't relevant to SSL, but there are a number of other possibilities to worry about in most languages, most obviously short-circuiting operations like boolean AND/OR. Lazy evaluation makes every operation short-circuit, so you need to worry about this in every operation. It can be done, but it's harder than it needs to be.
    - automatthew 12y ago
      So we should choose the approach that gives us trivial attacks that reveal 64K straight out of Compton to the approach that may be slightly harder to defend against timing attacks?
PeterisP 12y ago
I'd rather say that the long list of overflow-related vulnerabilities would be a good argument to ensure that all crypto libraries are implemented in some kind of a strict language that disallows a large class of vulnerabilities, even if it costs us some time and effort. Seriously, for many languages bugs cause unintended behavior within bounds of implemented logic - such as the recent logic bug that returned an 'okay' response even if the certificate was invalid; however, the fact that ordinary bugs tend to have effects of "read arbitrary memory" or "execute arbitrary code" is a very specific niche of C and friends. In a language appropriate for security, a bug in heartbeat extension would break the heartbeat extension - maybe disable heartbeats not work, maybe cause different heartbeats - but it should be unable to affect the rest of application. In a language appropriate for security, if a single module is secure (i.e., the limited number of API/method calls it exposes are secure), then bugs in all other modules shouldn't be able to affect the insides of that module; so if your app has a tiny core that does some signing w/o exposing the key secrets, then the rest of the app can't touch it even deliberately, much less by an acidental bug.

johnbender 12y ago

Possibly more interesting is a machine checked implementation. http://www.mitls.org/wsgi http://www.mitls.org/wsgi

dyoder 12y ago
Very interesting. I was thinking something similar could be done in Haskell.
- quchen 12y ago
  Haskell is not a theorem prover, and I doubt it can be made one. You can encode some properties of data via the type system, but it's still a general purpose language. Agda on the other hand is a theorem prover, but much less general purpose.
jude- 12y ago
From the website, it seems that they proved that their implementation is correct with respect to their formalization of the interfaces in the RFCs. That is, their implementation is logically correct. However, this says nothing about whether or not the implementation is secure. They admit that they don't model time in their proofs, so I doubt their implementation is free of timing attacks. Moreover, its written in F#, so you have to trust your CLI implementation to be bug-free as well.
- ketralnis 12y ago
  > its written in F#, so you have to trust your CLI implementation to be bug-free as well Is that any different to an implementation in C relying on the processor being bug-free?
  - reidrac 12y ago
    The CLI is running in a processor, isn't it? I guess your argument is that the software using CLI is potentially affected by more bugs ;)
  - 12y ago

krick 12y ago

Nice and everything, but I somehow cannot imagine people massively jump over it. Maybe it's superstitious, I dunno… On the other hand, I undoubtedly agree that we should start making and deploying alternatives in more safe modern languages. In fact, I guess we should start step-by-step rewriting everything that's written in C/C++ and OpenSSL is a good thing to start with. I guess it's a good chance for Rust & friends.

gizmo686 12y ago
Crypto poses a unique challenge with the threat of timing attacks. A major benitif of using low level languages is that it is easier to assure that your code takes constant time regardless of the input.
- betterunix 12y ago
  With the downside being that things like Heartbleed become possible. Dealing with timing attacks in high-level code is not necessarily hard -- Haskell, for example, has strict evaluation.
- pmahoney 12y ago
  So what candidates are there? While C may make it possible to write code that avoids timing attacks, a quick glance at [1] shows one must avoid memcmp and array lookups based on secret data, neither of which would be prevented by the compiler, and both probably similarly easy mistakes as heartbleed. Can Rust compile to a shared lib the programs can use as easily as a C library? (I think the answer is "not yet", but I'm not sure? At least, I've seen projects for compiling Rust without any runtime library). Today I learned this is possible with Ada [2], but it seems there is some boilerplate to start/stop the runtime. Does Ada provide the necessary low-level control to implement crypto? Are there sufficiently strict dialects of C? NaCl [1] says "There are an increasing number of cases where the C implementations and assembly-language implementations are automatically generated from code that was actually written in another language, such as CAO or qhasm." CAO is a "a domain specific language for describing cryptographic software" [3], while qhasm [4] is a portable assembly seemingly not focused on safety. [1] http://nacl.cr.yp.to/internals.html http://nacl.cr.yp.to/internals.html [2] http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gnat_ugn_unw/Creating-an-Ada-Library-to-be-Used-in-a-Non_002dAda-Context.html#Creating-an-Ada-Library-to-be-Used-in-a-Non_002dAda-Context http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gnat_ugn_unw/Creatin... [3] [PDF] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113.8971&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113... [4] http://cr.yp.to/qhasm.html http://cr.yp.to/qhasm.html

chimeracoder 12y ago

While Haskell mitigates or eliminates some classes of bugs common in C (such as buffer overflow), it also makes it more difficult to guard against side-channel attacks like timing attacks[0], because lazy evaluation makes it more difficult to reason about the actual behavior of the code at runtime. This isn't a dig at either Haskell or C; the point is that all programming languages and environments have their "gotcha!" moments. [0] https://en.wikipedia.org/wiki/Timing_attack https://en.wikipedia.org/wiki/Timing_attack

pintor 12y ago
Maybe Rust will provide the right balance between the two.
- kzrdude 12y ago
  No programming language seems to provide primitives for constant-time algorithms. At this point, gcc and clang should at least provide constant time memcmp primitives; any custom solution not supported by the compiler is not portable and needs to be validated separately for each implementation, each platform, each compiler version.
  - kivikakk 12y ago
    http://golang.org/pkg/crypto/subtle/ http://golang.org/pkg/crypto/subtle/
    - sseveran 12y ago
      Package subtle implements functions that are often useful in cryptographic code but require careful thought to use correctly.
- awda 12y ago
  whoosh!
codygman 12y ago
Perhaps it would be more interesting to discuss how the author of the Haskell TLS/SSL library gets around timing attacks. Actually I have him on twitter... paging @vincenthz. Timing attacks is the first thing I thought of when I saw this implementation so this should be interesting if he can respond.

jcurbo 12y ago

If you're curious (like I was) if anything else in the Haskell ecosystem is using this, this page lists packages that have dependencies on tls in Hackage (the Haskell package repository). There are 26 packages that depend on tls. http://packdeps.haskellers.com/reverse/tls http://packdeps.haskellers.com/reverse/tls Meanwhile, HsOpenSSL (Haskell bindings for OpenSSL) has 22 dependencies: http://packdeps.haskellers.com/reverse/HsOpenSSL http://packdeps.haskellers.com/reverse/HsOpenSSL

pekk 12y ago

and you can still write bugs in Haskell.

chrisdone 12y ago
I'll notify the Haskell people straight away, sir.

AaronFriel 12y ago

A number of people are suggesting that this Haskell implementation must be worse than OpenSSL. It probably is. Writing good crypto code is hard. There are probably bugs. Many are saying that one problem with Haskell is that you can't eliminate side-channel attacks due to features of the language. I disagree. There is no common language better than Haskell at encoding invariants in the type system. One could, for example, implement a "biggishnum" library in Haskell using large but fixed size integers and constant-time operations. Free monads are a powerful idea in Haskell[1]. They allow one to easily generalize "interpreters" over sequences of commands. In Haskell, more-so than any other language I've ever used, one can decouple execution from algorithm specification. Free applicative functors generalize further[2]. They define a computational structure that must be fixed a priori. That is, by definition a free applicative functor cannot know the state of the data during its execution. There are some problems with this. Applicative functors have an operation which can lift regular functions into it. That operation would have to be hidden, so that only a kernel was exposed that offered the ability to initialize data, and then perform computations upon it. But it's possible to do this. It is actually not a radical idea to imagine this being done in Haskell. Making a library and a set of primitive operations that can be used by an end user safely, in provably constant time is possible. [1] http://www.haskellforall.com/2012/06/you-could-have-invented-free-monads.html http://www.haskellforall.com/2012/06/you-could-have-invented... [2] http://paolocapriotti.com/assets/applicative.pdf http://paolocapriotti.com/assets/applicative.pdf

cynicalkane 12y ago
I'm wondering about a situation where forgetting a strictness annotation is the analogous Haskell situation of forgetting to bounds-check some input. There are lots of ways in Haskell for something not to be evaluated. (No, the simple fixes like 'use strict fields' do not cover all cases.) To put all of them behind a free monad seems like it would be giving up a lot. In C you could have made some 'safe buffer' struct together with some safe set of functions. But people didn't do that.
- PeterisP 12y ago
  The point is that in Haskell you could reasonably define a 'biggish-num' type where only strict and constant-time operations would be possible - you couldn't forget to make an annotation, you'd have to explicitly ask for the value to become a 'normal number' before being able to make any such operation. In C having such a 'safe buffer' struct would require discipline from you, in Haskell that'd be the natural order of things.

runeks 12y ago

This seems interesting. I'm completely ignorant about Haskell. I see there's some code in a "Benchmarks" folder; I think it would be highly interesting to see a comparison in speed between OpenSSL's SSL implementation and this one (the operations that a web server would normally have to do). Can anyone make that happen? I can't even figure out how to execute Haskell code in Ubuntu 13.04. Seems to me like if the code base is 20 times smaller than OpenSSL, and we can assess whether timing attacks are present or not -- and if they are, replace the timing critical code with C code, perhaps -- that this would be a real alternative to OpenSSL. Am I being unrealistic in thinking this? Not that everyone will adopt it, mind you, but that adopting it would be a wise thing to do?

kazagistar 12y ago
sudo apt-get install haskell-platform You can install development packages through the "cabal" command line tool. The REPL environment is "ghci". On one hand, it is a very high performance language with tons of purity, abstraction, and invariants built in to the type system and semantics. On the other hand, certain aspects can be problematic to reason about.
- runeks 12y ago
  E: Unable to locate package haskell-platform The package seems unavailable for Ubuntu 13.04. I think it's time to install 14.04 for me.
  - prakashk 12y ago
    http://www.ubuntuask.com/q/answers-haskell-platform-on-13-04-298601.html http://www.ubuntuask.com/q/answers-haskell-platform-on-13-04...
tene 12y ago
The big difficulty in adopting it in any current codebase is that most current pieces of software are not written in haskell. The huge advantage of projects in C like OpenSSL is that you can produce platform-native shared libraries that can be used easily from any other language. A bit of research shows that it's possible to make shared libraries with haskell, but not quite as straightforward to use them. I have no practical experience about how troublesome it would actually be.

aalpbalkan 12y ago

TLS implementation in Go. http://golang.org/pkg/crypto/tls/ http://golang.org/pkg/crypto/tls/ Go is probably better at this.

somethingnew 12y ago
According to Adam Langley, a Go contributor, it can still be side-channeled. https://twitter.com/agl__/status/453370970552532992 https://twitter.com/agl__/status/453370970552532992
- tptacek 12y ago
  s/Go contributor/primary author of the Golang TLS package/g (Also, he's one of Google's point people on TLS.) JFWIW.
dscrd 12y ago
Unfortunately this library can only be used in Go, right?
- justincormack 12y ago
  You could terminate connections with it and have a local socket to another process. As we have seen putting ssl in another process is helpful for memory isolation...
wyager 12y ago
>Go is probably better at this. Why? Go doesn't really offer a whole lot in terms of security, except for better managed memory. I'm not even sure you could reliably eliminate side channel attacks in Go.
- johntyree 12y ago
  >Go doesn't really offer a whole lot in terms of security, except for better managed memory. What makes it better? Haskell's GC is very advanced.

jacobwcarlson 12y ago

With all due respect, I don't know that TLS/SSL implementation problems will be largely solved by changing programming languages.

sitkack 12y ago
Every flaw we have seen in OpenSSL in the last year would definitely have been impossible in a managed language.
- runeks 12y ago
  Not this one: http://eprint.iacr.org/2014/161.pdf http://eprint.iacr.org/2014/161.pdf
  - sitkack 12y ago
    I think side channel attacks are valid, but in this case they are a red herring. One side channel exploit and what three remote code executions? It sounds like lots of people (sockpuppet echo chamber) are saying if the new language/runtime doesn't fix all possible flaws we should stay with the broken-on-purpose OpenSSL codebase?
    - runeks 12y ago
      > It sounds like lots of people (sockpuppet echo chamber) are saying if the new language/runtime doesn't fix all possible flaws we should stay with the broken-on-purpose OpenSSL codebase? I think it's more likely they are saying that replacing one broken implementation with another broken implementation isn't worth the effort. Sure, remote code execution and reading of arbitrary memory are a lot worse than an attacker figuring out a private key. But if an implementation of a crypto system is not able to conceal the private key, it is completely useless. Seems to me like we may need to, first of all, redesign some algorithms to be easier to implement in constant time (like Ed25519 and symmetric encryption algorithms that avoid S-boxes), and secondly, develop a language that combines both memory safety and the ability to reason about whether an operation runs in constant time. I'm not saying this is something we just do, it's a huge undertaking. I'm saying that it seems to me this may be needed, unless we want to find 5 years down the line, when everyone is using a Haskell TLS implementation, that attackers can retrieve the private key through timing attacks. That would be a fairly large effort put towards writing another TLS implementation that is broken by design.

msie 12y ago

How bad are timing/side-channel attacks, really? I think that half of the people who talk about this are showing off. Some nerdy one-uppance.

001spartan 12y ago
When you're talking about something used to secure as much sensitive data for as many people as TLS/SSL, timing and side channel attacks are very important. Any little flaw can lead to information exposure such that people are put into danger.
wyager 12y ago
>How bad are timing/side-channel attacks, really? Bad. They are not something to blow off. They may seem "out there", but they are actually leveraged somewhat frequently. They are particularly dangerous in certain shared-hardware environments (e.g. VPS services like DigitalOceal, AWS, etc), and against physical devices that are supposed to resist data extraction (like smart cards).
brohee 12y ago
Extremely bad and practical : http://cr.yp.to/antiforgery/cachetiming-20050414.pdf http://cr.yp.to/antiforgery/cachetiming-20050414.pdf

developer786 12y ago

Totally off topic, but programmers, I REALLY need your help... https://news.ycombinator.com/item?id=7559067 https://news.ycombinator.com/item?id=7559067