[jitsi-dev] Video bridges, conference calls, and encryption, oh my

Archive
1

I've got a couple of questions. I'm seeing if Jitsi will work for remote
meetings.

  * I've tested both a conference call and a video bridge. What's the
    difference? It appears that video bridges don't support ZRTP but
    conference calls maybe do, and they both seem to work when I toggle
    video on.
  * When doing either a conference call or video bridge on a jabber
    server that uses SSL, are the video/audio streams themselves
    encrypted using SSL too? So in the worst case, there's at least
    transport encryption the entire time?
  * Do video bridges or conference calls support any sort of end-to-end
    encryption, so that the server can't spy on the call at all?

Thanks!

2

Hey Micah,

I've got a couple of questions. I'm seeing if Jitsi will work for remote
meetings.

You may also want to try JitMeet: https://meet.jit.si

  * I've tested both a conference call and a video bridge. What's the
    difference?

One is hosted on your computer, the other on a server.

It appears that video bridges don't support ZRTP

No. They support DTLS/SRTP though.

but
    conference calls maybe do, and they both seem to work when I toggle
    video on.
  * When doing either a conference call or video bridge on a jabber
    server that uses SSL, are the video/audio streams themselves
    encrypted using SSL too?

No. SSL is only for signalling. Media is securely transported by SRTP.

So in the worst case, there's at least
    transport encryption the entire time?
  * Do video bridges or conference calls support any sort of end-to-end
    encryption, so that the server can't spy on the call at all?

No and ... I am going to go out on a limb here and state that this is not really possible. Solutions like SRTP EKT [0] allow servers to operate without decrypting media but there's nothing that can prevent them from doing so if they choose to.

So, if you are looking for real security: run your own conference server.

Emil

[0] SRTP EKT - http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt

···

On 27.03.14, 21:33, Micah Lee wrote:

Thanks!

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

--
https://jitsi.org

3

Hi,

Just a quick question to clear up some doubts about crypto I still have.
Let's say user A starts a conference call with B and C.

When using the Jitsi app to host a video/audio conference, I know that the
focus/hoster (A in this case) has ZRTP encrypted audio and video to the
other participants (B and C).
However, I'm not sure how ZRTP encryption works between the other two (B
and C). Are their bilateral media streams encrypted too (their screen shows
the red lock open between them) or are their streams being relayed through
the host (A) and therefore "piggy backing" on those established ZRTP
encrypted streams?

Sorry if my question sounds confusing but since I know multi-party ZRTP
(like mpOTR) is still not really a reality yet, I'm trying to figure out
how jitsi deals with this.

Thanks,

Peter

···

On Thu, Mar 27, 2014 at 10:34 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Micah,

On 27.03.14, 21:33, Micah Lee wrote:

I've got a couple of questions. I'm seeing if Jitsi will work for remote
meetings.

You may also want to try JitMeet: https://meet.jit.si

   * I've tested both a conference call and a video bridge. What's the

    difference?

One is hosted on your computer, the other on a server.

It appears that video bridges don't support ZRTP

No. They support DTLS/SRTP though.

but

    conference calls maybe do, and they both seem to work when I toggle
    video on.
  * When doing either a conference call or video bridge on a jabber

    server that uses SSL, are the video/audio streams themselves
    encrypted using SSL too?

No. SSL is only for signalling. Media is securely transported by SRTP.

So in the worst case, there's at least

    transport encryption the entire time?
  * Do video bridges or conference calls support any sort of end-to-end

    encryption, so that the server can't spy on the call at all?

No and ... I am going to go out on a limb here and state that this is not
really possible. Solutions like SRTP EKT [0] allow servers to operate
without decrypting media but there's nothing that can prevent them from
doing so if they choose to.

So, if you are looking for real security: run your own conference server.

Emil

[0] SRTP EKT - http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt

Thanks!

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

--
https://jitsi.org

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

4

Hi,

Just a quick question to clear up some doubts about crypto I still have.
Let's say user A starts a conference call with B and C.

When using the Jitsi app to host a video/audio conference, I know that
the focus/hoster (A in this case) has ZRTP encrypted audio and video to
the other participants (B and C).
However, I'm not sure how ZRTP encryption works between the other two (B
and C). Are their bilateral media streams encrypted too

Yes. You can see this as two separate 1-to-1 ZRTP calls that the organiser of the conference has established with the two other participants.

(their screen
shows the red lock open between them) or are their streams being relayed
through the host (A) and therefore "piggy backing" on those established
ZRTP encrypted streams?

Sorry if my question sounds confusing but since I know multi-party ZRTP
(like mpOTR) is still not really a reality yet, I'm trying to figure out
how jitsi deals with this.

Well ... that's not entirely accurate (see my note above). ZRTP also provides a trusted MitM mode which allows you to use it even with entities such as Jitsi Videobridge. It's a bit (or in some cases even exactly) like using SSL certs.

Hope this helps,
Emil

···

On 06.04.14, 16:28, Peter Villeneuve wrote:

Thanks,

Peter

On Thu, Mar 27, 2014 at 10:34 PM, Emil Ivov <emcho@jitsi.org > <mailto:emcho@jitsi.org>> wrote:

    Hey Micah,

    On 27.03.14, 21:33, Micah Lee wrote:

        I've got a couple of questions. I'm seeing if Jitsi will work
        for remote
        meetings.

    You may also want to try JitMeet: https://meet.jit.si

           * I've tested both a conference call and a video bridge.
        What's the
             difference?

    One is hosted on your computer, the other on a server.

        It appears that video bridges don't support ZRTP

    No. They support DTLS/SRTP though.

        but
             conference calls maybe do, and they both seem to work when
        I toggle
             video on.
           * When doing either a conference call or video bridge on a jabber

             server that uses SSL, are the video/audio streams themselves
             encrypted using SSL too?

    No. SSL is only for signalling. Media is securely transported by SRTP.

        So in the worst case, there's at least
             transport encryption the entire time?
           * Do video bridges or conference calls support any sort of
        end-to-end

             encryption, so that the server can't spy on the call at all?

    No and ... I am going to go out on a limb here and state that this
    is not really possible. Solutions like SRTP EKT [0] allow servers to
    operate without decrypting media but there's nothing that can
    prevent them from doing so if they choose to.

    So, if you are looking for real security: run your own conference
    server.

    Emil

    [0] SRTP EKT - http://tools.ietf.org/html/__draft-ietf-avt-srtp-ekt
    <http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt>

        Thanks!

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

    --
    https://jitsi.org

    _________________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/__mailman/listinfo/dev
    <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

--
https://jitsi.org

5

Thanks for clearing that up Emil. It can be scary for people participating
in a conference to suddenly see that there is no encryption signalled
between B and C (in my example above). If I understood you right, media
between B and C, although not directly encrypted end to end, is still
encrypted because it is being transmitted by A's ZRTP connections to B and
C. Please correct me if I'm wrong.

Also, I'm aware that ZRTP's trusted MiTM mode allows the server to act like
as the "classic" SDES SRTP mode.
In fact classic SDES SRTP is pretty much equal to MiTM ZRTP since obviously
the server always needs to be trusted in both cases.

But when I mentioned mpOTR I'm referring to the possibility to have true
end to end multiparty encryption going on. As far as I know that's quite
difficult because of the key management mess and it does not yet exist for
either (mp)OTR or ZRTP.

···

On Sun, Apr 6, 2014 at 9:32 PM, Emil Ivov <emcho@jitsi.org> wrote:

On 06.04.14, 16:28, Peter Villeneuve wrote:

Hi,

Just a quick question to clear up some doubts about crypto I still have.
Let's say user A starts a conference call with B and C.

When using the Jitsi app to host a video/audio conference, I know that
the focus/hoster (A in this case) has ZRTP encrypted audio and video to
the other participants (B and C).
However, I'm not sure how ZRTP encryption works between the other two (B
and C). Are their bilateral media streams encrypted too

Yes. You can see this as two separate 1-to-1 ZRTP calls that the organiser
of the conference has established with the two other participants.

(their screen

shows the red lock open between them) or are their streams being relayed
through the host (A) and therefore "piggy backing" on those established
ZRTP encrypted streams?

Sorry if my question sounds confusing but since I know multi-party ZRTP
(like mpOTR) is still not really a reality yet, I'm trying to figure out
how jitsi deals with this.

Well ... that's not entirely accurate (see my note above). ZRTP also
provides a trusted MitM mode which allows you to use it even with entities
such as Jitsi Videobridge. It's a bit (or in some cases even exactly) like
using SSL certs.

Hope this helps,
Emil

Thanks,

Peter

On Thu, Mar 27, 2014 at 10:34 PM, Emil Ivov <emcho@jitsi.org >> <mailto:emcho@jitsi.org>> wrote:

    Hey Micah,

    On 27.03.14, 21:33, Micah Lee wrote:

        I've got a couple of questions. I'm seeing if Jitsi will work
        for remote
        meetings.

    You may also want to try JitMeet: https://meet.jit.si

           * I've tested both a conference call and a video bridge.
        What's the
             difference?

    One is hosted on your computer, the other on a server.

        It appears that video bridges don't support ZRTP

    No. They support DTLS/SRTP though.

        but
             conference calls maybe do, and they both seem to work when
        I toggle
             video on.
           * When doing either a conference call or video bridge on a
jabber

             server that uses SSL, are the video/audio streams themselves
             encrypted using SSL too?

    No. SSL is only for signalling. Media is securely transported by SRTP.

        So in the worst case, there's at least
             transport encryption the entire time?
           * Do video bridges or conference calls support any sort of
        end-to-end

             encryption, so that the server can't spy on the call at all?

    No and ... I am going to go out on a limb here and state that this
    is not really possible. Solutions like SRTP EKT [0] allow servers to
    operate without decrypting media but there's nothing that can
    prevent them from doing so if they choose to.

    So, if you are looking for real security: run your own conference
    server.

    Emil

    [0] SRTP EKT - http://tools.ietf.org/html/__draft-ietf-avt-srtp-ekt
    <http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt>

        Thanks!

        _________________________________________________
        dev mailing list
        dev@jitsi.org <mailto:dev@jitsi.org>

        Unsubscribe instructions and other list options:
        http://lists.jitsi.org/__mailman/listinfo/dev

        <http://lists.jitsi.org/mailman/listinfo/dev>

    --
    https://jitsi.org

    _________________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>

    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/__mailman/listinfo/dev
    <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

--
https://jitsi.org

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