[9fans] Secure ftp Again

[9fans] Secure ftp Again

[Gregory Pavelcak]

A couple of weeks ago, I posted saying that I couldn't connect
to an ftp server. I got the message "No non-SSL connections
allowed" (Or something like that). I said that I had looked at
ssl(3), but couldn't see how to use it.

Someone (Russ Cox???. I forget now.) replied saying that I 
probably needed to be looking at tls and pushtls. Well, I have.
I hate to be a bonehead about this, but I still don't see how
to make use of these things. The tips pages have nice things
for ordinary users like mounting cds and using cdfs. Would
anyone be kind enough to walk me through making secure
ftp connections in a `tip o' the day' sort of way.

Thanks.

Greg

Re: [9fans] Secure ftp Again

[Russ Cox]

> Someone (Russ Cox???. I forget now.) replied saying that I
> probably needed to be looking at tls and pushtls. Well, I have.
> I hate to be a bonehead about this, but I still don't see how
> to make use of these things. The tips pages have nice things
> for ordinary users like mounting cds and using cdfs. Would
> anyone be kind enough to walk me through making secure
> ftp connections in a `tip o' the day' sort of way.

I'm not sure anyone here has ever used FTP over SSL,
so we're not very forthcoming with recipes.  However,
it looks like there are two ways people do FTP over SSL.
The first is by connecting to port 990 and SSL-encrypting
the entire connection.  If this is what you're supposed to
be doing, then running
    tlsclient tcp!yourserver!990
should give you something like "220 ftp server ready".
If so, you need to change ftpfs/hget to pushtls after 
connecting:
    TLSconn conn;
    fd = dial(etc.);
    memset(&conn, 0, sizeof conn);
    fd = tlsClient(fd, &conn);
instead of just calling dial.

The other way appears to be to send an "AUTH TLS"
command during the session, and if you get a 234 
response back, to then push TLS using the last two 
lines above.  If you do this you will also have to reinitialize
the i/o buffers, if any, with the new file descriptor.

http://www.ietf.org/internet-drafts/draft-murray-auth-ftp-ssl-16.txt
has what appears to be up-to-date info about TLS and FTP.

For examples of pushing TLS onto connections, grep for
tlsClient in /sys/src/cmd/hget.c (like the first case)
or /sys/src/cmd/upas/fs/imap4.c (also like the first case)
or /sys/src/cmd/upas/fs/pop3.c (the needssl code is like
the first case; the needtls code is like the second;
pop3pushtls illustrates reinitializing the i/o buffers).

Russ

Re: [9fans] Secure ftp Again

[lucio]

Now I'm going to be a bonehead:

> If so, you need to change ftpfs/hget to pushtls after 
> connecting:
>     TLSconn conn;
>     fd = dial(etc.);
>     memset(&conn, 0, sizeof conn);
>     fd = tlsClient(fd, &conn);
> instead of just calling dial.

Shouldn't this be done by enhancing dial to understand a TLS
qualifier?  How difficult would that be?  I'm a lot better at trivial
changes, maybe I can figure my way around it if it makes sense.

Suggestions?

++L

Re: [9fans] Secure ftp Again

[Russ Cox]

> > If so, you need to change ftpfs/hget to pushtls after
> > connecting:
> >     TLSconn conn;
> >     fd = dial(etc.);
> >     memset(&conn, 0, sizeof conn);
> >     fd = tlsClient(fd, &conn);
> > instead of just calling dial.
>
> Shouldn't this be done by enhancing dial to understand a TLS
> qualifier?  How difficult would that be?  I'm a lot better at trivial
> changes, maybe I can figure my way around it if it makes sense.

changing dial? no.  writing a tlsdial?
maybe, but it doesn't happen very often.
what's more common is that you connect,
talk plaintext for a little while, and then decide
to start tls.  i don't think there are enough
instances yet to know what the common case is.

russ

Re: [9fans] Secure ftp Again

[Devon H. O'Dell]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

On Sun, Apr 03, 2005 at 08:36:56AM -0500, Russ Cox wrote:
> > > If so, you need to change ftpfs/hget to pushtls after
> > > connecting:
> > >     TLSconn conn;
> > >     fd = dial(etc.);
> > >     memset(&conn, 0, sizeof conn);
> > >     fd = tlsClient(fd, &conn);
> > > instead of just calling dial.
> >
> > Shouldn't this be done by enhancing dial to understand a TLS
> > qualifier?  How difficult would that be?  I'm a lot better at trivial
> > changes, maybe I can figure my way around it if it makes sense.
> 
> changing dial? no.  writing a tlsdial?
> maybe, but it doesn't happen very often.
> what's more common is that you connect,
> talk plaintext for a little while, and then decide
> to start tls.  i don't think there are enough
> instances yet to know what the common case is.
> 
> russ

It seems to be pretty standard protocol to me. Exchange, verify,
encrypt. The original IETF draft is at

http://www.ford-hutchinson.com/~fh-1-pfh/draft-murray-auth-ftp-ssl-05.txt

and every current popular FTP client implements it, so there
should be plenty of source with a friendly license out there.

--Devon

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] Secure ftp Again

[Russ Cox]

> > changing dial? no.  writing a tlsdial?
> > maybe, but it doesn't happen very often.
> > what's more common is that you connect,
> > talk plaintext for a little while, and then decide
> > to start tls.  i don't think there are enough
> > instances yet to know what the common case is.
> >
> > russ
> 
> It seems to be pretty standard protocol to me. Exchange, verify,
> encrypt. The original IETF draft is at

i was talking about tls, not the ftp tls.
i agree that the tls ftp looks standard,
but i don't know of any ftp servers that
actually implement it (or why they would!)
so i have nothing to test against.
i also don't understand how much auth
is supposed to happen before you start tls.
it's all a little weird.

> and every current popular FTP client implements it, so there
> should be plenty of source with a friendly license out there.

i'm not worried about this either.  it's only a
couple of lines of code.  no need to copy
someone else.

russ

Re: [9fans] Secure ftp Again

[lucio]

> changing dial? no.  writing a tlsdial?

The dial interface ought to remain unchanged, or at the very least
compatible (that's the hard bit).  But considering that TLS is an
additional layer, you'd think that the right way to implement it would
be as a layered device.  I have been known to misunderstand these
things, though, so I'd best go do some reading first :-)

As for your reservations about common occurrences, I do see your
point.

++L

Re: [9fans] Secure ftp Again

[geoff]

If one were going to add TLS dialing as a standard facility, I'd
suggest adding it to cs, not dial, perhaps as a qualifier similar to
"!r": tcp!host!ftp!tls.  This would make TLS dialing available
uniformly and immediately to all programs, without recompilation, and
even to command-line usage.

Re: [9fans] Secure ftp Again

[Russ Cox]

> If one were going to add TLS dialing as a standard facility, I'd
> suggest adding it to cs, not dial, perhaps as a qualifier similar to
> "!r": tcp!host!ftp!tls.  This would make TLS dialing available
> uniformly and immediately to all programs, without recompilation, and
> even to command-line usage.

since icann has deprecated having separate
"automatically start tls after connecting" tcp ports
for services, tweaking any of these is not very useful.
for example (and this was my point earlier, which
i did not make very clearly) in ftp you have to
send an "AUTH TLS" and have the server send back
a success response before you start tls.  other
protocols have similar protocol-specific negotiation
phases.

also, adding it to cs requires having /net/tcp understand
the !tls qualifier (cs just passes !r into the tcp dial string),
which would mean having the gory public-key certificate
etc. part of tls in the kernel (or in a separate user-space
network stack).

russ

Re: [9fans] Secure ftp Again

[geoff]

I hadn't heard about the icann deprecation; do you have a pointer to
it?

I guess I'd been thinking that cs would strip !tls from the end before
passing the modified string (containing IP address rather than domain
name) to /net/tcp, though I suppose access to certificates would be
complicated by having cs, running as hostowner, start TLS.  Sounds
like it's now moot anyway.

Re: [9fans] Secure ftp Again

[geoff]

Googling turns up references to the IESG being opposed to `separate
ports' for using TLS and not using TLS under some protocol.  Of course
a new protocol could run only over TLS and thus use some form of
tlsdial().

Re: [9fans] Secure ftp Again

[lucio]

> I hadn't heard about the icann deprecation; do you have a pointer to
> it?
> 
I hope that's IETF, if it's ICANN, it certainly doesn't carry much
weight outside the US ;-)

> I guess I'd been thinking that cs would strip !tls from the end before
> passing the modified string (containing IP address rather than domain
> name) to /net/tcp, though I suppose access to certificates would be
> complicated by having cs, running as hostowner, start TLS.  Sounds
> like it's now moot anyway.

Can certificates not be served in a factotum fashion?  I've been
scratching my head over PEM and its cousins for a while and I feel
Plan 9 has the right infrastructure to at least alleviate this
particular migraine.

In fact, there are many such corners of the IT universe that could do
with ambitious redesign within the Plan 9 namespace paradigm, I'd like
to see a forum where these are discussed and, hopefully, brought to
maturation.  I suspect 9fans is inappropriate as there is (sorry for
stealing your wind, Choate) an entry barrier to those with ideas but
no code to contribute.

That said, I agre that code contribution is the way to go, I just wish
I had the stamina for it.

++L

Re: [9fans] Secure ftp Again

[Russ Cox]

> I hope that's IETF, if it's ICANN, it certainly doesn't carry much
> weight outside the US ;-)

actually i meant iana or whoever is giving out
port numbers these days.

russ

Re: [9fans] Secure ftp Again

[Lyndon Nerenberg]

--On 2005-4-3 4:05 PM -0700 geoff@collyer.net wrote:

> If one were going to add TLS dialing as a standard facility, I'd
> suggest adding it to cs, not dial, perhaps as a qualifier similar to
> "!r": tcp!host!ftp!tls.  This would make TLS dialing available
> uniformly and immediately to all programs, without recompilation, and
> even to command-line usage.

But the trend is towards negotiating TLS after chatting over the 
connection a bit. IMAP, SMTP, and POP all have a separate command to 
start up TLS. (Yes, there is an unofficial "imaps" that I expect to 
slowly die out now that RFC3501 has made STARTTLS mandatory to 
implement.)

So adding "...!tls" to cs doesn't really solve the general case.

--lyndon

Re: [9fans] Secure ftp Again

[Micah Stetson]

> But the trend is towards negotiating TLS after chatting over the
> connection a bit. IMAP, SMTP, and POP all have a separate command to

Let's implement Transport Layer Security inside all our application
layer protocols!

Micah

Re: [9fans] Secure ftp Again

[lucio]

> Let's implement Transport Layer Security inside all our application
> layer protocols!

I can see the logic in the IESG (thanks, again, Geoff) mandating TLS
as a negotiated layer _and_ I can see the nightmare it gives rise to.
Properly designed, this means there is a single implementation of TLS
(Russ's comments about a TLS-savvy kernel, more likely a kernel module
in the brave new world after Linux) and a reality of each school
implementing it slightly differently and totally incompatibly.

My gut feel is that applying namespace rules (OK!) would alleviate the
nightmare, just as factotum very successfully simplifies a different
aspect of security.

++L

Re: [9fans] Secure ftp Again

[geoff]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

Avoiding this was sort of thing was surely part of the motivation for
IPsec, but presotto points out (I hope I'm not misrepresenting him)
that implementing IPsec, at least in the kernel, is messy, requiring
lots of state and the ability to interrupt and restart cryptographic
computations at awkward times.  I've wondered off and on if it might
be feasible and cleaner in a user-mode file server.  tcpmux (rfc 1078)
looks easier in user-land.

[-- Attachment #2: Type: message/rfc822, Size: 3266 bytes --]

From: Micah Stetson <micah.stetson@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] Secure ftp Again
Date: Sun, 3 Apr 2005 20:01:30 -0700
Message-ID: <b3b4f6f305040320013c9864a9@mail.gmail.com>

> But the trend is towards negotiating TLS after chatting over the
> connection a bit. IMAP, SMTP, and POP all have a separate command to

Let's implement Transport Layer Security inside all our application
layer protocols!

Micah

Re: [9fans] Secure ftp Again

[C H Forsyth]

>>tcpmux (rfc 1078) looks easier in user-land.

has that ever been much used?

Re: [9fans] Secure ftp Again

[boyd, rounin]

i'd say dial should be left along and a lib written
to help setup and talk tls across the established
connection.
--
MGRS 31U DQ 52572 12604

Re: [9fans] Secure ftp Again

[Russ Cox]

> i'd say dial should be left along and a lib written
> to help setup and talk tls across the established
> connection.

that's already done.  believe me,
there's already an enormous library (and a kernel
driver) sitting under the

    fd = tlsClient(fd, &conn);
    free(conn.cert);

lines. 

russ

Re: [9fans] Secure ftp Again

[geoff]

[-- Attachment #1: Type: text/plain, Size: 106 bytes --]

I believe it's been used a little.  If there were more implementations,
it would probably be used more.

[-- Attachment #2: Type: message/rfc822, Size: 2260 bytes --]

From: C H Forsyth <forsyth@vitanuova.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Secure ftp Again
Date: Mon, 4 Apr 2005 12:09:05 +0100
Message-ID: <b9bf798828851c194102adc76d981f58@vitanuova.com>

>>tcpmux (rfc 1078) looks easier in user-land.

has that ever been much used?

Re: [9fans] Secure ftp Again

[Tim Newsham]

> Avoiding this was sort of thing was surely part of the motivation for
> IPsec, but presotto points out (I hope I'm not misrepresenting him)
> that implementing IPsec, at least in the kernel, is messy, requiring
> lots of state and the ability to interrupt and restart cryptographic
> computations at awkward times.

Most of the complexity in IPSEC lies in the key negotiation protocol. 
The actual per-packet handling (encryption and authentication) is pretty 
simple. The key negotiation protocols do not need to reside in the kernel, 
in fact in most implementations they do not.

Tim Newsham
http://www.lava.net/~newsham/

Re: [9fans] Secure ftp Again

[Christoph Lohmann]

Good evening.

On Sat, 2 Apr 2005 18:11:59 -0500
Gregory Pavelcak <g.pavelcak@comcast.net> wrote:

> A couple of weeks ago, I posted saying that I couldn't connect
> to an ftp server. I got the message "No non-SSL connections
> allowed" (Or something like that). I said that I had looked at
> ssl(3), but couldn't see how to use it.
> 
> Someone (Russ Cox???. I forget now.) replied saying that I 
> probably needed to be looking at tls and pushtls. Well, I have.
> I hate to be a bonehead about this, but I still don't see how
> to make use of these things. The tips pages have nice things
> for ordinary users like mounting cds and using cdfs. Would
> anyone be kind enough to walk me through making secure
> ftp connections in a `tip o' the day' sort of way.
> 
> Thanks.
> 
> Greg

I submitted a patch (/n/sources/patch/ftpfs-auth-tls), which adds
the option -t for AUTH TLS to ftpfs. It seems to be what you need,
if the server you want to connect to supports TLSv1 or SSLv3.

Sincerly,

Christoph