Connecting to Azure SQL with tokio (on mac) gives a Tls connection closed via error.

[AdsSengupta]

this is my code

let mut config = Config::from_ado_string("server=xxx.database.windows.net,1433;UID=xxx;PWD=xxx;TrustServerCertificate=true")?;
let tcp = TcpStream::connect(config.get_addr()).await?;
tcp.set_nodelay(true)?;
let mut client = Client::connect(config, tcp.compat_write()).await.expect("Failed!");

and I get
thread 'main' panicked at 'Failed!: Tls("connection closed via error")', src/main.rs:80:22

[AdsSengupta]

It works without issues on Windows except that the username needs to be set as [email protected]

[pimeys]

What version? I remember @esheppa fixing this a while ago already.

[parkerp1]

@pimeys Has there been a solution to this? I am currently running into this issue for my own project.
We are using version 0.4.8

[AdsSengupta]

I ended up using ODBC since it doesn't work on the latest release.

[AdsSengupta]

I believe it's a mac TLS issue since it works on Linux

[pimeys]

We might need a developer using a Mac to fix this issue... Sent from ProtonMail mobile

…

-------- Original Message --------

On Aug 13, 2020, 19:58, Ads Sengupta wrote: I believe it's a mac TLS issue since it works on Linux — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](#65 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAAIRF3IP6PU4LX2UKT7YBDSAQSUPANCNFSM4OPESXQA).

[parkerp1]

@AdsSengupta I ended up using ODBC as well

[pimeys]

It seems to be a problem with native-tls and Catalina:

sfackler/rust-native-tls#151

[pimeys]

It would be really nice if somebody could debug this a bit, forking Tiberius and then in their app then pointing to this fork and seeing certain things first:

• See if it fails with Tokio and async-std both
• If async-std works, maybe trying to patch async-native-tls in Cargo.toml with

async-native-tls = { version = "0.4", default-features = false, features = [ "runtime-tokio" ] }

If none of these work, the problem might be with the system certificates (Catalina has more strict rules how big the certificate needs to be compared to the older mac versions).

[pimeys]

Here's a ticket that might provide some useful information:

microsoft/azuredatastudio#6949

[pimeys]

And another one:

microsoft/mssql-docker#37

[pimeys]

I found a way to get TLS working on macOS and here's the plan how to move forward:

We create a new crate async-openssl that takes some code from native-tls and async-native-tls. This crate uses openssl always, and we can force vendoring to statically compile openssl.

From here Tiberius would have a new feature flag force-openssl that then uses this new crate instead of async-native-tls, and vendors openssl to the binary. I tried this approach by modifying native-tls to always use openssl and it definitely seems to fix connection issues on macOS.

Candidating for the next release.

[pimeys]

Hey all! TLS should now work on macOS systems. With no additional feature flags you must have OpenSSL installed to your system before compiling Tiberius. You can also use a feature flag vendored-openssl to use the vendored version from crates.io, which links to it statically. This is probably not the best thing security-wise, but if you're not running a macOS server, only using it for development, why not?

Please open up a new issue if having problems.

[pimeys]

Versions 0.5.2 and 0.4.19 are released with this fix.

[schneipp]

i'm sorry to bother you, but i'm having issues with the "vendored-openssl" feature flag on macos again.
Tested it on two machines, so i guess the problem is real.
.cargo/registry/src/github.com-1ecc6299db9ec823/tiberius-0.11.3/src/client/tls_stream.rs:39:1 | 31 | / pub(crate) async fn create_tls_stream<S: AsyncRead + AsyncWrite + Unpin + Send>( 32 | | config: &Config, 33 | | stream: S, 34 | | ) -> crate::Result<TlsStream<S>> { 35 | | native_tls_stream::create_tls_stream(config, stream).await 36 | | } | |_- previous definition of the valuecreate_tls_streamhere ... 39 | / pub(crate) async fn create_tls_stream<S: AsyncRead + AsyncWrite + Unpin + Send>( 40 | | config: &Config, 41 | | stream: S, 42 | | ) -> crate::Result<TlsStream<S>> { 43 | | opentls_tls_stream::create_tls_stream(config, stream).await 44 | | } | |_^create_tls_streamredefined here | = note:create_tls_stream` must be defined only once in the value namespace of this module

error[E0252]: the name TlsStream is defined multiple times
--> /Users/rams/.cargo/registry/src/github.com-1ecc6299db9ec823/tiberius-0.11.3/src/client/tls_stream.rs:20:16
|
14 | pub(crate) use native_tls_stream::TlsStream;
| ---------------------------- previous import of the type TlsStream here
...
20 | pub(crate) use opentls_tls_stream::TlsStream;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TlsStream reimported here
|
= note: TlsStream must be defined only once in the type namespace of this module
help: you can use as to change the binding name of the import
|
20 | pub(crate) use opentls_tls_stream::TlsStream as OtherTlsStream;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

error[E0308]: mismatched types
--> /Users/rams/.cargo/registry/src/github.com-1ecc6299db9ec823/tiberius-0.11.3/src/client/tls_stream.rs:43:58
|
43 | opentls_tls_stream::create_tls_stream(config, stream).await
| ^^^^^^ expected struct async_native_tls::TlsStream, found struct opentls::async_io::TlsStream
|
= note: expected enum std::result::Result<async_native_tls::TlsStream<S>, _>
found enum std::result::Result<opentls::async_io::TlsStream<S>, _>
`

[esheppa]

@schneipp - Because the default features block has default = ["tds73", "winauth", "native-tls"] you'll need to set default-features = false and then explicitly set tds73 along with your desired TLS implementation and any other features you require.

@pimeys this would be fixed by #237

[schneipp]

OH! Damn it - i'm so sorry! I had tiberius in my shared types folder for some macro magic where i didn't set the correct feature flags.
Everything works now as expected. Thank you!