Improve ease-of-use for untrusted communications

[Ralith]

Currently, it is only possible to connect to a server whose certificate is signed by a trusted authority. While this is ideal for web services, for some applications there is no expectation of or even feasible mechanism for this level of trust. Examples include tests, P2P applications with transient peers, and systems where trust is managed externally. Quinn should support these gracefully, without undermining security for applications where useful certificate authorities exist.

To accomplish this, we need:

• Support for selectively disabling trust checks on outgoing connections (Client configuration API #57)
• Helpers to generate a self-signed (or unsigned?) certificate for a server
  This API should make it convenient, but optional, to cache generated certificates in persistent storage, for convenience in systems which can take advantage of a persistent identity, such as in pseudonymous or trust-on-first-use models. Blocked by rustls missing support for generating certificates.

[est31]

I'm planning on a crate that allows generation of self signed certificates for this very purpose.

[est31]

There it is: https://github.com/est31/rcgen

I want to split it up into two crates: a library and a tool.

[djc]

Do you have API docs up somewhere?

[briansmith]

IMO a library like this should almost definitely not be providing an API for generating self-signed certificates or making it easy to trust arbitrary certificates. Instead, I think the library should provide an extension point that allows a completely separate crate to plug in such unsafe things. This is what Rustls does, in particular.

In the case of testing code, it is usually much better to have tests use certificates that have "real-looking" certificate chains: end-entity <- intermediate <- root, where the root is a custom one. That way the majority of the tests reflect the real-world ideal use of the library.

[est31]

@djc eventually it'll be uploaded to docs.rs (the current crates.io presence is mostly a placeholder), but for that I need an upstream crate to merge my changes and publish a new version. Until then I recommend either cloning and doing cargo doc manually, or including it only in Cargo.toml, and cargo doc manually. Also, you can look at the main.rs.

[djc]

@briansmith while I agree with you in the case of webpki, note that QUIC is also attractive for any number of different scenarios, including peer-to-peer networks where no CA is available. For these scenarios (and hidden behind an off-by-default feature flag) it seems to me that generating certificates on the fly would still make sense.

[est31]

I want to use QUIC for games and I don't want to require people to manually create/renew certificates or domain names when they want to set up servers or a LAN game or something. It should "just work". Autogenerating some 100 year valid dummy cert on the server at each restart and making the clients accept any cert the server presents is a good initial approach for this. Whether this is done in quinn directly or whether users of quinn have to integrate rkgen themselves, I don't really care.

@briansmith how would you envision an API to be that requires you to use a third party crate if you want to turn off certificate checks?

[Ralith]

I'm not necessarily averse to disposable certificate generation being external, if it is otherwise very convenient. My concern is that any barriers here will lead people to stick with the "easier" totally unencrypted UDP/TCP solutions they're accustomed to for non-web applications, which does not seem like an improvement.

[est31]

Okay, I've published version 0.1.0 of rcgen on crates.io.