Testing Autobahn fuzzing client with fuzzing server

#1

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?

autobahnpython_case_1_1_1.html (11 KB)

0 Likes

#2

Hi,

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

fuzzingclient <=> testeeserver
fuzzingserver <=> testeeclient

Tobias

···

Am 07.05.2013 12:43, schrieb 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?
--
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.

0 Likes

#3

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?

···

On Tuesday, May 7, 2013 4:19:05 PM UTC+5:30, Tobias Oberstein wrote:

Hi,

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

fuzzingclient <=> testeeserver

fuzzingserver <=> testeeclient

Tobias

Am 07.05.2013 12:43, schrieb 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?


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.

0 Likes

#4

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

···

Am 07.05.2013 14:18, schrieb 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?

On Tuesday, May 7, 2013 4:19:05 PM UTC+5:30, Tobias Oberstein wrote:

    Hi,

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

    fuzzingclient <=> testeeserver
    fuzzingserver <=> testeeclient

    Tobias

    Am 07.05.2013 12:43, schrieb 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
    <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
    <http://www.websocket.org/echo.html> to send empty request,
    request is
    > successful. I get empty response back. Can you please help with
    this?
    > --
    > 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 autobah...@googlegroups.com <javascript:>.
    > For more options, visit https://groups.google.com/groups/opt_out
    <https://groups.google.com/groups/opt_out>.
    >

--
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.

0 Likes

#5

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

···

On Tue, May 7, 2013 at 5:54 PM, Tobias Oberstein tobias.o...@gmail.com wrote:

  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







  Am 07.05.2013 14:18, schrieb 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?

  On Tuesday, May 7, 2013 4:19:05 PM UTC+5:30, Tobias Oberstein

wrote:

    Hi,




    easy, for testing AutobahnPython with the AutobahnTestsuite, you

need

    the following pairs of modes of wstest:




    fuzzingclient <=> testeeserver


    fuzzingserver <=> testeeclient




    Tobias




    Am 07.05.2013 12:43, schrieb 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](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](http://www.websocket.org/echo.html)
    to send empty request, request is

    > successful. I get empty response back. Can you please help

with this?

    > --

    > 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](https://groups.google.com/groups/opt_out)        .


    >


    >
  --

  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](https://groups.google.com/groups/opt_out).
0 Likes

#6

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

···

Am 07.05.2013 14:34, schrieb 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 ..

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

On Tue, May 7, 2013 at 5:54 PM, Tobias Oberstein > <tobias.o...@gmail.com <mailto:tobias.o...@gmail.com>> wrote:

    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

    Am 07.05.2013 14:18, schrieb 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?

    On Tuesday, May 7, 2013 4:19:05 PM UTC+5:30, Tobias Oberstein wrote:

        Hi,

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

        fuzzingclient <=> testeeserver
        fuzzingserver <=> testeeclient

        Tobias

        Am 07.05.2013 12:43, schrieb 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?
        > --
        > 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 autobah...@googlegroups.com.
        > For more options, visit
        https://groups.google.com/groups/opt_out.
        >

    -- 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/groups/opt_out.

0 Likes

#7

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

···

On Tue, May 7, 2013 at 6:17 PM, Tobias Oberstein tobias.o...@gmail.com wrote:

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



  Am 07.05.2013 14:34, schrieb 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

      On Tue, May 7, 2013 at 5:54 PM, Tobias

Oberstein tobias.o...@gmail.com
wrote:

            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](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







            Am 07.05.2013 14:18, schrieb 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?

            On Tuesday, May 7, 2013 4:19:05 PM UTC+5:30, Tobias

Oberstein wrote:

Hi,

              easy, for testing AutobahnPython with the

AutobahnTestsuite, you need

              the following pairs of modes of wstest:



              fuzzingclient <=> testeeserver

              fuzzingserver <=> testeeclient



              Tobias



              Am 07.05.2013 12:43, schrieb 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](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](http://www.websocket.org/echo.html)
              to send empty request, request is

              > successful. I get empty response back. Can you

please help with this?

              > --

              > 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 autobah...@googlegroups.com                  .


              > For more options, visit [https://groups.google.com/groups/opt_out](https://groups.google.com/groups/opt_out)                  .


              >

              >

                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](https://groups.google.com/groups/opt_out).
0 Likes

#8

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"

?

···

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

On Tue, May 7, 2013 at 6:17 PM, Tobias Oberstein > <tobias.o...@gmail.com <mailto:tobias.o...@gmail.com>> wrote:

    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

    Am 07.05.2013 14:34, schrieb 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 ..

    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

    On Tue, May 7, 2013 at 5:54 PM, Tobias Oberstein >> <tobias.o...@gmail.com <mailto:tobias.o...@gmail.com>> >> wrote:

        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

        Am 07.05.2013 14:18, schrieb 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?

        On Tuesday, May 7, 2013 4:19:05 PM UTC+5:30, Tobias Oberstein >>> wrote:

            Hi,

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

            fuzzingclient <=> testeeserver
            fuzzingserver <=> testeeclient

            Tobias

            Am 07.05.2013 12:43, schrieb 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?
            > --
            > 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 autobah...@googlegroups.com.
            > For more options, visit
            https://groups.google.com/groups/opt_out.
            >

        --
        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/groups/opt_out.

0 Likes

#9

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

0 Likes

#10

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.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>

             <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

0 Likes