Implementing starttls with Network.framework

The Network framework does not currently support enabling (or disabling) TLS midstream (r. 44222634). Honestly, we’d rather not support that because it’s not great security-wise. However, it’s clear that there are situations where it’s absolutely required. If you’re in one of those situations, please file your own enhancement request describing your requirements.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks,

I will fill a request. This is needed to implement an XMPP-based chat client, as many servers only expose a single port with starttls support. A while back, the XMPP Standards Foundation has declared the pure TLS connection on port 5223 "legacy", so that's why starttls is the only option in many cases.

I will fill a request.

Thanks. Don’t forget to post the bug number here.

This is needed to implement an XMPP-based chat client …

And that sort of background info is exactly what needs to go in the bug report.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hi,

> Thanks. Don’t forget to post the bug number here.

Bug number is 45256384

Cheers,

Anything new on this front?

I wanted to implement STARTTLS with Network Famework for Monal (because implementing ALPN negotiation is only possible with Network Framework and not wit NSStream).

I would like to +1 this request, in my case it's required to implement a PostgreSQL client, which enables TLS midstream, after a STARTTLS message.

I agree that it's not ideal security wise, but there is a whole host of protocols (SMTP, PostgreSQL, XMPP, LDAP, etc) that use opportunistic DNS. When Network.framework is not offering the ability to enable TLS on an existing stream, it means that those applications are either

• Stuck with SecureTransport on macOS (which means they don't get TLS 1.3)

• Need to use a third party library like OpenSSL on top of Network.framework which means that don't get the macOS/iOS trust settings by default, which is would argue is worse for Security.

I've created a Feedback: FB8888057

We need this to enable a TLS connection through a Socks5 proxy (more specifically a Tor Socks5 proxy).
As the Socks5 protocol is very simple, it is no trouble creating our own implementation of its handshake. However, when connecting to an SSL secured TCP socket through a Socks5 proxy, we need to start TLS after the Socks5 handshake.

As this is not currently supported by Network.framework, is there any community library, or alternative way of achieving this ?

SOCKS proxy support with NWConnection would be an Enhancement Request. As a side note, you could also try connecting against the SOCKS proxy directly, and letting the proxy handle the connection upgrade for you on the remote side of the connection, but that type of configuration would have to be done outside of NWConnection.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

This is what we have implemented. It works so far, but it is far from optimal.

1. Open a raw client connection (which I'll call RCC) that connects to the remote without TLS.

2. Speak to the remote whatever protocol you need with RCC, until you need TLS.

3. Create a listener that listens on "127.0.0.1" port "0" (it will select a free port).

4. Only accept the first connection to that listener (which I'll call BLC for "bridge listener connection").

5. Bridge everything from BLC to RCC and from RCC to BLC.

6. Get the port P used by the listener (with nw_listener_get_port).

7. Open a secure client connection (which I'll call SCC) on port P with TLS enabled (but you need to set sec_protocol_options_set_peer_authentication_required(secOptions, false) to its security options.

8. Speak to the remote whatever protocol over TLS you need with SCC.

Code Block 
SCC <-----> BLC <-----> RCC
      tls         raw

We do know that disabling authentication on security options does lower TLS security significantly, but at least it's working.