Hi
I'm a volunteer for The Tor Project contributing to Arti. We are encountering a persistent problem that HTTPS requests consistently fail on MacOS when using native-tls
, more context on the issue can be found here and here.
In Arti we have a custom DataStream (data.rs#L105) which does internal buffering. On Linux making a request when using native-tls
works fine, but when executing the same code on MacOS we consistently get the error Error: connection closed via error
.
I did some thorough research and found out that native-tls
under the hood uses OpenSSL when ran on Linux and uses the deprecated Secure Transport when ran on MacOS.
My research also told me that OpenSSL has some advanced mechanics like e.g BIO which might somehow trigger an automatic flush of the internal custom DataStream provided by Arti - masking the fact that we are not flushing the buffer ourselves in DataStream. While Secure Transport does not have such a mechanism resulting in stalling the request because the data remains buffered in DataStream.
So my initial thought was that the OpenSSL C-implementation simply contains mechanisms which might trigger an auto-flush, while Secure Transport simply doesn't. And that this is not related to a Rust crate because they simple bridge to those low-level implementations.
But, I want to be sure it is not a possibility this is related to a specific Rust crate (e.g native-tls
or tokio-native-tls
) which has a bug not flushing when Secure Transport is used.
I am already researching this issue for a long time but lack the in-depth expertise in TLS implementations to find a conclusive answer. Thanks!