[sip-comm-dev] Security disabled by default?


#1

Hi Werner,

I've performed a few no-registrar tests (which now works pretty fine!) between a macosx an linux client with build 1683, and I noticed that security was not enabled (see the enclosed picture). I guess it's not the expected behaviour right? Let me know if you need additional information.

Cheers,
romain


#2

Hi Romain,

The SIP accounts have an option "Enable support to encrypt calls" on
the Advanced tab which is off by default. After it's checked on (for
both ends of the call), the security should kick in fine.

Best regards,
Lubo

···

On Mon, Feb 16, 2009 at 12:17 PM, Romain KUNTZ <kuntz@lsiit.u-strasbg.fr> wrote:

Hi Werner,

I've performed a few no-registrar tests (which now works pretty fine!)
between a macosx an linux client with build 1683, and I noticed that
security was not enabled (see the enclosed picture). I guess it's not the
expected behaviour right? Let me know if you need additional information.

Cheers,
romain

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Lubo,

Yes indeed :slight_smile: Now I've got the security enabled for the audio.
However it's not enabled for the video, is this expected?

Thanks,
romain

···

On 2009/02/16, at 11:21, Lubomir Marinov wrote:

Hi Romain,

The SIP accounts have an option "Enable support to encrypt calls" on
the Advanced tab which is off by default. After it's checked on (for
both ends of the call), the security should kick in fine.

Best regards,
Lubo

On Mon, Feb 16, 2009 at 12:17 PM, Romain KUNTZ <kuntz@lsiit.u-strasbg.fr > > wrote:

Hi Werner,

I've performed a few no-registrar tests (which now works pretty fine!)
between a macosx an linux client with build 1683, and I noticed that
security was not enabled (see the enclosed picture). I guess it's not the
expected behaviour right? Let me know if you need additional information.

Cheers,
romain


#4

Romain,

some problems here:

1st: security should be enabled by default. I implemented this
     a time agoe. Somhow this disappeared and I need to check
     where and why and re-do it.

2nd: Just recently we had a big change in the handling of security
     events and the related GUI. I found a small problem in the
     SecurityManager class and fixed it. I don't have the hardware
     to test video - can you do me a favour and check it. As far as
     I understood video worked in secure mode at FOSDEM - thus
     it must be something changed during the last days :slight_smile:

Regards,
Werner

Romain KUNTZ schrieb:

···

Hi Lubo,

Yes indeed :slight_smile: Now I've got the security enabled for the audio.
However it's not enabled for the video, is this expected?

Thanks,
romain

On 2009/02/16, at 11:21, Lubomir Marinov wrote:

Hi Romain,

The SIP accounts have an option "Enable support to encrypt calls" on
the Advanced tab which is off by default. After it's checked on (for
both ends of the call), the security should kick in fine.

Best regards,
Lubo

On Mon, Feb 16, 2009 at 12:17 PM, Romain KUNTZ >> <kuntz@lsiit.u-strasbg.fr> wrote:

Hi Werner,

I've performed a few no-registrar tests (which now works pretty fine!)
between a macosx an linux client with build 1683, and I noticed that
security was not enabled (see the enclosed picture). I guess it's not
the
expected behaviour right? Let me know if you need additional
information.

Cheers,
romain

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi Werner,

1st: security should be enabled by default. I implemented this
    a time agoe. Somhow this disappeared and I need to check
    where and why and re-do it.

Actually it is enabled by default on newly created accounts.
Mine were created long time ago, when the security checkbox did not exist yet, this is why I had to enable it by myself.

2nd: Just recently we had a big change in the handling of security
    events and the related GUI. I found a small problem in the
    SecurityManager class and fixed it. I don't have the hardware
    to test video - can you do me a favour and check it. As far as
    I understood video worked in secure mode at FOSDEM - thus
    it must be something changed during the last days :slight_smile:

Sure, I'll give a try tomorrow morning on the latest builds.

Cheers,
romain

···

On 2009/02/16, at 18:38, Werner Dittmann wrote:

Romain KUNTZ schrieb:

Hi Lubo,

Yes indeed :slight_smile: Now I've got the security enabled for the audio.
However it's not enabled for the video, is this expected?

Thanks,
romain

On 2009/02/16, at 11:21, Lubomir Marinov wrote:

Hi Romain,

The SIP accounts have an option "Enable support to encrypt calls" on
the Advanced tab which is off by default. After it's checked on (for
both ends of the call), the security should kick in fine.

Best regards,
Lubo

On Mon, Feb 16, 2009 at 12:17 PM, Romain KUNTZ >>> <kuntz@lsiit.u-strasbg.fr> wrote:

Hi Werner,

I've performed a few no-registrar tests (which now works pretty fine!)
between a macosx an linux client with build 1683, and I noticed that
security was not enabled (see the enclosed picture). I guess it's not
the
expected behaviour right? Let me know if you need additional
information.

Cheers,
romain

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Werner Dittmann schrieb:

Romain,

some problems here:

1st: security should be enabled by default. I implemented this
     a time agoe. Somhow this disappeared and I need to check
     where and why and re-do it.

I've checked the code and in *.plugin.sipaccregwiz the checkbox
shall be "checked" be default:

    private JCheckBox enableDefaultEncryption =
        new SIPCommCheckBox(Resources
            .getString("plugin.sipaccregwizz.ENABLE_DEFAULT_ENCRYPTION"), true);

thus a new account shall have encryption enabled by default.

When loading saved account properties in method loadAccount(...):

        boolean enabledDefaultEncryption = accountID.getAccountPropertyBoolean(
                            ProtocolProviderFactory.DEFAULT_ENCRYPTION, false);

thus an existing account may have encryption disabled, depending on its previous
saved state. If the account never had this property stored then it's not set
by default. Maybe we shall set this to "true" also to be compliant with account
creation?

Romain, can you check this if necessary? Thanks.

Regards,
Werner

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Romain,

if you test it can you please switch on logging (INFO) for
the *.transformer.zrtp level a provide the log output? I just
want to check to sequence of the information calls. Thanks.

Regards,
Werner

Romain KUNTZ schrieb:

···

Hi Werner,

2nd: Just recently we had a big change in the handling of security
    events and the related GUI. I found a small problem in the
    SecurityManager class and fixed it. I don't have the hardware
    to test video - can you do me a favour and check it. As far as
    I understood video worked in secure mode at FOSDEM - thus
    it must be something changed during the last days :slight_smile:

Sure, I'll give a try tomorrow morning on the latest builds.

Cheers,
romain

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hi Werner,

···

On 2009/02/16, at 19:07, Werner Dittmann wrote:

If the account never had this property stored then it's not set
by default. Maybe we shall set this to "true" also to be compliant with account
creation?

Yes, this should IMHO be the default behaviour.

Cheers,
romain

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Hi all,

···

On Mon, Feb 16, 2009 at 6:53 PM, Romain KUNTZ <kuntz@lsiit.u-strasbg.fr> wrote:

On 2009/02/16, at 18:38, Werner Dittmann wrote:

1st: security should be enabled by default. I implemented this
   a time agoe. Somhow this disappeared and I need to check
   where and why and re-do it.

Actually it is enabled by default on newly created accounts.
Mine were created long time ago, when the security checkbox did not exist
yet, this is why I had to enable it by myself.

I've just created a registrarless SIP account with the first start
wizard from current SVN and "enable support to encrypt calls" is
unticked by default in the account properties.

--
Sébastien Mazy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Hi Werner,

sip-communicator0.log.0 (120 KB)

···

On 2009/02/16, at 20:32, Werner Dittmann wrote:

if you test it can you please switch on logging (INFO) for
the *.transformer.zrtp level a provide the log output? I just
want to check to sequence of the information calls. Thanks.

Security for the video is still disabled on the latest builds.
Enclosed you will find the logs for a p2p call.

Thanks,
romain


#11

Hi guys,

I've just changed that (revision 5024). The encryption is now set to true if there's no stored value.

Regards,
Yana

Romain KUNTZ wrote:

···

Hi Werner,

On 2009/02/16, at 19:07, Werner Dittmann wrote:

If the account never had this property stored then it's not set
by default. Maybe we shall set this to "true" also to be compliant with account
creation?

Yes, this should IMHO be the default behaviour.

Cheers,
romain

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#12

Hi Werner,

I'm performing some more tests, my previous test config was not OK. I'll come back to you later.

Cheers,
romain

···

On 2009/02/17, at 11:06, Romain KUNTZ wrote:

Hi Werner,

On 2009/02/16, at 20:32, Werner Dittmann wrote:

if you test it can you please switch on logging (INFO) for
the *.transformer.zrtp level a provide the log output? I just
want to check to sequence of the information calls. Thanks.

Security for the video is still disabled on the latest builds.
Enclosed you will find the logs for a p2p call.

Thanks,
romain

<sip-communicator0.log.0>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#13

Hi again,

Here are some results with build 1695:
- Security seems enabled on both sides for the video when calling between 2 computers that have a webcam (here, 2 macosx laptops). Schreenshot enclosed.
- When calling from a laptop with a camera (macosx) to one without a webcam (linux), security for the video is reported to be off on both side. You'll find enclosed the SC logs from the computer with a camera. Note that this may also come from the gui which may not display the status correctly in that case?

Cheers,
romain

sip-communicator0.log.0 (586 KB)

···

On 2009/02/17, at 11:18, Romain KUNTZ wrote:

Hi Werner,

I'm performing some more tests, my previous test config was not OK. I'll come back to you later.

Cheers,
romain

On 2009/02/17, at 11:06, Romain KUNTZ wrote:

Hi Werner,

On 2009/02/16, at 20:32, Werner Dittmann wrote:

if you test it can you please switch on logging (INFO) for
the *.transformer.zrtp level a provide the log output? I just
want to check to sequence of the information calls. Thanks.

Security for the video is still disabled on the latest builds.
Enclosed you will find the logs for a p2p call.

Thanks,
romain

<sip-communicator0.log.0>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#14

Romain,

ok. According to the log the second chanel was activated for ZRTP. ZRTP
handshake starts only if it has seen at least one RTP from both parties
on this RTP session.

Regards,
Werner

Romain KUNTZ schrieb:

···

Hi Werner,

I'm performing some more tests, my previous test config was not OK. I'll
come back to you later.

Cheers,
romain

On 2009/02/17, at 11:06, Romain KUNTZ wrote:

Hi Werner,

On 2009/02/16, at 20:32, Werner Dittmann wrote:

if you test it can you please switch on logging (INFO) for
the *.transformer.zrtp level a provide the log output? I just
want to check to sequence of the information calls. Thanks.

Security for the video is still disabled on the latest builds.
Enclosed you will find the logs for a p2p call.

Thanks,
romain

<sip-communicator0.log.0>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#15

Ok, does it mean that we wouldn't be encrypting video if one of the peer does not have a webcam?

Cheers,
romain

···

On 2009/02/17, at 11:36, Werner Dittmann wrote:

Romain,

ok. According to the log the second chanel was activated for ZRTP. ZRTP
handshake starts only if it has seen at least one RTP from both parties
on this RTP session.

Regards,
Werner

Romain KUNTZ schrieb:

Hi Werner,

I'm performing some more tests, my previous test config was not OK. I'll
come back to you later.

Cheers,
romain

On 2009/02/17, at 11:06, Romain KUNTZ wrote:

Hi Werner,

On 2009/02/16, at 20:32, Werner Dittmann wrote:

if you test it can you please switch on logging (INFO) for
the *.transformer.zrtp level a provide the log output? I just
want to check to sequence of the information calls. Thanks.

Security for the video is still disabled on the latest builds.
Enclosed you will find the logs for a p2p call.

Thanks,
romain

<sip-communicator0.log.0>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#16

Romain,

this is an expected behaviour. Only if both sides use the channel,
i.e. support video then it is encrypted. If only one partner
uses the channel (sends data) then ZRTP doesn't start with handshake.

If this behaviour should be modified then we need to think about
how to trigger (and when) the ZRTP handshake for this "half-used"
channel.

Regards,
Werner

Romain KUNTZ schrieb:

···

Hi again,

Here are some results with build 1695:
- Security seems enabled on both sides for the video when calling
between 2 computers that have a webcam (here, 2 macosx laptops).
Schreenshot enclosed.
- When calling from a laptop with a camera (macosx) to one without a
webcam (linux), security for the video is reported to be off on both
side. You'll find enclosed the SC logs from the computer with a camera.
Note that this may also come from the gui which may not display the
status correctly in that case?

Cheers,
romain

On 2009/02/17, at 11:18, Romain KUNTZ wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#17

Romain KUNTZ schrieb:

Ok, does it mean that we wouldn't be encrypting video if one of the peer
does not have a webcam?

Exactly. I'm just thinking how to trigger such a "one-way" communication.
This is not an issue of the ZRTP4J lib but buried inside the
transformer inside SC. Maybe we can some enhancements to trigger ZRTP
for dedicated channels that may be used "one-way" only. I would not
recommend this for audio, video would be ok as "one-way" communication.

Sounds like a plan?

Regards,
Werner

···

Cheers,
romain

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#18

Werner Dittmann wrote:

Romain KUNTZ schrieb:

Ok, does it mean that we wouldn't be encrypting video if one of the
peer does not have a webcam?

Exactly. I'm just thinking how to trigger such a "one-way"
communication.

How about removing the condition on the sent packet? You mentioned
earlier that:

ZRTP handshake starts only if it has seen at least one RTP from both
parties on this RTP session.

Is there any ZRTP related reason that requires it to absolutely see an
outgoing packet before starting the handshake?

This is not an issue of the ZRTP4J lib but buried inside the
transformer inside SC. Maybe we can some enhancements to trigger ZRTP
for dedicated channels that may be used "one-way" only. I would not
recommend this for audio,

Why not? We could imagine a scenario where users join a multi-way conf
call and they do so muted by default. I guess that in this case it would
still be nice to have the incoming flow encrypted.

Does this sound reasonable or am I missing something?

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#19

Hi,

I could see that there might be scenarios where one wishes to *broadcast*
secure audio / secure video / secure audio+video one-direction only.

Why not allow this for 2 or 3 people? And later in the future to 20 or 30?

SC can not yet do one-direction broadcasting from 1 to many, for example
1 to 30 people, but this may be available in the future.
For example, I wish to show a modification to a solar photo voltaic panel
that greatly increases its efficiency, and I want to broadcast this to 20 or 30
people.
This has been done on Skype in the area of alternate energy research, where
one researcher is showing his experiment in real-time to many colleagues so
this is something that should be remembered when brain-storming about how
to design SC architecture.

Although some ideas are for the future, decisions should not be made now
that will make it more difficult to implement extensions at a future date.

At first thought, it seems silly to broadcast secure A+V to someone with no
Webcam, but on second thought there are valid scenarios where this is
desired.

Regards, Earl

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#20

Hi,

just some thoughts.

There are some obstacles to solve for such a sort of encrypted
conference/broadcast and also to start ZRTP and SRTP.

Several topics:

We need a two way audio (could be video if you use paper and
pencil :slight_smile: ) communication to be able to verify the
SAS if required. For example if this is the first call to a new
party of if the other party did not store the so-called
"retained shared secrets (RS)" or has lost it due to system
failures. If one does not verify the SAS in these cases then
nobody can guarantee that the keys were no modified by a
Man-in-the-middle attack. This would be a security disaster.

The main reason why starting of ZRTP is delayed until the first
RTP data was seen is due to network problems. Some resarch has
shown that quite often the first UDP/RTP packets of a session
either have a long delay or are discarded (not in local networks
but in the "real" Internet). After the first RTP packets are
seen it's save to start ZRTP and thus minimize the risk to
loose all Hello packets and to report "ZRTP not available"
(Phil and some of his colleagues did some resarch on this -
somewhere I have a short documentation about this)

In addition SC adds quite some time after starting the RTP
session before it is able to respond to Hello packets from
the other party (initialization issues I suppose).

To start or re-start a "failed ZRTP" requires yet another GUI
element, the user needs to know what it means "ZRTP failed", what
are the security risks, when it is the right time to re-start etc.

Currently ZRTP4J and its C++ counterpart support a "start or
re-start ZRTP in the middle of a session" feature. This is not
supported by other ZRTP implementations. The the user may not
be able to re-start ZRTP if the other party uses one of these
implementations and ZRTP Hello detection failed beuase of initial
network problems.

Regarding broadcasts/conference features:

This is not a problem of ZRTP but mainly of SRTP. SRTP requires a crypto
context per session. SRTP was designed as a point-to-point solution. If
you have multiple sessions you need multiple crypto contexts, multiple
ZRTP handshakes to negotiate the keys. How would you make sure all the
ZRTP handshakes were correct (SAS verfification) in all cases? See above
regarding the risks.

Thus, IMHO, we sould go for one-way" communications only on so called
"multi-stream" sessions only. These sessions are available after a first
Diffie-Helman (DH) ZRTP session was done and a SAS was computed and
displayed. This must be a two-way communication channel. Due to the
mentioned network problems we might need to build in some "auto restart"
functions in case the first one or two ZRTP handshakes fail for these
one-way communication (can be done in the SecurityManager class plus
some small enhancements in ZRTPTransformEngine).

Thoughts?

Regards,
Werner

Earl schrieb:

···

Hi,

I could see that there might be scenarios where one wishes to *broadcast*
secure audio / secure video / secure audio+video one-direction only.

Why not allow this for 2 or 3 people? And later in the future to 20 or 30?

SC can not yet do one-direction broadcasting from 1 to many, for example
1 to 30 people, but this may be available in the future.
For example, I wish to show a modification to a solar photo voltaic panel
that greatly increases its efficiency, and I want to broadcast this to
20 or 30
people.
This has been done on Skype in the area of alternate energy research, where
one researcher is showing his experiment in real-time to many colleagues so
this is something that should be remembered when brain-storming about how
to design SC architecture.

Although some ideas are for the future, decisions should not be made now
that will make it more difficult to implement extensions at a future date.

At first thought, it seems silly to broadcast secure A+V to someone with no
Webcam, but on second thought there are valid scenarios where this is
desired.

Regards, Earl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net