Some login/sasl questions for 0.11

I asked these on the MUC, but remko wanted the discussion to be here. 

1) do we want double encryption (TLS and SASL based at the same time)
    we currently do double encryption, but i think it's not a great idea.
    i think changing psi to don't double encrypt would be easy. I can
    try to write a patch for that *if* that's what should be done.

2) does auth-int (that is SASL based connection integrety support 
  (aka signing stuff send over the wire)) still show up the same
  as encrypted connections? If so, is that ok?
    I guess this needs testing. Matthias Wimmer mentioned this
    when we debugged psi+cyrus and jabberd1.6 interop

3) do we want to have a allow plaintext login over encrypted streams
   option? (or change current allow plaintext to mean that). 
     some start of a discussion at 
     http://chatlogs.jabber.ru/psi%40conference.jabber.ru/2007/02/04.html#20:55:18
     I think a 
     Allow Plaintext: [Over encrypted session | Always | Never]
     would be best. But maybe we just don't need this.

- Martin

Re: Some login/sasl questions for 0.11

textshell wrote:

> 3) do we want to have a allow plaintext login over encrypted streams
>    option? (or change current allow plaintext to mean that). 
>      some start of a discussion at 
>      http://chatlogs.jabber.ru/psi%40conference.jabber.ru/2007/02/04.html#20:55:18
>      I think a 
>      Allow Plaintext: [Over encrypted session | Always | Never]
>      would be best. But maybe we just don't need this.

I think we cannot disallow users to use plaintext login - some servers 
require it (simpliest example: Google Talk - it requires STARTTLS and 
plaintext). However, we should warn user if he/she selects plaintext but 
no encryption.

--

-- 
Michał Jazłowiecki (michalj)
Psi Forum & Wiki Moderator :: Psi-Daisy Author

Re: Some login/sasl questions for 0.11

> I think we cannot disallow users to use plaintext login

That was never the intention. The question was whether we should make
a distinction of allowing plaintext over encrypted and non-encrypted
streams, in order to give the user more control over his security.
Now, it's all or nothing (unless you force SSL).

cheers,
Remko

Re: Some login/sasl questions for 0.11

Hi Remko!

... I'll later check again if the lock icon is still locked for only 
integrity-protected connections.

Remko Tronçon schrieb:
>> I think we cannot disallow users to use plaintext login
> 
> That was never the intention. The question was whether we should make
> a distinction of allowing plaintext over encrypted and non-encrypted
> streams, in order to give the user more control over his security.
> Now, it's all or nothing (unless you force SSL).

BTW: What about changing the force SSL setting to not force TLS but only 
an encryption layer? I.e. also allowing non-TLS but DIGEST-MD5 in 
auth-crypt mode.

Matthias

--

-- 
Matthias Wimmer      Fon +49-700 77 00 77 70
Züricher Str. 243    Fax +49-89 95 89 91 56
81476 München        http://ma.tthias.eu/

_______________________________________________
psi-devel mailing list
psi-devel <at> lists.affinix.com
http://lists.affinix.com/listinfo.cgi/psi-devel-affinix.com

Re: Some login/sasl questions for 0.11

Hi Remko!

Matthias Wimmer schrieb:
> ... I'll later check again if the lock icon is still locked for only 
> integrity-protected connections.
>   

I've just rechecked. Test environment:

psi-dev-snapshot-2007-02-04 using Cyrus SASL, OS: Linux

Established connection to my server using no TLS (disabled at the 
server) and DIGEST-MD5 in auth-int mode (disabled auth-conf by seting 
max_ssf to 1 at the server).

Result:

Lock is shown as closed, so that a user might expect, that the 
connection is encrypted and cannot be read by someone having access to 
the network.

I think as a first solution the lock should be shown as open in case, 
that the connection is only integrity protected (i.e. Cyrus returns a 
security strength factor of "1"). But for the long term it might be good 
to have a third symbol indicating a connection is integrity protected 
but not encrypted.

Matthias

Re: Some login/sasl questions for 0.11

Sorry I already deleted the posting I am replying.

Concerning the question if establishing a SASL encryption layer should 
be supported inside a connection, that is already protected by a TLS layer:

I think that a SASL encryption layer inside a TLS layer should be supported:
One reason for this would be a server, that wants to be sure, that it is 
really the user, that is on the other side of the connection and there 
is no man-in-the-middle attack taking place. The server cannot relay on 
the TLS layer for this as long as the client does not present its own 
certificate! This is because he does not know if the TLS layer has been 
established by the client at all (or just by the man in the middle which 
told the client that TLS support is not available by the server or the 
client got offered TLS but did not check the certificate).
A auth-conf layer is the only currently available solution for a server 
to know, that there is a secure connection to the client if client 
certificates are not used. Note that even not auth-int is enough for a 
server to know this, as the TLS layer is established before the 
connection is protected by the SASL integrity layer and therefore TLS 
could have been established by the man in the middle before doing SASL 
and telling the Jabber client that TLS is not available. The connection 
is then only protected against the man in the middle injecting or 
removing stanzas, but not from being watched by this man in the middle.

Tot kijk
     Matthias

Re: auth-int encryption status patch

On Mon, Feb 05, 2007 at 01:41:57AM +0100, Matthias Wimmer wrote:
> Hi Remko!
> 
> Matthias Wimmer schrieb:
> > ... I'll later check again if the lock icon is still locked for only 
> > integrity-protected connections.
> >   
> 
> I've just rechecked. Test environment:
> 
> psi-dev-snapshot-2007-02-04 using Cyrus SASL, OS: Linux
> 
> Established connection to my server using no TLS (disabled at the 
> server) and DIGEST-MD5 in auth-int mode (disabled auth-conf by seting 
> max_ssf to 1 at the server).
> 
> Result:
> 
> Lock is shown as closed, so that a user might expect, that the 
> connection is encrypted and cannot be read by someone having access to 
> the network.
> 
> I think as a first solution the lock should be shown as open in case, 
> that the connection is only integrity protected (i.e. Cyrus returns a 
> security strength factor of "1"). But for the long term it might be good 
> to have a third symbol indicating a connection is integrity protected 
> but not encrypted.
> 
> 

opt_shortcuts, fix empty shortcut item dbl click

Hey,

when double clicking an empty shortcut item (shortcut with no keys
associated), it won't create a new key item currently. 
This patch fixes this behave.

Ciao Ephraim

Hey,

when double clicking an empty shortcut item (shortcut with no keys
associated), it won't create a new key item currently. 
This patch fixes this behave.

Ciao Ephraim

Re: some mouse clicks not working on tray icon

I figured out what is happening.  When the "use double-click style"
option is checked, a double-click on the tray icon will "receive next
event", even though it should be doing a show/hide roster.  If I
uncheck that option, I get the behavior I expected, both for
single-click (show/hide) and for middle-click (receive next event).
This option used to work as expected, something has changed.

On 1/16/07, Ephraim Talrock <ephraim@...> wrote:
> Here under Ubuntu does a double click often nothing too...
> I'm clicking like crazy and then the event opens.
> It looks like that Psi doesnt get the click events. Right click often
> opens the default bar popupmenu.
>
> I thought its something wrong with my desktop but when hal reports the
> same Psi perhaps has a prob.
>
> Ciao Ephraim
>
> Am Dienstag, den 16.01.2007, 18:40 +0100 schrieb Maciek Niedzielski:
> > Maciek Niedzielski wrote:
> > > Hal Rottenberg wrote:
> > >> this is using latest nightly
> > >
> > > Works here, on latest source code plus my two hotkeys (shouldn't change
> > > anything)
> >
> > But default setup requires double click to unhide and double click to
> > open new event.
> >
> > _______________________________________________

Jive's new stuff

http://www.igniterealtime.org/blog/2007/02/01/release-news-the-beta-wave

Comments?

--

-- 
Psi webmaster (http://psi-im.org)
im:hal@...
http://halr9000.com