async-rs / async-tls

A TLS implementation over AsyncRead and AsyncWrite
https://async.rs
Apache License 2.0
165 stars 47 forks source link

We need a method to get TlsStream's client cert #33

Open Earthson opened 4 years ago

Earthson commented 4 years ago

In the case of X509 client verification, we want to get the certificate of client to extract some extra info(email, name, ...)

but ServerSession is not for public use. https://github.com/async-rs/async-tls/blob/master/src/server.rs#L20

Is it a good idea to have some code like:

impl<IO> TlsStream<IO> {
    pub fn peer_certificates(&self) -> Option<Vec<Certificate>> {
        self.session.get_peer_certificates()
    }
}
FlorianUekermann commented 4 years ago

Yes, this is necessary information. Not just to extract certain fields, but the whole certificate.

@YangzhenZhao already sent pull request #25, which implemented exactly this, but has been rejected because it publicly exposes a rustls type. This is easily fixed, because the rustls certificate type is simply a byte vector: pub struct Certificate(pub Vec<u8>);.

@skade: I can send a pull request if you indicate that such a solution would be accepted.

FlorianUekermann commented 3 years ago

I'll reply to the closing comment by @skade on #35 here, so the discussion isn't fragmented all over the place.

I'm not interested in a design that exposes the client certificate raw. async-tls was rather initially designed to implement high level operations on TLS connections ("Client authentication" rather than "here's the client certificate, implement client auth").

I think this makes a lot of sense, when it comes to implementing client auth (i.e. verifying that the client cert matches some criteria). However, a certificate isn't just authentication information that needs to be checked, but also part of the connection payload. Similar to what @Earthson describes in the OP, I need to retrieve the certificate, but not to implement authentication, which I do via the rustls ClientCertVerifier.

In my opinion rustls has a good approach by offering only a set of correctly implemented ClientCertVerifiers, but allowing access to the certificate as data afterwards.