Network Framework

Are you talking about TLS sessions?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes, in TLS session, my idea is to enable the TLS Session Resumption and TLS False Start. I used below code with the help of Network Framework in my project but unable to get success.

let tlsOptions = NWProtocolTLS.Options()

sec_protocol_options_set_tls_resumption_enabled(tlsOptions.securityProtocolOptions, true) sec_protocol_options_set_tls_false_start_enabled(tlsOptions.securityProtocolOptions, true)

What TLS versions does your server support?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Our server support TLS1.3

Have you tried it without enabling false start?

I don’t think that’s a factor, but I want to rule it out before going further.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I have a very similar challenge. I am working on extending a legacy FTP BSD/POSIX/UNIX sockets client code base (not libcurl) with RFC4217 "Secure FTP with TLS" support using Network.framework.

The first step in that effort was abstracting away BSD/POSIX/UNIX sockets into a FTP channel abstraction. I created a TCP channel type to do so and have BSD/POSIX/UNIX sockets and Network.framework implementations working equally well with "clear" operations.

I then moved onto implementing the easier / simpler "implicit" TLS support for Network.framework with a new TLS channel abstraction. That was reasonably straightforward and works with some FTPS server implementations; however, the majority return "425: Cannot secure data connection - TLS session resumption required." when trying to secure the data channel.

I then moved onto implementing the more difficult "explicit" TLS support for Network.framework, based on the nw_framer_t pass-through approach intimated at this forum post. After some refinement for generalization, that worked well enough, at least for the "AUTH TLS" FTP command on the FTP control channel.

However, once again, when attempting to secure the data channel with the TCP w/ Opportunistic TLS channel type, many servers respond with same "425: Cannot secure data connection - TLS session resumption required." witnessed before with the implicit TLS channel type.

This forum thread seems the "freshest" on this topic and after surveying the macOS 14.7 "Sonoma" Network.framework documentation, I do not see any clear way to get the TLS session context or identifier from the secure FTP control channel to then pass and reuse for the secure FTP data channel.

Any insights or examples would be greatly appreciated.

DTS case identifier 11028404.

Lemme start with some context. The FTP protocol specs are always fabulously vague, and RFC 4217 is no exception. AFAICT it’s only comment on this subject is:

It is reasonable for the server to insist that the data connection uses a TLS cached session. This might be a cache of a previous data connection or of a cleared control connection. If this is the reason for the refusal to allow the data transfer, then the '522' reply should indicate this.

There are two problems with this:

• It not exactly clear as to why the server might insist on that. That is, is this for performance or for security?

• In your case the server is failing with 425 not the mandated 522.

I’ve looked at this before — probably as part of a DTS case rather than here on the forums [1] — and my understanding is that such servers require:

• The use of TLS 1.2 or earlier, which use the traditional session_id field for their abbreviated handshake.

• That the client sends its data connection ClientHello with a session_id value that matches the session_id returned by the server for the control connection.

See section 7.3 of RFC 5246 for more background on this.

Does that gel with your understanding?

If so, there’s no way to do this with Network framework. The relevant APIs here are the metadata APIs in <Security/SecProtocolMetadata.h> and the option APIs in <Security/SecProtocolOptions.h>, and neither of them exposed the notion of the session ID.

I believe that it is possible to do this with Secure Transport. With that API the session cache — see QA1727 TLS Session Cache — is indexed by the peer ID that you specify with SSLSetPeerID. If you use the same peer ID for the control and data connections, Secure Transport attempts to use an abbreviated handshake on the data connection based on the state cached by the control connection.

If you’d like to see this supported by Network framework, I encourage you to file an enhancement request describing your requirements. Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Oh, hey, that’s not quite right. It turns out I first hit this in a MacNetworkProg thread back in 2011. But there have been a number of DTS cases about this over the years. The trick was to search for SSLSetPeerID!

For the particular server I've been testing against, since it does not do a typical server announce on connection, I am unclear of its implementation.

However, for vsftpd (a popular FTP server), there is this blog post <https://scarybeastsecurity.blogspot.com/2009/02/vsftpd-210-released.html> that talks about the following setting added in 2.1.0:

require_ssl_reuse If set to yes, all SSL data connections are required to exhibit SSL session reuse (which proves that they know the same master secret as the control channel). Although this is a secure default, it may break many FTP clients, so you may want to disable it. For a discussion of the consequences, see http://scarybeastsecurity.blogspot.com/2009/02/vsftpd-210-released.html (Added in v2.1.0). Default: YES

Made feature request 11147232.

For what it is worth, I was able to recode the explicit FTPS with TCP with opportunistic TLS using the deprecated Secure Transport interfaces, with the SSLSetPeerID being the most important one absent from Network.framework, and was able to successfully do RFC4217 Secure FTP with TLS on both secure control-only channel as well as control+data channels as follows:

Uname: Darwin|aesop.local|23.6.0|Darwin Kernel Version 23.6.0: Fri Nov 15 15:13:28 PST 2024; root:xnu-10063.141.1.702.7~1/RELEASE_X86_64|x86_64
Sysinfo: Mac OS X 14.7.2 (Build 23H311)
Channel model: Network.framework
Channel security: Secure Transport
"control" channel (0x60d000000c70) state did change: "<unknown>" (0) -> "initialized" (1)
"control" channel (0x60d000000c70) state did change: "initialized" (1) -> "opened" (2)
"control" channel (0x60d000000c70) state did change: "opened" (2) -> "connecting" (10)
"control" channel (0x60d000000c70) state did change: "connecting" (10) -> "connected" (11)
220: Welcome to test.rebex.net!
         See https://test.rebex.net/ for more information and terms of use.
     If you don't have an account, log in as 'anonymous' or 'ftp'.
Connected to test.rebex.net.
Cmd: FEAT
211: Supported extensions:
      AUTH TLS;SSL;
      CDUP
      CLNT
      CSID
      EPSV
      EPRT
      MDTM
      MFMT
      MLST Type*;Modify*;Create*;Win32.ea;Size*;
      PASV
      PBSZ
      PORT
      PROT C;P;
      REST STREAM
      SIZE
      TVFS
      UTF8
     End.
Cmd: HELP SITE
214: 'SITE' - Custom commands.
Cmd: AUTH TLS
234: Switching to TLS.
TLS 1.2 connection using cipher ECDHE-RSA-AES128-GCM-SHA256
SSL state is connected
Cmd: USER anonymous
331: Anonymous login OK, send your complete email address as your password.
Cmd: PASS user@
230: User 'anonymous' logged in.
Logged in to test.rebex.net as anonymous.
Cmd: FEAT
211: Supported extensions:
      AUTH TLS;SSL;
      CDUP
      CLNT
      CSID
      EPSV
      EPRT
      MDTM
      MFMT
      MLST Type*;Modify*;Create*;Win32.ea;Size*;
      PASV
      PBSZ
      PORT
      PROT C;P;
      REST STREAM
      SIZE
      TVFS
      UTF8
     End.
Cmd: HELP SITE
214: 'SITE' - Custom commands.
Cmd: PBSZ 0
200: 'PBSZ' OK.
Cmd: PROT P
200: 'PROT' OK.
Cmd: PWD
257: "/" is current directory.
Cmd: TYPE I
200: TYPE set to I.
"data" channel (0x60c000017c80) state did change: "<unknown>" (0) -> "initialized" (1)
"data" channel (0x60c000017c80) state did change: "initialized" (1) -> "opened" (2)
Cmd: PASV
227: Entering Passive Mode (194,108,117,16,4,19)
"data" channel (0x60c000017c80) state did change: "opened" (2) -> "bound" (8)
"data" channel (0x60c000017c80) state did change: "bound" (8) -> "connecting" (10)
"data" channel (0x60c000017c80) state did change: "connecting" (10) -> "connected" (11)
TLS 1.2 connection using cipher ECDHE-RSA-AES128-GCM-SHA256
SSL state is connected
Connected to 194.108.117.16:1043 for PASV.
Cmd: RETR readme.txt
150: Opening 'BINARY' data connection.
Welcome to test.rebex.net!

You are connected to an FTP or SFTP server used for testing purposes
by Rebex FTP/SSL or Rebex SFTP sample code. Only read access is allowed.

For information about Rebex FTP/SSL, Rebex SFTP and other Rebex libraries
for .NET, please visit our website at https://www.rebex.net/

For feedback and support, contact support@rebex.net

Thanks!
"data" channel (0x60c000017c80) state did change: "connected" (11) -> "closing" (6)
"data" channel (0x60c000017c80) state did change: "closing" (6) -> "closed" (7)
226: Transfer complete.
Cmd: QUIT
221: Closing session.
"control" channel (0x60d000000c70) state did change: "connected" (11) -> "closing" (6)
"control" channel (0x60d000000c70) state did change: "closing" (6) -> "closed" (7)