I am not Miguel Flores. I have no idea who he is. I do not know why he replied to my question with his own question since it's not clear they're related.

In your reply, Dan, you've misattributed who wrote what. I'll see if I can straighten it out. I've also reverted the Subject line back to my Subject and not Miguel's.

On Jan 8, 2014, at 2:19 PM, Dan Fandrich <dan_at_coneharvesters.com> wrote:

> On Wed, Jan 08, 2014 at 07:31:18PM +0000, Flores,Miguel,NORTH YORK,LGO Business Connections wrote:
>> I use the command below:
>>
>> curl -3 -v --cacert /home/adm/ssl/certs/cert.pem --disable-epsv
>> --ftp-skip-pasv-ip --ftp-ssl -T "/adm/FILE.TXT" ftp://User:Password@URL:990
>
> You're specifying an explicit SSL FTP connection here, but giving the implicit
> SSL FTP port (990). That won't work on a normally-configured server.

I didn't write the above (I'm not Miguel).

>> However, when I instead do:
>>
>> curl --insecure ftps://localhost:21/hello.txt
>
> And you're doing the opposite here: specifying an implicit SSL FTP transfer
> (ftps:) but specifying the normal FTP port number (21). If you just drop the
> port numbers in both the above commands, you may find that both of them work.

I did write the above (not Miguel). I specified the port explicitly because the ProFTPD server is listening only on port 21. From the ProFTPD mini-HOWTO on FTP and SSL/TLS <http://www.proftpd.org/docs/howto/TLS.html>:

> Question: How come mod_tls does not support "implicit" FTPS (i.e. automatically encrypting sessions on port 990)?

> Answer: The short answer is because the Draft no longer specifies support for such a mode. Here is a description of why the alternatives to the current mode (client-requested encryption using standard control channel) are "bad".
>
> The long answer is covered in Eric Rescorla's excellent book, "SSL and TLS". There tend to be two different strategies used when adding new features to a protocol: separate ports for protocol variants, or upward negotiation. Port 443 for HTTPS is an example of the separate ports strategy. The drawback to the separate ports approach is that there is a finite number of ports available, and so this approach does not scale well. The benefit is that use of separate ports tends to require smaller changes to client and server code. Upward negotiation is more flexible, but requires that the protocol support some sort of feature negotiation or extension discovery, allowing clients and servers to easily agree to negotiate "upward" into a secure channel. The authors of the FTPS Draft felt that upward negotiation was the more appropriate of these two approaches for encrypting FTP channels.

However, after reading that, I did some more digging and discovered the ProFTPD "TLSOptions UseImplicitSSL" configuration directive. The light bulb went on in my head that there's 2 flavors of FTP/SSL: explicit (ftp + subsequent request for SSL) and implicit (ftps).

I created a VirtualHost for ProFTPD and it's now also listening on port 990. After doing that, it works. So I guess never mind. (But at least I was nudged in the right direction; thanks.)

- Paul

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-01-09