[Pre-RFC] Securer Tokens (Private keys for Cargo)

tools and infrastructure cargo
1

Currently Cargo uses hashed plaintext tokens that can be compromised by (accidentally or by an exploited vulnerability) logging the tokens. To protect against that kind of attack, it would be nice if tokens were private keys instead. This would prevent any crates.io compromise from getting access to tokens. While we do trust the crates.io team to revoke any tokens if that does happen, it'd still be nice to see them being protected by default. This could be implemented with TLS client certs and certfp/keyfp or some other public key mechanism.

This would only change the uploading of crates, so old versions of Cargo would still be able to download any crates.

2

There has bean some discussion of this in https://github.com/rust-lang/rfcs/pull/3139 the last comment asked for the discussion of asymmetric cryptography be moved to a new RFC. I am drafting it now, very hopeful that I can post in the next week.

2 Likes
3

I would personally recommend against TLS client certs.

In addition to general concerns about mTLS complexity, client certs require the front-end load balancer which terminates the TLS connection both manages to validate it against a custom CA and also somehow passes the subject information through to the backend.

Considering crates.io is currently deployed on Heroku (I believe), it's completely incompatible with this approach.

Bearer token-based formats like Biscuits or PASETO which are validated directly by the backend application as opposed to the frontend load balancer are much more compatible with a reverse proxy setup.

2 Likes
4

well maybe if you weren't MITMing the TLS connection you wouldn't have this issue.

but also certfp/keyfp only cares about the cert fingerprint or key fingerprint, and expiry we guess, but not the CA or any of that other stuff. it's commonly used on IRC, but there's nothing that makes it IRC-only.

5

Something needs to verify the certificate against trusted CA(s) for a particular application, otherwise the certificate is easily spoofed.

As it were, I double checked and Heroku has no support for client certificates, so they seem like a nonstarter for crates.io.

6

no, you only need a CA if you care about some form of decentralization. in which case you might want to just use let's encrypt.

for something like cargo, or IRC, or oauth, or whatever, just use certfp.

(heroku is vulnerable to NSA tho.)

7

That article does not mention Heroku, or even AWS (which hosts Heroku's infrastructure). It describes an NSA program that intercepts data sent between Google and Yahoo datacenters.

8

please pay attention to the functionality, not the deployment.

9

anyway we wish we could close this thread and point ppl to the above:

1 Like
10

Sorry for the delay. Several experts have been willing to meet with me to go over my draft, only to have to delay the meeting due to them coming down with COVID. This has not been abandoned. I'm still working on it.

1 Like
11

Here we go! Cargo authenticateing users without sending secrets over the network by Eh2406 · Pull Request #3231 · rust-lang/rfcs · GitHub This describes a mechanism how registries choose to implement that mechanism is out of scope for this RFC. If you're excited to find ways to use the system, then let's stay focused and get it merged so you can start experimenting!