[jitsi-dev] SSLH and the Videobridge?

Developers
#1

Hello,

Have you ever tried setting up SSLH with the Videobridge?

SSLH is a protocol multiplexer, that allows you to run various services
behind one port.

I'd like to make available on port 443 all of these:

   - The JVB TCP binding (
   https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md)
   - The Jitsi Meet webapp
   - The BOSH endpoint
   - ...

The goal is to be able to operate in very restrictive networks.

SSLH operates based on inspection of the first few bytes of data that it
receives. Based on configured selection criteria (which can be a regex), it
forwards data to the corresponding service.

I believe I'll manage to configure this for most services, but I'm unsure
how to identify data that is send to the JVB TCP port. Does that have some
kind of magic number that I can use, by chance?

Regards,

  Guus

#2

Hey Guus,

This is currently the default behavior of jitsi-meet if you install it
on a machine which has java8 and has no nginx and apache installed.
When you install it, it configures jetty on port 443 and it
multiplexes the traffic for web and media using the same port.
I'm not sure about the traffic on the tcp port, it should have some
stun going in that direction and then media flows.

Regards
damencho

···

On Tue, Nov 7, 2017 at 5:09 AM, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

Hello,

Have you ever tried setting up SSLH with the Videobridge?

SSLH is a protocol multiplexer, that allows you to run various services
behind one port.

I'd like to make available on port 443 all of these:

The JVB TCP binding
(https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md)
The Jitsi Meet webapp
The BOSH endpoint
...

The goal is to be able to operate in very restrictive networks.

SSLH operates based on inspection of the first few bytes of data that it
receives. Based on configured selection criteria (which can be a regex), it
forwards data to the corresponding service.

I believe I'll manage to configure this for most services, but I'm unsure
how to identify data that is send to the JVB TCP port. Does that have some
kind of magic number that I can use, by chance?

Regards,

  Guus

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

#3

I need more services on that port :slight_smile:

I'll see if I can dump some traffic, figure things out that way.

···

On 7 November 2017 at 15:25, Damian Minkov <damencho@jitsi.org> wrote:

Hey Guus,

This is currently the default behavior of jitsi-meet if you install it
on a machine which has java8 and has no nginx and apache installed.
When you install it, it configures jetty on port 443 and it
multiplexes the traffic for web and media using the same port.
I'm not sure about the traffic on the tcp port, it should have some
stun going in that direction and then media flows.

Regards
damencho

On Tue, Nov 7, 2017 at 5:09 AM, Guus der Kinderen > <guus.der.kinderen@gmail.com> wrote:
> Hello,
>
> Have you ever tried setting up SSLH with the Videobridge?
>
> SSLH is a protocol multiplexer, that allows you to run various services
> behind one port.
>
> I'd like to make available on port 443 all of these:
>
> The JVB TCP binding
> (https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md)
> The Jitsi Meet webapp
> The BOSH endpoint
> ...
>
> The goal is to be able to operate in very restrictive networks.
>
> SSLH operates based on inspection of the first few bytes of data that it
> receives. Based on configured selection criteria (which can be a regex),
it
> forwards data to the corresponding service.
>
> I believe I'll manage to configure this for most services, but I'm unsure
> how to identify data that is send to the JVB TCP port. Does that have
some
> kind of magic number that I can use, by chance?
>
> Regards,
>
> Guus
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

#4

Hi Guss, is there some standard demultiplexer that can take care of this? If so, I wonder if we want to get rid of the de-multiplexing code in the bridge.

···

On Nov 7, 2017, at 8:31 AM, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

I need more services on that port :slight_smile:

I'll see if I can dump some traffic, figure things out that way.

On 7 November 2017 at 15:25, Damian Minkov <damencho@jitsi.org <mailto:damencho@jitsi.org>> wrote:
Hey Guus,

This is currently the default behavior of jitsi-meet if you install it
on a machine which has java8 and has no nginx and apache installed.
When you install it, it configures jetty on port 443 and it
multiplexes the traffic for web and media using the same port.
I'm not sure about the traffic on the tcp port, it should have some
stun going in that direction and then media flows.

Regards
damencho

On Tue, Nov 7, 2017 at 5:09 AM, Guus der Kinderen > <guus.der.kinderen@gmail.com <mailto:guus.der.kinderen@gmail.com>> wrote:
> Hello,
>
> Have you ever tried setting up SSLH with the Videobridge?
>
> SSLH is a protocol multiplexer, that allows you to run various services
> behind one port.
>
> I'd like to make available on port 443 all of these:
>
> The JVB TCP binding
> (https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md)
> The Jitsi Meet webapp
> The BOSH endpoint
> ...
>
> The goal is to be able to operate in very restrictive networks.
>
> SSLH operates based on inspection of the first few bytes of data that it
> receives. Based on configured selection criteria (which can be a regex), it
> forwards data to the corresponding service.
>
> I believe I'll manage to configure this for most services, but I'm unsure
> how to identify data that is send to the JVB TCP port. Does that have some
> kind of magic number that I can use, by chance?
>
> Regards,
>
> Guus
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org <mailto:dev@jitsi.org>
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org <mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

#5

For posterity: This might be the handshake that I'm after:
https://github.com/jitsi/ice4j/blob/master/src/main/java/org/ice4j/ice/harvest/GoogleTurnSSLCandidateHarvester.java#L58-L69

···

On 7 November 2017 at 15:31, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

I need more services on that port :slight_smile:

I'll see if I can dump some traffic, figure things out that way.

On 7 November 2017 at 15:25, Damian Minkov <damencho@jitsi.org> wrote:

Hey Guus,

This is currently the default behavior of jitsi-meet if you install it
on a machine which has java8 and has no nginx and apache installed.
When you install it, it configures jetty on port 443 and it
multiplexes the traffic for web and media using the same port.
I'm not sure about the traffic on the tcp port, it should have some
stun going in that direction and then media flows.

Regards
damencho

On Tue, Nov 7, 2017 at 5:09 AM, Guus der Kinderen >> <guus.der.kinderen@gmail.com> wrote:
> Hello,
>
> Have you ever tried setting up SSLH with the Videobridge?
>
> SSLH is a protocol multiplexer, that allows you to run various services
> behind one port.
>
> I'd like to make available on port 443 all of these:
>
> The JVB TCP binding
> (https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md)
> The Jitsi Meet webapp
> The BOSH endpoint
> ...
>
> The goal is to be able to operate in very restrictive networks.
>
> SSLH operates based on inspection of the first few bytes of data that it
> receives. Based on configured selection criteria (which can be a
regex), it
> forwards data to the corresponding service.
>
> I believe I'll manage to configure this for most services, but I'm
unsure
> how to identify data that is send to the JVB TCP port. Does that have
some
> kind of magic number that I can use, by chance?
>
> Regards,
>
> Guus
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

#6

I'm trying to get this one to work:
http://www.rutschle.net/tech/sslh/README.html

···

On 7 November 2017 at 17:13, George Politis <gp@jitsi.org> wrote:

Hi Guss, is there some standard demultiplexer that can take care of this?
If so, I wonder if we want to get rid of the de-multiplexing code in the
bridge.

On Nov 7, 2017, at 8:31 AM, Guus der Kinderen <guus.der.kinderen@gmail.com> > wrote:

I need more services on that port :slight_smile:

I'll see if I can dump some traffic, figure things out that way.

On 7 November 2017 at 15:25, Damian Minkov <damencho@jitsi.org> wrote:

Hey Guus,

This is currently the default behavior of jitsi-meet if you install it
on a machine which has java8 and has no nginx and apache installed.
When you install it, it configures jetty on port 443 and it
multiplexes the traffic for web and media using the same port.
I'm not sure about the traffic on the tcp port, it should have some
stun going in that direction and then media flows.

Regards
damencho

On Tue, Nov 7, 2017 at 5:09 AM, Guus der Kinderen >> <guus.der.kinderen@gmail.com> wrote:
> Hello,
>
> Have you ever tried setting up SSLH with the Videobridge?
>
> SSLH is a protocol multiplexer, that allows you to run various services
> behind one port.
>
> I'd like to make available on port 443 all of these:
>
> The JVB TCP binding
> (https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md)
> The Jitsi Meet webapp
> The BOSH endpoint
> ...
>
> The goal is to be able to operate in very restrictive networks.
>
> SSLH operates based on inspection of the first few bytes of data that it
> receives. Based on configured selection criteria (which can be a
regex), it
> forwards data to the corresponding service.
>
> I believe I'll manage to configure this for most services, but I'm
unsure
> how to identify data that is send to the JVB TCP port. Does that have
some
> kind of magic number that I can use, by chance?
>
> Regards,
>
> Guus
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

#7

Yep.

Or else, if the "fake" SSL handshake is not used, look for a STUN packet[0] with RFC4571 framing (i.e. the first two bytes in the stream will indicate the packet length).

Regards,
Boris

[0] https://tools.ietf.org/html/rfc5389#section-6

···

On 07/11/2017 10:12, Guus der Kinderen wrote:

For posterity: This might be the handshake that I'm after: https://github.com/jitsi/ice4j/blob/master/src/main/java/org/ice4j/ice/harvest/GoogleTurnSSLCandidateHarvester.java#L58-L69

#8

I'm horrible in low-level protocols like that - is the information in the
fake SSL handshake, as well as the handskae for the RFC4571 framing, enough
to distinguish the traffic from other (potentially SSL) traffic?

···

On 7 November 2017 at 17:19, Boris Grozev <boris@jitsi.org> wrote:

On 07/11/2017 10:12, Guus der Kinderen wrote:

For posterity: This might be the handshake that I'm after:
https://github.com/jitsi/ice4j/blob/master/src/main/java/
org/ice4j/ice/harvest/GoogleTurnSSLCandidateHarvester.java#L58-L69

Yep.

Or else, if the "fake" SSL handshake is not used, look for a STUN
packet[0] with RFC4571 framing (i.e. the first two bytes in the stream will
indicate the packet length).

Regards,
Boris

[0] https://tools.ietf.org/html/rfc5389#section-6

#9

I've been successful in setting up an environment where all data is flowing
over one IP and port. Something that was giving me some issues is the fact
that the harvester (from the ice4j project) bind to specific interfaces.

Browsing through the code, I believe that the same set of
TransportAddresses (InetAddress, port, protocol-id) is used to both:

   - bind to interfaces
   - generate a list of candidates

It obviously makes little sense to expose 127.0.0.1 as a candidate - but
with this multiplexing in place, I'd like to be able to connect to that
address (from my multiplexer).

Does it make sense to allow binding to all interfaces?

Regards,

  Guus

···

On 7 November 2017 at 18:39, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

I'm horrible in low-level protocols like that - is the information in the
fake SSL handshake, as well as the handskae for the RFC4571 framing, enough
to distinguish the traffic from other (potentially SSL) traffic?

On 7 November 2017 at 17:19, Boris Grozev <boris@jitsi.org> wrote:

On 07/11/2017 10:12, Guus der Kinderen wrote:

For posterity: This might be the handshake that I'm after:
https://github.com/jitsi/ice4j/blob/master/src/main/java/org
/ice4j/ice/harvest/GoogleTurnSSLCandidateHarvester.java#L58-L69

Yep.

Or else, if the "fake" SSL handshake is not used, look for a STUN
packet[0] with RFC4571 framing (i.e. the first two bytes in the stream will
indicate the packet length).

Regards,
Boris

[0] https://tools.ietf.org/html/rfc5389#section-6

#10

Hi Guus,

I've been successful in setting up an environment where all data is flowing over one IP and port. Something that was giving me some issues is the fact that the harvester (from the ice4j project) bind to specific interfaces.

Browsing through the code, I believe that the same set of TransportAddresses (InetAddress, port, protocol-id) is used to both:

  * bind to interfaces
  * generate a list of candidates

It obviously makes little sense to expose 127.0.0.1 as a candidate - but with this multiplexing in place, I'd like to be able to connect to that address (from my multiplexer).

Does it make sense to allow binding to all interfaces?

I think the code which prevents what you're trying to do is here:
https://github.com/jitsi/ice4j/blob/master/src/main/java/org/ice4j/ice/harvest/AbstractTcpListener.java#L82

I don't see a problem with allowing the user of ice4j to have it bind on a local interface if that's what they need. So contributions would be welcome, but please keep the default behavior the same.

Regards,
Boris

···

On 09/11/2017 08:50, Guus der Kinderen wrote:

#11

It would be pretty cool to have that documented! Any chance you can send a PR?

Cheers,

···

On Nov 9, 2017, at 15:50, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

I've been successful in setting up an environment where all data is flowing over one IP and port.

--
Saúl

#12

I'd be happy to show, after I remove a lot of ducttape. Apart from what I'm
requesting here, I didn't actually make code changes. I've applied SSLH and
some network settings. That won't fit in a PR :slight_smile:

···

On 9 November 2017 at 16:02, Saúl Ibarra Corretgé <scorretge@atlassian.com> wrote:

> On Nov 9, 2017, at 15:50, Guus der Kinderen <guus.der.kinderen@gmail.com> > wrote:
>
> I've been successful in setting up an environment where all data is
flowing over one IP and port.

It would be pretty cool to have that documented! Any chance you can send a
PR?

Cheers,

--
Saúl

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

#13

I'd be happy to show, after I remove a lot of ducttape. Apart from what I'm requesting here, I didn't actually make code changes. I've applied SSLH and some network settings. That won't fit in a PR :slight_smile:

Awesome! I know it’s environment dependent, but could be helpful for a one-box-for-everything kinda scenario. Feel free to brain dump + attach some configs and I’ll document it if you’re short on time.

Cheers,

···

On Nov 9, 2017, at 16:11, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

On 9 November 2017 at 16:02, Saúl Ibarra Corretgé <scorretge@atlassian.com> wrote:

> On Nov 9, 2017, at 15:50, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:
>
> I've been successful in setting up an environment where all data is flowing over one IP and port.

It would be pretty cool to have that documented! Any chance you can send a PR?

Cheers,

--
Saúl

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Saúl

#14

Hello,

I’ve spent a bit of time trying to configure sslh on a box which also runs OpenVPN. Therefore, I couldn’t rely on the “anyprot” sslh fallback to route unmatched traffic to the Jitsi Video Bridge because the OpenVPN sslh rule would intercept it first.

I was able to write a regex match that sends the required traffic to the videobridge. Here’s the resulting sslh config file (/etc/sslh.cfg)

verbose: 0;
foreground: false;
inetd: false;
numeric: false;
transparent: true;
timeout: 2;
user: "sslh";
pidfile: "/var/run/sslh/sslh.pid";
chroot: "/var/empty";


# Change hostname with your external address name.
listen:
(
    { host: "<server_ip>"; port: "443"; }
);

protocols:
(
     { name: "ssh"; service: "ssh"; host: "<server_ip>"; port: "22"; fork: true; },
     { name: "tls"; host: "<server_ip>"; port: "4444"; log_level: 0; },
     { name: "xmpp"; host: "<server_ip>"; port: "5222"; },
     { name: "regex"; host: "<server_ip>"; port: "4443"; regex_patterns: [ "\x00\x50\x21\x12" ]; log_level: 1; },
     { name: "openvpn"; host: "<server_ip>"; port: "1194"; },
     { name: "anyprot"; host: "<server_ip>"; port: "4444"; }
);

# Jitsi Meet TCP signature "\x00\x64\x00\x01\x00\x50\x21\x12" but only mathes on last 4 bytes...

Under debian, I replaced the DAEMON_OPTS line in /etc/default/sslh with:
DAEMON_OPTS="-F /etc/sslh.cfg"

I also had to add the following lines to the videobridge config file /etc/jitsi/videobridge/sip-communicator.properties:
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=443
org.jitsi.videobridge.TCP_HARVESTER_SSLTCP=true