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?
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.
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?
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
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.
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
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
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.
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
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).
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:
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).
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'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:
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).
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 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.
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
> 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?
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
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.
> 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?
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)
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