[jitsi-users] Desktop sharing and ZRTP encryption


#1

Hi,

I've stumbled upon some issues and lacking documentation for a specific
use case of mine.

Using two google accounts, both running jitsi 2.8.5426-1 on debian.
(the one from deb http://download.jitsi.org/deb unstable/)

When placing audio calls both ends can reach each other fine,
ZRTP is working as expected.

But when activating desktop sharing the video stream is initiated but
a message is shown that it is not encrypted.
This also happens when starting directly with desktop sharing enabled.

My questions:
* How can I fix the not encrypted video (other accounts, settings?)
* How is the data stream for remote control protected?

I've already searched for some instructions but was unable to find
anything related to this, hence I'm trying here.

best
Armin


#2

Hi,

I've stumbled upon some issues and lacking documentation for a specific
use case of mine.

Using two google accounts, both running jitsi 2.8.5426-1 on debian.
(the one from deb http://download.jitsi.org/deb unstable/)

When placing audio calls both ends can reach each other fine,
ZRTP is working as expected.

But when activating desktop sharing the video stream is initiated but
a message is shown that it is not encrypted.
This also happens when starting directly with desktop sharing enabled.

My questions:
  * How can I fix the not encrypted video (other accounts, settings?)

This is probably a UI bug[0]. Check the "call info" for a more reliable indication.

  * How is the data stream for remote control protected?

It goes over XMPP.

Regards,
Boris

[0] http://lists.jitsi.org/pipermail/users/2013-June/004286.html

···

On 27/01/16 01:29, Armin Novak wrote:


#3

Thank you for the information,
I've tried your suggestion.
(now also tried with 2 real jabber servers, same result as gmail)

Sadly the call information shows the same as the GUI,
the video is not encrypted.
This is true for video calls as well as desktop sharing.

As for my second question, I have to rephrase,
what I'm interested in is how the desktop sharing back channel (the one
sending keyboard / mouse)
is encrypted.

If that is only XMPP (which is server to server if I am not mistaken) it
would have to be considered insecure.

best
Armin

For reference, here the call information (sensitive data wiped):
Identity : xxxx@jabber (Jabber)
Signalling call transport : TLS
TLS protocol : TLSv1.2
TLS cipher suite : TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
View certificate xxx@jabber/jitsi :
Call duration : 00:03:07

Audio info :
Media stream transport protocol : UDP / SRTP (Key exchange protocol:
ZRTP AES-CM-128/DH3K)
Codec / Frequency : opus / 48000 Hz
ICE candidate extended type : host
Local host IP / Port : xxxxx/port
Remote host IP / Port : xxxxx/port
Bandwith : ↓ 9 Kbps ↑ 32 Kbps
Loss rate : ↓ 0% ↑ 0%
Packets decoded with FEC : 0
Packets currently being discarded : 0%
Number of discarded packets : 2 (0 late, 2 full, 0 shrink, 0 reset)
Adaptive jitter buffer : enabled
Jitter buffer : ~40ms;currently in queue: 0/4 packets
Jitter : ↓ 2 ms ↑ 0 ms

Video info :
Media stream transport protocol : UDP / RTP
Video size : ↓ 1920 x 1080 ↑ 3840 x 2160
Codec / Frequency : H264 / 90000 Hz
ICE candidate extended type : host
Local host IP / Port : xxxxx/port
Remote host IP / Port : xxxxx/port
Bandwith : ↓ 27 Kbps ↑ 0 Kbps
Loss rate : ↓ 0% ↑ 0%
Packets decoded with FEC : 0
Packets currently being discarded : 0%
Number of discarded packets : 0 (0 late, 0 full, 0 shrink, 0 reset)
Adaptive jitter buffer : enabled
Jitter buffer : ~360ms; currently in queue: 0/36 packets
Jitter : ↓ 2 ms ↑ 0 ms
Total harvesting time : 1674 ms (for 6 harvests)
Harvesting time JingleNodesHarvester : 1 ms (for 1 harvests)
Harvesting time StunCandidateHarvester : 169 ms (for 4 harvests)
Harvesting time UPNPHarvester : 1504 ms (for 1 harvests)

It clearly states that the video is unencrypted.

···

On 01/27/2016 04:06 PM, Boris Grozev wrote:

On 27/01/16 01:29, Armin Novak wrote:

Hi,

I've stumbled upon some issues and lacking documentation for a specific
use case of mine.

Using two google accounts, both running jitsi 2.8.5426-1 on debian.
(the one from deb http://download.jitsi.org/deb unstable/)

When placing audio calls both ends can reach each other fine,
ZRTP is working as expected.

But when activating desktop sharing the video stream is initiated but
a message is shown that it is not encrypted.
This also happens when starting directly with desktop sharing enabled.

My questions:
  * How can I fix the not encrypted video (other accounts, settings?)

This is probably a UI bug[0]. Check the "call info" for a more
reliable indication.

  * How is the data stream for remote control protected?

It goes over XMPP.

Regards,
Boris

[0] http://lists.jitsi.org/pipermail/users/2013-June/004286.html

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