Re: sftp module cant connect to new hosts



I totally agree with you that people don't verity the host-key, I have
in fact written a paper related to this problem. But if we are using
ssh, we must stick to its security model. Even if we only protect the 1%
that perform the check, the majority of users will at least have made
things insecure by choice. 
What I think is the challenge is to write the information to make the
users able to make an informed decision. 

The solution to the problem you point out is not to "accept anything
since this is what most users will do anyway", but using some other
method with another security model. The security models we have is to
complex and are built on the assumption that the user have some hidden
desire to know about the technology behind the scene. Unfortunately I
haven't found any secure and simple solution to this problem. So for now
I suggest we stick to the security mechanisms we have, but keep on
looking for better ones. 

//Snaggen

mån 2004-03-15 klockan 04.15 skrev Seth Nickell:
> The problem is the assumption that popping up a dialog means we are
> using ssh in a "secure way". There is a very small percentage of
> paranoid ("security conscious") people in the world who would actually
> check if the ssh key changed (which is something that happens all too
> often in the real world). The majority of these people will be using the
> command line.
> 
> Everyone else will just click "OK", and the only thing accomplished will
> be to have wasted a little time, and some people will be worried (but
> still uninformed... worrying people without helping them is the worst)
> 
> In short: popping up this dialog only makes ssh secure for a minority
> (the probably less than 1% who will actually check to make sure the key
> really changed) of a minority (the paranoid people who actually use
> nautilus).
> 
> That's not a solution, its just "passing the buck"
> 
> -Seth
> 
> On Wed, 2004-03-10 at 02:14, Mattias Eriksson wrote: 
> > Well what do you suggest? My imagination can only come up with three
> > options:
> > 1. We accept all connections - this is NOT the solution since we then
> > would use SSH in a insecure way.
> > 2. We deny all connections and tell the user about it - the user then
> > has to run ssh/sftp from the command line. This (and I think we agree
> > here) is not the best way of doing things from a usability point of
> > view.
> > 3. Let the user decide what to do - this is really the only choise we
> > have since we cannot decide if the server is actually the server that
> > the user wants to connect to. 
> > 
> > I guess the message might be improved to inform the user what is
> > happening and how the user may validate the host key, but I have to
> > narrow imagination to see how this may be automated.
> > 
> > //Snaggen, not so good a UIs and with a small imagination
> > 
> > ons 2004-03-10 klockan 00.03 skrev Seth Nickell:
> > > UI wise I'm not sure popping up a dialog to "accept" the host key really
> > > adds security.
> > > 
> > > -Seth
> > > 
> > > On Mon, 2004-03-08 at 05:25, Alexander Larsson wrote:
> > > > On Sun, 2004-03-07 at 14:59, Mattias Eriksson wrote:
> > > > > Hi, I was looking at the sftp module because I had some trouble
> > > > > connecting to a host. I then connected manually and realized I have
> > > > > never connected to that host before so I had to accept the host-key.
> > > > > When I looked at the code to fix the problem I can't find a easy way to
> > > > > do it. I have looked at the callback mechanisms, but the standard
> > > > > callbacks are for authentication and status from what I can see. If I
> > > > > define a new callback I have to patch nautilus to handle that. 
> > > > > But before I go through to much trouble I want to hear if the callback
> > > > > mechanism might be used as I think for general ask-user dialogs. I guess
> > > > > the pointer to the in-argument can point to a struct that contains the
> > > > > message and the options, then in return in the out-argument you just get
> > > > > which argument the user selected.
> > > > > Another thing if I patch gnome-vfs to create a new standard callback,
> > > > > where should the general code to handle this in gnome be? libgnomeui?
> > > > > 
> > > > > So is this a possible solution or am I running in the wrong direction?
> > > > 
> > > > Its probably right. We don't want a bazillion different callbacks in
> > > > gnome-vfs, but in this case its probably right. It should be a generic
> > > > callback that can be used by other backends with similar issues though.
> > > > 
> > > > The default gnome implementation goes in libgnomeui with the other auth
> > > > callback dialogs.
> > > > 
> > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > >  Alexander Larsson                                            Red Hat, Inc 
> > > >                    alexl redhat com    alla lysator liu se 
> > > > He's a notorious devious filmmaker gone bad. She's a transdimensional 
> > > > out-of-work pearl diver prone to fits of savage, blood-crazed rage. They fight 
> > > > crime! 
> > > > 
> > > > _______________________________________________
> > > > gnome-vfs-list mailing list
> > > > gnome-vfs-list gnome org
> > > > http://mail.gnome.org/mailman/listinfo/gnome-vfs-list




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]