So your TLS issue is the stone-old version you're using. You actually still
use SIP-Communicator, the last build before we renamed to Jitsi (from March
2011). Please download the current stable version of Jitsi (December 2011)
or a nightly (from last Wednesday).
We had an issue back then when there was _no_ NAT or Firewall in place...
I don't understand Ingo, I downloaded the .deb from jitsi site, and
as there's no real doc/howto on the site (or may be there are, but
*nothing* really points where), I thought it was loading the very
ii jitsi 1.0-beta1-nightly.build.3820
ii sip-communicator 1.0-beta1-nightly.build.3364
ii sip-communicator-keyring-udeb 2008.06.23.1
So, what is the URL to download the latest version?
> Yep, that's what I used for testing - but I'll see with FS ML when
> tests will be achieved if there's a way to use a much secure crypto
> than AES.
If you really care about security, then SRTP is probably not your best
option anyway as the server sits on the line an can intercept the encryption
keys for the media data. ZRTP on the other hand is an end-to-end encryption.
After reading papers about VoIP security, that was also my conclusion;
there are much more "entry points" into tls+srtp than in ZRTP.
But I'm quite stubborn and I don't like when something resist me;
I also work for the time to come as I'll recreate a small business by
the end of this year, and tls+srtp will for sure be asked by
> BTW I also tested (in SIP) the ZRTP function - I wasn't able to
> download the ZRTP last version because their download site is down,
> and I don't know if it is really needed for jitsi or not?
You don't need to download anything for ZRTP, it's all built-in.
This is good to hear as I wasn't 100% sure:)
BTW, I noticed something strange (well, strange for me, because one
is java & the other C++): since I installed sip-communicator, twinkle
also benefits from ZRTP!
> It seems that there's no encryption until both end points have
> clicked on their padlocks, but they still have each a check drawn
> since the first try - I'm not really sure about that, but wireshark
> shows that after both SAS acceptances the protocol flipped from RTP
> to SRTP.
> What is the truth in all this?
The ZRTP encryption is active as soon as the padlock near the Call-State
("Connecting...", "Connected") is closed. The larger padlock above is for
the comparison of the SAS. If you have verified the SAS on both sides of the
call, you should click on the padlock to inform Jitsi about this fact.
Afterwards, for further calls, the upper padlock will be locked from the
beginning of the call as long as nobody tampers your connection.
Arf, I didn't noticed there was a 2nd padlock into the "connecting"
Wireshark on the other hand is not really capable of distinguishing RTP
between SRTP. All it does is a best guess if it sees ZRTP packages or has
seen the SDP from an INVITE that announced secure streams.
ah, I though I could trust it; may be in the next version.
Anyway, your program is one of the best I tested; usually I hate
java (bloated and slow), but this one's really well done.
The best point is about ergonomy: even unskilled people can't say
they don't understand it:)
On Sat, 17 Mar 2012 13:24:55 +0100 "Ingo Bauersachs" <email@example.com> wrote:
I have just enough white in me to make my honesty questionable.
-- Will Rogers