How to use new IoBoxed

[Antiarchitect]

Using 0.4.x was like Handshake<Io> which I converted into tokio Either like this:

use tokio::net::TcpStream;
use tokio_util::either::Either;

#[cfg(feature = "tls-openssl")]
pub type Stream = Either<tokio_openssl::SslStream<TcpStream>, TcpStream>;

#[cfg(feature = "tls-rustls")]
pub type Stream = Either<tokio_rustls::server::TlsStream<TcpStream>, TcpStream>;

type Handshake = ntex_mqtt::v3::Handshake<Stream>;

And after that I could use it like this:

use std::net::Ipv4Addr;

use anyhow::{anyhow, Result};

use super::{Handshake, Stream};
use crate::util::ipv4_from_socket_addr;

#[cfg(feature = "tls-openssl")]
pub(super) fn peer_ipv4_from_handshake(handshake: &mut Handshake) -> Result<Ipv4Addr> {
    let peer_addr = match handshake.io() {
        Stream::Left(tls) => tls.get_ref().peer_addr(),
        Stream::Right(tcp) => tcp.peer_addr(),
    };
    peer_addr.map_err(|e| anyhow!("{:#}", e)).map(ipv4_from_socket_addr)?
}

#[cfg(feature = "tls-rustls")]
pub(super) fn peer_ipv4_from_handshake(handshake: &mut Handshake) -> Result<Ipv4Addr> {
    let peer_addr = match handshake.io() {
        Stream::Left(tls) => tls.get_ref().0.peer_addr(),
        Stream::Right(tcp) => tcp.peer_addr(),
    };
    peer_addr.map_err(|e| anyhow!("{:#}", e)).map(ipv4_from_socket_addr)?
}

How can I reach the internal Io from the Handshake without a generic (with IoBoxed) in 0.5.x and distinguish between tcp, rustls TlsStream, and openssl SslStream? Because I need access to the real Io in order to make Auth based on cert content, IP and much more in my project that uses ntex-mqtt.

[fafhrd91]

you can get peer addr via query() api, io.query::<ntex_io::types::PeerAddr>()
you can get cert, and chain from openssl. I didn't add rustls support for certs yet, but it is easy to add.

[Antiarchitect]

Aha! That sounds very good! Would be nice to have it. Will try to obtain information needed via query API.

[fafhrd91]

you can try to add certs types to rustls, or I can add it but maybe tomorrow or after tomorrow.

[Antiarchitect]

If I have enough time today :) Also is there a way to distinguish underlying IO between TCP and TLS via query API? I need this explicit because auth schemes can differ. Is query api described somewhere in docs or source code is the only source of info?

[fafhrd91]

query api is not documented yet, but it is very simple.
here is example for openssl

ntex/ntex-tls/src/openssl/mod.rs

Line 76 in d359b6c

fn query(&self, id: any::TypeId) -> Option<Box<dyn any::Any>> {

the fact of getting info from tls stack is distinguish factor

[Antiarchitect]

I've looked inside rustls part of ntex_tls and am not sure that I can do it at once. Should we convert Certificate and CertChain to common form for both openssl/rustls? For now, I have (rustls part is obviousely not working, and I took it from the previous version of my code):

#[cfg(feature = "tls-openssl")]
fn extract_cname_from_handshake(handshake: &mut Handshake) -> Option<String> {
    use openssl::nid::Nid;
    let peer_cert = handshake.io().query::<PeerCert>();
    let x509 = &peer_cert.as_ref()?.0;
    let entry = x509.subject_name().entries_by_nid(Nid::COMMONNAME).next().or_else(|| {
        log::warn!("[MQTT_SERVER][AUTH][OPENSSL] Failed to get any CN from the client certificate");
        None
    })?;
    let cname = entry
        .data()
        .as_utf8()
        .map_err(|e| {
            log::warn!("[MQTT_SERVER][AUTH][OPENSSL] Failed to parse CN as UTF-8 string: {}", e);
            e
        })
        .ok()?;
    Some(cname.to_string())
}

#[cfg(feature = "tls-rustls")]
fn extract_cname_from_handshake(handshake: &mut Handshake) -> Option<String> {
    use x509_parser::prelude::{FromDer, X509Certificate};
    let cert = handshake.io().query::<PeerCert>().as_ref()?;
    let (_, x509) = X509Certificate::from_der(cert.as_ref())
        .map_err(|e| {
            log::warn!(
                "[MQTT_SERVER][AUTH][RUSTLS] Failed to parse the certificate as x509: {}",
                e
            );
            e
        })
        .ok()?;
    let cname_attr = x509.subject().iter_common_name().next().or_else(|| {
        log::warn!("[MQTT_SERVER][AUTH][RUSTLS] Failed to get any CN from the client certificate");
        None
    })?;
    let cname = cname_attr
        .attr_value()
        .content
        .as_str()
        .map_err(|e| {
            log::warn!("[MQTT_SERVER][AUTH][OPENSSL] Failed to parse CN as string: {}", e);
            e
        })
        .ok()?;
    Some(cname.to_string())
}

that still differ. It would be nice to have the Certificate implementation in independent form for cname extraction and other operations become implementation independent. Maybe x509_parser crate is an appropriate choice.

[Antiarchitect]

@fafhrd91 What about uniforming the certificates in both cases? Any ideas of how to do that?

[fafhrd91]

i dont know. do we actually need uniform cert access? in any case to make uniform access we need to convert to some generic types.

[Antiarchitect]

Had some time to update my branch where I'm performing the upgrade to ntex-0.5.x
This code worked a couple of days ago:

#[cfg(feature = "tls-openssl")]
use ntex_tls::openssl::PeerCert;
#[cfg(feature = "tls-rustls")]
use ntex_tls::rustls::PeerCert;

Now it cannot find PeerCert in rustls case:

error[E0432]: unresolved import `ntex_tls::rustls::PeerCert`
 --> src/mqtt/auth.rs:6:5
  |
6 | use ntex_tls::rustls::PeerCert;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^ no `PeerCert` in `rustls`

I need it to patch rustls case for the PeerCert extraction.

[fafhrd91]

i’ve never added peercert to rustls

[Antiarchitect]

Maybe I'm wrong and tested only with the working OpenSSL variant. Sorry.