[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CERT advisory
In <[email protected]> you write:
[Some items of interest to C-punks include CERT's advocacy of stopping
cleartext transmission of password (no shit sherlock), and their proposed
solutions, including the use of one-time passwords which I had queried about
on this list a few months back. Of course they don't mention any sort of
real encryption, let alone PGP. How hard would it be to build in PGP
security to the transmission layer of something like FTP? Seems like a
fairly simple problem, given that any site which supports anonymous FTP can
publish a public key. Even if we assume that encryption would slow down the
file transmission too much, we could still use it for the
login/authentication part of the session... --AW]
Since the command channel is flat ascii, one could extend the protocol
with a pgp-password command, which would send the password encrypted in the
server's public key. Similarly one could use the sort of convention that
the wu-ftpd does to request encrypted files... simply request file.pgp,
just like you request file.z, file.gz, etc.
Of course, there really *ought* to be an RFC for it, but I'm thinking
something like a command
666 PGPL
-----BEGIN PGP MESSAGE-----
...
-----END PGP MESSAGE-----
which would send an encrypted login and password.
The other piece to hack up would be the ftp client, it would have to
ask for your login/password on the ftp server host, then crank that
through pgp, and send an ELOGIN command down the socket -- no problem.
The big issue, in my mind, is how the ftpd is going to get the key
to unlock the *system's* private key... Do you compile it into the
code? Should ftpd ask for it when it comes up?
Marc