hey Daniel, Moving this discussion to guardian-dev so that others can join in. Your updates is totally inline with what I'm thinking these days. That wiki page contains some of the earlier ideas.
About DNS names and embedded ACME, that sounds like adding a ton of complexity. As a reminder, this is something happening in the F-Droid client app, not the server side. As for the flowchart, the first step is really just the standard set of the most basic certificate checks, i.e. the stuff that is listed in the certificate should be valid (expiry, hostname, cert signature is valid, format is valid, etc). That's part of any HTTPS stack, so it didn't seem worth breaking out separately so that the novel parts of the flowchart are well represented. .hc Daniel McCarney: > Hi again, > > https://dev.guardianproject.info/projects/bazaar/wiki/Chained_TLS_Cert_Verification > > For the chained TLS verification page it wasn't clear if I could comment > inline > so I've hacked up some markdown below. I apologize for the volume of > feedback, I assure you that I believe any errors/rough spots were > probably my fault to begin with :-D > > > Problem: > ---------------- > >> The central challenge is that as we have more application repos >> appearing on >> both servers and peer devices on local networks, we need to handle the >> fact that the majority of these will not have certificates signed by a >> Root CA and cannot be pinned. > > I think this can be updated to specifically focus on the peer devices on > local > networks scenario. We should talk about what needs to happen to get ACME > built > into the FDroid server for the heavier weight persistent servers w/ DNS > names to > get CA issued certs on first boot. (Caddy is an excellent example of > software that does this). > >> As an example, the Kerplapp app mentioned runs a tiny HTTPS server on >> your >> device, and we need a way to verify that cert in a dynamic way. > > This is the hard one... > >> TLS secret key pinning is great when you have a finite amount of known, >> centralized servers. We aren't doing that, so we need something more >> flexible. > > I think that a few years of experience has also shown that without great > care > these pins are an excellent single point of failure. Doubly so if you're > intending to pin to the end entity certificate instead of an > intermediate or > root. > > Definitions: > ---------------- > >> fingerprint - the hash over a standard chunk of a key > > What's a "standard chunk" in this case? I think what's meant here could > be said > most accurately as a "hash of the certificate's DER encoding". > >> pin - a hostname, SPKI, CA-signed boolean, and optional expire date to >> compare >> all connections to > > The "CA-signed" part here seems under specified. What CA? Is it the CA's > own > SPKI that is put into the pin & signed, or a leaf certificate's SPKI > signed by > the CA that issued it? > > Flowchart: > ---------- > > The first decision has two questions inside of it ("hostname matches?", > "cert > not expired"?) which seems confusing. > > At the bottom of the "YES" flow from "valid CA-chain" is "hostname > marked as > CA-signed" - what does that mean? Similar q for "mark pin as CA-signed". > > One red flag for me in the "valid CA-chain" -> Yes -> Accept Certificate > flow is > that there's no explicit check that the signature on the end entity > certificate > validates with the certificate's claimed public key. Overall I think the > best > bet is to try and completely execute the system trust manager to make > CA-related > decisions and only fall back to your own decision tree when its clear > that the > certificate is *not* signed by a rootstore trusted CA. It's so hard to get > certificate validation in the standard web PKI right and all the > plumbing is > there to use. > > For all of the cases where it says "add pin of X" it would be best to be > really > explicit about what SPKI is being pinned. I think the leftmost "Accept" > branch > pins the leaf but the middle "Accept" branch pins the CA? (Unclear if CA > means > root or intermediate). > > Discussion and Resources > ------------------------ > > I had to skip reading these for time. > > Certificate vs. Secret Key > ------------------------ > > I think pinning against a whole certificate hash is a bad idea and should > probably be scratched. With the benefit of experience from Let's Encrypt > its > clear certificates change a lot. Pinning to the whole cert will make > adding/removing names a non-starter and also creates incentives for > long-lived secrets instead of certificates with shorter liftetimes > (which, given > the state of revocation are very useful). > > RE: pinning the secret key, I think based on earlier content the intent > is to > talk about pinning the SPKI, not the private key per-say. It's probably > clearer > to talk about the SPKI and refer to the associated private key as required. > >> this is much more vulnerable: if the secret key is compromised, then the >> attacker could issue certs that would be trusted by the pin/tofu > > I don't understand this claim. If the attacker can compromise the secret > key and > you're pinning the byte-for-byte DER encoding of a certificate that has the > corresponding public key you're equally in trouble. -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556 _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
