cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: [PATCH] Compatibility flag for SecureTransport FTPS

From: Dan Nelson <dnelson_at_allantgroup.com>
Date: Sat, 8 Jul 2006 21:46:52 -0500

In the last episode (Jul 08), Daniel Stenberg said:
> On Fri, 7 Jul 2006, Dan Nelson wrote:
> > Tumbleweed's (formerly Valicert) Secure Transport server has the
> > ability to do client-certificate-only authentication in its FTPS
> > server, but it does it in a sort of annoying way. Instead of
> > sending USER/PASS commands, you have to send SITE AUTH, which tells
> > the server to pull the userid out of your client cert (which you
> > have already sent due to AUTH SSL negotiation).
>
> How very... silly.
>
> > Anyway, attached is a patch that adds a CURLOPT_FTP_SITE_AUTH
> > option (commandline flag --ftp-site-auth) that causes "SITE AUTH"
> > to be sent instead of "USER xxx". I think I've added docs in all
> > the right files.
>
> Thanks. I do however feel a bit reluctant to apply this patch since
> it is so _very_ specific to one particular (flawed) implementation of
> FTPS, and also since it does in fact require you to know this and
> manually select this option.
>
> 1) Won't it be better to let the option make libcurl send SITE AUTH
> only if the common USER approach doesn't work? Since then you can
> use this option for all servers and it would automatically work
> around this violation when need be.

Sending a "SITE AUTH" after a failed USER/PASS attempt does
authenticate correctly, so that would work. Just as long as it doesn't
encourage other vendors to start supporting that in their servers. RFC
4217 section 4.2 is pretty clear that this is the wrong way to do it:

   Although the TLS negotiation may be providing authentication
   information, the USER command MUST still be issued by the client.
   However, it will be a server implementation issue to decide which
   credentials to accept and what consistency checks to make between
   the client cert used and the parameter on the USER command.

I'm all for making it hard, but possible, to interoperate with broken
servers :)

> 2) I think (I'm not really done pondering over this subject and I would
> really value more feedback from others on this) that I would
> prefer a way for the app to provide the full custom command to
> send if the USER approach is not enough. I mean, the app would in
> this case not set CURLOPT_FTP_SITE_AUTH but would instead set
> CURLOPT_FTP_ALTERNATIVE_TO_USER to point to the string "SITE
> AUTH". It would then allow libcurl to be used for other similarly
> strange work-arounds without us having to add a new fix for each
> new incarnation...

That'd work for me too.

-- 
	Dan Nelson
	dnelson_at_allantgroup.com
Received on 2006-07-09