WebSocket protocol is newly standardized protocol which is supported by many of current versions of browsers. Currently there is a draft of protocol draft-ietf-xmpp-websocket-00 which describes usage of WebSocket to connect to XMPP servers. Tigase XMPP Server implementation of WebSocket protocol to connect to XMPP server is very close to this draft of this specification. By default Tigase XMPP Server has XMPP-over-WebSocket protocol enabled without encryption on port 5290. To use this protocol you need to use library which supports XMPP-over-WebSocket protocol.
It is possible to enable encrypted WebSocket connection in Tigase XMPP Server. To do this you need to add following lines
to etc/config.tdsl
config file:
ws2s { connections { ports = [ 5290, 5291 ] 5290 { socket = 'ssl' type = 'accept' } 5291 { socket = 'plain' type = 'accept' } } }
In this example we enabled WebSocket endpoint on port 5290 allowing unencrypted connections, and encrypted WebSocket endpoint
on port 5291.
As this is TLS/SSL connection (no STARTTLS) it uses default certificate installed in Tigase XMPP Server instance. This certificate
is located in certs/default.pem
.
Note
There is no default configuration for non-default ports. All ports outside 443 MUST be configured.
As mentioned in Tip #1 WebSocket endpoint is plain TLS/SSL port, so it always serves default certificate for Tigase XMPP Server
instance. That is ok if we are hosting single domain and if default certificate matches matches our domain. But If we host
multiple domain we cannot use wss://example1.com:5291/
connection URL, if our default certificate is for domain example2.com
. In this situation it is recommended to use the default certificate for the domain under which the server is accessible from
the internet. This domain should identify this server, so this domain would not point to two nodes of a cluster. After we
deploy separate certificate for each of cluster nodes, we should follow same tip as Tip #1 for BOSH. Our web-based XMPP client
should have knowledge about each node of a cluster and when it needs to connect it should randomly select one node from list
of available cluster nodes and try to connect using connection URL that would contain name of server under which it can be
identified from internet.
Example:
We have servers t1.example1.com
and t2.example1.com
which are nodes of a cluster in hosting domain example2.com
. Each of our nodes contains default SSL certificate with domain names matching the cluster node. Web client retrieves list
of cluster nodes from web server and then when it needs to connect to XMPP server it picks random host from list of retrieved
cluster nodes (i.e. t2.example1.com
) and tries to connect using WebSocket encrypted protocol to host t2.example1.com
using the following URL: wss://t2.example1.com:5291/
. Upon connection the client should still send example2.com as name of server to which it tries to connect (example2.com
should be value of to attribute of XMPP stream). This will allow browser to validate certificate as it will be for the same
domain to which browser connects, and it will allow XMPP client to connect to domain example2.com
, which is one of hosted vhosts.