Add client TLS cert auth

[andrewbanchich]

Feature Request

It would be great to have an equivalent of warp's client_auth_required.

Motivation

I'd like to use mTLS for request authentication. I found a low level example that looks relevant, but it would be nice to have something high level like what warp offers.

[davidpdrsn]

@programatik29 is this something axum-server can do?

[programatik29]

Everything possible with rustls::ServerConfig is possible with axum-server.

[programatik29]

Features that rustls doesn't support requires openssl which is not implemented yet in axum-server. Though it is possible for users to implement it with Accept trait.

[andrewbanchich]

Would it make sense to add the axum-server functionality to axum? I feel like configuring TLS would be a much needed high level piece of functionality.

[jplatte]

A lot of people exclusively run their http services behind a reverse proxy, e.g. nginx, haproxy or traefik. Terminating TLS in the same application that also contains the business logic isn't necessary and maybe even a bad idea security-wise – the projects mentioned are much larger than Rust web frameworks and more likely to receive quick security fixes.

[davidpdrsn]

Would it make sense to add the axum-server functionality to axum? I feel like configuring TLS would be a much needed high level piece of functionality.

An HTTP server is currently out of scope for axum. Axum is flexible enough that these things can be built by the community and doesn't have to be built and maintained specifically for axum.

I also agree with what @jplatte said.

[ttys3]

agree with @jplatte
Usually, serve HTTP services behind a reverse proxy is more efficiently and flexible.
And most CDN providers even provide flexible SSL feature.

[davidpdrsn]

Think I'll close this for now since its not actionable in axum. @andrewbanchich just let us know if you have more questions :)

[andrewbanchich]

@jplatte @ttys3 There are other discussions about this:

http-rs/tide#25 (comment)

seanmonstar/warp#743

A reverse proxy isn't a one size fits all solution for people. I agree with @seanmonstar that it's a great feature to have and with the other commenters in that thread that requiring someone to deploy an entire reverse proxy just for that feature seems like overkill for many people. I also am of the opinion that application architecture is best decided by the architect.

IMO if there is a security issue with Rustls / the rest of the Rust implementation then that's just a bug that should be fixed.

That's fine if you decide to not support it. Just providing some extra context from other similar projects and users.

[andrewbanchich]

And most CDN providers even provide flexible SSL feature.

I'm running Axum in an airgapped environment so that won't work.

[davidpdrsn]

Just to elaborate on why a server is out of scope for axum: I think every framework having its own custom server implementation is counter productive. I would rather collaborate on abstractions that allows frameworks and servers to be built independently and mixed and matched however users see fit. This is a general goal with axum. I don't want us to keep reinventing things. This is one of the reasons axum is based on tower::Service. That makes axum compatible with any server that supports tower. Realistically your only option is hyper (or building something on top of hyper, which is what axum-server is) but nothing is stopping you from building something yourself.

[andrewbanchich]

@davidpdrsn That sounds ideal, and I agree with that. I may be misunderstanding something though, but axum-server sounds like it is specific to axum.

I don't know much about Tower, but is this something which could be written as middleware?

[davidpdrsn]

I may be misunderstanding something though, but axum-server sounds like it is specific to axum.

I agree the name can be confusing but axum-server can be used with any tower service and no just axum. Its created and maintained by @programatik29.

I don't know much about Tower, but is this something which could be written as middleware?

Yes, tower is a general "async function from request to response" abstraction that can be used to build clients, servers, and middleware. For a general introduction to tower I recommend reading the guides. tower-http has many HTTP compatible middleware which work with axum but also hyper clients/servers, and even tonic client/servers. For example tower_http::trace::Trace is how you add tracing to axum apps, without having to write something specific for axum.

[andrewbanchich]

Yeah, that is confusing. Also, the first line is:

axum-server is a hyper server implementation designed to be used with axum framework.

Maybe it's worth renaming / explaining in the README @programatik29 ?

I don't want to get too off track here since this seems to be about axum-server / tower now. I'll open an issue there.

Thanks @davidpdrsn

[davidpdrsn]

np :)

[andrewbanchich]

Found an existing issue here in case you're interested in weighing in.

[davidpdrsn]

programatik29 is active in Discord and we've talked about it a few times already so they know what I think. Ultimately its their decision.

[ttys3]

@andrewbanchich

Axum is not battery included framework. currently it does not has built in mTLS feature.

But you can use Axum with a TLS server with mTLS enabled.

I just tried with axum-server (with TLS client cert auth enabled). this works.

[programatik29]

I think axum-server name is all right with current state of ecosystem. hyper already has a high level server which is re-exported in axum. But this high level server design works badly with TLS so axum-server solves it with a different design.

Name and documentation is written for users who want to do TLS with axum.

I don't think changing the name makes sense until new version of hyper drops high level server and become a more low level library. Then a renamed axum-server can be one of the high level hyper servers.

[ttys3]

@andrewbanchich here's a mTLS example based on exists axum example:

https://github.com/ttys3/rust-mtls-axum-example/blob/45d07d3545a1affeeaf854dc6c4d1d7b3417c5fd/src/main.rs#L111

the main diff is a custom rustls ServerConfig with client auth enable.

[andrewbanchich]

Thanks @ttys3