HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
mirleft
ocaml-tls
OCaml2014–2019
mirleft / ocaml-tls

ocaml-tls

TLS in pure OCaml

15Distinct people
21Mentions
0Explicit recommenders
321GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

TLS in pure OCaml

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year21 dated mentions

Observed mentions: 2014-04-09 06:43:21 UTC to 2019-06-29 17:31:22 UTC.

02468102014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC1019
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC505
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC413
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
TLS - Transport Layer Security purely in OCaml %%VERSION%% Transport Layer Security (TLS) is probably the most widely deployed security protocol on the Internet. It provides communication privacy to prevent eavesdropping, tampering, and message forgery. Furthermore, it optionally provides authentication of the involved endpoints. TLS is commonly deployed for securing web services (HTTPS), emails, virtual private networks, and wireless networks. TLS uses asymmetric cryptography to exchange a symmetric key, and optionally authenticate (using X.509) either or both endpoints. It provides algorithmic agility, which means that the key exchange method, symmetric encryption algorithm, and hash algorithm are negotiated. Read our Usenix Security 2015 paper for further details. Documentation API documentation Installation opam install tls will install this library. You can also build this locally by conducting the steps: opam install --deps-only -t . # or a named package instead of `.` - i.e. ./tls-lwt.opam dune build --profile=release # you can also put a package list here, i.e. tls,tls-lwt -- you can also use `@all` target to compile examples as well Usage The core of ocaml-tls (the opam package tls, available in the lib subdirectory) is an library independent of schedulers and does not perform any I/O operations. The library is designed so that a Tls.Engine.state state informs you of when to write and when to feed more data. It does not use mutation and is in a value-passing style (so, read data and state is the input, and data to be sent or presented to the upper layer, and state is the output). There are therefore ocaml-tls derivations with different schedulers that perform read and write operations. These derivations offer an interface similar to what an SSL socket (like ssl) can offer. lwt: tls-lwt proposes to initiate a TLS flow with Lwt_io.{input,output}_channel from a Unix socket. It can also propose an abstract type Tls_lwt.Unix.t (which can be created from a Unix socket) associated with a Tls_lwt.Unix interface similar to a Unix socket. miou: tls-miou-unix proposes a TLS flow via an abstract type Tls_miou_unix.t and an interface similar to a Unix socket from a Miou_unix.file_descr socket. MirageOS: tls-mirage proposes a composition of a Mirage_flow.S module to obtain a new Mirage_flow.S (corresponding to the TLS layer) which uses the lwt scheduler. eio: tls-eio proposes the creation of an eio flow from another eio flow. async: tls-async proposes a TLS flow via Async.{Reader,Writer}.t from a Async.Socket. Depending on the scheduler you choose, you should choose one of these ocaml-tls derivations, distributed in the mentioned opam packages (tls-lwt, tls-mirage, tls-eio, tls-async). Each one takes advantage of what the scheduler used has to offer. Composability ocaml-tls can also be used as it is in order to be able to compose with other protocols without choosing a scheduler. This is the case, for example, with sendmail.starttls, which composes the SMTP and TLS protocols. The user can also be more selective about the use of certificates involved in a TLS connection, as albatross can offer in its transactions between clients and the server. When seen as OCaml values, the critical elements that enable instantiation of a TLS connection can be very finely controlled. Portability ocaml-tls is currently used for MirageOS unikernels, which makes it portable and available on many systems (even the most restricted ones such as Solo5 as long as OCaml is available on them.
Read the full README on GitHub

What Hacker News says

21 sources
To the commenters blaming OCaml - it is being used in the Project Everest[1] (along with F#) for creating a proven network security stack. Basically, they created ML-like language called F*[2], which fits the task perfectly. There is also a pure OCaml implementation[3] of TLS stack, along with x509[4]. [1] https://project-everest.github.io/ [2] https://www.fstar-lang.org/ [3] https://github.com/mirleft/ocaml-tls [4] https://github.com/mirleft/ocaml-x509
In SKS Keyserver Network Under Attack
Already done in Ocaml for projects willing to use something other than OpenSSL: https://github.com/mirleft/ocaml-tls It's performance was within 80% or so of regular TLS with Ocaml's safety and easier verification. Quite a few components were purely functional, too. I've seen SML embedded in LISP's and PreScheme compiled to efficient C or ASM. So, that means a static LISP could handle it piggybacking on C compilers. Ivory embeds a subset of C in Haskell to keep things easy to analyze and automatically safe. Parts of a SSL library could use it. http://ivorylang.org/ivory-introduction.html So, Haskell, LISP, and ML are already capable of replacing our SSL libraries if people choose. One is already done in Ocaml. COGENT, if people apply it to this, will take it further by having an easier-to-verify implementation in functional language with
Read the rest
certified compilation to C or assembly.
In OpenSSL after Heartbleed
Because if you use C libraries you will inherit their problems (and also their interface is rarely idiomatic in the new language). Usually if you want to use a different language it's because you think that language has advantages over C. E.g. a large part of the point of using OCaml is to avoid the safety problems of C, but that only applies if your libraries aren't written in C. See https://github.com/mirleft/ocaml-tls#why-a-new-tls-implement... (Almost all languages do offer some "FFI" to call C. But in languages that don't naturally fit, there will often be significant overhead to e.g. aligning memory management so that the same memory doesn't get freed twice, as might happen when a garbage-collected language called a C library)
In Would You Bet $100M on Your Pet Programming Language? (2007)
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 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 for discussion on the Lucky 13 mitigation that isn't merged in for example. Editing the goto-fail reference to reflect
Read the rest
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.
In Introducing Transport Layer Security in pure OCaml
Hey, (Disclaimer: one of the authors) We randomize the connection parameters on each connect to help us gauge the stack's behavior with various combinations (see https://github.com/mirleft/ocaml-tls/issues/159 ). Normally it uses first available from the list here: https://github.com/mirleft/ocaml-tls/blob/master/lib/config..... (For some reason the RSA variant got on top; it should have been DHE_RSA, which does provide PFS.) Side channel attacks were a very big concern, and I invite you to read the entire series of articles we plan on publishing in the next few days, where we try to lay down our strategy and explain what we know and what we don't. Or even skim through the handshake code and check some of the comments there. We were already warned that CVE-2014-1266 CVE-2014-0224 are not memory safety issues. The article is badly worded t
Read the rest
here. What was meant is that they are, at least in our pretty firm opinion, issues with C (something we will elaborate in more detail in further articles, but in essence, you get regular control-flow in a functional language and you can encode state machines in a far more explicit manner). Working to update the post and clarify this. As for the issue #6, yes, its closing was not documented too well. This does not mean we didn't expend significant effort to actually address the points there :) . Thank you for the input and please have patience with us. We still have (at least) four more articles to publish!
In Introducing Transport Layer Security in pure OCaml

Showing the 15 most recent of 21 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.