Re: [Ekiga-devel-list] New features in CVS.

2006-09-05 Thread Daniel Smertnig 
On 9/5/06, simon <[EMAIL PROTECTED]> wrote:
> How is it going to communicate the authentication string (the one you
> are supposed to audiably confirm with your call partner)?

Currently I intend to show a dialog box that explains to the user that
an encrypted connection was established and lets him confirm the SAS.
It should not be necessary to display the SAS in later sessions, but
one could probably give the user access to it by clicking the
(planned) padlock icon in case he wants to verify it again, for
whatever reason.

My current dialog designs are at:
http://smertnig.textdriven.com/sas_buttons.png
http://smertnig.textdriven.com/sas_radios.png

Opinions on which one is more user friendly and/or how to improve them
are of course welcome :-).

--
Daniel
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] New features in CVS.

2006-09-06 Thread Daniel Smertnig 
On 9/6/06, simon <[EMAIL PROTECTED]> wrote:
> Hi,
> Personally I prefer the 'buttons' one. The 'Ask again Later'
> should be a tick box and have an alternative location within the config so
> that it can be turned back on - maybe just when the padlock is clicked...

I don't think that will work since the Ask again later option is not
meant as an additional option to the buttons, but as a third
alternative, the user in theory has three alternatives:

- Confirm that the SAS was sucessfully compared.
- Tell the application that the SAS values are different (oops!).
- Do nothing in this session, and defer verification of the SAS to the
next session. If this were a check box the user would still be forced
to answer either "Yes" or "No", which is actually incorrect.
- Actually there would be a fourth option: never verify the SAS, but
since SAS verification is easy I don't think it should be there (if
it's wanted it could be a preference).

> Hovering over the padlock could 'pop up' the SAS.
Good idea.

> [Techically the SAS does not confirm that someone is not listening in (as
> they could steal the session key a different way and then be able to
> decode the ZRTP stream) it prevents 'Man in the Middle' attacks.]

I know, but I want to explain it to the users without using too much
technical jargon, improved texts are welcome (probably "not
intercepted"?). BTW, if somebody has the ability to get your session
keys without mounting a MitM attack you're in serious trouble anyway,
encryption won't help you (or your peer) then ;-).

> You should also model the window which would appear if there is
> 'tampering' detected (partner cert does not match previous call etc).

I think a simple message box will suffice here.
For the exact details on how to handle "lost" shared secrets I'm
waiting for a newer ZRTP since the current one has some deficiencies
in this area (an active MitM can easily nullify shared-secrets because
the corresponding ID fields in the DHPart messages are not
authenticated, I hope this will be fixed).

> You may want 'Use Anyway' as they may be using a different computer from
> last time (maybe on vacation, etc) and you might want to keep the validation
> data for the next call with their normal set-up.

I don't think "Use Anyway" would be of any use, if the peer is using
another computer the ZID will (hopefully) be different. If he is using
his own profile/home directory then hopefully both the ZID and the
shared secrets are carried with him.

> And along the same lines it would be nice to have a 'Clear Privacy Data'
> in much the same way that mozilla has (should clear the certs as well as
> the call logs).

Hmm, I am not sure what this would be useful for.

> PS Never store the session key to disk and use an encrypted swap
> file ;-)

I'll probably keep the secrets (or at least those that persist to a
later session) in a mlock()ed page anyway. And I can't image why one
would store the session key to disk ;-)

--
Daniel
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] New features in CVS.

2006-09-06 Thread Daniel Smertnig 
On 9/6/06, simon <[EMAIL PROTECTED]> wrote:
> If presented with a 'non valid' SAS then what can the user/application
> do

'non valid' == audible verification turns up that the SAS are
different, this then triggers the usual security-alert message (i.e.
"Your connection may be under attack" or some other cool sounding
message, the user can then choose what should happen)

> Maybe the question should be along the lines 'Do you want to validate
> peer?'.
That would require a two step process -- first ask if the SAS should
be validated and then ask for the validation information, I think it
should be kept down to a single step/dialog.

> I was thinking that the idea of 'Check Again' is usefull as it incourages
> the checking of the SAS as a normal routine. Although this is not necessary
> on the second call to a partner, unless you are routinely clearing
> persistant data (in which case it would pop up the box anyhow).

Yeah, but it is unlikely that somebody would want to validate the SAS
every time. I think it would be better to provide some place in the UI
to call up the dialog again if someone wants to change his opinion.
However displaying the SAS when hovering over the padlock may become
useful if one of the parties forgets to check the SAS-flag or somehow
manages to clear it.

> I agree that the 'never check SAS' seems a bit pointless maybe in
> the config pages next to 'use ZRTP when available'. In which case the
> padlock chould just be shown good/broken depending on whether peer has
> been previously validated and clicking on it would open the 'validation
> window'.

Actually the padlock should not be show broken just because the SAS
has not been verified, after all ZRTP gives pretty strong security
even without ever validating the SAS. I would reserve the broken
padlock for
a) failed ZRTP negotiation although the other endpoint supports it (to
let the user know, might be a DoS on ZRTP)
and
b) a compromised session (e.g. known SAS mismatch) if the user chooses
to continue after an alert.

> Goes with the concept that you can't be confident that the device on the
> other end of conversation isn't hacked, or (comment below) happens to keep
> a record of the session keys which can be used for later decryption.
Yes, but that is outside of the scope of ZRTP -- if one of the
endpoints is compromised there are different ways to get at the data
easier, e.g. intercepting the decrypted RTP packets in memory,
intercepting the audio stream on it's way to the speakers, replacing
the softphone binary etc.

> OK I'm probably not understanding how the persistant data exists in the
> case of multiple endpoints (ie. Hard IP phone and Laptop softphone)
> registered to same VoIP account. If it is 'sip address'+'random ID'
> Ekiga would treat them as different 'people' and the use of one would
> not effect the persistant data of the other...

ZRTP is completely independent from the signalling layer, therefore it
also does not use sip-addresses to identify peers. It generates a
random 96-bit number, the ZID, to identify a peer. The specification
refers to one ZID per installation, which is generated at installation
time. I plan to generate it per system user, since otherwise you have
an implicit trust relationship between different users by the way of
the SAS-flags (i.e. if "user A" sets the SAS-flag "user B" would
automatically trust "user A" to have carried out the SAS
verification).

BTW, the signalling-agnostic design of ZRTP also allows it to be used for H.323.

> > > And along the same lines it would be nice to have a 'Clear Privacy Data'
> > > in much the same way that mozilla has (should clear the certs as well as
> > > the call logs).
> >
> > Hmm, I am not sure what this would be useful for.
>
> When the secret police kick down the door they don't have a record of
> who you have called in the past. Useful for activists in opressive
> regimes (and the Tin Foil Hat briggade).

Hmm, it should probably be added. But I think the police will have an
easier time just looking at your SIP/RTP traffic. To use the ZRTP
persistent data to reconstruct your connection they would probably
have to know both parties already and then match the ZIDs and shared
secrets found on both computers (they won't be able to map a ZID to an
SIP address).

> Stupid things happen. I was thinking that a 'good' approach to law
> enforcement would be to cut the power as they kick down the door.
> A full disk image (with swap file/partition) could be maintained and
> investigated later.

Yes, and having an encrypted swap is always a good idea, but Ekiga
will also do its best not to swap key data (e.g. via mlock(), since
Linux >= 2.6.9 that is also available to unprivileged users, Windows
also has VM-locking facilities IIRC).

> As a side note the ZPhone application has the ability to 'Go Clear' and
> 'Go Secure' - which I assume re-negoiates the RTP stream with or without
> ZRTP.
>
> Why would anyone want the ability to do this and do we ne

[Ekiga-devel-list] URI ComboBoxEntry

2006-09-11 Thread Daniel Smertnig 
Hi,

is there any chance of being able to replace the current (=CVS)
GtkComboBoxEntry with a GtkEntry + GtkEntryCompletion combination?
This would make it a lot easier to put a padlock icon in there because
there are already various implementations floating around (e.g.
ephy-icon-entry.c is very simple and can be reused easily, libsexy has
a GtkIconEntry and Gtk 2.12 may also get one).

Thanks,
Daniel
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] URI ComboBoxEntry

2006-09-11 Thread Daniel Smertnig 
Hi,

On 9/11/06, Damien Sandras <[EMAIL PROTECTED]> wrote:
> Hi,
>
> The GtkComboBoxEntry already uses a GtkEntryCompletion.
> Removing it would be a regression as you wouldn't have any more the list
> of last dialed numbers.

I meant using the same list (GtkEntryCompletion), but instead of
having a GtkComboBoxEntry having a GtkEntry / EphyIconEntry.
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] URI ComboBoxEntry

2006-09-11 Thread Daniel Smertnig 
On 9/11/06, Damien Sandras <[EMAIL PROTECTED]> wrote:
> I guess it could be done.
>
> I don't plan doing it any time soon though, perhaps Jan or Julien have
> the time?

Cool,
I already have a quick-and-dirty version locally for testing purpose,
I only need to verify that it does not break any existing feature.
I only wanted to know if there is any opposition from a UI point of view :-).

Thanks,
--
Daniel
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] URI ComboBoxEntry

2006-09-11 Thread Daniel Smertnig 

On 9/11/06, Jan Schampera <[EMAIL PROTECTED]> wrote:

While you were writing the last few mails I dug into that stuff. If
you already have working code, can you share it?


The patch is attached (although I developed it against a version which
is a few days old and rebased it to CVS HEAD, it should work).
ephy-icon-entry.h/c does the hard part of the icon entry and is copied
verbatim from the Epiphany browser source.

The lines enclosed by "TEST TEST TEST" add a icon to demonstrate that
it actually works, though probably the final version will/should have
a GmURIEntry derived from EphyIconEntry which handles the nasty stuff
of setting up the actual icons and provide functions like
"gm_uri_entry_set_security_status()" for Ekiga to call.

--
Daniel
=== added file 'lib/gui/ephy-icon-entry.c'
--- lib/gui/ephy-icon-entry.c	1970-01-01 00:00:00 +
+++ lib/gui/ephy-icon-entry.c	2006-09-11 13:59:08 +
@@ -0,0 +1,352 @@
+/*
+ *  Copyright (C) 2003, 2004, 2005  Christian Persch
+ *
+ *  This library is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU Lesser General Public
+ *  License as published by the Free Software Foundation; either
+ *  version 2 of the License, or (at your option) any later version.
+ *
+ *  This library is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  Lesser General Public License for more details.
+ *
+ *  You should have received a copy of the GNU Lesser General Public
+ *  License along with this library; if not, write to the
+ *  Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ *  Boston, MA 02111-1307, USA.
+ *
+ *  Adapted and modified from gtk+ code:
+ *
+ *  Copyright (C) 1995-1997 Peter Mattis, Spencer Kimball and Josh MacDonald
+ *  Modified by the GTK+ Team and others 1997-2005.  See the AUTHORS
+ *  file in the gtk+ distribution for a list of people on the GTK+ Team.
+ *  See the ChangeLog in the gtk+ distribution files for a list of changes.
+ *  These files are distributed with GTK+ at ftp://ftp.gtk.org/pub/gtk/. 
+ *
+ *  $Id: ephy-icon-entry.c,v 1.4 2005/08/07 20:31:32 chpe Exp $
+ */
+
+#include "config.h"
+
+#include "ephy-icon-entry.h"
+
+#include 
+#include 
+#include 
+
+#define EPHY_ICON_ENTRY_GET_PRIVATE(object)(G_TYPE_INSTANCE_GET_PRIVATE ((object), EPHY_TYPE_ICON_ENTRY, EphyIconEntryPrivate))
+
+struct _EphyIconEntryPrivate
+{
+	GtkWidget *hbox;
+};
+
+static GtkWidgetClass *parent_class = NULL;
+
+/* private helper functions */
+
+static gboolean
+entry_focus_change_cb (GtkWidget *widget,
+		   GdkEventFocus *event,
+		   GtkWidget *entry)
+{
+	gtk_widget_queue_draw (entry);
+
+	return FALSE;
+}
+
+static void
+ephy_icon_entry_get_borders (GtkWidget *widget,
+			 GtkWidget *entry,
+			 int *xborder,
+			 int *yborder)
+{
+	int focus_width;
+	gboolean interior_focus;
+
+	g_return_if_fail (entry->style != NULL);
+
+	gtk_widget_style_get (entry,
+			  "focus-line-width", &focus_width,
+			  "interior-focus", &interior_focus,
+			  NULL);
+
+	*xborder = entry->style->xthickness;
+	*yborder = entry->style->ythickness;
+
+	if (!interior_focus)
+	{
+		*xborder += focus_width;
+		*yborder += focus_width;
+	}
+}
+
+static void
+ephy_icon_entry_paint (GtkWidget *widget,
+		   GdkEventExpose *event)
+{
+	EphyIconEntry *entry = EPHY_ICON_ENTRY (widget);
+	GtkWidget *entry_widget = entry->entry;
+	int x = 0, y = 0, width, height, focus_width;
+	gboolean interior_focus;
+
+	gtk_widget_style_get (entry_widget,
+			  "interior-focus", &interior_focus,
+			  "focus-line-width", &focus_width,
+			  NULL);
+
+	gdk_drawable_get_size (widget->window, &width, &height);
+
+	if (GTK_WIDGET_HAS_FOCUS (entry_widget) && !interior_focus)
+	{
+		x += focus_width;
+		y += focus_width;
+		width -= 2 * focus_width;
+		height -= 2 * focus_width;
+	}
+
+	gtk_paint_flat_box (entry_widget->style, widget->window, 
+			GTK_WIDGET_STATE (entry_widget), GTK_SHADOW_NONE,
+			NULL, entry_widget, "entry_bg", 
+			/* FIXME: was 0, 0 in gtk_entry_expose, but I think this is correct: */
+			x, y, width, height);
+ 
+	gtk_paint_shadow (entry_widget->style, widget->window,
+			  GTK_STATE_NORMAL, GTK_SHADOW_IN,
+			  NULL, entry_widget, "entry",
+			  x, y, width, height);
+
+	if (GTK_WIDGET_HAS_FOCUS (entry_widget) && !interior_focus)
+	{
+		x -= focus_width;
+		y -= focus_width;
+		width += 2 * focus_width;
+		height += 2 * focus_width;
+
+		gtk_paint_focus (entry_widget->style, widget->window,
+ GTK_WIDGET_STATE (entry_widget),
+ NULL, entry_widget, "entry",
+ /* FIXME: was 0, 0 in gtk_entry_draw_frame, but I think this is correct: */
+ x, y, width, height);
+	}
+}
+
+/* Class implementation */
+
+static void
+ephy_icon_entry_init (EphyIconEntry *entry)
+{
+	EphyIconEntryPrivate *priv;
+	GtkWidget *widget = (GtkWidget *) entry;

Re: [Ekiga-devel-list] URI ComboBoxEntry

2006-09-11 Thread Daniel Smertnig 
On 9/11/06, Jan Schampera <[EMAIL PROTECTED]> wrote:
> Just curious, what is the purpose of that padlock icon? Secure/Insecure
> connections?

Yep, it should become:

- No background color, no icon -> unknown / security not supported by
other endpoint
- Yellow background color, padlock icon -> secure connection
- No background color, broken padlock icon -> known insecure
connection (security protocol failed or detected an attack)

Theoretically one could distinguished connections with confirmed SAS
and not confirmed SAS (e.g. stock_lock-ok and stock-lock) for ZRTP,
but I think that would be overkill and would confuse users.

--
Daniel
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] URI ComboBoxEntry

2006-09-11 Thread Daniel Smertnig 
On 9/11/06, Julien PUYDT <[EMAIL PROTECTED]> wrote:
> I guess it's 100% gtk+, and hence will give 0% more issues on win32 ?

No gnome code is used, so it should work, yes. Though we should
probably test it to be sure. (And in when gtk 2.12 takes up the
libsexy icon-entry (http://www.gtk.org/plan/meetings/20060625.txt
seems to indicate so) and is widespread enough, we can probably switch
to that).

--
Daniel
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] URI ComboBoxEntry

2006-09-11 Thread Daniel Smertnig 
On 9/11/06, Damien Sandras <[EMAIL PROTECTED]> wrote:
> Wouldn't it be better to place that icon in the status bar than in the
> location entry?

It probably depends on what you wold prefer (I don't have a particular
preference), but the current trend in browsers seems to go towards
putting an padlock icon in the url bar but only when the connection is
secured.
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] URI ComboBoxEntry

2006-09-11 Thread Daniel Smertnig 
On 9/11/06, Jan Schampera <[EMAIL PROTECTED]> wrote:
> I just inspected GtkComboBoxEntry, it should be "no problem" to rewrite
> it, given the code and idea Daniel provides. But for security display
> it's the wrong one IMHO.

Hmm, the problem is that you have to provide a custom paint-event
handler, which was the original reason why I asked about using
GtkEntry instead of GtkComboBoxEntry (for GtkEntry other people
already wrote that code ;-)).

So consensus for the padlock-icon is on putting it into the status-bar?

--
Daniel
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] URI ComboBoxEntry

2006-09-11 Thread Daniel Smertnig 
On 9/11/06, Jan Schampera <[EMAIL PROTECTED]> wrote:
> For this purpose I'd say yes. It's like with a browser, a connection is
> secure, not an URI (i.e. IMHO it belongs in some "general" place).

Hmm, that's where i was taking the idea from ;-) (Note that the icon
is only displayed in the entry, not in the completion suggestions!).

But anyway, I will put it into the statusbar.

--
Daniel
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] URI ComboBoxEntry

2006-09-11 Thread Daniel Smertnig 
On 9/11/06, Damien Sandras <[EMAIL PROTECTED]> wrote:
> Can you send a screenshot/link to a screenshot of where it is now before
> changing things?

Sure, here you go:

What you currently get with the patch posted earlier:
http://smertnig.textdriven.com/ekiga-current-patch.png

What I intended to make it look like:

When the peer does not indicate encryption support:
http://smertnig.textdriven.com/ekiga-entry-no-encryption-support.png

When an encrypted connection was successfully established:
http://smertnig.textdriven.com/ekiga-entry-secure.png

When the peer seems to support encryption but out of some reason
(protocol version mismatch, timeouts, lost packets, active attack, SAS
mismatch...) establishing a secure connection has failed:
http://smertnig.textdriven.com/ekiga-entry-known-insecure.png

(Note that most of the code comes straight from Epiphany, I've only
added a bit of glue).

--
Daniel
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] URI ComboBoxEntry

2006-09-11 Thread Daniel Smertnig 
On 9/11/06, Jan Schampera <[EMAIL PROTECTED]> wrote:
> > Don't both the meter and the padlock say something about the state of
> > the connection? And hence shouldn't they come together?
>
> There the taste wins over the logic.

Putting the padlock to the right also makes it posible to display no
padlock icon at all when the remote end does not support encryption.
Under the assumption that this is (currently at least) the case for
most peers this avoids cluttering the screen unecessarily (Or should
we display it anyway but open?).
Putting it to the left requires us to always display the icon,
otherwise the status text either jumps around when the icon changes or
is displayed with an invisible and strange offset.
Of course I have no idea how this works out with RTL scripts :-/.

--
Daniel
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] Ekiga - crash on exit

2006-09-20 Thread Daniel Smertnig 
On 9/20/06, Damien Sandras <[EMAIL PROTECTED]> wrote:
> I thought it was my new code Apparently not. We'll have to
> investigate...

It looks to me like OnReceivedAuthenticationRequired is being called
when SIPEndPoint is being destroyed, so that SIPEndPoint's destructor
has already been called (but OpalEndPoint's destructor most likely has
not run yet), which then results into OpalEndPoint's pure virtual
method being called.
In this backtrace thread 1 seems to be in the process of destroying
the endpoint (with the wait caused by CloseWait() being an explanation
why it happens comparable often that ~SIPEndPoint() has already
destroyed part of the object, but ~OpalEndPoint() was not called yet),
and thread 12 tries to dispatch an received event to the SIPEndPoint
object which is already half-destroyed (oops!).
Thread 12 probably should not be alive anymore at this point in time,
though I neither know why it still is or how to stop it currectly as I
have not looked at this part of OPAL to closely :(. Probably it should
be stopped form ~SIPEndPoint()?

-- 
Daniel
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] SRTP with Ekiga

2006-09-29 Thread Daniel Smertnig 
On 9/29/06, Alexandre Passito <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'd like to know if somebody is working to put SRTP in Ekiga. If so, how is
> the working going? I'd like to help in this task.

Craig Southeren is implementing SRTP in the OPAL library with the help
of libSRTP and I am implementing ZRTP (a protocol for SRTP key
negotiation). I also have a native SRTP implementation against an
older OPAL version lying around but it most likely won't be used.

Unfortunately I did not get much done during the last two weeks or so,
because I am currently occupied moving and other stuff related to
university (yea! :-)). I think I will have more time again in another
week or two, when things have calmed down.

-- 
Daniel
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list