[opam-devel] [ocaml-infra] expiration SSL certificate

[David Sheets]

On Tue, Sep 13, 2016 at 12:42 PM, Daniel Bünzli
<daniel.buenzli at erratique.ch> wrote:
> On Tuesday 13 September 2016 at 12:56, David Sheets wrote:
>> > "Note that yojson never checks the encoding of strings."
>>
>> This refers to the internal string representation.
>
> Please, check your facts.

>From the yojson docs:

Note that yojson never checks the encoding of strings. All
ASCII-compatible encodings including UTF-8 are supported by yojson
readers and writers. Non-ASCII-compatible encodings UTF-16BE,
UTF-16LE, UTF-32BE and UTF-32LE are not supported. "\uXXXX" escape
sequences are converted by the readers into the equivalent UTF-8
multibyte sequences. Characters outside the ASCII range are always
written as is, as permitted by the JSON standard. Bytes that do not
form valid UTF-8 characters are also output as is. It is the user's
responsibility to check for the correctness of UTF-8 data when
appropriate.

>> It's not clear to me why or how this will result in users "being sorry" for using a
>> library in order to get a certificate from a (trusted) CA.
>
> Any yojson user might end up being sorry at some point and I have said this for a long time [1]. There are quite a few scenarios where you could be bitten by this behaviour since it invalidates invariants you may think hold about a string that was decoded about a standard compliant JSON parser (like absence of NULL byte in the original string -- note that decoded strings reencoded to UTF-8 may have null bytes because U+0000 is allowed via *escape*). Now store that original string somewhere and think about the fact that most OCaml's system APIs were vulnerable to NULL byte injection until recently (and I'm sure a lot of other C bindings are).

The attack you are partially describing would be the ACME CA sending
you malicious JSON. This seems fairly unlikely and in violation of the
trust model of the CA system, though, I admit, it is possible. It is
likely that the author of the library is not aware of these facts
which is why I continue to urge you to help them understand the
issues.

>> Telling them is certainly more effective (and socially responsible) than
>> spreading FUD on an unrelated mailing list.
>
> I'm not spreading FUD I'm talking about a reality, on mailing list were this project was mentioned to be used. And sorry I don't have time to loose with random people toying in a random, unreleased, github repository.

You are sending messages containing unsubstantiated security claims
which result in fear (probably overblown), uncertainty (because the
claims have no demonstration), and doubt (about the author's "ability
to actually implement these things"). I find it quite something that
your original messages were vague to the point of useless but now you
have expended far more effort justifying your opinion than would have
been required to help the project.

> Security is a mindset.

Security is also an economic proposition and a community effort. A CA
attacking you is possible but unlikely. Helping others to develop
secure software is beneficial to all the users of that software. We
are talking about a project that is *already written in OCaml* so it
is unlikely that the author is incapable of building excellent
software in the short to medium term.

> You are showing that you are not having it and I personally feel that neither does an individual that uses insecure libraries to build security infrastructure. Now trust who you want I just happens that I have different expectations about the quality of the code I use.

It's interesting that defending against knee-jerk FUD attacks is not
compatible with a "security mindset". I think that a blanket dismissal
of the library (and its author) due to the adoption of a widespread
(though fraught) library is absurd. It is very likely the author does
not know the things you know and does not have the experience with
yojson or the OCaml community that you have. Clearly they are
interested in security and clearly they have produced something of
value even if not perfect (it's unreleased!).

David