blog/content/2017/09/adventures-in-autobahnwamp-security.html

---
title: Adventures in Autobahn/WAMP Security
description: >
  Adventures in Autobahn/WAMP Security
posted: !!timestamp '2017-09-17'
created: !!timestamp '2017-09-17'
time: 12:21 PM
tags:
  - web
  - WAMP
  - security
---

## Or how security continues to suck because: It's Hard and Someone Else's Problem™

For a personal project, I've decided to use WAMP to move some events and
messages around between different components.  I decided on the AutoBahn
libraries and Crossbar.io as the router.  I was already somewhat familiar
w/ AutoBahn from previous work, and the Crossbar.io router seems to just
work.  As a security person, I decided to evaluate how to make things as
secure as possible.

First off,
[my projects must be both authenticated and encrypted](https://twitter.com/encthenet/status/881596129573347328).
WAMP does not appear to have it's own encryption layer, but it does have
it's own authentication layer.  You really don't want to have to trust
two different authentication layers<label for="sn-encauth"
class="margin-toggle sidenote-number"></label><input type="checkbox"
id="sn-encauth" class="margin-toggle"/><span class="sidenote">The
encryption layer must be authenticated, otherwise
any attacker could MiTM the connection.  Most uses of TLS make use of
the CA system for authentication (which has serious issues in trust),
and most web apps add their own authentication layer on top of it (not
using Basic Auth, or other scheme).  The issues w/ this is that if there
is no binding between the two layers, the lower layer (application
layer) cannot be sure that the upper layer has not been compromised.</span>,
so being able to use
[TLS Channel Bindings](https://tools.ietf.org/html/rfc5929) would be an
improvement.  This would ensure that a strong authentication method in
WAMP would ensure that the channel is properly encrypted.  I
[received confirmation](https://twitter.com/crossbario/status/904690145907142656)
from the Crossbar.io team that it was present.

Autobahn and Crossbar.io supports a number of
[different authentication schemes](https://crossbar.io/docs/Authentication/).
As I plan on putting this behind a reverse proxy (which I realize will
have it's own issues w/ channel binding), I wanted the strongest security
binding between my client and the server (and I'm a glutton for punishment
for using unproven tech).  The only one that satisfies this requirement
is WAMP-Cryptosign.

After I got basic functionality working to make sure things would be
workable w/ this framework, I decided to start working on the
authentication piece.  First problem I ran into was that the AutoBahn|JS
library does not support TLS channel binding.  There is a good reason the
library doesn't support it, and it's for a very bad reason.  There is
no support in the browser [WebSocket API](https://www.w3.org/TR/websockets/)
to query the channel binding information necessary.  The fact that
WebSockets was standardized after Channel bindings were demonstrates that
the people involved in standardizing the web do not take security
seriously.  As usual, they assume that security is not their problem and
leaves it up to someone else to solve (or at another layer).

Disappointed that I wouldn't be able to use channel bindings w/ the web
client for this project (I still had the crappy CA authentication of TLS,
so not all was lost), I moved forward w/ CryptoSign.  As has been
demonstrated many times, the only way to get security baked in, is to
make it as easy as possible to use.  I've been long familiar w/
[Crypto Box](https://nacl.cr.yp.to/box.html) by djb (and used by the
Autobahn libraries), and also the [noise protocol](https://noiseprotocol.org/)
(which my friend Trevor created).  Both of these have goals of making
it simple to let developers include security in their projects and not
mess it up, resulting in a broken system.  As currently implemented,
Autobahn's CryptoSign is most definitely not easy to use.

Though the documentation is decent, some examples are not present
(`client_ssh_key.py` for example from
[WAMP-cryptosign Static Authentication](https://github.com/crossbario/crossbar-examples/tree/master/authentication/cryptosign/static)).
The
[ApplicationRunner](https://autobahn.readthedocs.io/en/latest/wamp/programming.html#running-components)
helper class does not document how to make use of authentication.  Though
the static authentication page has examples, they make you write quite
a bit of boiler plate.

Then even once you do that, you find out that the code doesn't even work
on Python 2.7 and have to
[fix it](https://github.com/crossbario/autobahn-python/pull/901) for
them.  Hopefully the pull request (PR) will not be ignored because of the
failing CI tests, because the current CI tests are problems with their
CI environment, and not the PR.  For CI checks like this, it should only
ding your PR on checks that are newly failing, and ignore any checks that
were previously failing.  This isn't the first project that their CI
environment was broken.

Even w/ the fixes in place, there is no documented method of extracting
a public key from a generated ssh key.  I will be adding a method to
print this out.

If I (who knows cryptography decently) have to fix and spend hours making
this work, it's no wonder than everyone things that strong cryptography
is hard.  It is hard, but it shouldn't be.