crossbario
README lacks description for WebSocket deps
CMake is complaining about missing Websocketpp_INCLUDE_DIR on Windows.
From the readme, it is not clear how to obtain this dependency.
How about adding a sub-module / external references to the dependencies (so that those who need them can just do git submodule update and those who do not want can still use their own)?
I'm not using Windows, so I can't update the README. I'll leave this open as a doc issue.
No, we won't use Git submodules for this. Just clone/get the upstream. Trivial.
Sorry, you are right, we should at least link to the repo;) Here: https://github.com/zaphoyd/websocketpp
It's never been in the README, as WebSocket transport is a fairly recent addition (previously, we only supported RawSocket transport). Not an excuse, but explanation;)
By any chance, does this depends on OpenSSL also? I am getting SSL related configuration issues in CMake and not sure where to get that code from (or if it is related to your project or not, right in the first place).
You might find it easier to use Linux or Docker to get started .. also see https://github.com/crossbario/autobahn-cpp/issues/115
Sorry, you have to have some experience with C++ development and getting around .. I can't do a C++ build course here;)
One thing I have done to get around SSL issues is add some defines around the '#Include "wamp_auth_utils.hpp" in session.ipp.
`#ifndef NO_OPEN_SSL #include "wamp_auth_utils.hpp" #endif``
Then add the define NO_OPEN_SSL to your project. Of course this only works if you are not using any of the authentication stuff.
I think a cleaner solution would be to avoid including wamp_auth_utils.hpp from wamp_session.ipp and put the onus on users to decide whether they want to include that file and depend on OpenSSL (or if they want to use a different implementation of the auth interface provided by themselves).
No, none of above.
The fact that wamp_auth_utils depends on OpenSSL sucks (we did that to quickly move forward). OpenSSL sucks. A better solution would be:
- include some code for base64 encoding directly in Autobahn (its trivial)
- for HMAC-SHA256, use https://github.com/jedisct1/libsodium
Regarding the latter: this will be a hard dependency for AutobahnCpp upcoming anyway. We need it for WAMP-cryptosign.
libsodium is a portable variant of NaCl, which is a state-of-the-art crypto library (providing EC crypto based on curve 25519).
Further, even for TLS, we should move away from OpenSSL, and use LibreSSL. The latter is maintained by the OpenBSD project - which has decades of track record in security.
I'll file follow up issues and post here ..
see: https://github.com/crossbario/autobahn-cpp/issues/125 and https://github.com/crossbario/autobahn-cpp/issues/126
So updating the README with hints of how to use OpenSSL is only a stop-gap solution ..
Regarding the above suggested Docker option, Followed the ReadMe from https://github.com/crossbario/crossbar-docker It worked for crossbar image, but the Autobahn images (clang and js) have some problems. Raised the ticket here https://github.com/crossbario/crossbar-docker/issues/17
Yes, OpenSSL sucks. Yes, libsodium is awesome and everyone doing crypto should use it. WAMP cryptosign seems like a good solution based on that.
However, I don't understand why there should be a hard dependency on something that the protocol specifies as optional and pluggable. For people who use autobahn for in-process communication, any kind of crypto/authentication is excessive. For people who already use OpenSSL, using the existing auth method works just fine. I feel that these people should be able to use autobahn-cpp without having a non-essential, non-trivial (because non-header-only) dependency pushed onto them.
Including an extra header is not an excessive amount of work, and allows you to make optional dependencies actually optional. The auth interface is already designed for optional plugins, so why not let people opt in to auth methods including their dependencies?
@jpetso
It boils down to these questions:
- Should LibreSSL and libsodium be required dependencies (or only optional, for each one)?
- Should we support OpenSSL at all (or only LibreSSL)?
My view: 1: Yes. 2: No.
Let me explain my thinking, commenting your post in below.
For TLS support, I'd like AutobahnCpp to not support OpenSSL at all in the future. Only LibreSSL.
If we do (continue to) support the former, we contribute to prolonging the life of a broken code base that is a constant source of security issues - merely by supporting it. And that brings bad karma;) OpenSSL should just die. I am aware that this is a multi-year effort in general (not for a single library though).
Yes, libsodium is awesome and everyone doing crypto should use it.
Making crypto "optional" is wrong IMO. It should be mandatory. Not mandatory in use as in you should still be able to run non-TLS of course, but mandatory as in being always included and hence, ready for immediate use.
And if used, the crypto should be "secure by default". The OpenBSD mantra.
that the protocol specifies as optional and pluggable.
Yes, the WAMP protocol makes it optional, but the Autobahn libraries are implementations, which can require dependencies, so that certain batteries are always included (such as TLS and/or WAMP-cryptosign).
For people who use autobahn for in-process communication, any kind of crypto/authentication is excessive.
I do get that the situation with Bonefish is special, yes. All other users of AutobahnCpp won't use it in-process though. Uumpf.
For people who already use OpenSSL, using the existing auth method works just fine.
WAMP-CRA is strictly inferior to WAMP-cryptosign. Both over TLS or non-TLS.
so why not let people opt in to auth methods including their dependencies
Because all Autobahn libraries will include WAMP-cryptosign. It'll be the primarily advertised / promoted WAMP authentication. The authentication method of choice.
I feel that these people should be able to use autobahn-cpp without having a non-essential, non-trivial (because non-header-only) dependency pushed onto them.
Crypto is essential. Not in the technical sense, but in the bigger picture. Because users should have control over and privacy for their data!
Also, I'd say libsodium-portable is a trivial dependency. If one can build C++ programs in the context of a monster like Boost, then libsodium is unlikely to make a user struggle.
Now I perfectly get that my attitude might seem like "shoving something" onto users. But that something is security!
And in my view, I look at this attitude as being required in the post-Snowden era - to fight back!
This is as much about overcoming inertness, as it is about crypto technology itself.
Yes, I am "religious" about that. Call me a fool;)
I guess that's a reasonable point of view, for the largest part. However, I would still strongly advise not to depend on both LibreSSL and libsodium, but only the latter.
Libsodium is less of the pain than the various *SSL libraries because there's only one source for it. However, when you have a codebase with WebRTC, which builds with BoringSSL by default but has an option to build with an external OpenSSL, then trying to fit in yet another permutation (LibreSSL) seems like a giant headache. This is the point where I'm likely to go from using upstream Autobahn to forking my own version with SSL dependency removed entirely. Integrating any *SSL into the build is a major hassle, I really shouldn't have to do it if all it does is implement a quasi-deprecated authentication method.
when you have a codebase with WebRTC, which builds with BoringSSL by default but has an option to build with an external OpenSSL, then trying to fit in yet another permutation (LibreSSL) seems like a giant headache.
That's a good argument. In fact, it seems, mixing BoringSSL with at least OpenSSL is not possible at all: https://www.imperialviolet.org/2015/10/17/boringssl.html - the same then might hold true for mixing with LibreSSL.
If this is the case, then shoving LibreSSL onto users goes too far, I agree. That would hurt users more, than there is value.
How about this?
- For TLS support (secure WebSocket or RawSocket), we support LibreSSL, BoringSSL and (bite the bullet) OpenSSL. None is mandatory, but one is required if a user wants TLS. However, we won't use ***SSL libraries for anything else but TLS.
- libsodium will be a mandatory dependency, and we'll reuse crypto utility stuff from there (eg HMAC-SHA256 for WAMP-CRA). And we have it for WAMP-cryptosign.
As you say, libsodium, similar to msgpack-c is an "encapsulated" / "one source" dependency - much less trouble.
If we did above, then the whole situation would look like:
- AutobahnCpp depends on Boost,
msgpack-candlibsodium - optionally, TLS is supported using one of LibreSSL, BoringSSL or OpenSSL
- optionally, WebSocket is supported via
websocketpp
Is that something you would support?
+1
- optionally Websocket is supported via
websocketpp(wss:// TLS via OpenSSL)
Afterthought...
libsodium will be a mandatory dependency, and we'll reuse crypto utility stuff from there (eg HMAC-SHA256 for WAMP-CRA). And we have it for WAMP-cryptosign.
Since it already uses OpenSSL and it works, it kind of makes sense to make it optional so one doesn't have to use multiple crypto libraries. An abstraction of crypto provider via wamp_crypto.hpp can use libsodium by default if OpenSSL is not specified.
@DZabavchik No, the idea is to use libsodium for HMAC-SHA256. Really, it's trivial. Same for base64 encoding. And (me personally), I want to get rid of OpenSSL altogether. I will do the change when I implement WAMP-cryptosign.
@jpetso Could you check with Topology if formalizing
- AutobahnCpp depends on Boost, msgpack-c and libsodium
- optionally, TLS is supported using one of LibreSSL, BoringSSL or OpenSSL
- optionally, WebSocket is supported via websocketpp
is fine?
@oberstet I can say with confidence that Topology won't have a problem with this approach.
@jpetso Perfect;)
@DZabavchik But you dislike a new mandatory dependency on libsodium?
I'm not married to OpenSSL, and not opposed to libsodium as default option (+ elimination of OpenSSL from default deps). I'm only concerned about mandates that hinder opportunities. Regardless of how theatrical the whole thing with FIPS and ugliness and monstrosity of OpenSSL, allowing people to pick their poison will allow wider adoption. So, abstracting crypto provider for HMAC-SHA256, base64 codec that could be provided by libsodium, OpenSSL/WolfSSL/PolarSSL/libreSSL makes this lib more open. Pretty much same thing @davidchapelle did for abstracting transports.
I guess my view is slightly different on this. WAMP as a protocol is designed for pluggable, transparent transports and serializers. WAMP is also designed for extensible authentication - but not pluggable. Eg WAMP-CRA uses HMAC-SHA256. You cant have say HMAC-Tiger. Same for WAMP-cryptosign. Its Ec25519 based. This is by design and deliberate. Now, AutobahnCpp supports MsgPack, but the implementation isnt pluggable. its msgpack-c. I think this is sane. There is little value in having pluggable implementations. Same goes for HMACSha256. And the same goes (in principle) for TLS. The latter though has to support some pluggability .. because of the practical argument that @jpetso made above. To the extreme: base64 encoding .. why would you want pluggability? Trivial implementatio, no gain. Rgd Ec25519: NaCl and libsodium are unmatched in various aspects. Side channel attacks? You are covered. Anyway. At least this repo will follow the outline above. OpenSSL must die.
Base64 implementation is really irrelevant. WAMP-CRA defines HMAC-SHA256 as one and only supported algo - NaCl fits the bill across all platforms (if authentication is even used). Using WAMP-cryptosign is not a requirement -> its dependency is optional. Websockets are optional, secure websockets even more optional. The only problem I see with proposal is when one needs to use both secure websockets and cryptosign: if libreSSL is required for wamp-crypto, and the only websocket implementation depends on OpenSSL, that results in code bloating.
P.S. I wouldn't bother with WS/WSS if raw-sockets transport had heartbeat/ping-pong. Pipe dream is - auto-transport detection on router, so there is no need to put separate TLS/SSL reverse proxies for raw and WS. Some people have strange fobias, like keeping private keys not on HSMs :)
if raw-sockets transport had heartbeat/ping-pong. Pipe dream is - auto-transport detection on router
Both features are in the WAMP spec for RawSocket. It's just that they are not implemented yet in say Crossbar.io (and I am not aware of any WAMP router that does).
The auto-detection (running WebSocket on RawSocket listening transport on 1 port) is possible, because RawSocket uses a first magic byte that is impossible for HTTP.
For ping/pongs, there are RawSocket transport message types.
Yes, WAMP-cryptosign is optional rgd the WAMP spec - but we will add it to all Autobahn's and require (Python, C++) or bundle (JS, Android, C) it.
@oberstet, thanks for clarifications. As long as the overhead of cryptography is not required (inside secure perimeter where trust is implicit) dormant crypto-code is not an issue.
Speaking of crossbar router, found an issue with compatibility in 0.13, will post an issue there
Yes, the use of crypto isn't required - there a perfectly valid use cases of course for implicit trust (no authentication needed), like you mention when inside secure perimeter.
It's just that it should be available by default if needed, without the user jumping through extra loops. The batteries included philosophy applied to crypto.
Regarding "dormant code": libsodium is lean and small.
There is even https://tweetnacl.cr.yp.to/: "TweetNaCl fits into just 100 tweets while supporting all 25 of the C NaCl functions used by applications."
This is 14k characters of C source code!
Compare: OpenSSL has like 500k lines of code