Testing Autobahn fuzzing client with fuzzing server

[Swati Deshpande]

I want to test Autobahn fuzzing client with fuzzing server.

For this, I started fuzzing server using command:
wstest -m fuzzingserver -s fuzzingserver.json

Then, I started fuzzing client like this:
wstest -m fuzzingclient -s fuzzingclient.json

I have used fuzzingclient.json and fuzzingserver.json from link: https://github.com/tavendo/AutobahnTestSuite/tree/master/examples.

I noticed that many requests are failing.
e.g. The closing behavior for Case1.1.1 is 'The connection was failed by the wrong endpoint (FAILED)'.

However, I am not able to find any logs and debug why this test is failing. When I used browser Echo client http://www.websocket.org/echo.html to send empty request, request is successful. I get empty response back. Can you please help with this?

[Tobias Oberstein]

Hi,

easy, for testing AutobahnPython with the AutobahnTestsuite, you need
the following pairs of modes of wstest:

fuzzingclient <=> testeeserver
fuzzingserver <=> testeeclient

Tobias

> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Swati Deshpande]

Thanks a lot. I was able to test fuzzingclient <=> testeeserver and fuzzingserver <=> testeeclient combinations. However, in my case I have a proxy in between WebSocket client and server. For this case, request is dropped for fuzzingserver <=> testeeclient combination because case id is null. Can you please help me out with this?

[Tobias Oberstein]

In case the proxy is not WebSocket aware, it'll likely mess things up. You can (most often) circumvent the proxy by running over secure WebSocket (wss).

wstest fully supports WSS for both fuzzing and testee modes. you will need to supply a server key+cert for fuzzingserver and testeeserver and then instruct the client to use a URL "wss://..".

pls see here (the wss subdir etc)

https://github.com/tavendo/AutobahnTestSuite/tree/master/examples/fuzzingserver

and the command line options of wstest:

$ wstest --help
Usage: wstest-script.py [options]
Options:
  -d, --debug            Debug output [default: off].
  -a, --autobahnversion  Print version information for Autobahn and
                         AutobahnTestSuite.
  -m, --mode=            Test mode, one of: echoserver, echoclient,
                         broadcastclient, broadcastserver, fuzzingserver,
                         fuzzingclient, testeeserver, testeeclient,
                         wsperfcontrol, wsperfmaster, wampserver, wampclient,
                         massconnect [required]
  -s, --spec=            Test specification file [required in some modes].
  -w, --wsuri=           WebSocket URI [required in some modes].
  -k, --key=             Server private key file for secure WebSocket (WSS)
                         [required in server modes for WSS].
  -c, --cert=            Server certificate file for secure WebSocket (WSS)
                         [required in server modes for WSS].
  -i, --ident=           Override client or server identifier for testee modes.
      --version          Display Twisted version and exit.
      --help             Display this help and exit.

Tobias

[Swati Deshpande]

Hi Tobias,

My proxy is WebSocket aware. Here is output of testeeclient:
/home/Swati/fuzzing>wstest -m testeeclient -w ws://<proxy_ip>:8081                                                                                    
Using Twisted reactor class <class 'twisted.internet.epollreactor.EPollReactor'>
Getting case count ..
Getting case count ..

I also see following when debug mode was used:
2013-05-07 07:30:51-0500 [TesteeClientProtocol,client] received HTTP response:
 
        HTTP/1.1 500 application fault
        Content-Type: text/plain; charset=utf-8
        Content-Length: 0
 
 
 
 
2013-05-07 07:30:51-0500 [TesteeClientProtocol,client] received HTTP status line in opening handshake : HTTP/1.1 500 application fault
2013-05-07 07:30:51-0500 [TesteeClientProtocol,client] received HTTP headers in opening handshake : {'content-length': u'0', 'content-type': u'text/plain; charset=utf-8'}
2013-05-07 07:30:51-0500 [TesteeClientProtocol,client] failing WebSocket opening handshake ('WebSocket connection upgrade failed (500 - applicationfault)')
2013-05-07 07:30:51-0500 [TesteeClientProtocol,client] dropping connection
2013-05-07 07:30:51-0500 [-] WebSocketProtocol.onClose:
        wasClean=False
        code=1006
        reason=connection was closed uncleanly (None)
        self.closedByMe=False
        self.failedByMe=False
        self.droppedByMe=True
        self.wasClean=False
        self.wasNotCleanReason=None
        self.localCloseCode=None
        self.localCloseReason=None
        self.remoteCloseCode=None
        self.remoteCloseReason=None

Can you please let me know from above logs what could be the reason for this handshake failure?

Ragards,

Swati

[Tobias Oberstein]

Hi Swait,

ok, this is getting interesting. Please be prepared for a little more tinkering, and probably missing functionality in Autobahn. We did not yet have a chance to test Autobahn in WebSocket aware proxy environments running over plain WS, not WSS.

My guess would be that the error returned is directly from the proxy, not the fuzzingserver instance. Could you add the "-d" option to the wstest -m fuzzingserver command and send the log output for when you are trying to connect from the wstest -m testeeclient?

Are you doing forward or reverse proxying? I guess forward proxying, otherwise you wouldn't specify "ws://<proxy_ip>:8081", right?

Even with a WebSocket aware proxy such as nginx, getting proxy configuration right seems to be non-trivial: http://nginx.org/en/docs/http/websocket.html
What type of proxy are you running?

Tobias

[Swati Deshpande]

Hi Tobias,

Here is the debug output for fuzzingserver:
2013-05-07 07:59:12-0500 [-] FuzzingServerFactory starting on 9001
2013-05-07 07:59:12-0500 [-] Starting factory <autobahntestsuite.fuzzing.FuzzingServerFactory instance at 0x1fea7d88>
2013-05-07 07:59:21-0500 [autobahntestsuite.fuzzing.FuzzingServerFactory] connection accepted from peer <proxy_ip>:38014
2013-05-07 07:59:26-0500 [-] onOpenHandshakeTimeout fired
2013-05-07 07:59:26-0500 [-] dropping connection
2013-05-07 07:59:26-0500 [-] Close received: 1006 - connection was closed uncleanly (peer did not finish (in time) the opening handshake)
2013-05-07 07:59:26-0500 [-] connection from <proxy_ip>:38014 lost
2013-05-07 07:59:26-0500 [-] Close received: 1006 - connection was closed uncleanly (peer did not finish (in time) the opening handshake)

You might be aware of Intel's product Expressway Service Gateway (ESG). I am using it as a proxy. I had used it as a proxy between fuzzingclient and testeeserver, which worked.

testeeclient sends request to ESG, ESG is able to process WebSocket messages. It then forwards it to WebSocket server and after getting response as '101 Switching Protocol', connection is established. Requests (frames) then flow through this connection.

Please let me know if you have any further queries.

Regards,
Swati

[Tobias Oberstein]

> Here is the debug output for fuzzingserver:
> 2013-05-07 07:59:12-0500 [-] FuzzingServerFactory starting on 9001
> 2013-05-07 07:59:12-0500 [-] Starting factory
> <autobahntestsuite.fuzzing.FuzzingServerFactory instance at 0x1fea7d88>
> 2013-05-07 07:59:21-0500
> [autobahntestsuite.fuzzing.FuzzingServerFactory] connection accepted
> from peer <proxy_ip>:38014

At this point, the server has accepted a new TCP connection from
<proxy_ip>:38014.

It hasn't yet received any data (and hasn't send any also). It has
started a timer ("opening handshake timeout"), because it is waiting for
the client to start the WebSocket opening handshake.

https://github.com/tavendo/AutobahnPython/blob/master/autobahn/autobahn/websocket.py#L2533

> 2013-05-07 07:59:26-0500 [-] onOpenHandshakeTimeout fired

The "opening handshake timeout" fired, since the server hasnt received
it from the client ..

> 2013-05-07 07:59:26-0500 [-] dropping connection

.. and hence the server actively terminates the TCP connection. This is
a DoS protection feature of Autobahn.

> 2013-05-07 07:59:26-0500 [-] Close received: 1006 - connection was
> closed uncleanly (peer did not finish (in time) the opening handshake)
> 2013-05-07 07:59:26-0500 [-] connection from <proxy_ip>:38014 lost
> 2013-05-07 07:59:26-0500 [-] Close received: 1006 - connection was
> closed uncleanly (peer did not finish (in time) the opening handshake)
>
>
> You might be aware of Intel's product Expressway Service Gateway (ESG).
> I am using it as a proxy. I had used it as a proxy between fuzzingclient
> and testeeserver, which worked.

Ok.

So

WORKS: "fuzzingclient <= ESG => testeeserver"
NOT WORKING: "testeeclient <= ESG => fuzzingserver"

?

>> <tobias.o...@gmail.com <mailto:tobias.o...@gmail.com>>

>>> <mailto:autobahnws+...@googlegroups.com>.

[Tobias Oberstein]

Hi Swati,

ok, I've implemented something. Don't know if it works, since I don't
have a suitable proxy around. If you want to try, pls do the following.

Fetch and install latest Autobahn (on Client and Server):

git clone git://github.com/tavendo/AutobahnPython.git
cd Autobahn/autobahn
python setup.py install


On Server (192.168.2.50), run:

cd Autobahn/examples/websocket/echo
python server.py debug


On Client (behind proxy = 192.168.1.100:8050), run:

cd Autobahn/examples/websocket/echo
python client_with_proxy.py ws://192.168.2.50:9000 192.168.1.100:8050 debug

Tobias

Am 08.05.2013 07:32, schrieb Swati Deshpande:
> Hi Tobias,
>

> Thanks a lot for looking into the issue. I will check your fix tomorrow
> and let you know if it works. I need to update AutobahnPython from
> https://github.com/tavendo/AutobahnPython for this right?
>
> Thanks,
> Swati

>
>
> On Tue, May 7, 2013 at 11:25 PM, Tobias Oberstein
> <tobias.o...@gmail.com <mailto:tobias.o...@gmail.com>> wrote:
>
> It hasn't yet received any data (and hasn't send any also).
> It has
> started a timer ("opening handshake timeout"), because it
> is waiting

> Ok. I understand this now. So, Can you please tell me why ESG
> does not
> receive any data from testeeclient?
>
>
> Autobahn currently does not implement HTTP/CONNECT which apparantly is
> the way it should work in the presence of explicit proxies.
>
> I have described this in this issue I added:
> https://github.com/tavendo/__AutobahnPython/issues/135
> <https://github.com/tavendo/AutobahnPython/issues/135>

>
> So
>
> WORKS: "fuzzingclient <= ESG => testeeserver"
> NOT WORKING: "testeeclient <= ESG => fuzzingserver"
>
> ?
>
>
>

> Yes. You are right.
>
>
> Given above, I now don't understand why any of those 2 works.
>
> Both needed to do a HTTP/CONNECT, in one case the fuzzingclient
> and in 2nd case the testeeclient.
>
> I can push code fixing #135 tomorrow. You could give it another try
> with that then. Which isn't an explanation for the behavior
> right now. But anyway ..
>
> Tobias
>
>

[Tobias Oberstein]

Hi Swati,

ESG does not behave like a (forward) proxy. If it did, it would accept
the initial HTTP/CONNECT. But it refuses. The 405 error response comes
from ESG.

Hence, I guess ESG isnt configured as a forward proxy.

Tobias

Am 08.05.2013 17:02, schrieb Swati Deshpande:
> Hi Tobias,
>

> I followed the steps given by you. I updated AutobahnPython, then
> started server and then started client_with_proxy. However, I am getting
> following errors (My WebSocket client, server and ESG is on same machine
> with ip 10.230.34.143, ESG is receiving requests on port 8081):
> /home/Autobahn/AutobahnPython-master/examples/websocket/echo>python
> client_with_proxy.py ws://10.230.34.143:9000 <http://10.230.34.143:9000>
> 10.230.34.143:8081 <http://10.230.34.143:8081> debug
> 2013-05-08 09:37:25-0500 [-] Log opened.
> 2013-05-08 09:37:25-0500 [-] Starting factory
> <autobahn.websocket.WebSocketClientFactory instance at 0x621a638>
> 2013-05-08 09:37:25-0500 [Uninitialized] connection to
> 10.230.34.143:8081 <http://10.230.34.143:8081> established
> 2013-05-08 09:37:25-0500 [Uninitialized] CONNECT 10.230.34.143:9000
> <http://10.230.34.143:9000> HTTP/1.1
> Host: 10.230.34.143
>
>
> 2013-05-08 09:37:25-0500 [Uninitialized] TX Octets to 10.230.34.143:8081
> <http://10.230.34.143:8081> : sync = False, octets =
> 434f4e4e4543542031302e3233302e33342e3134333a3930303020485454502f312e310d0a486f73743a2031302e3233302e33342e3134330d0a0d0a
> 2013-05-08 09:37:25-0500 [EchoClientProtocol,client] RX Octets from
> 10.230.34.143:8081 <http://10.230.34.143:8081> : octets =
> 485454502f312e3120343035204d4554484f44204e4f5420414c4c4f5745440d0a436f6e74656e742d4c656e6774683a20300d0a416c6c6f773a204745542c20504f53542c205055542c20484541442c2044454c4554452c204f5054494f4e532c2054524143450d0a0d0a
> 2013-05-08 09:37:25-0500 [EchoClientProtocol,client] received HTTP response:
>
> HTTP/1.1 405 METHOD NOT ALLOWED
> Content-Length: 0
> Allow: GET, POST, PUT, HEAD, DELETE, OPTIONS, TRACE
>
>
>
>
> 2013-05-08 09:37:25-0500 [EchoClientProtocol,client] received HTTP
> status line for proxy connect request : HTTP/1.1 405 METHOD NOT ALLOWED
> 2013-05-08 09:37:25-0500 [EchoClientProtocol,client] received HTTP
> headers for proxy connect request : {'content-length': u'0', 'allow':
> u'GET, POST, PUT, HEAD, DELETE, OPTIONS, TRACE'}
> 2013-05-08 09:37:25-0500 [EchoClientProtocol,client] failing proxy
> connect ('HTTP proxy connect failed (405 - METHODNOTALLOWED)')
> 2013-05-08 09:37:25-0500 [EchoClientProtocol,client] dropping connection
> 2013-05-08 09:37:25-0500 [-] WebSocketProtocol.onClose:

> wasClean=False
> code=1006
> reason=connection was closed uncleanly (None)
> self.closedByMe=False
> self.failedByMe=False
> self.droppedByMe=True
> self.wasClean=False
> self.wasNotCleanReason=None
> self.localCloseCode=None
> self.localCloseReason=None
> self.remoteCloseCode=None
> self.remoteCloseReason=None
>

> 2013-05-08 09:37:25-0500 [-] connection to 10.230.34.143:8081
> <http://10.230.34.143:8081> lost
> 2013-05-08 09:37:25-0500 [-] Stopping factory
> <autobahn.websocket.WebSocketClientFactory instance at 0x621a638>
> 2013-05-08 09:37:30-0500 [-] skipping onOpenHandshakeTimeout since
> WebSocket connection already closed
>
>
> Can you please let me know what is the issue over here?
>
> Thanks,
> Swati

>
>
> On Wed, May 8, 2013 at 7:06 PM, Tobias Oberstein
> <tobias.o...@gmail.com <mailto:tobias.o...@gmail.com>> wrote:
>
> Hi Swati,
>
> ok, I've implemented something. Don't know if it works, since I
> don't have a suitable proxy around. If you want to try, pls do the
> following.
>
> Fetch and install latest Autobahn (on Client and Server):
>

> git clone git://github.com/tavendo/__AutobahnPython.git
> <http://github.com/tavendo/AutobahnPython.git>

> cd Autobahn/autobahn
> python setup.py install
>
>
> On Server (192.168.2.50), run:
>

> cd Autobahn/examples/websocket/__echo

> python server.py debug
>
>
> On Client (behind proxy = 192.168.1.100:8050

> <http://192.168.1.100:8050>), run:
>
> cd Autobahn/examples/websocket/__echo

> python client_with_proxy.py ws://192.168.2.50:9000

> <http://192.168.2.50:9000> 192.168.1.100:8050
> <http://192.168.1.100:8050> debug

>
> Tobias
>
>
>
> Am 08.05.2013 07:32, schrieb Swati Deshpande:
>
> Hi Tobias,
>
> Thanks a lot for looking into the issue. I will check your fix
> tomorrow
> and let you know if it works. I need to update AutobahnPython from

> https://github.com/tavendo/__AutobahnPython

> <https://github.com/tavendo/AutobahnPython> for this right?
>
> Thanks,
> Swati
>
>
> On Tue, May 7, 2013 at 11:25 PM, Tobias Oberstein
> <tobias.o...@gmail.com <mailto:tobias.o...@gmail.com>

> <mailto:tobias.oberstein@__gmail.com

> <mailto:tobias.o...@gmail.com>>> wrote:
>
> It hasn't yet received any data (and hasn't send
> any also).
> It has
> started a timer ("opening handshake timeout"),
> because it
> is waiting
> Ok. I understand this now. So, Can you please tell me
> why ESG
> does not
> receive any data from testeeclient?
>
>
> Autobahn currently does not implement HTTP/CONNECT which
> apparantly is
> the way it should work in the presence of explicit proxies.
>
> I have described this in this issue I added:

> https://github.com/tavendo/____AutobahnPython/issues/135
> <https://github.com/tavendo/__AutobahnPython/issues/135>