async-email / async-native-tls Goto Github PK

View Code? Open in Web Editor NEW

69.0 69.0 17.0 70 KB

Native TLS for futures and async-std

License: Apache License 2.0

Rust 100.00%

async-native-tls's People

Contributors

Stargazers

Watchers

Forkers

yoshuawuyts isgasho mehcode llebout frando flub alex-dukhno serzhiio windoze e00e spektom jbr tomusdrw icodein tomaszwaszczyk kr1tos

async-native-tls's Issues

Update to Tokio 1.0

It's a major first release which the whole ecosystem is supporting, so we should probably follow suit in order to provide better compatibility for lib users. I'm creating this issue so I can link and track from the web3 upgrade issue.

Publish a new release to crates.io?

It's been a long time since the latest release, and many important improvements have been merged into this crate, namely #25 (upgrade to tokio 1.0) and #18 (replace async-std with futures).

Is there any plan for a new release?

how to use openssl with async-std?

Like title

Allow compiling against OpenSSL on macOS

We're kind of hit by the issue of Apple's Secure Transport being super picky about certificates since macOS Catalina in Tiberius. We really can't change how Microsoft creates their certificates or what kind of certs Apple accepts. I was thinking could it be possible to force this crate to statically compile against OpenSSL, so we could distribute a version of Prisma for macOS that could talk TLS with SQL Server?

I don't know is this the right solution here, but that's how node.js solved the issues for their users: statically linking to OpenSSL on all platforms.

Connection randomly gives WouldBlock

When connecting to a TLS-enabled server with the crate, and using it together with async-std version 1.6.4 or later, the connection randomly throws an error with a message "operation would block".

This does not happen when using the crate together with async-std 1.6.3 or tokio.

RFC 9266: Channel Bindings for TLS 1.3 support

Can you add the support of RFC 9266: Channel Bindings for TLS 1.3?

https://datatracker.ietf.org/doc/html/rfc9266

Little details, to know easily:

tls-unique for TLS =< 1.2
tls-exporter for TLS = 1.3

Thanks in advance.

malloc_consolidate(): invalid chunk size

Thread 7 "async-std/execu" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff74b7700 (LWP 11374)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) backtrace
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7a61535 in __GI_abort () at abort.c:79
#2  0x00007ffff7ab8508 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7bc328d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007ffff7abec1a in malloc_printerr (str=str@entry=0x7ffff7bc4b68 "malloc_consolidate(): invalid chunk size") at malloc.c:5341
#4  0x00007ffff7abef2a in malloc_consolidate (av=av@entry=0x7fffec000020) at malloc.c:4471
#5  0x00007ffff7ac1a58 in _int_malloc (av=av@entry=0x7fffec000020, bytes=bytes@entry=16712) at malloc.c:3695
#6  0x00007ffff7ac356a in __GI___libc_malloc (bytes=16712) at malloc.c:3057
#7  0x00007ffff7f5ba3c in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.1
#8  0x00007ffff7f5b118 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.1
#9  0x00007ffff7f62265 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.1
#10 0x00007ffff7f6ccfa in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.1
#11 0x00007ffff7f6ce03 in SSL_read () from /lib/x86_64-linux-gnu/libssl.so.1.1
#12 0x0000555555a44bc1 in openssl::ssl::SslRef::read (self=0x7fffec267e00, buf=...) at /home/debian/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.10.26/src/ssl/mod.rs:2369
#13 0x0000555555767af9 in openssl::ssl::SslStream<S>::ssl_read (self=0x7fffe800a240, buf=...)
    at /home/debian/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.10.26/src/ssl/mod.rs:3408
#14 0x00005555557669cd in <openssl::ssl::SslStream<S> as std::io::Read>::read (self=0x7fffe800a240, buf=...)
    at /home/debian/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.10.26/src/ssl/mod.rs:3550
#15 0x000055555578f1d0 in <native_tls::imp::TlsStream<S> as std::io::Read>::read (self=0x7fffe800a240, buf=...)
    at /home/debian/.cargo/registry/src/github.com-1ecc6299db9ec823/native-tls-0.2.3/src/imp/openssl.rs:396
#16 0x00005555557567f0 in <native_tls::TlsStream<S> as std::io::Read>::read (self=0x7fffe800a240, buf=...)
    at /home/debian/.cargo/registry/src/github.com-1ecc6299db9ec823/native-tls-0.2.3/src/lib.rs:649
#17 0x00005555556f2749 in <async_native_tls::tls_stream::TlsStream<S> as futures_io::if_std::AsyncRead>::poll_read::{{closure}} (s=0x7fffe800a240)
    at /home/debian/.cargo/git/checkouts/async-native-tls-f8ca429da40dea5c/f995a78/src/tls_stream.rs:63
#18 0x00005555556f1df3 in async_native_tls::tls_stream::TlsStream<S>::with_context (self=0x7fffe800a240, ctx=0x7ffff74b6148, f=...)
    at /home/debian/.cargo/git/checkouts/async-native-tls-f8ca429da40dea5c/f995a78/src/tls_stream.rs:34
#19 0x00005555556f26fc in <async_native_tls::tls_stream::TlsStream<S> as futures_io::if_std::AsyncRead>::poll_read (self=..., ctx=0x7ffff74b6148, buf=...)
    at /home/debian/.cargo/git/checkouts/async-native-tls-f8ca429da40dea5c/f995a78/src/tls_stream.rs:63
#20 0x0000555555785683 in <futures_util::io::split::ReadHalf<R> as futures_io::if_std::AsyncRead>::poll_read::{{closure}} (l=..., cx=0x7ffff74b6148)
    at /home/debian/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.1/src/io/split.rs:39
#21 0x00005555557853ae in futures_util::io::split::lock_and_then (lock=0x7fffe8034d40, cx=0x7ffff74b6148, f=...)
    at /home/debian/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.1/src/io/split.rs:27
#22 0x000055555578562c in <futures_util::io::split::ReadHalf<R> as futures_io::if_std::AsyncRead>::poll_read (self=..., cx=0x7ffff74b6148, buf=...)
    at /home/debian/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.1/src/io/split.rs:39
#23 0x00005555557855c0 in <&mut T as futures_io::if_std::AsyncRead>::poll_read (self=..., cx=0x7ffff74b6148, buf=...)
    at /home/debian/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-io-0.3.1/src/lib.rs:321
#24 0x000055555576af52 in <futures_util::io::read::Read<R> as core::future::future::Future>::poll (self=..., cx=0x7ffff74b6148)
    at /home/debian/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.1/src/io/read.rs:28

Make a new release 0.5.0

cc @dignifiedquire

A new release with #32 merged is needed to replace https://lib.rs/crates/async-native-tls-alpn

Make async-std dependency optional

I'm not sure if this is possible, but it would be great if the async-std dependency could be made optional so that (like async-tls) this could also be used by other runtimes (e.g. the one from glib).

acceptor API

This is what I'm currently thinking for the acceptor API:

let key = File::open("identity.pfx").await?;
let acceptor = TlsAcceptor::new(key, "<password>").await?;
let listener = TcpListener::bind("0.0.0.0:8443")?;

for stream in listener.incoming() {
    let acceptor = acceptor.clone();
    let stream = stream?;
    task::spawn(move || {
        let stream = acceptor.accept(stream)?;
        // handle stream here
    });
}

TlsAcceptor::new would take impl Read as an argument, which allows both byte buffers, files and networked streams to be passed. Removing the manual "open file, create buffer, read into buffer" steps should make setup a lot easier.

We should also introduce a one-off accept function as a counterpart for TcpListener::accept and async_native_tls::connect:

let listener = TcpListener::bind("0.0.0.0:8443")?;
let stream = listener.accept().await?;

let key = File::open("identity.pfx").await?;
let stream = async_native_tls::accept(key, "<password>", stream).await?;
// handle stream here

pass through AsyncBufRead

If AsyncBufRead is implemented on T, the stream should expose it. This makes some implementations much more efficient. Thanks!

Align API with origin native-tls

TlsAcceptor::new accepts a file and a password as parameters. It goes against the constructor in the origin native-tls crate where it accepts Identity. Due to Identity is encapsulated from_pkcs8 method is missed.

I think this crate should extend the origin one, not override it.

Could you align API of both crates one to one? Or add other possibility to use from_pkcs8 method?

Add support for rusttls

The idea is to define common interfaces for TlsConnector etc. as traits and implement them in submodules like async_native_tls::rusttls::TlsConnector and async_native_tls::native_tls::client, so it is possible to conditionally use one module or the other, and compile implementations based on selected features.

See async-email/async-smtp#3 (comment)

Then probably rename the module or merge with async_tls.

This will make it possible to fix async-email/async-smtp#4 without conditional compilation.

convert from url::Url on connect / accept

tcp takes localhost:8080, http takes http://localhost:8080/foo/bar, tls takes localhost. Converting between all of these can be difficult to remember; it'd be great if TLS knew how to take a Url and get the relevant bits.

The way I'd do this would be to introduce a new type: Host that has From<&Url> and From<&str> impls. accept would then be:

pub async fn accept(host: impl Into<Host>, stream: impl Read + Write) -> Result;

This would make it lots easier to use TLS on top of existing streaming HTTP setups.

tests are not compiling

The smoke.rs file is failing. This seems to be a blocker to enable CI as well. Thanks!

Proposal: A shared trait for tls acceptors that are implemented by both async-tls and async-native-tls

I have some code that implements this using wrapper types, but would really love for a trait like this to exist:

A proposed async-tls-acceptor crate that publishes this trait:

#[async_trait]
pub trait Acceptor<Input>: Clone + Send + Sync + 'static
where
    Input: AsyncRead + AsyncWrite + Send + Sync + Unpin + 'static,
{
    type Output: AsyncRead + AsyncWrite + Send + Sync + Unpin + 'static;
    type Error: std::fmt::Debug + Send + Sync;

    async fn accept(&self, input: Input) -> Result<Self::Output, Self::Error>;
}

The implementation for async-native-tls would be:

#[async_trait]
impl<Input> Acceptor<Input> for async_native_tls::TlsAcceptor
where
    Input: AsyncRead + AsyncWrite + Send + Sync + Unpin + 'static,
{
    type Output = async_native_tls::TlsStream<Input>;
    type Error = async_native_tls::Error;
    async fn accept(&self, input: Input) -> Result<Self::Output, Self::Error> {
        async_native_tls::TlsAcceptor::accept(&self, input).await
    }
}

Would this be welcomed?

refs: async-rs/async-tls#43