[jitsi-users] tls & srtp problem


#1

Hi list,

I use the jitsi .deb packages under sid & squeeze w/ a freeswitch
server. I'm far from being a VoIP specialist, though.

I have a problem when calling in TLS mode (certificate is accepted &
both jitsi are correctly registered): when I try to make a call
nothing happens on the receiver's side and after the FS programmed
delay I fall back to the VM.

Both jitsi have this in their logs:
19:40:56.161 GRAVE: impl.protocol.sip.SipLogger.logError().154 Error from the JAIN-SIP stack: Problem Accepting Connection
java.io.IOException: no cipher suites in common
  at gov.nist.javax.sip.stack.TLSMessageChannel.<init>(TLSMessageChannel.java:175)
  at gov.nist.javax.sip.stack.TLSMessageProcessor.run(TLSMessageProcessor.java:187)
  at java.lang.Thread.run(Thread.java:636)

May be the given server name could be involved: it is referred as a
name that is a CNAME of the real machine, and certificate is
established to the WAN name of the server (which is internally
looped to the real server name by my DNS).
That would not be good, as some people will have to connect from
abroad to the server.

Jitsi is working right w/ SIP.

Jean-Yves

···

--


#2

Hey

I have a problem when calling in TLS mode (certificate is accepted &
both jitsi are correctly registered): when I try to make a call
nothing happens on the receiver's side and after the FS programmed
delay I fall back to the VM.

Both jitsi have this in their logs: 19:40:56.161 GRAVE:
impl.protocol.sip.SipLogger.logError().154 Error from the JAIN-SIP
stack: Problem Accepting Connection java.io.IOException: no cipher
suites in common at
gov.nist.javax.sip.stack.TLSMessageChannel.<init>(TLSMessageChannel.java:
175) at
gov.nist.javax.sip.stack.TLSMessageProcessor.run(TLSMessageProcessor.java
:187 ) at java.lang.Thread.run(Thread.java:636)

That stacktrace leads me to believe that it's actually an issue in the TLS
cipher negotiation: FS (FreeSwitch?) apparently expects a cipher that Jitsi
doesn't announce. Jitsi currently supports Java's default list of ciphers,
which on JRE6/Windows 7 is:
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV

RFC3261 mandates the availability of TLS_RSA_WITH_AES_128_CBC_SHA on SIP
servers, which is among the above list.

Could you therefore please ensure that your server supports one of those
ciphers and that your Java security configuration is not modified from its
default? If you have verified these two points and the issue still persists,
could you please attach a Wireshark trace when the client tries to connect
to the server?

May be the given server name could be involved: it is referred as a
name that is a CNAME of the real machine, and certificate is
established to the WAN name of the server (which is internally
looped to the real server name by my DNS).

So just that I get you correct here:
Internal: CNAME sip.mydomain.com -> A my.host.int -> 192.168.1.1
External: CNAME sip.mydomain.com -> A myhost.mydomain.com -> 123.123.123.123

And now the cert is issued to sip.mydomain.com?

Whether a certificate is accepted as valid for domain depends on two
conditions:
a) If you use proxy auto-detection, the certificate must contain the domain
of your SIP account (e.g. if the SIP user is alice@sip.domain.com then the
certificate must contain sip.domain.com)
b) If you use a manually configured proxy, then the certificate can either
be issued to the name of the proxy you entered OR to the domain of the SIP
account (as in a).

That would not be good, as some people will have to connect from
abroad to the server.

If the issue were a certificate problem, you'd see a warning dialog that the
certificate is invalid. But to get this far, the client and server have to
negotiate a common cipher first.

Jitsi is working right w/ SIP.

Jean-Yves

Regards,
Ingo


#3

Hi Ingo,

That stacktrace leads me to believe that it's actually an issue in the TLS
cipher negotiation: FS (FreeSwitch?) apparently expects a cipher that Jitsi
doesn't announce. Jitsi currently supports Java's default list of ciphers,
which on JRE6/Windows 7 is:
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV

RFC3261 mandates the availability of TLS_RSA_WITH_AES_128_CBC_SHA on SIP
servers, which is among the above list.

This is what I found in freeswitch logs:
AES_CM_128_HMAC_SHA1_32|AES_CM_128_HMAC_SHA1_80

Which BTW I don't like very much, I'd prefer to use Twofish which
is proposed in jitsi list, but I don't know if it is handled by
openssl nor how to change it into freeswitch.

Could you therefore please ensure that your server supports one of those
ciphers and that your Java security configuration is not modified from its
default? If you have verified these two points and the issue still persists,
could you please attach a Wireshark trace when the client tries to connect
to the server?

You tell me, I'm not tough enough w/ crypto to know if it right or
not.

> May be the given server name could be involved: it is referred as a
> name that is a CNAME of the real machine, and certificate is
> established to the WAN name of the server (which is internally
> looped to the real server name by my DNS).

So just that I get you correct here:
Internal: CNAME sip.mydomain.com -> A my.host.int -> 192.168.1.1
External: CNAME sip.mydomain.com -> A myhost.mydomain.com -> 123.123.123.123

Hmm, not exactly:
fs.intra IN CNAME machine1.intra
mywanname.org IN CNAME machine1.intra

Well, it's a bit more complicated for the WAN domain name as I
have my own DNS authoritative zone that makes mywanname.org ==
192.168.1.25

And now the cert is issued to sip.mydomain.com?

To mywanname.org

Whether a certificate is accepted as valid for domain depends on two
conditions:
a) If you use proxy auto-detection, the certificate must contain the domain
of your SIP account (e.g. if the SIP user is alice@sip.domain.com then the
certificate must contain sip.domain.com)
b) If you use a manually configured proxy, then the certificate can either
be issued to the name of the proxy you entered OR to the domain of the SIP
account (as in a).

I use a manually configured proxy.

> That would not be good, as some people will have to connect from
> abroad to the server.

If the issue were a certificate problem, you'd see a warning dialog that the
certificate is invalid. But to get this far, the client and server have to
negotiate a common cipher first.

ok.

This is my last attempt; I launch the call, waited enough
for a standard SIP call to ring ~2 times and terminated it.

log for emitter of the call:

02:05:07.246 GRAVE: impl.protocol.sip.SipLogger.logError().154 Error from the JAIN-SIP stack: Problem Accepting Connection
java.io.IOException: no cipher suites in common
  at gov.nist.javax.sip.stack.TLSMessageChannel.<init>(TLSMessageChannel.java:175)
  at gov.nist.javax.sip.stack.TLSMessageProcessor.run(TLSMessageProcessor.java:187)
  at java.lang.Thread.run(Thread.java:636)
02:05:16.314 ATTENTION: impl.protocol.sip.SipApplicationData.getApplicationData().96 container is null
02:05:16.333 GRAVE: impl.protocol.sip.SipStackSharing.findTargetFor().829 no listeners
02:05:16.349 ATTENTION: impl.protocol.sip.SipApplicationData.getApplicationData().96 container is null
02:05:16.362 GRAVE: impl.protocol.sip.SipStackSharing.processRequest().617 couldn't find a ProtocolProviderServiceSipImpl to dispatch to
02:05:16.366 GRAVE: impl.protocol.sip.SipStackSharing.findTargetFor().829 no listeners
02:05:16.382 GRAVE: impl.protocol.sip.SipStackSharing.processRequest().617 couldn't find a ProtocolProviderServiceSipImpl to dispatch to

I also attached the WS capture.

Jean-Yves

WS_CALL_ATTEMPT_LOG.log (70.5 KB)

···

On Sat, 17 Mar 2012 01:27:53 +0100 "Ingo Bauersachs" <ingo@jitsi.org> wrote:
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


#4

Hey

That stacktrace leads me to believe that it's actually an issue in the

TLS

cipher negotiation: FS (FreeSwitch?) apparently expects a cipher that

Jitsi

doesn't announce. Jitsi currently supports Java's default list of

ciphers,

which on JRE6/Windows 7 is:
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV

RFC3261 mandates the availability of TLS_RSA_WITH_AES_128_CBC_SHA on SIP
servers, which is among the above list.

This is what I found in freeswitch logs:
AES_CM_128_HMAC_SHA1_32|AES_CM_128_HMAC_SHA1_80

Those are the SRTP ciphers, not the TLS ciphers.

Which BTW I don't like very much, I'd prefer to use Twofish which
is proposed in jitsi list, but I don't know if it is handled by
openssl nor how to change it into freeswitch.

Could you therefore please ensure that your server supports one of
those ciphers and that your Java security configuration is not modified
from its default? If you have verified these two points and the issue
still persists, could you please attach a Wireshark trace when the
client tries to connect to the server?

You tell me, I'm not tough enough w/ crypto to know if it right or not.

I have absolutely no idea about FreeSwitch, so I can't tell where to look
there. The Java part is probably okay, but maybe this wiki-entry from
FreeSwitch is related:
http://wiki.freeswitch.org/wiki/SIP_TLS#TLS_Negotiation_Error_.27No_matching
_cipher.27

May be the given server name could be involved: it is referred as a
name that is a CNAME of the real machine, and certificate is
established to the WAN name of the server (which is internally
looped to the real server name by my DNS).

So just that I get you correct here:
Internal: CNAME sip.mydomain.com -> A my.host.int -> 192.168.1.1
External: CNAME sip.mydomain.com -> A myhost.mydomain.com ->

123.123.123.123

Hmm, not exactly:
fs.intra IN CNAME machine1.intra
mywanname.org IN CNAME machine1.intra

Well, it's a bit more complicated for the WAN domain name as I have my
own DNS authoritative zone that makes mywanname.org == 192.168.1.25

Okay, so just split DNS. That should not be a problem.

And now the cert is issued to sip.mydomain.com?

To mywanname.org

Whether a certificate is accepted as valid for domain depends on two
conditions:
a) If you use proxy auto-detection, the certificate must contain the

domain

of your SIP account (e.g. if the SIP user is alice@sip.domain.com then

the

certificate must contain sip.domain.com)
b) If you use a manually configured proxy, then the certificate can

either

be issued to the name of the proxy you entered OR to the domain of the

SIP

account (as in a).

I use a manually configured proxy.

That would not be good, as some people will have to connect from
abroad to the server.

If the issue were a certificate problem, you'd see a warning dialog
that the certificate is invalid. But to get this far, the client and
server have to negotiate a common cipher first.

ok.

This is my last attempt; I launch the call, waited enough
for a standard SIP call to ring ~2 times and terminated it.

log for emitter of the call:

02:05:07.246 GRAVE: impl.protocol.sip.SipLogger.logError().154 Error
from the JAIN-SIP stack: Problem Accepting Connection
java.io.IOException: no cipher suites in common at
gov.nist.javax.sip.stack.TLSMessageChannel.<init>(TLSMessageChannel.java:
175) at
gov.nist.javax.sip.stack.TLSMessageProcessor.run(TLSMessageProcessor.java
:187 ) at java.lang.Thread.run(Thread.java:636) 02:05:16.314

ATTENTION:

impl.protocol.sip.SipApplicationData.getApplicationData().96 container
is null 02:05:16.333 GRAVE:
impl.protocol.sip.SipStackSharing.findTargetFor().829 no listeners
02:05:16.349 ATTENTION:
impl.protocol.sip.SipApplicationData.getApplicationData().96 container
is null 02:05:16.362 GRAVE:
impl.protocol.sip.SipStackSharing.processRequest().617 couldn't find a
ProtocolProviderServiceSipImpl to dispatch to 02:05:16.366 GRAVE:
impl.protocol.sip.SipStackSharing.findTargetFor().829 no listeners
02:05:16.382 GRAVE:
impl.protocol.sip.SipStackSharing.processRequest().617 couldn't find a
ProtocolProviderServiceSipImpl to dispatch to

I also attached the WS capture.

I couldn't find any beginning of a TLS session in your trace. Please ensure
that you start the capture _before_ you start Jitsi. Could you please also
attach the whole log files from Jitsi (including the pcap-traces) as per
http://jitsi.org/index.php/Documentation/FAQ#logs.
You may also send the logs directly to me if you don't want them to appear
on the mailing list.

Jean-Yves

Regards,
Ingo


#5

Hey Ho, Hey Ho :wink:

> This is what I found in freeswitch logs:
> AES_CM_128_HMAC_SHA1_32|AES_CM_128_HMAC_SHA1_80

Those are the SRTP ciphers, not the TLS ciphers.

Ah, ok.

>
> You tell me, I'm not tough enough w/ crypto to know if it right or not.

I have absolutely no idea about FreeSwitch, so I can't tell where to look
there. The Java part is probably okay, but maybe this wiki-entry from
FreeSwitch is related:
http://wiki.freeswitch.org/wiki/SIP_TLS#TLS_Negotiation_Error_.27No_matching
_cipher.27

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.

I couldn't find any beginning of a TLS session in your trace. Please ensure
that you start the capture _before_ you start Jitsi. Could you please also
attach the whole log files from Jitsi (including the pcap-traces) as per
http://jitsi.org/index.php/Documentation/FAQ#logs.
You may also send the logs directly to me if you don't want them to appear
on the mailing list.

Yes, I prefer.

I'm gonna do what you ask and send you directly the wanted logs.

Cheers,
Jean-Yves

···

On Sat, 17 Mar 2012 02:59:53 +0100 "Ingo Bauersachs" <ingo@jitsi.org> wrote:
--
reintarnation:
  Coming back to life as a hillbilly.


#6

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...
:slight_smile:

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.

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.

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.

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.

Regards,
Ingo


#7

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...
:slight_smile:

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
last version:
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
customers.

> 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"
area.

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:)

regards,

Jean-Yves

···

On Sat, 17 Mar 2012 13:24:55 +0100 "Ingo Bauersachs" <ingo@jitsi.org> wrote:
--
I have just enough white in me to make my honesty questionable.
    -- Will Rogers


#8

I found it; just a question: is it safe to choose the nightly
build, or is there chances that is breaks randomly without notice?

JY

···

On Sat, 17 Mar 2012 13:24:55 +0100 "Ingo Bauersachs" <ingo@jitsi.org> wrote:

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).

--
Pick another fortune cookie.


#9

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).

I found it; just a question: is it safe to choose the nightly
build, or is there chances that is breaks randomly without notice?

The nightlies are actually are created after commits, so there may appear
multiple builds per day. Generally, they work very well, but it's of course
possible that something breaks. If you want to be on the safe side, stick
with the stable build-line.

JY

Ingo


#10

Sorry to be late; I finally installed the nightlies (build 3952),
and it is working good.

An exception though: a call between 2 machines, using TSL+ZRTP raises
the CPU use tremendously:
on an Athlon-XP1600 (1900MHz) => ~70%,
on a Celeron 2.0GHz => 100%

I'm gonna retry w/ the stable package to see if these values are
also reached.

JY

···

On Mon, 19 Mar 2012 09:20:43 +0100 "Ingo Bauersachs" <ingo@jitsi.org> wrote:

The nightlies are actually are created after commits, so there may appear
multiple builds per day. Generally, they work very well, but it's of course
possible that something breaks. If you want to be on the safe side, stick
with the stable build-line.

--