On Mon, 8 May 2017, Paul Howarth wrote:

> Whilst testing TLS support in proftpd, I found that curl does not re-use the
> control connection TLS session for the data connection, which appears to be
> a well-known thing:

Ah, you speak of TLS session ID.

Yes, now that you mention this I recall someone once mentioned something about
this effect. Nobody has filed an issue for this nor fixed it with a patch or
pull-request so I forgot about it. (In typical me fashion :-)

Session ID resumption was introduced in TLS as a way to shortcut the TLS
handshake like when you want to resume a disconnected connection to the same
server. curl certainly supports this, but it only asks for resumption if you
connect back to the same scheme, host and port number as before. We did it
like this a long time ago and this FTPS style of using session id has never
been documented/promoted in a way that reached me until just recently when I
heard of this proftpd feature.

As you know, the FTP data connection is done on a different port than the
control connection so not even is it not really a "resumed session", the curl
logic won't consider the new connection worth of resumption due to the
mismatch in port - and probably also mismatch in host name as the second
connection tends to be made to an IP while the initial is often a host name...

This can certainly be fixed. It's just code that needs to be tweaked.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html