

Introducing Transport Layer Security in pure OCaml - tizoc
http://openmirage.org/blog/introducing-ocaml-tls

======
richardwhiuk
It looks like they have some odd cipher suite selection mechanic.

[https://tls.openmirage.org](https://tls.openmirage.org) negotiates
TLS_RSA_WITH_RC4_128_SHA which is the second worse suite that Chrome 35 will
offer by default. If I renegotiate, the server will suggets
TLS_RSA_WITH_AES_256_CBC_SHA, so it looks like the server wants to change the
cipher later, which seems odd.

This means it doesn't support PFS or several other advantages in the newer
protocols.

I'd be very interested to know about side channel attacks which may be
possible in OCaml, as opposed to in another languages - there doesn't seem to
be any discussion of them here.

They also refer to the Apple Goto fail bug as a memory safety issue - that's
not true, it was a programming flaw that could be made in a GCed language.

Finally, if I look at the issue tracker I see things like
[https://github.com/mirleft/ocaml-
tls/issues/6](https://github.com/mirleft/ocaml-tls/issues/6) \- closed, with
no explanation and marked as a security concern - which gives me no confidence
that the issue was addressed.

~~~
avsm
Well done on noticing the slightly random cipher negotiation. That was
actually deliberately put into the demo server on tls.openmirage.org to help
us get more test coverage from visitors to the site (see the
[https://github.com/mirleft/ocaml-tls/tree/demo-
random](https://github.com/mirleft/ocaml-tls/tree/demo-random) branch). We've
mitigated most of the commonly known client incompatibilities, but there are
no doubt obscure cipher-specific mitigations remaining, and the only way to
uncover those is by forcing their negotiation ahead of better ciphers.

We've looked into timing side channels attacks quite a bit, but decided to
focus on the core protocol support before tackling the big issue of data-
dependent control flow attacks See [https://github.com/mirleft/ocaml-
tls/pull/49](https://github.com/mirleft/ocaml-tls/pull/49) for discussion on
the Lucky 13 mitigation that isn't merged in for example.

Editing the goto-fail reference to reflect that it's not purely memory safety
(but of course we believe that more structured programming abstractions will
help mitigate this class of errors). I've asked Hannes about the #6 issue as
well, as that shouldn't have been closed with no explanation -- do feel free
to post queries on such issues yourself as polling HN threads for feedback
isn't reliable.

~~~
amirmc
Clicky link to the reply is:

[https://github.com/mirleft/ocaml-
tls/issues/6#issuecomment-4...](https://github.com/mirleft/ocaml-
tls/issues/6#issuecomment-48383788)

------
emillon
The work on Mirage is very interesting. If I understand it correctly, it may
be possible to run a Xen domain with a Linux application server, and with a
TLS reverse proxy in front using another Xen domain (in the form of a
unikernel).

This would be fantastic and does not change a lot how you run your
application, except that you get hardened crypto for free.

That's assuming that ocaml-tls has no "high level" bugs (not memory corruption
related) of course, but I'm quite sure that it is way easier to review than
existing TLS implementations.

~~~
edwintorok
One thing that concerns me is the entropy source in Xen guest domains, but
hopefully that'll be worked out for the final version.

~~~
avsm
We're putting together a front/backend ring (rndfront/rndback) that will proxy
entropy from dom0 directly into the guest. It'll take some time for this to
percolate into the public cloud, so we'll need to do what Linux does in the
meanwhile (harvest entropy from interrupt timings, attempt RDRAND, and so on).

The ENTROPY module type supports this sort of callback in 1.2.0:
[https://github.com/mirage/mirage/blob/master/types/V1.mli#L7...](https://github.com/mirage/mirage/blob/master/types/V1.mli#L75)

(If you're interested in contributing, the entropy harvesting is in sore need
of more eyes and help!)

~~~
rwmj
/me grumbles about virtio-rng and reinventing ABIs ...

~~~
avsm
Dave Scott's added support for a low-bandwidth channel into XL with the
intention of reusing virtio-rng (and virtio-serial and friends).
[http://lists.xen.org/archives/html/xen-
devel/2014-06/msg0293...](http://lists.xen.org/archives/html/xen-
devel/2014-06/msg02931.html)

On the other hand, I disagree that we're reinventing an ABI given that:

1) virtio isn't the supported PV interface in Xen -- rndfront/back follows the
same design principles as net/blk/fb/usb/pci/console etc.

2) The Xen shared-ring interface is older than virtio, and much simpler for
pure PV guests such as Mirage (no PCI emulation to worry about). I do wonder
what happened to that GSoC project from a few years to add virtio support to
Xen though...I don't think any patches ever appeared.

~~~
djs55
s/added/currently trying to add/ :-)

For HVM guests I hope that virtio-rng would work as-is (if it could be turned
on via the control path). That's definitely worth a look.

For PV guests like Mirage I'm currently plumbing through a Xen PV analogue of
virtio-serial by hijacking^Wextending the existing PV console support. Since
the backend for that is in qemu already it might be possible to hook up the
entropy source (with all the rate limiting etc). I think the trick would be to
get the guest to recognise the frontend for what it is -- I imagine the
virtio-rng device in the guest presents itself as a magic hardware PCI device
and 'just works'.

------
hoggle
Are we finally approaching consensus in the field of systems programming that
security is more important than performance (thanks to heartbleed)?

Or put differently: have we reached the point where computers are fast enough
so that we can move on and sacrifice some of those abundant MIPS and extra RAM
for much improved clarity in our critical infrastructure code?

OCaml could actually be a great choice for maintaining a solid TLS layer.

~~~
pdpi
For the sake of moving things forward: every time we have this discussion,
someone always points out that functional languages would make it easier to
get correct behaviour from a crypto library, and someone always replies that
garbage collection opens you up to side-channel (timing, in this case)
attacks.

~~~
hoggle
Interesting, I didn't know that. I always wondered why (non "functional") Ada
doesn't get mentioned more often in these kinds of discussions:

[http://www.adaic.org/advantages/](http://www.adaic.org/advantages/)

[http://www.seas.gwu.edu/~mfeldman/ada-project-
summary.html](http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html)

~~~
e12e
Last time it was brought up, there appeared to be some lingering confusion and
issues with how the compiler and runtime was and is licensed.

The latest version of Ada is available for a (large) fee from Adacore _and_
for free under the GPL. There is also a version published as part of gcc, that
trails the upstream version a little in terms of features -- but like the rest
of gcc, the relevant parts are under LGPL, so not all binaries distributed to
third parties need be distributed under the GPL, but can be under any licence
one choose[1] -- without the need for a commercial licence from Adacore.

It would appear the lack of an up-to-date, gratis, version of Ada was a real
problem for adoption at some point -- and the impression of Ada being
difficult to get access to outside of large contractors put a damper on its
popularity (justified or not).

[1] The "problem" with a compiler under GPL is that most compilers will have
some kind of library code or language runtime that needs to be distributed
with resulting binaries, thus forcing all projects to adopt GPL, rather than
just the projects that build directly on the compiler.

~~~
pjmlp
More than price, what really hindered Ada was lack of adoption by popular OS
vendors and hardware requirements for the early compilers.

Back in the day everyone was paying for compilers, the prices were the normal
ones for the target audience.

Rational Software first product was an advanced Ada Machine, providing an
early 80's InteliJ experience. Which followed the same fate as all special
purpose computers.

UNIX, mainframe and other enterprise OS vendors that eventually provided an
Ada compiler, treated it as second class citizen in regard to their main
systems programming language.

Home computers lacked the required hardware to implement a proprer Ada
compiler.

A systems programming language really needs to be "the language" an OS vendor
SDK requires, otherwise it becomes just another application language that can
also go low level.

Besides Ada Core, there are a few embedded and real time OS vendors providing
Ada compilers.

~~~
e12e
> Home computers lacked the required hardware to implement a proprer Ada
> compiler.

Could you elaborate? Are you thinking 80s home computers like the Amiga 1000,
or more classical PCs?

~~~
pjmlp
Both, from the Spectrum days up to the time we could get them to run on 32
bits.

On those days I and many older than me were still writing business
applications in Assembly. Compilers for higher level languages were
constrained in what they could achieve in the amount of memory that was
available.

And Ada did required lots of it. Funny enough I would bet modern Ada compilers
are less resource intensive than C++ ones.

------
edwintorok
Looking at the development history it would appear that this project started
in Feb 2014: [https://github.com/mirleft/ocaml-
tls/commit/10b53cd1ebde0360...](https://github.com/mirleft/ocaml-
tls/commit/10b53cd1ebde036047fb4a0d33261d07ce54432b) . Writing an (almost
complete) TLS 1.2 stack in such a short amount of time is amazing! (compared
to how long it took for NSS to gain TLS 1.2).

Looking forward to the next blogpost in this series.

------
olifante
Security is too damn important to use languages that are insecure by default
and that require rigorous discipline and extensive auditing, such as C and
C++. The world needs to move its entire crypto and networking layer to
functional languages focusing on immutability, thereby immensely reducing the
surface of attack.

~~~
jude-
Secure implementations require more than formal, logical correctness. They
must also not leak information to adversaries--i.e. the must be free of side-
channels. Unfortunately, ensuring this usually requires the developers to be
aware of the low-level behavior of the underlying architecture, which is
difficult in functional languages since unlike C, they abstract away behaviors
of the underlying hardware that can leak information.

I suppose you could extend the functional language's type system to tag data
as e.g. needing to be compared to other data in constant time, or needing to
be accessed in a particular way to avoid cache-timing attacks, and so on, but
this just off-loads the problem to the compiler (i.e. the problem must still
be addressed, and not in a high-level functional language). But if you're
going to go that far, you might as well put the requisite safe code primitives
into a shared library, so if you find bugs in them later (or discover new
side-channels you didn't think about earlier), you can update the library
without having to re-compile and re-deploy everything affected by it.

------
amirmc
Just an additional note that this is the first in a series of posts about the
OCaml TLS stack. More are coming in the next few days [1].

[1]
[https://github.com/mirage/mirage/issues/257](https://github.com/mirage/mirage/issues/257)

------
wereHamster
On one side I see the flaws in the existing openssl and other C-based
libraries and when written languages such as OCaml or Haskell those just would
not happen.

On the other hand those existing libraries work. Which can not be said of the
new ones. At least the Haskell TLS library has logic flaws in it that I'm
wondering why it works at all. And a lot of Haskell projects use the native
tls package instead of the openssl bindings. It is not fun at all having to
spend two days to debug something that just works in literally every
mainstream language. I hope ocaml-tls doesn't make the same mistake.

~~~
avsm
The Conduit I/O library that we're building in Mirage/OCaml allows the
application to select which SSL transport layer implementation that it's
linking with. Both Lwt_ssl (which binds to OpenSSL) and OCaml-TLS will be
supported when it's released for exactly this reason. There's a blog post due
about this next week.

As to your other complaint that OpenSSL "just works", note that numerous
issues have been swept under the rug over the years (see the LibreSSL CVS logs
for more pointers). I'd suggest reading this paper about the most dangerous
code in the world for more background:
[http://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-
client-b...](http://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-
bugs.html)

So when you're using the Haskell library and running into bugs, think of the
time you're spending bugfixing and filing patches as a little social tax that
contributes to fixing an important technical issue that threatens the
stability of the Internet if it's not comprehensively addressed.

------
tenzing
There's also miTLS
[http://www.mitls.org/wsgi/home](http://www.mitls.org/wsgi/home) \- a verified
reference implementation of TLS written in F#

------
Hello71
it would probably be a good idea to make some mention of 1/n-1 record
splitting, lest confusion arise regarding the apparent "new line" between G
and ET in the HTTP requests

------
swordswinger12
Any benchmarks? I am very interested in this, it looks really cool!

