[jitsi-users] Fwd: "Call not secure" (02)


#1

I'd like to rephrase my question in order to narrow down on this
issue.

Here it is:

_quote_
Is there anything in the configuration of
Jitsi that must absolutely be done at both ends (caller and receiver) so
that a call will be secure?
_unquote_

If I know that, I wll make sure
that Jitsi is thusly configured; and if the problem persists we can be
reasonably certain that the reasons must lie elsewhere

Thanks in
advance !

-------- Originalnachricht --------

···

Betreff: Re:
[jitsi-users] "Call not secure"
Datum: 22.08.2013 20:12
Von:
haldenwang@posteo.de
An: <users@jitsi.org>

Alright then.

Attached find
the log covering the last call with "call not secure" message. It is
rather verbose, I'm afraid :slight_smile:

M.H.

Am 22.08.2013 19:34 schrieb Yannik Völker:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am

22.08.2013 17:16, schrieb haldenwang@posteo.de:

Sorry for the

confusion.

But then I don't understand the question - both parties

are

obviously using Jitsi as a client and no 3rd party SW involved

Exactly that is not obvious, thanks for the clarification.

So what

can I do in order to make these calls secure? Anything I

need to

change in the configuration?

If you changed something change it back,

otherwise please send your logs.

- --
Yannik Völker
-----BEGIN

PGP SIGNATURE-----

Version: GnuPG v2.0.21 (GNU/Linux)

iQIcBAEBAgAGBQJSFkuYAAoJEDqk81AiCyXKosIP/A0AChdCg5IUN1TwsT988NBO

na229G66kgFad5EKSW4WPWblUx2NcrnUtYvB+BZyLDXQo6ZqHnvJ1FafMM6CsNoE

akK5fUkwkGPgvIwdvQSyR7JIxCzdkMai53TiijPhRFa+FMPnBq/15Nxw8KJsTcl/

4YByn5n1qqUsvwTU/aqeM6MXB2wSs1PwDDqPOVSphZlJDBdt9Reivilwq+E9n1my

A4HPfmcHJPrOusGQEdSCzf0v0D0eqflzsPGISj4DI0Sic2xpM3R3uq3uBXLM0/3H

q/J2huwBUOVhesmxX7YyAuL7zzOJU+F4d6vBbLtpLHRBfcNAanEIzHpJEJAIc6U8

9L6RlM5MJs342np2ILm4OFOzfr6SqZPTJDddISgEIy7FDF/bZo/k7e1tFoyGrG8o

dDNh1j340+N/ct65AtJ/ykk226nn0ydALUCuB4kP5nCdFThPAWPPzAhOyYrYKUji

8ZR5iAA9YsAij+041wnGUS0abe257c7FkR+xbrKsBM8IbR2B9Ytixy6HuzcSo5GK

/EliOCy8qcv49T9WLim09mTWPx36DNnHVBBcEGw1Z+8yHDS5bYn5gSb1z0clgkZ7

Anyf0CquDVbG6ReyYKq8tdAsykyz480LIU/gndOEFkiEBRw++HCHOhHk3AbyZQdr

YW16xWlE1SYAbdhwKgWD

=o/hY
-----END PGP SIGNATURE-----

_______________________________________________

users mailing list

users@jitsi.org

Unsubscribe instructions and other list options:

http://lists.jitsi.org/mailman/listinfo/users


#2

I'd like to rephrase my question in order to narrow down on this issue.

Here it is:

quote Is there anything in the configuration of Jitsi that must
absolutely be done at both ends (caller and receiver) so that a call
will be secure? unquote

No. By default ZRTP is enabled as an encryption protocol both for SIP and XMPP. If ZRTP negotiation doesn't succeed, then it is likely that a normal audio-connection also doesn't work as the media transport between the two clients cannot be established.
If a call between two ZRTP capable clients stays unencrypted AND you hear each other, the only thing that comes to mind is a "rogue" server in between the two clients that blocks ZRTP packets (e.g. for SIP an Asterisk server that does codec translation).

If I know that, I wll make sure that Jitsi is thusly configured; and if
the problem persists we can be reasonably certain that the reasons must
lie elsewhere

Thanks in advance !

Ingo


#3

I'd like to rephrase my question in order to narrow down on this issue.

Here it is:

/quote/
Is there anything in the configuration of Jitsi that must absolutely be done at both ends (caller and receiver) so that a call will be secure?
/unquote/

With Jitsi on both sides, it (ZRTP) should work out-of-the-box.

If I know that, I wll make sure that Jitsi is thusly configured; and if the problem persists we can be reasonably certain that the reasons must lie elsewhere

The logs you sent[1] contain some exceptions from WASAPI. I think that
the first one[2] might have prevented ZRTP from working.

You should try the Jitsi nightly builds -- they contain multiple fixes
for WASAPI.

Regards,
Boris

[1] http://lists.jitsi.org/pipermail/users/2013-August/005017.html

[2]
13:23:42.347 WARNING: [14]
org.jitsi.impl.neomedia.ZrtpFortunaEntropyGatherer.warn() Got an IO
Exception during entropy preparation
java.io.IOException
  at
org.jitsi.impl.neomedia.jmfext.media.protocol.wasapi.WASAPIStream.connect(WASAPIStream.java:288)
  at
org.jitsi.impl.neomedia.jmfext.media.protocol.wasapi.WASAPIStream.setLocator(WASAPIStream.java:596)
  at
org.jitsi.impl.neomedia.jmfext.media.protocol.wasapi.DataSource.doConnect(DataSource.java:76)
  at
org.jitsi.impl.neomedia.jmfext.media.protocol.AbstractPullBufferCaptureDevice$1.doConnect(AbstractPullBufferCaptureDevice.java:60)
  at
org.jitsi.impl.neomedia.jmfext.media.protocol.AbstractBufferCaptureDevice.connect(AbstractBufferCaptureDevice.java:110)
  at
org.jitsi.impl.neomedia.jmfext.media.protocol.AbstractPullBufferCaptureDevice.connect(AbstractPullBufferCaptureDevice.java:142)
  at javax.media.Manager.createDataSource(Manager.java:384)
  at
org.jitsi.impl.neomedia.ZrtpFortunaEntropyGatherer$GatherAudio.prepareAudioEntropy(ZrtpFortunaEntropyGatherer.java:176)
  at
org.jitsi.impl.neomedia.ZrtpFortunaEntropyGatherer$GatherAudio.access$100(ZrtpFortunaEntropyGatherer.java:130)
  at
org.jitsi.impl.neomedia.ZrtpFortunaEntropyGatherer.setEntropy(ZrtpFortunaEntropyGatherer.java:124)
  at
org.jitsi.impl.neomedia.MediaServiceImpl.postInitializeOnce(MediaServiceImpl.java:1488)
  at
org.jitsi.impl.neomedia.MediaServiceImpl.<init>(MediaServiceImpl.java:242)

···

On 8/23/13 7:42 PM, haldenwang@posteo.de wrote: