Skip to content

[PoC] macos-native-tls-issue: Solving native-tls issue on MacOS

⚠️ This MR serves as a Proof of Concept and is not meant to be merged. It is meant to showcase the issue and to determine the next steps.

ℹ️ Related issue: #2117 - Users on MacOS encounter issues when trying to use native-tls, they consistently get the error Error: connection closed via error.

In the linked ticket I wrote that my initial thought was that native-tls isn't working in MacOS because it uses Apple's Secure Transport (deprecated) under the hood, and the implementation of Arti's DataStream is not compatible with what Secure.Transport expects from the passed I/O socket. This thought was on the right track.

Arti's DataStream buffers data internally before actually sending it (see tor_proto/stream/data.rs:L108), this is an intentional design choice to improve performance. But Secure.Transport expects the I/O socket to send the data immediately. Not sending data immediately somehow causes it to timeout and yield an error.

In this MR I edited the hyper-http-client-example to implement a small custom transport called CustomAutoFlush which does not do buffering, but immediately flushes after write, and flushes before read. This way, native-tls works fine on MacOS.

ℹ️ Conclusion: The design choice to do internal buffering in Arti's DataStream is not compatible with Apple's Secure.Transport used by native-tls on MacOS.

Next steps? So with this information, what are the next steps? As I see it the most viable option is to alter the behavior of DataStream to flush immediately when native-tls is used and the compile target is MacOS.

/cc @opara

Edited by Niel Duysters

Merge request reports

Loading