Using Autobahn to test a WSS (Secured Websocket) server implementation

#1

Hello there,

Autobahn was a great tool for me to nude out implementation errors of the websocket protocol.
I created an “echo server” out of the protocol implementation, then used wstest tool to run a fuzzing client that executes with the following specification file:

{
“options”: {“failByDrop”: false},
“outdir”: “D:\reports”,

“servers”: [{“agent”: “Push Framework Websocket Server”, “url”: “ws://localhost:10010”, “options”: {“version”: 18}}],

“cases”: ["*"],
“exclude-cases”: [],
“exclude-agent-cases”: {}
}

It was really great.

Now I need to test WSS. I have an implementation of TLS and a means to wire it on top of the code of Websocket.
How can I run the same Autobahn test ?
Obviously, just changing the url to wss://localhost:10010 is not enough: I need to provide the fuzzing client with a certificate authority with which I have signed the certificate used by the echo server.

Based on what I found in the documentation I did the following:

wstest -m fuzzingclient -s fuzzingclient.json -c “E:\certificates\ca.crt”

(supplying the -c option).

But this does not work. Of course, my TLS code can be wrong, but I am hoping that someone confirms that my way of testing is correct.

Thanks.

0 Likes

#2

Hi Ahmed,

Hello there,

Autobahn was a great tool for me to nude out implementation errors of
the websocket protocol.

Great to hear! Interoperability is good;)

Now I need to test WSS. I have an implementation of TLS and a means to
wire it on top of the code of Websocket.
How can I run the same Autobahn test ?
Obviously, just changing the url to wss://localhost:10010 is not enough:

For running a fuzzing client to test a WSS server it should be enough to provide a "wss" URL in the spec.

I need to provide the fuzzing client with a certificate authority with
which I have signed the certificate used by the echo server.

Not necessarily. When running over WSS, the fuzzing client will simply accept _any_ server certificate. It does not care.

For a production client, that would be unacceptable of course (a client really should verify the server presented cert. against a trusted CA list or whatever).

The fuzzing client does not implement this .. so there is not option to set.

The only case you need to provide things with is when running a fuzzing server: you need to have "key" and "cert" in your spec providing paths to the respective PEM encoded files.

Cheers,
/Tobias

···

Am 26.05.2014 19:39, schrieb Ahmed Charfeddine:

Based on what I found in the documentation I did the following:

wstest -m fuzzingclient -s fuzzingclient.json -c "E:\certificates\ca.crt"

(supplying the -c option).

But this does not work. Of course, my TLS code can be wrong, but I am
hoping that someone confirms that my way of testing is correct.

Thanks.

--
You received this message because you are subscribed to the Google
Groups "Autobahn" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to autobahnws+...@googlegroups.com
<mailto:autobahnws+...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.

0 Likes