[lug] Re: securing files

[Bear Giles]

> > But neither is really supported on Linux, partially due to the
> > odd fetish for SSH/SSL....
> 
> I think that the . . . frequent use of OpenSSH is for very good reasons.
> 
> It is a good, inter operable, Free implementation of a reliable, open
> protocol.  It has a good history of not having an excessive number of
> security problems. 

It also eliminates the pressure to implement SSL/TLS in the protocols
and software and thus keeps everything at a "barely good enough" stage.

The NFS-over-SSH tunnel is an excellent example of this.  NFS-over-SSH
tunnels gives you a secure channel.  BFD.  You still have almost no 
assurance that the disk you mounted is the disk you intended to mount.
The daemon has almost no assurance that the person mounting it really
is authorized to do so.  (Yes, I know that the SysAdmin article talked 
about setting up mutual authentication, but that's still totally outside
of the mount program and NFS client and daemon.)

In contrast, with RPC-GSSAPI or *real* SSL/TLS support you could run
"mount" with your user cert and demand that the remote site authenticate
itself before you get your data. 

NFS is a bit weird, since the authentication is actually handled in the
RFC layer.  A better example is something like a database, e.g., with
PostgreSQL.  It natively supports SSL connections, but doesn't yet 
provide hooks between the SSL connection certs and the database identity.
Once that's in place the database will always know who you are (if you
require certs), and if your cert is in a smart card (or similar token)
you could even autodisconnect from the database when the card is removed
from the reader.  That's one of my motivations in my PKIX extensions to
PostgreSQL.

Another good example are the "secure" IMAP servers.  Most (all?) of them
just use anonymous DH encryption and you still have to log into the mail
server.  It would be much cleaner to use certs to provide the authentication -
establishing the connection would also establish your identity.

> IMO this beats the crap out of every Joe rolling his own, half-baked
> encryption subsystem.

Nobody is saying that "every Joe" should roll his own encryption subsystem,
but I (and others) are saying that people should be trying to add native
support for SSL/TLS via OpenSSL (or similar tools) instead of just waving
their hands and saying "use a SSH tunnel if you want security."

And even this doesn't (usually) require rolling your own protocol.  A
number of protocols have already defined TLS extensions, and the rest can
easily use a second port number for secure connections until extensions
are added to the standard protocol.

Bear