WSS and WAMP

#1

Hello,

I have been using wamp to communicate between browser and server. Autobahn javascript in the browser, Autobahn python on the server. Things have been good so far. I now want to switch over to using secure websockets.

On the server i’m doing this:

contextFactory = ssl.DefaultOpenSSLContextFactory(‘keys/myapp.key’, ‘keys/myapp.crt’)

factory = WampServerFactory(“wss://myserver:80”, debugWamp = debug, debugCodePaths = debug)

factory.protocol = MyAppProtocol

factory.setProtocolOptions(allowHixie76 = True)

listenWS(factory, contextFactory) # Calls reactor.listenTCP for the factory

On the client i’m doing this:

var wsuri = “wss://myserver:80”;

ab.connect(wsuri, function(sess) { … });

The connection between client and server occurs but then is immediately closed. Debugging I see this:

(TLSMemoryBIOProtocol),0,76.21.0.64] WebSocketProtocol.onClose:

wasClean=False

code=1006

reason=connection was closed uncleanly (peer dropped the TCP connection without previous WebSocket closing handshake)

self.closedByMe=False

self.failedByMe=False

self.droppedByMe=False

self.wasClean=False

self.wasNotCleanReason=peer dropped the TCP connection without previous WebSocket closing handshake

self.localCloseCode=None

self.localCloseReason=None

self.remoteCloseCode=None

self.remoteCloseReason=None

Am I doing something wrong?

How do I get WSS working with WAMP?

Thanks!

Amichi

0 Likes

#2

This definitely works. I.e. check out

https://webmq.tavendo.de/

All those demos use WSS.

Try opening

https://myserver:80

in your browser .. entering it into the address bar. Yes. Autobahn should render a status page ("I am not a web server bla bla").

Probably you are using self-signed certs. You will then be prompted
to accept those .. try Firefox .. it allows to accept permanently.

Then, after accepting, try your test stuff again ..

If that does not help, please turn on logging on server: debug = True, debugWamp = True

and report the output here ..

Cheers,
Tobias

···

Am 01.11.2012 20:18, schrieb Amichi Amar:

Hello,

I have been using wamp to communicate between browser and server.
Autobahn javascript in the browser, Autobahn python on the server.
Things have been good so far. I now want to switch over to using secure
websockets.

0 Likes

#3

Hello together,

I’m facing the same issue. As WAMP relies upon websockets, this has to be possible, however, I get the same exception like Amichi when the client tries to connect and the server is using the WampServerFactory for Pub/sub e.g.

The output from the debug is:

2013-05-02 11:39:45+0200 [-] Log opened.
2013-05-02 11:39:45+0200 [-] myWampServerFactory (TLS) starting on 9000
2013-05-02 11:39:45+0200 [-] Starting factory <main.myWampServerFactory instance at 0x03575BE8>
2013-05-02 11:39:45+0200 [-] WampServerFactory starting
2013-05-02 11:39:45+0200 [-] Site (TLS) starting on 8080
2013-05-02 11:39:45+0200 [-] Starting factory <twisted.web.server.Site instance at 0x0357F738>
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware (TLSMemoryBIOProtocol),1,127.0.0.1] Certs are fine
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware (TLSMemoryBIOProtocol),1,127.0.0.1] Certs are fine
2013-05-02 11:40:03+0200 [-] 127.0.0.1 - - [02/May/2013:09:40:03 +0000] “GET / HTTP/1.1” 200 1262 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0”
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware (TLSMemoryBIOProtocol),1,127.0.0.1] 127.0.0.1 - - [02/May/2013:09:40:03 +0000] “GET /index.js HTTP/1.1” 304 - “https://localhost:8080/” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0”
2013-05-02 11:40:12+0200 [twisted.protocols.tls.TLSMemoryBIOFactory] connection accepted from peer 127.0.0.1:56614
2013-05-02 11:40:12+0200 [PubSubProtocol (TLSMemoryBIOProtocol),0,127.0.0.1] unsubscribed peer 127.0.0.1:56614 from all topics
2013-05-02 11:40:12+0200 [PubSubProtocol (TLSMemoryBIOProtocol),0,127.0.0.1] WebSocketProtocol.onClose:
wasClean=False
code=1006
reason=connection was closed uncleanly (peer dropped the TCP connection without previous WebSocket closing handshake)
self.closedByMe=False
self.failedByMe=False
self.droppedByMe=False
self.wasClean=False
self.wasNotCleanReason=peer dropped the TCP connection without previous WebSocket closing handshake
self.localCloseCode=None
self.localCloseReason=None
self.remoteCloseCode=None
self.remoteCloseReason=None

2013-05-02 11:40:12+0200 [PubSubProtocol (TLSMemoryBIOProtocol),0,127.0.0.1] connection from 127.0.0.1:56614 lost
2013-05-02 11:40:17+0200 [-] skipping onOpenHandshakeTimeout since WebSocket connection already closed

Any advice?

Thanks!
Marc

···

Am Donnerstag, 1. November 2012 21:36:24 UTC+1 schrieb Tobias Oberstein:

Am 01.11.2012 20:18, schrieb Amichi Amar:

Hello,

I have been using wamp to communicate between browser and server.

Autobahn javascript in the browser, Autobahn python on the server.

Things have been good so far. I now want to switch over to using secure

websockets.

This definitely works. I.e. check out

https://webmq.tavendo.de/

All those demos use WSS.

Try opening

https://myserver:80

in your browser … entering it into the address bar. Yes. Autobahn
should render a status page (“I am not a web server bla bla”).

Probably you are using self-signed certs. You will then be prompted

to accept those … try Firefox … it allows to accept permanently.

Then, after accepting, try your test stuff again …

If that does not help, please turn on logging on server: debug = True,
debugWamp = True

and report the output here …

Cheers,

Tobias

0 Likes

#4

Hello there…

I figured it out!
You have also to accept the server certificate for the port the Websocket is running. I was only able to do that by entering the url with that port and doing it manually.

Now communication over wss: and https: respectively works fine.
However, I’m now facing another issue. Once I’ve opened the socket and closed it afterwards, I cannot reopen it again. Same for the website. After I have authenticated the client with its certificate to access the website and to allow the websocket connection, I cannot reload the page or reopen the socket. Only after deleting the browser cache, I’m able to authenticate again and open the socket. This seems to have something to do with browser ssl caching or something like that.

Any suggestions how to handle this? I want like to achieve interaction with the page and socket like without authentication, that means, the user can open and reopen the socket and reload the page as many times as he likes without re-authentication or deleting the browser cache.

Thanks!
Marc

···

Am Donnerstag, 2. Mai 2013 11:41:05 UTC+2 schrieb muehl...@googlemail.com:

Am 01.11.2012 20:18, schrieb Amichi Amar:

Hello,

I have been using wamp to communicate between browser and server.

Autobahn javascript in the browser, Autobahn python on the server.

Things have been good so far. I now want to switch over to using secure

websockets.

This definitely works. I.e. check out

https://webmq.tavendo.de/

All those demos use WSS.

Try opening

https://myserver:80

in your browser … entering it into the address bar. Yes. Autobahn
should render a status page (“I am not a web server bla bla”).

Probably you are using self-signed certs. You will then be prompted

to accept those … try Firefox … it allows to accept permanently.

Then, after accepting, try your test stuff again …

If that does not help, please turn on logging on server: debug = True,
debugWamp = True

and report the output here …

Cheers,

Tobias

Hello together,

I’m facing the same issue. As WAMP relies upon websockets, this has to be possible, however, I get the same exception like Amichi when the client tries to connect and the server is using the WampServerFactory for Pub/sub e.g.

The output from the debug is:

2013-05-02 11:39:45+0200 [-] Log opened.
2013-05-02 11:39:45+0200 [-] myWampServerFactory (TLS) starting on 9000
2013-05-02 11:39:45+0200 [-] Starting factory <main.myWampServerFactory instance at 0x03575BE8>
2013-05-02 11:39:45+0200 [-] WampServerFactory starting
2013-05-02 11:39:45+0200 [-] Site (TLS) starting on 8080
2013-05-02 11:39:45+0200 [-] Starting factory <twisted.web.server.Site instance at 0x0357F738>
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware (TLSMemoryBIOProtocol),1,127.0.0.1] Certs are fine
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware (TLSMemoryBIOProtocol),1,127.0.0.1] Certs are fine
2013-05-02 11:40:03+0200 [-] 127.0.0.1 - - [02/May/2013:09:40:03 +0000] “GET / HTTP/1.1” 200 1262 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0”
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware (TLSMemoryBIOProtocol),1,127.0.0.1] 127.0.0.1 - - [02/May/2013:09:40:03 +0000] “GET /index.js HTTP/1.1” 304 - “https://localhost:8080/” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0”
2013-05-02 11:40:12+0200 [twisted.protocols.tls.TLSMemoryBIOFactory] connection accepted from peer 127.0.0.1:56614
2013-05-02 11:40:12+0200 [PubSubProtocol (TLSMemoryBIOProtocol),0,127.0.0.1] unsubscribed peer 127.0.0.1:56614 from all topics
2013-05-02 11:40:12+0200 [PubSubProtocol (TLSMemoryBIOProtocol),0,127.0.0.1] WebSocketProtocol.onClose:
wasClean=False
code=1006
reason=connection was closed uncleanly (peer dropped the TCP connection without previous WebSocket closing handshake)
self.closedByMe=False
self.failedByMe=False
self.droppedByMe=False
self.wasClean=False
self.wasNotCleanReason=peer dropped the TCP connection without previous WebSocket closing handshake
self.localCloseCode=None
self.localCloseReason=None
self.remoteCloseCode=None
self.remoteCloseReason=None

2013-05-02 11:40:12+0200 [PubSubProtocol (TLSMemoryBIOProtocol),0,127.0.0.1] connection from 127.0.0.1:56614 lost
2013-05-02 11:40:17+0200 [-] skipping onOpenHandshakeTimeout since WebSocket connection already closed

Any advice?

Thanks!
Marc

Am Donnerstag, 1. November 2012 21:36:24 UTC+1 schrieb Tobias Oberstein:

0 Likes

#5

Hello there...

I figured it out!
You have also to accept the server certificate for the port the
Websocket is running. I was only able to do that by entering the url
with that port and doing it manually.

This is expected behavior for browsers, since browsers don't render special dialogs (like "insecure certificate .. do you want to accept?") for Web page _subresources_. Subresources are things like images, but also WebSocket connections.

Now communication over wss: and https: respectively works fine.
However, I'm now facing another issue. Once I've opened the socket and
closed it afterwards, I cannot reopen it again. Same for the website.
After I have authenticated the client with its certificate to access the
website and to allow the websocket connection, I cannot reload the page
or reopen the socket. Only after deleting the browser cache, I'm able to
authenticate again and open the socket. This seems to have something to
do with browser ssl caching or something like that.

With Firefox, you can accept an invalid/insecure certificate permantently. With Chrome - as far as I remember - you can only accept for a browser session. Probably you can manually install your server certificate using some settings dialog in Chrome.

Anyway. For production use, you should use a certificate signed by a CA
which certificate is built into the browser. Also important: this certificate must include all intermediate CA certificates also. E.g. if you use StartSSL, they have the root CA in all browsers, but the free cert you get is signed with their intermediate cert. And the latter can be downloaded automatically by Firefox, but not Chrome (or was it reverse? dont remember). So include also the intermediate CA StartSSL cert into your server cert.

Hope that helps. Getting WSS and certs right is somewhat tricky ..

Tobias

···

Am 02.05.2013 13:21, schrieb muehlba...@googlemail.com:

Any suggestions how to handle this? I want like to achieve interaction
with the page and socket like without authentication, that means, the
user can open and reopen the socket and reload the page as many times as
he likes without re-authentication or deleting the browser cache.

Thanks!
Marc

Am Donnerstag, 2. Mai 2013 11:41:05 UTC+2 schrieb muehl...@googlemail.com:

    Hello together,

    I'm facing the same issue. As WAMP relies upon websockets, this has
    to be possible, however, I get the same exception like Amichi when
    the client tries to connect and the server is using the
    WampServerFactory for Pub/sub e.g.

    The output from the debug is:

    2013-05-02 11:39:45+0200 [-] Log opened.
    2013-05-02 11:39:45+0200 [-] myWampServerFactory (TLS) starting on 9000
    2013-05-02 11:39:45+0200 [-] Starting factory
    <__main__.myWampServerFactory instance at 0x03575BE8>
    2013-05-02 11:39:45+0200 [-] WampServerFactory starting
    2013-05-02 11:39:45+0200 [-] Site (TLS) starting on 8080
    2013-05-02 11:39:45+0200 [-] Starting factory
    <twisted.web.server.Site instance at 0x0357F738>
    2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware
    (TLSMemoryBIOProtocol),1,127.0.0.1] Certs are fine
    2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware
    (TLSMemoryBIOProtocol),1,127.0.0.1] Certs are fine
    2013-05-02 11:40:03+0200 [-] 127.0.0.1 - - [02/May/2013:09:40:03
    +0000] "GET / HTTP/1.1" 200 1262 "-" "Mozilla/5.0 (Windows NT 6.1;
    WOW64; rv:20.0) Gecko/20100101 Firefox/20.0"
    2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware
    (TLSMemoryBIOProtocol),1,127.0.0.1] 127.0.0.1 - -
    [02/May/2013:09:40:03 +0000] "GET /index.js HTTP/1.1" 304 -
    "https://localhost:8080/" "Mozilla/5.0 (Windows NT 6.1; WOW64;
    rv:20.0) Gecko/20100101 Firefox/20.0"
    2013-05-02 11:40:12+0200 [twisted.protocols.tls.TLSMemoryBIOFactory]
    connection accepted from peer 127.0.0.1:56614 <http://127.0.0.1:56614>
    2013-05-02 11:40:12+0200 [PubSubProtocol
    (TLSMemoryBIOProtocol),0,127.0.0.1] unsubscribed peer
    127.0.0.1:56614 <http://127.0.0.1:56614> from all topics
    2013-05-02 11:40:12+0200 [PubSubProtocol
    (TLSMemoryBIOProtocol),0,127.0.0.1] WebSocketProtocol.onClose:
         wasClean=False
         code=1006
         reason=connection was closed uncleanly (peer dropped the TCP
    connection without previous WebSocket closing handshake)
         self.closedByMe=False
         self.failedByMe=False
         self.droppedByMe=False
         self.wasClean=False
         self.wasNotCleanReason=peer dropped the TCP connection without
    previous WebSocket closing handshake
         self.localCloseCode=None
         self.localCloseReason=None
         self.remoteCloseCode=None
         self.remoteCloseReason=None

    2013-05-02 11:40:12+0200 [PubSubProtocol
    (TLSMemoryBIOProtocol),0,127.0.0.1] connection from 127.0.0.1:56614
    <http://127.0.0.1:56614> lost
    2013-05-02 11:40:17+0200 [-] skipping onOpenHandshakeTimeout since
    WebSocket connection already closed

    Any advice?

    Thanks!
    Marc

    Am Donnerstag, 1. November 2012 21:36:24 UTC+1 schrieb Tobias Oberstein:

        Am 01.11.2012 20:18, schrieb Amichi Amar:
         > Hello,
         >
         > I have been using wamp to communicate between browser and
        server.
         > Autobahn javascript in the browser, Autobahn python on the
        server.
         > Things have been good so far. I now want to switch over to
        using secure
         > websockets.

        This definitely works. I.e. check out

        https://webmq.tavendo.de/

        All those demos use WSS.

        Try opening

        https://myserver:80

        in your browser .. entering it into the address bar. Yes. Autobahn
        should render a status page ("I am not a web server bla bla").

        Probably you are using self-signed certs. You will then be prompted
        to accept those .. try Firefox .. it allows to accept permanently.

        Then, after accepting, try your test stuff again ..

        If that does not help, please turn on logging on server: debug =
        True,
        debugWamp = True

        and report the output here ..

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

0 Likes

#6

Hi Tobias,

of course one should use trusted CA signed certs. I just used self-signed certs to get into the issue of client authenticatiion with certs and twisted/autobahn. But the problem persists that somehow FF relies upon a kind of cache for the cert authentication, which causes the problem that once the client is authenticated and received the page and granted access to the websocket, he cannot simply reload the page or close/re-open the socket without cleaning the cache (with IE 10 i wasn’t able to reproduce this behaviouor).

Marc

···

Am Donnerstag, 2. Mai 2013 19:49:55 UTC+2 schrieb Tobias Oberstein:

Am 02.05.2013 13:21, schrieb muehl...@googlemail.com:

Hello there…

I figured it out!

You have also to accept the server certificate for the port the

Websocket is running. I was only able to do that by entering the url

with that port and doing it manually.

This is expected behavior for browsers, since browsers don’t render
special dialogs (like “insecure certificate … do you want to accept?”)
for Web page subresources. Subresources are things like images, but
also WebSocket connections.

Now communication over wss: and https: respectively works fine.

However, I’m now facing another issue. Once I’ve opened the socket and

closed it afterwards, I cannot reopen it again. Same for the website.

After I have authenticated the client with its certificate to access the

website and to allow the websocket connection, I cannot reload the page

or reopen the socket. Only after deleting the browser cache, I’m able to

authenticate again and open the socket. This seems to have something to

do with browser ssl caching or something like that.

With Firefox, you can accept an invalid/insecure certificate
permantently. With Chrome - as far as I remember - you can only accept
for a browser session. Probably you can manually install your server
certificate using some settings dialog in Chrome.

Anyway. For production use, you should use a certificate signed by a CA

which certificate is built into the browser. Also important: this
certificate must include all intermediate CA certificates also. E.g. if
you use StartSSL, they have the root CA in all browsers, but the free
cert you get is signed with their intermediate cert. And the latter can
be downloaded automatically by Firefox, but not Chrome (or was it
reverse? dont remember). So include also the intermediate CA StartSSL
cert into your server cert.

Hope that helps. Getting WSS and certs right is somewhat tricky …

Tobias

Any suggestions how to handle this? I want like to achieve interaction

with the page and socket like without authentication, that means, the

user can open and reopen the socket and reload the page as many times as

he likes without re-authentication or deleting the browser cache.

Thanks!

Marc

Am Donnerstag, 2. Mai 2013 11:41:05 UTC+2 schrieb muehl...@googlemail.com:

Hello together,
I'm facing the same issue. As WAMP relies upon websockets, this has
to be possible, however, I get the same exception like Amichi when
the client tries to connect and the server is using the
WampServerFactory for Pub/sub e.g.
The output from the debug is:
2013-05-02 11:39:45+0200 [-] Log opened.
2013-05-02 11:39:45+0200 [-] myWampServerFactory (TLS) starting on 9000
2013-05-02 11:39:45+0200 [-] Starting factory
<__main__.myWampServerFactory instance at 0x03575BE8>
2013-05-02 11:39:45+0200 [-] WampServerFactory starting
2013-05-02 11:39:45+0200 [-] Site (TLS) starting on 8080
2013-05-02 11:39:45+0200 [-] Starting factory
<twisted.web.server.Site instance at 0x0357F738>
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware
(TLSMemoryBIOProtocol),1,127.0.0.1] Certs are fine
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware
(TLSMemoryBIOProtocol),1,127.0.0.1] Certs are fine
2013-05-02 11:40:03+0200 [-] 127.0.0.1 - - [02/May/2013:09:40:03
+0000] "GET / HTTP/1.1" 200 1262 "-" "Mozilla/5.0 (Windows NT 6.1;
WOW64; rv:20.0) Gecko/20100101 Firefox/20.0"
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware
(TLSMemoryBIOProtocol),1,127.0.0.1] 127.0.0.1 - -
[02/May/2013:09:40:03 +0000] "GET /index.js HTTP/1.1" 304 -
"[https://localhost:8080/](https://localhost:8080/)" "Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:20.0) Gecko/20100101 Firefox/20.0"
2013-05-02 11:40:12+0200 [twisted.protocols.tls.TLSMemoryBIOFactory]
connection accepted from peer [127.0.0.1:56614](http://127.0.0.1:56614) <[http://127.0.0.1:56614](http://127.0.0.1:56614)>
2013-05-02 11:40:12+0200 [PubSubProtocol
(TLSMemoryBIOProtocol),0,127.0.0.1] unsubscribed peer
[127.0.0.1:56614](http://127.0.0.1:56614) <[http://127.0.0.1:56614](http://127.0.0.1:56614)> from all topics
2013-05-02 11:40:12+0200 [PubSubProtocol
(TLSMemoryBIOProtocol),0,127.0.0.1] WebSocketProtocol.onClose:
     wasClean=False
     code=1006
     reason=connection was closed uncleanly (peer dropped the TCP
connection without previous WebSocket closing handshake)
     self.closedByMe=False
     self.failedByMe=False
     self.droppedByMe=False
     self.wasClean=False
     self.wasNotCleanReason=peer dropped the TCP connection without
previous WebSocket closing handshake
     self.localCloseCode=None
     self.localCloseReason=None
     self.remoteCloseCode=None
     self.remoteCloseReason=None
2013-05-02 11:40:12+0200 [PubSubProtocol
(TLSMemoryBIOProtocol),0,127.0.0.1] connection from [127.0.0.1:56614](http://127.0.0.1:56614)
<[http://127.0.0.1:56614](http://127.0.0.1:56614)> lost
2013-05-02 11:40:17+0200 [-] skipping onOpenHandshakeTimeout since
WebSocket connection already closed
Any advice?
Thanks!
Marc
Am Donnerstag, 1. November 2012 21:36:24 UTC+1 schrieb Tobias Oberstein:
    Am 01.11.2012 20:18, schrieb Amichi Amar:
     > Hello,
     >
     > I have been using wamp to communicate between browser and
    server.
     > Autobahn javascript in the browser, Autobahn python on the
    server.
     > Things have been good so far. I now want to switch over to
    using secure
     > websockets.
    This definitely works. I.e. check out
    [https://webmq.tavendo.de/](https://webmq.tavendo.de/)
    All those demos use WSS.
    Try opening
    [https://myserver:80](https://myserver:80)
    in your browser .. entering it into the address bar. Yes. Autobahn
    should render a status page ("I am not a web server bla bla").
    Probably you are using self-signed certs. You will then be prompted
    to accept those .. try Firefox .. it allows to accept permanently.
    Then, after accepting, try your test stuff again ..
    If that does not help, please turn on logging on server: debug =
    True,
    debugWamp = True
    and report the output here ..
    Cheers,
    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.

0 Likes

#7

I had the issue as well.

I think accepting an untrusted cert in Firefox makes it valid for all ports. Hence, if you accept the cert on the webpage, the websocket connection will also start working. On Chrome unrusted certs will only work on the port on which the exception has been set. It also took me quite some time to figure this out, and navigate to the https of the wss port to also validate that cert.

This is where the ability of running the page and websocket on the same port should come in handy, in addition to the ease of configuring the firefall / port forwarding.

Daniel

···

On Friday, May 3, 2013 12:01:55 PM UTC+2, muehl...@googlemail.com wrote:

Hi Tobias,

of course one should use trusted CA signed certs. I just used self-signed certs to get into the issue of client authenticatiion with certs and twisted/autobahn. But the problem persists that somehow FF relies upon a kind of cache for the cert authentication, which causes the problem that once the client is authenticated and received the page and granted access to the websocket, he cannot simply reload the page or close/re-open the socket without cleaning the cache (with IE 10 i wasn’t able to reproduce this behaviouor).

Marc

Am Donnerstag, 2. Mai 2013 19:49:55 UTC+2 schrieb Tobias Oberstein:

Am 02.05.2013 13:21, schrieb muehl...@googlemail.com:

Hello there…

I figured it out!

You have also to accept the server certificate for the port the

Websocket is running. I was only able to do that by entering the url

with that port and doing it manually.

This is expected behavior for browsers, since browsers don’t render
special dialogs (like “insecure certificate … do you want to accept?”)
for Web page subresources. Subresources are things like images, but
also WebSocket connections.

Now communication over wss: and https: respectively works fine.

However, I’m now facing another issue. Once I’ve opened the socket and

closed it afterwards, I cannot reopen it again. Same for the website.

After I have authenticated the client with its certificate to access the

website and to allow the websocket connection, I cannot reload the page

or reopen the socket. Only after deleting the browser cache, I’m able to

authenticate again and open the socket. This seems to have something to

do with browser ssl caching or something like that.

With Firefox, you can accept an invalid/insecure certificate
permantently. With Chrome - as far as I remember - you can only accept
for a browser session. Probably you can manually install your server
certificate using some settings dialog in Chrome.

Anyway. For production use, you should use a certificate signed by a CA

which certificate is built into the browser. Also important: this
certificate must include all intermediate CA certificates also. E.g. if
you use StartSSL, they have the root CA in all browsers, but the free
cert you get is signed with their intermediate cert. And the latter can
be downloaded automatically by Firefox, but not Chrome (or was it
reverse? dont remember). So include also the intermediate CA StartSSL
cert into your server cert.

Hope that helps. Getting WSS and certs right is somewhat tricky …

Tobias

Any suggestions how to handle this? I want like to achieve interaction

with the page and socket like without authentication, that means, the

user can open and reopen the socket and reload the page as many times as

he likes without re-authentication or deleting the browser cache.

Thanks!

Marc

Am Donnerstag, 2. Mai 2013 11:41:05 UTC+2 schrieb muehl...@googlemail.com:

Hello together,
I'm facing the same issue. As WAMP relies upon websockets, this has
to be possible, however, I get the same exception like Amichi when
the client tries to connect and the server is using the
WampServerFactory for Pub/sub e.g.
The output from the debug is:
2013-05-02 11:39:45+0200 [-] Log opened.
2013-05-02 11:39:45+0200 [-] myWampServerFactory (TLS) starting on 9000
2013-05-02 11:39:45+0200 [-] Starting factory
<__main__.myWampServerFactory instance at 0x03575BE8>
2013-05-02 11:39:45+0200 [-] WampServerFactory starting
2013-05-02 11:39:45+0200 [-] Site (TLS) starting on 8080
2013-05-02 11:39:45+0200 [-] Starting factory
<twisted.web.server.Site instance at 0x0357F738>
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware
(TLSMemoryBIOProtocol),1,127.0.0.1] Certs are fine
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware
(TLSMemoryBIOProtocol),1,127.0.0.1] Certs are fine
2013-05-02 11:40:03+0200 [-] 127.0.0.1 - - [02/May/2013:09:40:03
+0000] "GET / HTTP/1.1" 200 1262 "-" "Mozilla/5.0 (Windows NT 6.1;
WOW64; rv:20.0) Gecko/20100101 Firefox/20.0"
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware
(TLSMemoryBIOProtocol),1,127.0.0.1] 127.0.0.1 - -
[02/May/2013:09:40:03 +0000] "GET /index.js HTTP/1.1" 304 -
"[https://localhost:8080/](https://localhost:8080/)" "Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:20.0) Gecko/20100101 Firefox/20.0"
2013-05-02 11:40:12+0200 [twisted.protocols.tls.TLSMemoryBIOFactory]
connection accepted from peer [127.0.0.1:56614](http://127.0.0.1:56614) <[http://127.0.0.1:56614](http://127.0.0.1:56614)>
2013-05-02 11:40:12+0200 [PubSubProtocol
(TLSMemoryBIOProtocol),0,127.0.0.1] unsubscribed peer
[127.0.0.1:56614](http://127.0.0.1:56614) <[http://127.0.0.1:56614](http://127.0.0.1:56614)> from all topics
2013-05-02 11:40:12+0200 [PubSubProtocol
(TLSMemoryBIOProtocol),0,127.0.0.1] WebSocketProtocol.onClose:
     wasClean=False
     code=1006
     reason=connection was closed uncleanly (peer dropped the TCP
connection without previous WebSocket closing handshake)
     self.closedByMe=False
     self.failedByMe=False
     self.droppedByMe=False
     self.wasClean=False
     self.wasNotCleanReason=peer dropped the TCP connection without
previous WebSocket closing handshake
     self.localCloseCode=None
     self.localCloseReason=None
     self.remoteCloseCode=None
     self.remoteCloseReason=None
2013-05-02 11:40:12+0200 [PubSubProtocol
(TLSMemoryBIOProtocol),0,127.0.0.1] connection from [127.0.0.1:56614](http://127.0.0.1:56614)
<[http://127.0.0.1:56614](http://127.0.0.1:56614)> lost
2013-05-02 11:40:17+0200 [-] skipping onOpenHandshakeTimeout since
WebSocket connection already closed
Any advice?
Thanks!
Marc
Am Donnerstag, 1. November 2012 21:36:24 UTC+1 schrieb Tobias Oberstein:
    Am 01.11.2012 20:18, schrieb Amichi Amar:
     > Hello,
     >
     > I have been using wamp to communicate between browser and
    server.
     > Autobahn javascript in the browser, Autobahn python on the
    server.
     > Things have been good so far. I now want to switch over to
    using secure
     > websockets.
    This definitely works. I.e. check out
    [https://webmq.tavendo.de/](https://webmq.tavendo.de/)
    All those demos use WSS.
    Try opening
    [https://myserver:80](https://myserver:80)
    in your browser .. entering it into the address bar. Yes. Autobahn
    should render a status page ("I am not a web server bla bla").
    Probably you are using self-signed certs. You will then be prompted
    to accept those .. try Firefox .. it allows to accept permanently.
    Then, after accepting, try your test stuff again ..
    If that does not help, please turn on logging on server: debug =
    True,
    debugWamp = True
    and report the output here ..
    Cheers,
    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.

0 Likes

#8

Hi Daniel,

I do run the webserver and websocket on the same port. And this seems to be a problem for the cert authentication in autobahn. Once I’ve accepted the cert for the page (e.g. webserver running on port 8080), the browser won’t ask me again for the websocket connection. Like you said is the observed behaviour for Firefox (Chrome and IE dont make any difference here). But, the websocket connection can’t be established because (I think this is the reason) the client is not asked again for authentication. And maybe this is the problem for the cert authentication procedure for autobahn/twisted. I can only circumvent this by deleting the browser ssl-cache after retrieving the page. Therefor I am asked again for authentication once I start to open the websocket. But, this is not a desirable behaviour. There must be a possibility to “save” the authentication for page AND websocket, throughout the session for example.

@Daniel: Do you have any advice regarding this?

Thanks!
Marc

···

Am Freitag, 3. Mai 2013 19:48:56 UTC+2 schrieb Daniel F.:

I had the issue as well.

I think accepting an untrusted cert in Firefox makes it valid for all ports. Hence, if you accept the cert on the webpage, the websocket connection will also start working. On Chrome unrusted certs will only work on the port on which the exception has been set. It also took me quite some time to figure this out, and navigate to the https of the wss port to also validate that cert.

This is where the ability of running the page and websocket on the same port should come in handy, in addition to the ease of configuring the firefall / port forwarding.

Daniel

On Friday, May 3, 2013 12:01:55 PM UTC+2, muehl...@googlemail.com wrote:

Hi Tobias,

of course one should use trusted CA signed certs. I just used self-signed certs to get into the issue of client authenticatiion with certs and twisted/autobahn. But the problem persists that somehow FF relies upon a kind of cache for the cert authentication, which causes the problem that once the client is authenticated and received the page and granted access to the websocket, he cannot simply reload the page or close/re-open the socket without cleaning the cache (with IE 10 i wasn’t able to reproduce this behaviouor).

Marc

Am Donnerstag, 2. Mai 2013 19:49:55 UTC+2 schrieb Tobias Oberstein:

Am 02.05.2013 13:21, schrieb muehl...@googlemail.com:

Hello there…

I figured it out!

You have also to accept the server certificate for the port the

Websocket is running. I was only able to do that by entering the url

with that port and doing it manually.

This is expected behavior for browsers, since browsers don’t render
special dialogs (like “insecure certificate … do you want to accept?”)
for Web page subresources. Subresources are things like images, but
also WebSocket connections.

Now communication over wss: and https: respectively works fine.

However, I’m now facing another issue. Once I’ve opened the socket and

closed it afterwards, I cannot reopen it again. Same for the website.

After I have authenticated the client with its certificate to access the

website and to allow the websocket connection, I cannot reload the page

or reopen the socket. Only after deleting the browser cache, I’m able to

authenticate again and open the socket. This seems to have something to

do with browser ssl caching or something like that.

With Firefox, you can accept an invalid/insecure certificate
permantently. With Chrome - as far as I remember - you can only accept
for a browser session. Probably you can manually install your server
certificate using some settings dialog in Chrome.

Anyway. For production use, you should use a certificate signed by a CA

which certificate is built into the browser. Also important: this
certificate must include all intermediate CA certificates also. E.g. if
you use StartSSL, they have the root CA in all browsers, but the free
cert you get is signed with their intermediate cert. And the latter can
be downloaded automatically by Firefox, but not Chrome (or was it
reverse? dont remember). So include also the intermediate CA StartSSL
cert into your server cert.

Hope that helps. Getting WSS and certs right is somewhat tricky …

Tobias

Any suggestions how to handle this? I want like to achieve interaction

with the page and socket like without authentication, that means, the

user can open and reopen the socket and reload the page as many times as

he likes without re-authentication or deleting the browser cache.

Thanks!

Marc

Am Donnerstag, 2. Mai 2013 11:41:05 UTC+2 schrieb muehl...@googlemail.com:

Hello together,
I'm facing the same issue. As WAMP relies upon websockets, this has
to be possible, however, I get the same exception like Amichi when
the client tries to connect and the server is using the
WampServerFactory for Pub/sub e.g.
The output from the debug is:
2013-05-02 11:39:45+0200 [-] Log opened.
2013-05-02 11:39:45+0200 [-] myWampServerFactory (TLS) starting on 9000
2013-05-02 11:39:45+0200 [-] Starting factory
<__main__.myWampServerFactory instance at 0x03575BE8>
2013-05-02 11:39:45+0200 [-] WampServerFactory starting
2013-05-02 11:39:45+0200 [-] Site (TLS) starting on 8080
2013-05-02 11:39:45+0200 [-] Starting factory
<twisted.web.server.Site instance at 0x0357F738>
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware
(TLSMemoryBIOProtocol),1,127.0.0.1] Certs are fine
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware
(TLSMemoryBIOProtocol),1,127.0.0.1] Certs are fine
2013-05-02 11:40:03+0200 [-] 127.0.0.1 - - [02/May/2013:09:40:03
+0000] "GET / HTTP/1.1" 200 1262 "-" "Mozilla/5.0 (Windows NT 6.1;
WOW64; rv:20.0) Gecko/20100101 Firefox/20.0"
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware
(TLSMemoryBIOProtocol),1,127.0.0.1] 127.0.0.1 - -
[02/May/2013:09:40:03 +0000] "GET /index.js HTTP/1.1" 304 -
"[https://localhost:8080/](https://localhost:8080/)" "Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:20.0) Gecko/20100101 Firefox/20.0"
2013-05-02 11:40:12+0200 [twisted.protocols.tls.TLSMemoryBIOFactory]
connection accepted from peer [127.0.0.1:56614](http://127.0.0.1:56614) <[http://127.0.0.1:56614](http://127.0.0.1:56614)>
2013-05-02 11:40:12+0200 [PubSubProtocol
(TLSMemoryBIOProtocol),0,127.0.0.1] unsubscribed peer
[127.0.0.1:56614](http://127.0.0.1:56614) <[http://127.0.0.1:56614](http://127.0.0.1:56614)> from all topics
2013-05-02 11:40:12+0200 [PubSubProtocol
(TLSMemoryBIOProtocol),0,127.0.0.1] WebSocketProtocol.onClose:
     wasClean=False
     code=1006
     reason=connection was closed uncleanly (peer dropped the TCP
connection without previous WebSocket closing handshake)
     self.closedByMe=False
     self.failedByMe=False
     self.droppedByMe=False
     self.wasClean=False
     self.wasNotCleanReason=peer dropped the TCP connection without
previous WebSocket closing handshake
     self.localCloseCode=None
     self.localCloseReason=None
     self.remoteCloseCode=None
     self.remoteCloseReason=None
2013-05-02 11:40:12+0200 [PubSubProtocol
(TLSMemoryBIOProtocol),0,127.0.0.1] connection from [127.0.0.1:56614](http://127.0.0.1:56614)
<[http://127.0.0.1:56614](http://127.0.0.1:56614)> lost
2013-05-02 11:40:17+0200 [-] skipping onOpenHandshakeTimeout since
WebSocket connection already closed
Any advice?
Thanks!
Marc
Am Donnerstag, 1. November 2012 21:36:24 UTC+1 schrieb Tobias Oberstein:
    Am 01.11.2012 20:18, schrieb Amichi Amar:
     > Hello,
     >
     > I have been using wamp to communicate between browser and
    server.
     > Autobahn javascript in the browser, Autobahn python on the
    server.
     > Things have been good so far. I now want to switch over to
    using secure
     > websockets.
    This definitely works. I.e. check out
    [https://webmq.tavendo.de/](https://webmq.tavendo.de/)
    All those demos use WSS.
    Try opening
    [https://myserver:80](https://myserver:80)
    in your browser .. entering it into the address bar. Yes. Autobahn
    should render a status page ("I am not a web server bla bla").
    Probably you are using self-signed certs. You will then be prompted
    to accept those .. try Firefox .. it allows to accept permanently.
    Then, after accepting, try your test stuff again ..
    If that does not help, please turn on logging on server: debug =
    True,
    debugWamp = True
    and report the output here ..
    Cheers,
    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.

0 Likes

#9

Hi Marc,

Are you talking about client certificate based authentication?

Regarding "accepting invalid server cert": I have never seen the behavior you describe. And in any case, it's quite unlikely, that it's specific to Autobahn.

You can try yourself: https://webmq.tavendo.de/

Tobias

···

Am 06.05.2013 16:06, schrieb muehlba...@googlemail.com:

Hi Daniel,

I do run the webserver and websocket on the same port. And this seems to be a problem for the cert authentication in autobahn. Once I've accepted the cert for the page (e.g. webserver running on port 8080), the browser won't ask me again for the websocket connection. Like you said is the observed behaviour for Firefox (Chrome and IE dont make any difference here). But, the websocket connection can't be established because (I think this is the reason) the client is not asked again for authentication. And maybe this is the problem for the cert authentication procedure for autobahn/twisted. I can only circumvent this by deleting the browser ssl-cache after retrieving the page. Therefor I am asked again for authentication once I start to open the websocket. But, this is not a desirable behaviour. There must be a possibility to "save" the authentication for page AND websocket, throughout the session for example.

@Daniel: Do you have any advice regarding this?

Thanks!
Marc

Am Freitag, 3. Mai 2013 19:48:56 UTC+2 schrieb Daniel F.:

    I had the issue as well.

    I think accepting an untrusted cert in Firefox makes it valid for
    all ports. Hence, if you accept the cert on the webpage, the
    websocket connection will also start working. On Chrome unrusted
    certs will only work on the port on which the exception has been
    set. It also took me quite some time to figure this out, and
    navigate to the https of the wss port to also validate that cert.

    This is where the ability of running the page and websocket on the
    same port should come in handy, in addition to the ease of
    configuring the firefall / port forwarding.

    Daniel

    On Friday, May 3, 2013 12:01:55 PM UTC+2, > muehl...@googlemail.com wrote:

        Hi Tobias,

        of course one should use trusted CA signed certs. I just used
        self-signed certs to get into the issue of client
        authenticatiion with certs and twisted/autobahn. But the
        problem persists that somehow FF relies upon a kind of cache
        for the cert authentication, which causes the problem that
        once the client is authenticated and received the page and
        granted access to the websocket, he cannot simply reload the
        page or close/re-open the socket without cleaning the cache
        (with IE 10 i wasn't able to reproduce this behaviouor).

        Marc

        Am Donnerstag, 2. Mai 2013 19:49:55 UTC+2 schrieb Tobias > Oberstein:

            Am 02.05.2013 13:21, schrieb muehl...@googlemail.com:
            > Hello there...
            >
            > I figured it out!
            > You have also to accept the server certificate for the
            port the
            > Websocket is running. I was only able to do that by
            entering the url
            > with that port and doing it manually.

            This is expected behavior for browsers, since browsers
            don't render
            special dialogs (like "insecure certificate .. do you want
            to accept?")
            for Web page _subresources_. Subresources are things like
            images, but
            also WebSocket connections.

            >
            > Now communication over wss: and https: respectively
            works fine.
            > However, I'm now facing another issue. Once I've opened
            the socket and
            > closed it afterwards, I cannot reopen it again. Same for
            the website.
            > After I have authenticated the client with its
            certificate to access the
            > website and to allow the websocket connection, I cannot
            reload the page
            > or reopen the socket. Only after deleting the browser
            cache, I'm able to
            > authenticate again and open the socket. This seems to
            have something to
            > do with browser ssl caching or something like that.

            With Firefox, you can accept an invalid/insecure certificate
            permantently. With Chrome - as far as I remember - you can
            only accept
            for a browser session. Probably you can manually install
            your server
            certificate using some settings dialog in Chrome.

            Anyway. For production use, you should use a certificate
            signed by a CA
            which certificate is built into the browser. Also
            important: this
            certificate must include all intermediate CA certificates
            also. E.g. if
            you use StartSSL, they have the root CA in all browsers,
            but the free
            cert you get is signed with their intermediate cert. And
            the latter can
            be downloaded automatically by Firefox, but not Chrome (or
            was it
            reverse? dont remember). So include also the intermediate
            CA StartSSL
            cert into your server cert.

            Hope that helps. Getting WSS and certs right is somewhat
            tricky ..

            Tobias

            >
            > Any suggestions how to handle this? I want like to
            achieve interaction
            > with the page and socket like without authentication,
            that means, the
            > user can open and reopen the socket and reload the page
            as many times as
            > he likes without re-authentication or deleting the
            browser cache.
            >
            > Thanks!
            > Marc
            >
            > Am Donnerstag, 2. Mai 2013 11:41:05 UTC+2 schrieb > muehl...@googlemail.com:
            >
            > Hello together,
            >
            > I'm facing the same issue. As WAMP relies upon
            websockets, this has
            > to be possible, however, I get the same exception
            like Amichi when
            > the client tries to connect and the server is using the
            > WampServerFactory for Pub/sub e.g.
            >
            > The output from the debug is:
            >
            > 2013-05-02 11:39:45+0200 [-] Log opened.
            > 2013-05-02 11:39:45+0200 [-] myWampServerFactory
            (TLS) starting on 9000
            > 2013-05-02 11:39:45+0200 [-] Starting factory
            > <__main__.myWampServerFactory instance at 0x03575BE8>
            > 2013-05-02 11:39:45+0200 [-] WampServerFactory starting
            > 2013-05-02 11:39:45+0200 [-] Site (TLS) starting on
            8080
            > 2013-05-02 11:39:45+0200 [-] Starting factory
            > <twisted.web.server.Site instance at 0x0357F738>
            > 2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware
            > (TLSMemoryBIOProtocol),1,127.0.0.1] Certs are fine
            > 2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware
            > (TLSMemoryBIOProtocol),1,127.0.0.1] Certs are fine
            > 2013-05-02 11:40:03+0200 [-] 127.0.0.1 - -
            [02/May/2013:09:40:03
            > +0000] "GET / HTTP/1.1" 200 1262 "-" "Mozilla/5.0
            (Windows NT 6.1;
            > WOW64; rv:20.0) Gecko/20100101 Firefox/20.0"
            > 2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware
            > (TLSMemoryBIOProtocol),1,127.0.0.1] 127.0.0.1 - -
            > [02/May/2013:09:40:03 +0000] "GET /index.js
            HTTP/1.1" 304 -
            > "https://localhost:8080/" "Mozilla/5.0 (Windows NT
            6.1; WOW64;
            > rv:20.0) Gecko/20100101 Firefox/20.0"
            > 2013-05-02 11:40:12+0200
            [twisted.protocols.tls.TLSMemoryBIOFactory]
            > connection accepted from peer 127.0.0.1:56614
            <http://127.0.0.1:56614> <http://127.0.0.1:56614>
            > 2013-05-02 11:40:12+0200 [PubSubProtocol
            > (TLSMemoryBIOProtocol),0,127.0.0.1] unsubscribed peer
            > 127.0.0.1:56614 <http://127.0.0.1:56614>
            <http://127.0.0.1:56614> from all topics
            > 2013-05-02 11:40:12+0200 [PubSubProtocol
            > (TLSMemoryBIOProtocol),0,127.0.0.1]
            WebSocketProtocol.onClose:
            > wasClean=False
            > code=1006
            > reason=connection was closed uncleanly (peer
            dropped the TCP
            > connection without previous WebSocket closing
            handshake)
            > self.closedByMe=False
            > self.failedByMe=False
            > self.droppedByMe=False
            > self.wasClean=False
            > self.wasNotCleanReason=peer dropped the TCP
            connection without
            > previous WebSocket closing handshake
            > self.localCloseCode=None
            > self.localCloseReason=None
            > self.remoteCloseCode=None
            > self.remoteCloseReason=None
            >
            > 2013-05-02 11:40:12+0200 [PubSubProtocol
            > (TLSMemoryBIOProtocol),0,127.0.0.1] connection from
            127.0.0.1:56614 <http://127.0.0.1:56614>
            > <http://127.0.0.1:56614> lost
            > 2013-05-02 11:40:17+0200 [-] skipping
            onOpenHandshakeTimeout since
            > WebSocket connection already closed
            >
            > Any advice?
            >
            > Thanks!
            > Marc
            >
            > Am Donnerstag, 1. November 2012 21:36:24 UTC+1 > schrieb Tobias Oberstein:
            >
            > Am 01.11.2012 20:18, schrieb Amichi Amar:
            > > Hello,
            > >
            > > I have been using wamp to communicate between
            browser and
            > server.
            > > Autobahn javascript in the browser, Autobahn
            python on the
            > server.
            > > Things have been good so far. I now want to
            switch over to
            > using secure
            > > websockets.
            >
            > This definitely works. I.e. check out
            >
            > https://webmq.tavendo.de/
            >
            > All those demos use WSS.
            >
            > Try opening
            >
            > https://myserver:80
            >
            > in your browser .. entering it into the address
            bar. Yes. Autobahn
            > should render a status page ("I am not a web
            server bla bla").
            >
            > Probably you are using self-signed certs. You
            will then be prompted
            > to accept those .. try Firefox .. it allows to
            accept permanently.
            >
            > Then, after accepting, try your test stuff again ..
            >
            > If that does not help, please turn on logging on
            server: debug =
            > True,
            > debugWamp = True
            >
            > and report the output here ..
            >
            > Cheers,
            > 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 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.

0 Likes

#10

Hi Tobias,

yes this is about client certificate based auth.
And yes, my guess, too, is that this has something to do with browser and caching, and not with autobahn.

Marc

0 Likes

#11

Hi Marc,

ahh, ok.

I cannot say alot about client cert. based auth. with WebSocket .. only been using Cookies and WAMP-CRA for authenticating WebSocket connections.

The arguing on the WS working group with WS auth was: we don't need a WS auth, we can just reuse any auth mechanism that HTTP provides. This makes some sense, but IMHO wasn't necessarily thought through to its end. I.e. as said, WS is a _subresource_ from a browser point of view. Which means no rendering of dialogs for "Basis HTTP Auth". Which in turn requires the WS to run on the same host/port (origin) as the Web page containing the JS opening the WS. And other nuisances like this ..

We need an example in AutobahnPython for that .. added an issue:

https://github.com/tavendo/AutobahnPython/issues/134

This would make it easier to test and talk about weird behaviors ..

Tobias

···

Am 07.05.2013 08:51, schrieb muehlba...@googlemail.com:

Hi Tobias,

yes this is about client certificate based auth.
And yes, my guess, too, is that this has something to do with browser and caching, and not with autobahn.

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

#12

Hi Tobias,

thanks for your troubles! I’m looking forward to see the example. And I will inform you when I figured out the weird behaviour in more detail.

Marc

···

Am Dienstag, 7. Mai 2013 09:05:09 UTC+2 schrieb Tobias Oberstein:

Hi Marc,

ahh, ok.

I cannot say alot about client cert. based auth. with WebSocket … only
been using Cookies and WAMP-CRA for authenticating WebSocket connections.

The arguing on the WS working group with WS auth was: we don’t need a WS
auth, we can just reuse any auth mechanism that HTTP provides. This
makes some sense, but IMHO wasn’t necessarily thought through to its
end. I.e. as said, WS is a subresource from a browser point of view.
Which means no rendering of dialogs for “Basis HTTP Auth”. Which in turn
requires the WS to run on the same host/port (origin) as the Web page
containing the JS opening the WS. And other nuisances like this …

We need an example in AutobahnPython for that … added an issue:

https://github.com/tavendo/AutobahnPython/issues/134

This would make it easier to test and talk about weird behaviors …

Tobias

Am 07.05.2013 08:51, schrieb muehl...@googlemail.com:

Hi Tobias,

yes this is about client certificate based auth.

And yes, my guess, too, is that this has something to do with browser
and caching, and not with autobahn.

Marc


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

#13

For all those readers who are using WAMP and webserver on the same port, here is a thread on stackoverflow in which Tobias helped me with this:

http://stackoverflow.com/questions/16234429/how-can-i-setup-an-autobahn-pub-sub-server-and-a-autobahn-webserver-listening-on

Many thanks again, Tobias!

Marc

0 Likes

#14

After some testing, I can say that the whole thing works in IE 10.

In Firefox and Chrome it does not work. If I first call my autobahn websocket under wss://localhost:8080/ws and authenticate with the cert, I cannot after that retrieve the page running on the webserver on https://localhost:8080. If I do it the other way round, first retrieve the page and authenticate for that, I cannot open the websocket after this.

In short: IE 10 “stores” or “accepts” one authentication for the whole session, FF and Chrome “block” or do not “store” the authentication for different ressources and hence access is denied. I also looked through the FF settings via about:config, but adjustment of ssl and caching parameters did not change anything.

Does someone else ever had these struggles when authenticating clients with certs and accessing subresources like websockets?

Marc

0 Likes

#15

After some testing, I can say that the whole thing works in IE 10.

In Firefox and Chrome it does not work. If I first call my autobahn
websocket under wss://localhost:8080/ws and authenticate with the cert,
I cannot after that retrieve the page running on the webserver on
https://localhost:8080. If I do it the other way round, first retrieve
the page and authenticate for that, I cannot open the websocket after this.

In short: IE 10 "stores" or "accepts" one authentication for the whole
session, FF and Chrome "block" or do not "store" the authentication for
different ressources and hence access is denied. I also looked through
the FF settings via about:config, but adjustment of ssl and caching
parameters did not change anything.

Does someone else ever had these struggles when authenticating clients
with certs and accessing subresources like websockets?

I guess "client cert. based auth." in the context of WebSocket is a quite special topic not a lot people will have experience with.

One option: post your findings on

https://www.ietf.org/mailman/listinfo/hybi

This list is where WS was developed, and there are a lot WS implementors hanging around. Including browser developers.

Tobias

···

Am 07.05.2013 15:38, schrieb muehlba...@googlemail.com:

Marc

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

#16

Hi Tobias,

has there been any progress regarding WSS and client certs?
I’m still stuck in this issue. Maybe the autobahn server does not reuse the security context of the https for the wss? Or do you think this is most likely a browser issue?

Greetings
Marc

0 Likes

#17

Hi Tobias,

has there been any progress regarding WSS and client certs?
I'm still stuck in this issue. Maybe the autobahn server does not reuse
the security context of the https for the wss? Or do you think this is

When a browser fetches a HTML page which then opens a WS connection to a server which serves both HTTP/HTML and WS on the same port, the browser will nevertheless open (at least) 2 TCP connections to the server, and the TLS will get negotiated on each TCP separately.

This isn't specific to Autobahn.

most likely a browser issue?

Yes.

I'd expect a browser to do the following: when doing the initial fetch of the HTML page, ask the user which client cert to authenticate with.
When subsequently fetching stuff via HTTP from or opening a WS to the same origin, reuse the user selected client cert to (silently) authenticate the other TCP connections as well.

You could do the following test: have a HTML page with a image element with src empty. Have JS inside the HTML which after some delay will set the src attribute to something on the same server. The image is a subresource and no dialogs will be rendered, but browser should reuse the client cert.

If that works for you with above test, but not WS, then the browser is doing something different for WS and other subresources => bug.

If that does not work for you even for the simple img test, thats even more severe ..

Could you do that test a report back?

Tobias

···

Am 14.05.2013 12:14, schrieb muehlba...@googlemail.com:

Greetings
Marc

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

#18

Hi Tobias,

thanks for the hint. I did that small test and images get displayed as expected, without dialog and just reusing the authentication.
Hence, it seems like a browser bug. Other users on stackoverflow also stated, that this seems to be a bug in browsers and I should report it.
However, I’m really surprised that it seems that only I or just a few experienced this behaviour. If it really was a bug, there had to be more responses I guess.

I will look through the bug reports for different browsers and see if I can place my issue somewhere there.

Greetings

···

Am Dienstag, 21. Mai 2013 15:22:05 UTC+2 schrieb Tobias Oberstein:

Am 14.05.2013 12:14, schrieb muehl...@googlemail.com:

Hi Tobias,

has there been any progress regarding WSS and client certs?

I’m still stuck in this issue. Maybe the autobahn server does not reuse

the security context of the https for the wss? Or do you think this is

When a browser fetches a HTML page which then opens a WS connection to a
server which serves both HTTP/HTML and WS on the same port, the browser
will nevertheless open (at least) 2 TCP connections to the server, and
the TLS will get negotiated on each TCP separately.

This isn’t specific to Autobahn.

most likely a browser issue?

Yes.

I’d expect a browser to do the following: when doing the initial fetch
of the HTML page, ask the user which client cert to authenticate with.

When subsequently fetching stuff via HTTP from or opening a WS to the
same origin, reuse the user selected client cert to (silently)
authenticate the other TCP connections as well.

You could do the following test: have a HTML page with a image element
with src empty. Have JS inside the HTML which after some delay will set
the src attribute to something on the same server. The image is a
subresource and no dialogs will be rendered, but browser should reuse
the client cert.

If that works for you with above test, but not WS, then the browser is
doing something different for WS and other subresources => bug.

If that does not work for you even for the simple img test, thats even
more severe …

Could you do that test a report back?

Tobias

Greetings

Marc

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

#19

Hi Marc,

> thanks for the hint. I did that small test and images get displayed as

expected, without dialog and just reusing the authentication.
Hence, it seems like a browser bug. Other users on stackoverflow also

Interesting. Thanks for reporting back ..

stated, that this seems to be a bug in browsers and I should report it.
However, I'm really surprised that it seems that only I or just a few
experienced this behaviour. If it really was a bug, there had to be more
responses I guess.

I'd guess that using client cert. based authentication for authenticating WS connections is not done very often.

I'd assume that most people will do cookie based auth. with WS or implement app level auth. (e.g. as Autobahn with WAMP-CRA provides).

I will look through the bug reports for different browsers and see if I
can place my issue somewhere there.

Yep, makes sense. I'd also be interested in this .. so if you file any bugs or find out anything relevant, could you please write a quick notice here?

Tobias

···

Greetings

Am Dienstag, 21. Mai 2013 15:22:05 UTC+2 schrieb Tobias Oberstein:

    Am 14.05.2013 12:14, schrieb muehl...@googlemail.com <javascript:>:
     > Hi Tobias,
     >
     > has there been any progress regarding WSS and client certs?
     > I'm still stuck in this issue. Maybe the autobahn server does not
    reuse
     > the security context of the https for the wss? Or do you think
    this is

    When a browser fetches a HTML page which then opens a WS connection
    to a
    server which serves both HTTP/HTML and WS on the same port, the browser
    will nevertheless open (at least) 2 TCP connections to the server, and
    the TLS will get negotiated on each TCP separately.

    This isn't specific to Autobahn.

     > most likely a browser issue?

    Yes.

    I'd expect a browser to do the following: when doing the initial fetch
    of the HTML page, ask the user which client cert to authenticate with.
    When subsequently fetching stuff via HTTP from or opening a WS to the
    same origin, reuse the user selected client cert to (silently)
    authenticate the other TCP connections as well.

    You could do the following test: have a HTML page with a image element
    with src empty. Have JS inside the HTML which after some delay will set
    the src attribute to something on the same server. The image is a
    subresource and no dialogs will be rendered, but browser should reuse
    the client cert.

    If that works for you with above test, but not WS, then the browser is
    doing something different for WS and other subresources => bug.

    If that does not work for you even for the simple img test, thats even
    more severe ..

    Could you do that test a report back?

    Tobias

     >
     > Greetings
     > Marc
     >
     > --
     > 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

#20

I filed a bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=878715

0 Likes