Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems

From: Thor Lancelot Simon <[email-masked]>
Date: Mon, 12 Mar 2001 17:31:30 -0500

On Mon, Mar 12, 2001 at 02:40:35PM +0100, Markus Friedl wrote:
> On Mon, Mar 12, 2001 at 08:31:48AM -0500, Jeffrey Altman wrote:
> > > In this case (i.e. in the case of wanting to "ftp" over SSH) the issue
> > > is with the stupid user interface.  Naive users are looking for some SSH
> > > file copying tool that works just like their FTP clients, i.e. where
> > > they can see a list of files on the server and click/drag/whatever them
> > > to effect the copy.
> > 
> > Why do you need to use FTP over SSH when FTP is "securable" using any
> > number of methods?  The most common methods are
> > 
> >   SSL/TLS
> > 
> >   GSSAPI 
> > 
> >   Kerberos
> > 
> >   SRP
> > 
> > 
> > When using any of these methods both the command and data channels
> > used by FTP are authenticated, encrypted and integrity checked.  In
> > other words, they are secure.  
> 
> so does SFTP. so what's the point?

I think the point is that the development of the SSH protocol has
involved a great deal of reinvention of wheels.  Some people think
that this is regrettable and wish that the SSH working group paid a
bit more attention to integration with other IETF protocols rather
than rampaging ahead inventing new ones.

I personally think that the SFTP protocol is a pretty gratuitous
addition; a whole lot of complexity, and it really doesn't buy you
much.  But then again, I think that reinventing most of what TLS
does for the SSHv2 transport layer instead of politely asking the
TLS folks for a record-oriented interface was rather silly, too.

We have those things now; there's not much point thinking about what
we _could_ have done.  However, it's a valid question to ask what the
point of implementing something like SFTP in _any particular 
implementation of other bits of the SSH suite_ is; I don't really think
that the "anonymous" bits of its function are well served by its design,
worse served, in fact, than by simply using FTP secured with TLS, GSSAPI,
or other standard methods, and it's massive overkill compared to the
simple BSD-rcp protocol used by the old "scp" application, when that's
going to be 99% of what it's used for in the real world, ISTM.

Ergo, a small, lightweight SSH implementation, even one that did v2,
might quite reasonably choose to *not* implement SFTP; to me, at least,
it sure seems to bring very little to the table in return for a lot
of increase in code size and maintenance.  But that's just my point
of view; clearly some people have put a lot of work into advancing
SFTP and they must have a more substantial use for it than I do.

-- 
Thor Lancelot Simon	                                      [email-masked]
    And now he couldn't remember when this passion had flown, leaving him so
  foolish and bewildered and astray: can any man?
						   William Styron

---

From: [email-masked] (Niels M�ller)
Date: 13 Mar 2001 00:12:46 +0100

Thor Lancelot Simon <[email-masked]> writes:

> But then again, I think that reinventing most of what TLS does for
> the SSHv2 transport layer instead of politely asking the TLS folks
> for a record-oriented interface was rather silly, too.

I've implemented both TLS (ok, it was actually SSL version 3 back
then) and ssh2. I'd say the ssh2 transport is better. It's cleaner,
more secure, more flexible, and its spec is a lot easier to
understand. And then a lot of the complexity in ssh is in the
connection layer, which isn't comparable to TLS in any way.

> of increase in code size and maintenance.

The ssh implementation and the sftp implementation are quite
independent. They have a common origin and uses a common language and
terminology, but you can run the sftp over any secure bidirectional
connection. The only feature in the ssh core protocol that makes sftp
easier is the subsystem request that lets a client start a program
without knowing an exact path, and without knowing whether or not it
is an external program or part of the ssh server.

If I get involved in a complete sftp implementation, it will run just
as well using lsh, kerberized rsh, or plain old insecure rsh if
anybody is still using that.

Furthermore, the server part (i.e. the subsystem) is not big, I expect
the one I started to write to be a self contained program of at most
5000-10000 lines of C code. Say about twice as large as GNU ls. 

/Niels

---

From: Damien Miller <[email-masked]>
Date: Tue, 13 Mar 2001 09:50:52 +1100 (EST)

On Mon, 12 Mar 2001, Thor Lancelot Simon wrote:

> much.

IMO sftp is not very complex and a worthwhile addition to SSH.
Compared to rfc959, sftp is a very clean protocol and a breeze
to implement (the client end at least).

> But then again, I think that reinventing most of what TLS

TLS is pretty intimately wed to x.509 and we still have not seen it
specified for other PK systems (except for an expired OpenPGP draft).

-d

-- 
| Damien Miller <[email-masked]> \ ``E-mail attachments are the poor man's
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer

---

From: [email-masked]
Date: Mon, 12 Mar 2001 18:39:35 -0600 (CST)

[..]
> SFTP and they must have a more substantial use for it than I do.

How do you assure Windows end-users can transfer and manage files to a
webserver in a secure way?  Is there publicly accessable IPSec software
for Windows 98? What about TLS?  What about GSSAPI?  How much added load
do they put on a 200mhz - 400mhz machine?  Are they 100% stable and
usable?  How do they interact over dialups?  What unforseen issues will
crop up for day to day usage online and offline?

You seem to be suggesting that I should have to suffer for two to ten
years before older technology that is not progressing at any decent
rate to be cross-platform supported and commonly used.  Or maybe your
suggestion I need to wait twenty or more years before UNIX (Linux, BSD,
etc) are common desktop machines and this technology is then native.  I
consider it pretty unacceptable.

I need something today that will allow me to security against poorly
written ftpd attacks, against password sniffing, etc.  When we gained sftp
server support I started in look for a sftp client solution for my
end-users.

sftp is totally optional.  It's not even part of the main v2 specs.  It is
an add-on draft that is no required.  So if you don't want it.  Don't
enable it.  

- Ben

---

From: "Richard E. Silverman" <[email-masked]>
Date: Tue, 13 Mar 2001 00:55:40 -0500 (EST)

> > > number of methods?  The most common methods are

Because while FTP may be "securable" using these methods, the fact is that
it has not actually been secured this way in real life.  Implementations
of these things have existed for a while, and have simply not caught on.
I will not debate why, but is is true.  In the short time that it has
existed, my impression is that SSH has achieved much more widespread use
than any of these techniques.  Hence, an easy-to-use, comprehensive
file-transfer protocol that operates over SSH has a good chance of
succeeding where these various secured FTP's have failed.

FTP has successfully been secured using SSH; cf the SecureFX product from
Van Dyke, and the FTP protocol forwarding in the latest version of SSH2
from ssh.com.  However, it's nasty.  The basic FTP techniques of using
multiple, separate TCP connections for data transfers, and carrying IP
addresses inside the command channel, make it badly suited to today's
Internet filled with restrictive firewalls and NAT.  A much better idea is
to have a protocol which requires nothing but a single, reliable,
full-duplex byte stream as its transport.  To my knowledge, there simply
isn't such a thing available.  rcp is too simple; it doesn't allow for
directory listings or generally fetching information about remote files,
and doesn't lend itself to conducting a file-transfer "session," as
opposed to just pushing or pulling a singly-specified set of files.  I
haven't looked at the protocols used by rsync, sup, etc. to see if they
would have been good alternatives -- but they are not standardized,
either.  If there's an existing IETF-standard file-transfer protocol that
meets these needs, I'd like to hear about it.

I agree that on the face of it, engineering such a thing in the context of
the SSH wg is a little odd; it has no direct connection with SSH at all.
But in a practical sense, it does.  People have two immediate needs when
connecting to remote computers: getting a remote command shell, and
transferring files.  SSH inherently provides the former.  By providing the
latter as well as a standard feature, SSH will be more widely used,
enhancing security in the Internet.  Since there is no existing,
widely-used, sufficiently general file-transfer protocol which is easily
securable via SSH, creating a new one is justified.

> ... But then again, I think that reinventing most of what TLS

Tatu Ylönen wrote SSH1 in 1995, a year before the TLS wg was even formed.
The first version of the SSH-2 protocol was designed by SSH Communications
Security in 1996, and the SSH wg formed in 1997.  RFC 2246 documenting TLS
1.0 did not appear until 1999.  So the claim that the SSH people should
have used TLS instead seems a bit stretched; it did not exist at the time.
SSL in its earlier versions existed, but as I noted before, it had not
(and to this day still has not) achieved much use outside of HTTPS.  Why
would Tatu or others have turned to a technology that, for whatever
reasons, had simply failed to do the job in the field?  Its dependence on
an eagerly-awaited-but-never-quite-there-yet global X.509-based PKI, plus
dependence on the overly complex ASN.1/BER/DER suite, were liabilities
just not worth the trouble.

> we _could_ have done. 

An odd statement, considering that you have just spent a fair amount of
space doing exactly this, and berating people for it.

> I don't really think that the "anonymous" bits of its function are well
> served by its design, worse served, in fact, than by simply using FTP
> secured with TLS, GSSAPI, or other standard methods

These methods, no matter how much they may appeal to our sense of elegance
or our like of reusing of existing technology, have simply not taken hold.
They have been rejected by the users.  SSH, on the other hand, is
spreading and gaining acceptance.  A file-transfer method that works over
SSH is therefore a good bet, and in the absence of a good existing
candidate, we are building a new one for the purpose.

> and it's massive overkill compared to the simple BSD-rcp protocol used
> by the old "scp" application, when that's going to be 99% of what it's
> used for in the real world, ISTM.

In the real world, people want long-lived file-transfer sessions including
the ability to list remote directories, push and pull various files during
that single session, perhaps initiate a long transfer and then continue to
list other directories and transfer other files while that long task
continues.  rcp is just not general enough to meet these needs.

-- 
  Richard Silverman
  [email-masked]

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 13 Mar 2001 01:00:41 -0500

>it has not actually been secured this way in real life.

I (and 5000 other people I know) use GSSAPI authenticated ftp every day
for real work.

Sure, I believe that ssh easily has more users, but just because you don't
use it doesn't mean it doesn't exist.

(I'm ambivalant about sftp, personally).

--Ken

---

From: "Richard E. Silverman" <[email-masked]>
Date: Tue, 13 Mar 2001 01:33:37 -0500 (EST)

> use it doesn't mean it doesn't exist.

Perhaps you received a garbled or incomplete version of the message I
posted.  I did not claim that GSSAPI-secured FTP doesn't exist; in fact,
if you read past that first sentence which you quoted out of context, I
specifically said that it and other secured FTP implementations exist and
have been around for a while.  They have their users, especially within
specific, controlled communities.  They have not, however, achieved
widespread use in the Internet in general, whereas SSH has a good start at
that and seems quite likely to be ubiquitous shortly.  That was all I
said, and all I meant.

-- 
  Richard Silverman
  [email-masked]

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 13 Mar 2001 01:49:58 -0500

>that and seems quite likely to be ubiquitous shortly.  That was all I

In my mind, there's a LARGE difference between:

"they have not, however, achieved widespread use in the Internet in general"

which you used in your most recent message, and

"the fact is that it has not actually been secured this way in real life"

which you used in your original message.

I'm not sure I really know what the first one means, actually.
I'd believe that GSSAPI-authenticated ftp doesn't meet the first
criteria, but I'm not sure what your definition of "widespread"
is.  I take HUGE issue with your characterization that these
protocols are not used "in real life".  As for being quoted out of
context ... you were responding to the original poster's comment
about different technologies used for securing ftp!  How is that
not in-context to this discussion?

--Ken

---

From: "Richard E. Silverman" <[email-masked]>
Date: Tue, 13 Mar 2001 02:05:57 -0500 (EST)

> which you used in your original message.

The second sentence merely paraphrases what I wrote to begin with, which I
did to avoid having to repeat it, which I will now do anyway since you're
ignoring it.  Here is what I wrote:

"Because while FTP may be "securable" using these methods, the fact is that
 it has not actually been secured this way in real life.  Implementations
 of these things have existed for a while, and have simply not caught on.
 I will not debate why, but is is true.  In the short time that it has
 existed, my impression is that SSH has achieved much more widespread use
 than any of these techniques.  Hence, an easy-to-use, comprehensive
 file-transfer protocol that operates over SSH has a good chance of
 succeeding where these various secured FTP's have failed."

The sentences following the first one, explain what I meant: that those
other techniques exist and are used, but not generally enough to count as
having "secured FTP" in the broadest sense.  That's all.

> I take HUGE issue with your characterization that these protocols are
> not used "in real life".

If that were all I had said, without any other explanation for what I
meant by that phrase, then I would agree with your objection.  However, I
think my meaning was sufficiently well explained in the rest of the text.
I'm sorry you didn't find it clear enough.

> As for being quoted out of context ... you were responding to the
> original poster's comment about different technologies used for securing
> ftp!  How is that not in-context to this discussion?

This is very confusing.  I did not say that your message was not in
context of the discussion.  I said that you quoted me out of context.
Those are different things.  You quoted the phrase "in real life" without
the following text which explained what I meant by it, and proceeded to
attach a very different meaning to it from that which I clearly
articulated in my post.

Since we're both clear on what I meant now (I hope), perhaps we could
continue to discuss the merits of the protocols in question.

-- 
  Richard Silverman
  [email-masked]

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 13 Mar 2001 02:22:59 -0500

Alright, my last message on the topic.

I have the following issues with this paragraph, and I did read it all,

> it has not actually been secured this way in real life. 

(I think we covered this before).

>Implementations

I disagree that they have not "caught on" - in the communities that use
Kerberos, for example, GSSAPI ftp is very popular.  I can even think of
several commercial implementations of GSSAPI ftp.

> I will not debate why, but is is true.

Fair enough, but I disagree with the basic premise.

>In the short time that it has
> than any of these techniques.

I'm not sure about this one, but I'd be going on gut feelings.  But without
hard numbers to back this up ... it wouldn't be very meaningful.

>Hence, an easy-to-use, comprehensive

And again, I disagree that the others have failed in the first place.
(Mind you, I don't think that file-transfer over SSH is bad ... I'm
just saying that I don't see any evidence that the others have failed).

And come on ... you have to admit that saying things like "not used in
real life," "not caught on", and saying that the other technologies
have "failed" isn't exactly the same as saying they haven't achieved
widespread use on the Internet (if we're using the "widespead use over
the Internet" benchmark, we should all be working furiously toward
getting SMTP-over-TLS and HTTP-over-TLS working better :-) ).

>attach a very different meaning to it from that which I clearly

Well, I appreciate the clarification (and my apologies for misunderstanding
your out-of-context remark) ... but reading back over that paragraph, I
still get the same meaning out of it.  *shrug*

--Ken

---

From: "Richard E. Silverman" <[email-masked]>
Date: Tue, 13 Mar 2001 03:46:23 -0500 (EST)

> several commercial implementations of GSSAPI ftp.

I did not mean to imply otherwise.  Again, I meant "caught on" in the
largest sense.  I'm thinking in terms of what the average user sees,
sitting at home accessing the Internet through a commerical ISP and
browsing the Web.  I don't see many ISP's or general-access FTP servers
providing or advertising GSSAPI-secured FTP, or SSL-secured Telnet, etc.
I do see them installing SSH servers with growing frequency, advertising
that fact to their customers and suggesting they use it.

> > In the short time that it has existed, my impression is that SSH has
> > achieved much more widespread use than any of these techniques.
> 

Oh, I'm just going on subjective impressions here as well -- I don't have
any research at hand about the the relative numbers of these things
deployed in the Internet.  If such numbers exist, I'd love to see them.
Perhaps I'd be surprised.

> > Hence, an easy-to-use, comprehensive file-transfer protocol that
> > operates over SSH has a good chance of succeeding where these various
> > secured FTP's have failed."
> 

Obviously, I did not mean that they failed to work.  They work just fine.
I meant only that they have failed to become a widespread solution to the
problem of insecure file transfers.  Whether that's due to technical
disadvantages, or merely to historical accident, I wasn't really opining
either way.  In a certain sense, it doesn't matter -- if SSH becomes
widespread and we can piggyback on its success to solve this problem as
well, then so much the better.  A technically better solution is no better
if it's not used.

> widespread use on the Internet 

I'm afraid I still think it's not fair to yank those phrases out of
context, concatenate them together, and complain about their meaning when
set that way.  They were surrounded by text which gave a different story.
For instance, those other technologies *have* failed -- to gain the kind
of widespread acceptance that SSH appears to be gaining, thus "succeeding
where [they] have failed."  It still seems clear to me.  But then, I wrote
it. :)  Sorry if I gave a different impression to begin with, but I hope
we've cleared that up now.

> (if we're using the "widespead use over the Internet" benchmark, we
> should all be working furiously toward getting SMTP-over-TLS and
> HTTP-over-TLS working better :-) ).

No disagreement there.  I am frequently frustrated that these options,
available in many standard clients, are almost always only available on
the server side exactly where they are least needed.  You can find
SMTP/TLS on mail servers inside secured corporate networks, but almost
never on your ISP's mailbox server.  My preferred way of allowing updates
to a web server is HTTP PUT over TLS -- but most commercial web
development packages seem to provide support for vanilla, insecure FTP
only (Netscape Composer being the only exception I can think of offhand,
though I'm sure there are some others).  It's very annoying.

-- 
  Richard Silverman
  [email-masked]