mte/unikernel/duniverse/ocaml-tls/attacks.md

### Attacks on TLS

TLS the most widely deployed security protocol on the Internet and, at
over 15 years, is also showing its age. As such, a flaw is a valuable
commodity due to the commercially sensitive nature of data that is
encrypted with TLS. Various vulnerabilities on different layers of TLS
have been found - [heartbleed][] and others are implementation
specific, advancements in cryptanalysis such as [collisions of
MD5][md5_collision] lead to vulnerabilities, and even others are due
to incorrect usage of TLS ([truncation attack][truncation] or
[BREACH][breach]). Finally, some weaknesses are in the protocol
itself. Extensive [overviews][tls_attacks] of [attacks on
TLS][mitls_attacks] are available.

We look at protocol level attacks of TLS and how [ocaml-tls][ocaml-tls]
implements mitigations against these.  [TLS 1.2 RFC][RFC5246] provides an
overview of attacks and mitigations, and we [track][issue31] our progress in
covering them. This is slightly out of date as the RFC is roughly six years old and
in the meantime more attacks have been published, such as the [renegotiation
flaw][understanding_reneg].

We track all our [mitigated][closed] and [open][open] security issues
on our GitHub issue tracker.

Due to the choice of using OCaml, a memory managed programming
language, we obstruct entire bug classes, namely temporal and spatial
memory safety.

Cryptanalysis and improvement of computational power weaken some
ciphers, such as RC4 and 3DES (see [issue 8][issue8] and [issue
10][issue10]). If we phase these two ciphers out, there wouldn't be
any matching ciphersuite left to communicate with some compliant TLS-1.0
implementations, such as Windows XP, that do not support AES.

[issue8]: https://github.com/mirleft/ocaml-tls/issues/8
[issue10]: https://github.com/mirleft/ocaml-tls/issues/10
[open]: https://github.com/mirleft/ocaml-tls/issues?labels=security+concern&page=1&state=open
[closed]: https://github.com/mirleft/ocaml-tls/issues?labels=security+concern&page=1&state=closed
[ocaml-tls]: https://github.com/mirleft/ocaml-tls
[understanding_reneg]: http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html
[heartbleed]: https://en.wikipedia.org/wiki/Heartbleed
[md5_collision]: http://eprint.iacr.org/2005/067
[truncation]: http://www.theregister.co.uk/2013/08/01/gmail_hotmail_hijacking/
[breach]: http://breachattack.com/
[RFC5246]: https://tools.ietf.org/html/rfc5246#appendix-D.4
[tls_attacks]: http://eprint.iacr.org/2013/049.pdf
[mitls_attacks]: http://www.mitls.org/wsgi/tls-attacks
[issue31]: https://github.com/mirleft/ocaml-tls/issues/31

**Timing attacks**

When the timing characteristics between the common case and the error
case are different, this might potentially leak confidential
information. Timing is a very prominent side-channel and there are a huge
variety of timing attacks on different layers, which are observable by
different attackers. Small differences in timing behaviour might
initially be exploitable only by a local attacker, but advancements to
the attack (e.g. increasing the number of tests) might allow a 
remote attacker to filter the noise and exploit the different timing
behaviour.

**Timing of cryptographic primitives**

We [already mentioned][nocrypto-intro] [cache][] [timing][cache_timing]
attacks on our AES implementation, and that we use [blinding][]
techniques to mitigate RSA timing attacks.

By using a memory managed programming language, we open the attack
vector of garbage collector (GC) timing attacks (also mentioned [in
our nocrypto introduction][nocrypto-intro]).

Furthermore, research has been done on virtual machine side channels
([l3][], [cross vm][cross_vm] and [cache timing][cache_vm]), which we
will need to study and mitigate appropriately.

**For the time being we suggest to not use the stack on a multi-tenant
shared host or on a shared host which malicious users might have
access to.**

[blinding]: https://en.wikipedia.org/wiki/Blinding_(cryptography)
[cache]: http://www.cs.tau.ac.il/~tromer/papers/cache.pdf
[cache_timing]: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
[l3]: http://eprint.iacr.org/2013/448.pdf
[cross_vm]: http://www.cs.unc.edu/~reiter/papers/2012/CCS.pdf
[cache_vm]: http://fc12.ifca.ai/pre-proceedings/paper_70.pdf

**Bleichenbacher**

In 1998, Daniel Bleichenbacher discovered a [timing flaw in the
PKCS1][bleichenbacher] encoding of the premaster secret: the TLS server
failed faster when the padding was wrong than when the decryption
failed. Using this timing, an attacker can run an adaptive chosen
ciphertext attack and find out the plain text of a PKCS1 encrypted
message. In TLS, when RSA is used as the key exchange method, this
leads to discovery of the premaster secret, which is used to derive the
keys for the current session.

The mitigation is to have both padding and decryption failures use the
exact same amount of time, thus there should not be any data-dependent
branches or different memory access patterns in the code. We
implemented this mitigation in [Handshake_server][answer_client_key_exchange].

[bleichenbacher]: http://archiv.infsec.ethz.ch/education/fs08/secsem/Bleichenbacher98.pdf
[answer_client_key_exchange]: https://github.com/mirleft/ocaml-tls/blob/c06cbaaffe49024d8570916b70f7839603a54692/lib/handshake_server.ml#L45

**Padding oracle and CBC timing**

[Vaudenay][] discovered a vulnerability involving block ciphers: if an
attacker can distinguish between bad mac and bad padding, recovery of
the plaintext is possible (within an adaptive chosen ciphertext
attack). Another approach using the same issue is to use
[timing][practical] information instead of separate error messages.
Further details are described [here][tls_cbc].

The countermeasure, which we implement [here][cbc_mit], is to continue
with the mac computation even though the padding is
incorrect. Furthermore, we send the same alert (`bad_record_mac`)
independent of whether the padding is malformed or the mac is
incorrect.

[tls_cbc]: https://www.openssl.org/~bodo/tls-cbc.txt
[Vaudenay]: http://www.iacr.org/archive/eurocrypt2002/23320530/cbc02_e02d.pdf
[practical]: http://lasecwww.epfl.ch/memo/memo_ssl.shtml
[cbc_mit]: https://github.com/mirleft/ocaml-tls/blob/c06cbaaffe49024d8570916b70f7839603a54692/lib/engine.ml#L100

**Lucky 13**

An advancement of the CBC timing attack was discovered in 2013, named
[Lucky 13][Lucky13]. Due to the fact that the mac is computed over the
plaintext without padding, there is a slight (but measurable)
difference in timing between computing the mac of the plaintext and
computing the fake mac of the ciphertext. This leaks information. We
do not have proper mitigation against Lucky 13 in place yet.  You can
find further discussion in [issue 7][issue7] and [pull request
49][pull49].

[Lucky13]: http://www.isg.rhul.ac.uk/tls/Lucky13.html
[issue7]: https://github.com/mirleft/ocaml-tls/issues/7
[pull49]: https://github.com/mirleft/ocaml-tls/pull/49

**Renegotiation not authenticated**

In 2009, Marsh Ray published a vulnerability of the TLS protocol which
lets an attacker prepend arbitrary data to a session due to
[unauthenticated renegotiation][understanding_reneg]. The attack
exploits the fact that a renegotiation of ciphers and key material is
possible within a session, and this renegotiated handshake is not
authenticated by the previous handshake. A man in the middle can
initiate a session with a server, send some data, and hand over the
session to a client. Neither the client nor the server can detect the
man in the middle.

A fix for this issue is the [secure renegotiation extension][RFC5746],
which embeds authenticated data of the previous handshake into the
client and server hello messages. Now, if a man in the middle
initiates a renegotiation, the server will not complete it due to
missing authentication data (the client believes this is the first
handshake).

We implement and require the secure renegotiation extension by
default, but it is possible to configure `ocaml-tls` to not require
it -- to be able to communicate with servers and
clients which do not support this extension.

Implementation of the mitigation is on the server side in
[ensure_reneg][] and on the client side in [validate_reneg][]. The
data required for the secure renegotiation is stored in
[`handshake_state`][reneg_state] while sending and receiving Finished
messages. You can find further discussion in [issue 3][issue3].

[RFC5746]: https://tools.ietf.org/html/rfc5746
[validate_reneg]: https://github.com/mirleft/ocaml-tls/blob/c06cbaaffe49024d8570916b70f7839603a54692/lib/handshake_client.ml#L50
[ensure_reneg]: https://github.com/mirleft/ocaml-tls/blob/c06cbaaffe49024d8570916b70f7839603a54692/lib/handshake_server.ml#L85
[issue3]: https://github.com/mirleft/ocaml-tls/issues/3
[reneg_state]: https://github.com/mirleft/ocaml-tls/blob/c06cbaaffe49024d8570916b70f7839603a54692/lib/state.ml#L97

**TLS 1.0 and known-plaintext (BEAST)**

TLS 1.0 reuses the last ciphertext block as IV in CBC mode. If an attacker
has a (partially) known plaintext, she can find the remaining plaintext.
This is known as the [BEAST][] attack and there is a [long discussion][mozilla-bug]
about mitigations. Our mitigation is to prepend each TLS-1.0
application data fragment with an empty fragment to randomize the IV.
We do this exactly [here][empty_iv]. There is further discussion in
[issue 2][issue2].

Our mitigation is slightly different from the 1/n-1 splitting proposed
[here][qualys]: we split every application data frame into a 0 byte
and n byte frame, whereas they split into a 1 byte and a n-1 byte
frame.

Researchers have exploited this vulnerability in 2011, although it was
known since [2006][]. TLS versions 1.1 and 1.2 use an explicit IV,
instead of reusing the last cipher block on the wire.

[qualys]: https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat
[mozilla-bug]: https://bugzilla.mozilla.org/show_bug.cgi?id=665814
[BEAST]: http://vnhacker.blogspot.co.uk/2011/09/beast.html
[empty_iv]: https://github.com/mirleft/ocaml-tls/blob/c06cbaaffe49024d8570916b70f7839603a54692/lib/engine.ml#L375
[2006]: http://eprint.iacr.org/2006/136
[issue2]: https://github.com/mirleft/ocaml-tls/issues/2

**Compression and information leakage (CRIME)**

When using compression on a chosen-plaintext, encrypting this can leak
information, known as [CRIME][crime]. [BREACH][breach] furthermore
exploits application layer compression, such as HTTP compression. We
mitigate CRIME by not providing any TLS compression support, while we
cannot do anything to mitigate BREACH.

[crime]: http://arstechnica.com/security/2012/09/crime-hijacks-https-sessions/

**Traffic analysis**

Due to limited amount of padding data, the actual size of transmitted
data can be recovered. The mitigation is to implement [length hiding
policies][length_hiding]. This is tracked as [issue 162][issue162].

[issue162]: https://github.com/mirleft/ocaml-tls/issues/162
[length_hiding]: http://tools.ietf.org/html/draft-pironti-tls-length-hiding-02

**Version rollback**

SSL-2.0 is insecure, a man in the middle can downgrade the version to
SSL-2.0. The mitigation we implement is that we do not support
SSL-2.0, and thus cannot be downgraded. Also, we check that the
version of the client hello matches the first two bytes in the
premaster secret [here][client_version]. You can find further discussion in
[issue 5][issue5].

[client_version]: https://github.com/mirleft/ocaml-tls/blob/c06cbaaffe49024d8570916b70f7839603a54692/lib/handshake_server.ml#L55
[issue5]: https://github.com/mirleft/ocaml-tls/issues/5

**Triple handshake**

A vulnerability including session resumption and renegotiation was
discovered by the [miTLS team][mitls], named [triple
handshake][triple].  Mitigations include disallowing renegotiation,
disallowing modification of the certificate during renegotiation, or
a hello extension. Since we do not support session resumption yet, we
have not yet implemented any of the mentioned mitigations. There is
further discussion in [issue 9][issue9].

[mitls]: http://www.mitls.org
[issue9]: https://github.com/mirleft/ocaml-tls/issues/9
[triple]: https://secure-resumption.com/

**Alert attack**

A [fragment of an alert][alert_attack] can be sent by a man in the
middle during the initial handshake. If the fragment is not cleared
once the handshake is finished, the authentication of alerts is
broken. This was discovered in 2012; our mitigation is to discard
fragmented alerts.

[alert_attack]: http://www.mitls.org/wsgi/alert-attack

### EOF.

Within six months, two hackers managed to develop a clean-slate TLS
stack, together with required crypto primitives, ASN.1, and X.509
handling, in a high-level pure language. We interoperate with widely
deployed TLS stacks, as shown by our [demo server][demo].  The code
size is nearly two orders of magnitude smaller than OpenSSL, the most
widely used open source library (written in C, which a lot of
programming languages wrap instead of providing their own TLS
implementation). Our code base seems to be robust -- the [demo
server][demo] successfully finished over 22500 sessions in less than a
week, with only 11 failing traces.

There is a huge need for high quality TLS implementations, because
several TLS implementations suffered this year from severe security
problems, such as [heartbleed][], [goto fail][CVE-2014-1266], [session
id][CVE-2014-3466], [Bleichenbacher][java], [change cipher
suite][CVE-2014-0224] and [GCM DoS][polar]. The main cause is
implementation complexity due to lack of abstraction, and memory
safety issues.

We still need to address some security issues, and improve our performance. We
invite people to do rigorous code audits (both manual and automated) and try
testing our code in their services.

**Please be aware that this release is a *beta* and is missing external code audits.
It is not yet intended for use in any security critical applications.**

[demo]: https://tls.openmirage.org
[polar]: https://polarssl.org/tech-updates/security-advisories/polarssl-security-advisory-2014-02
[java]: http://armoredbarista.blogspot.de/2014/04/easter-hack-even-more-critical-bugs-in.html
[CVE-2014-1266]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1266
[CVE-2014-3466]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3466
[CVE-2014-0224]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0224

[nocrypto-intro]: http://openmirage.org/blog/introducing-nocrypto