Article delegate-en/1115 of [1-5169] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
search
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
[Reference:<_A1106@delegate-en.ML_>]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: delegate as FTPS-proxy blocks
20 Apr 2001 11:34:53 GMT dirk laurijssen <piucabdyi-n4ll7kdx4nxr.ml@ml.delegate.org>


Hi,
I did some comparison between various FTPS-clients. They all seem to live up to
the IETF-recommandations, meaning that they all no longer support implicit FTP,
and went to supporting RFC2228.

Basically like you mentioned before they are waiting for an AUTH TLS of some sort
to initiate the SSL-session.

I'm aware that it will mean a lot of effort, but do you think that it is
feasible/possible to support this behaviour in delegate ?

Thanks & kind regards,
dirk L.

Yutaka Sato wrote:

> On 04/17/01(16:50) I wrote in <_A1100@delegate-en.ML_>
>  | |Is this setup even possible ?
>  |
>  |If the client can be configured to use SSL without negotiation,
>  |at least the control-connection will be relayed with the FTP-DeleGate
>  |with FCL=sslway.  And the enclosed patch will make FTP-DeleGate apply
>  |the FCL=sslway to each data-connection too.  I checked two chained
>  |FTP-DeleGates with FSV=sslway and FCL=sslway respectively do
>  |SSL data-connection by the patch.  But I don't know if there is a
>  |client or a server which goes this way.
>  |
>  |Maybe I will read following documents and support them, in near future.
>  |
>  |  RFC2228 (Oct.1997)
>  |  draft-murray-auth-ftp-ssl-07.txt (Apr.2001)
>
> I found the answer in the internet-draft:
>
> <URL:http://www.ietf.org/internet-drafts/draft-murray-auth-ftp-ssl-07.txt>
> >A.  Deprecated SSL negotiation mechanisms
> >
> >  There are two other mechanisms that have been used for FTP over SSL,
> >  these mechanisms do not conform to [RFC-2228] and so are now
> >  deprecated.  They are documented below.
> >
> >  i) Implicit SSL protection of the FTP session
> >
> >     There is a port, registered with the IANA, for secure FTP using
> >     ssl {FTP-TLSPORT}.  This approach can be likened to the [RFC-2818]
> >     approach for https, in that the SSL negotiation happens upon
> >     connection  (for the control and all data connections).  This
> >     approach is not favoured by the IETF and should not be used for
> >     new FTP-TLS implementations.
>
> Although deprecated now, this implicit approach using a dedicated
> FTP-TLSPORT, ie. "FTPS" port (990), is the very one which is implemented
> in DeleGate with the patch in my previous message.
>
> Cheers,
> Yutaka
> --
>   @ @ Yutaka Sato <y.sato@delegate.org> http://www.delegate.org/y.sato/
>  ( - ) National Institute of Advanced Industrial Science and Technology (AIST)
> _<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan


  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
@_@V