[jitsi-dev] [jvb] serve meet, tcp harvester and xmpp http binding in non-ssl mode


#1

I’ve been using the configuration described in https://github.com/jitsi/jitsi-videobridge/blob/master/doc/http.md to configure my jvb install to serve meet and all other http/tcp traffic over ssl which seems to be the default configuration.

I’m wondering if there’s a way to configure jvb to server all components in non-ssl mode so I can put something like AWS’ ELB in front of it to do all the SSL and terminate the encryption before forwarding the traffic onto the jvb instance.

Has anyone tried to do this before and has any pointers?

Roberto


#2

The media traffic (ICE/TCP, RTP) does not use TLS or HTTP. You will need to handle it separately on the ELB, and I don't see how you could do that.

Regards,
Boris

···

On 26/01/16 10:21, Roberto Andrade wrote:

I’ve been using the configuration described in
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/http.md to
configure my jvb install to serve meet and all other http/tcp traffic
over ssl which seems to be the default configuration.

I’m wondering if there’s a way to configure jvb to server all components
in non-ssl mode so I can put something like AWS’ ELB in front of it to
do all the SSL and terminate the encryption before forwarding the
traffic onto the jvb instance.

Has anyone tried to do this before and has any pointers?


#3

ELB has the concept of a TCP load balancer, so that takes care of the protocol issue (i.e.: non HTTP), but now on the non-TLS… so the JVB is able to distinguish between ICE/RTP traffic and handle that without encryption even though it’s coming in on port 443?

Basically, Jetty is not invoked at that point?

···

On 1/26/16, 11:54 AM, "dev on behalf of Boris Grozev" <dev-bounces@jitsi.org on behalf of boris@jitsi.org> wrote:

On 26/01/16 10:21, Roberto Andrade wrote:

I’ve been using the configuration described in
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/http.md to
configure my jvb install to serve meet and all other http/tcp traffic
over ssl which seems to be the default configuration.

I’m wondering if there’s a way to configure jvb to server all components
in non-ssl mode so I can put something like AWS’ ELB in front of it to
do all the SSL and terminate the encryption before forwarding the
traffic onto the jvb instance.

Has anyone tried to do this before and has any pointers?

The media traffic (ICE/TCP, RTP) does not use TLS or HTTP. You will need
to handle it separately on the ELB, and I don't see how you could do that.

Regards,
Boris

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


#4

Yes, exactly.

Boris

···

On 26/01/16 10:59, Roberto Andrade wrote:

ELB has the concept of a TCP load balancer, so that takes care of the
protocol issue (i.e.: non HTTP), but now on the non-TLS… so the JVB
is able to distinguish between ICE/RTP traffic and handle that
without encryption even though it’s coming in on port 443?

Basically, Jetty is not invoked at that point?


#5

Hi,

···

Le 26 janv. 2016 18:10, "Boris Grozev" <boris@jitsi.org> a écrit :

On 26/01/16 10:59, Roberto Andrade wrote:

ELB has the concept of a TCP load balancer, so that takes care of the
protocol issue (i.e.: non HTTP), but now on the non-TLS… so the JVB
is able to distinguish between ICE/RTP traffic and handle that
without encryption even though it’s coming in on port 443?

Basically, Jetty is not invoked at that point?

Yes, exactly.

Boris

I've an haproxy configuration that handle HTTPS, jvb traffic, ssh on port
443, with fully transparent proxying (nginx & openssh see original client
IP)
I can send it tomorrow (it's at work)


#6

:

Hi,

>
>>
>> ELB has the concept of a TCP load balancer, so that takes care of the
>> protocol issue (i.e.: non HTTP), but now on the non-TLS… so the JVB
>> is able to distinguish between ICE/RTP traffic and handle that
>> without encryption even though it’s coming in on port 443?
>>
>> Basically, Jetty is not invoked at that point?
>
>
> Yes, exactly.
>
>
> Boris
>

I've an haproxy configuration that handle HTTPS, jvb traffic, ssh on port
443, with fully transparent proxying (nginx & openssh see original client
IP)
I can send it tomorrow (it's at work)

https isn't handled by haproxy but by nginx,
haproxy just scan the content of the first packet and choose a backend

frontend ft_https

    mode tcp
    option tcplog
    bind <public-ip>:443

    acl client_attempts_ssh req.payload(0,7) -m str SSH-2.0
    acl ssl2-1 payload(0,1) -m bin 80
    acl ssl2-2 payload(2,1) -m bin 01
    acl https req_ssl_sni -i <domain name>

    tcp-request inspect-delay 5s
    tcp-request content accept if client_attempts_ssh
    tcp-request content accept if ssl2-1 ssl2-2
    tcp-request content accept if https

    use_backend bk_ssh if client_attempts_ssh
    use_backend bk_jvb2 if ssl2-1 ssl2-2
    use_backend bk_https if https
    default_backend bk_jvb

backend bk_https
    mode tcp
    source 0.0.0.0 usesrc clientip
    server srv_https 127.0.0.1:443

backend bk_ssh
    mode tcp
    source 0.0.0.0 usesrc clientip
    server srv_ssh 127.0.0.1:22

backend bk_jvb
    mode tcp
    #source 0.0.0.0 usesrc clientip
    server srv_jvb <public-ip>:4443

backend bk_jvb2
    mode tcp
    #source 0.0.0.0 usesrc clientip
    server srv_jvb2 <public-ip>:4443

the "usesrc clientip" need some black magic:

echo 1 > /proc/sys/net/ipv4/conf/all/route_localnet
ip rule add from 127.0.0.1 table 42
ip route add default table 42 via 127.0.0.1 dev lo

you can only use it with program listening on 127.0.0.1 (not jvb by default)

Regards
Etienne

···

2016-01-26 22:44 GMT+01:00 Etienne Champetier <champetier.etienne@gmail.com>

Le 26 janv. 2016 18:10, "Boris Grozev" <boris@jitsi.org> a écrit :
> On 26/01/16 10:59, Roberto Andrade wrote: