Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
http: pin TLS pubkeys instead of fixing cert store
Currently, lpass bakes in the root CAs that are needed to validate the peer certificate chain for lastpass.com and lastpass.eu. This approach serves two purposes: first, it enables the certs to validate if the root CAs are not in the system certificate store, and second, it limits the risk that a compromised or untrustworthy CA can produce a fake certificate for lastpass. While the latter reason remains important, the former is not so important today as pretty much every platform maintains their own system certificate store that is reasonably up-to-date. LastPass will soon be updating both the root CA and key for some properties. To prepare for that, at least the new root will need to be added, so now is a good time to revisit this. Key pinning has some advantages over cert pinning, namely that even as certs expire and are reissued, key pinning can continue to work without changes. Also, HPKP is being implemented by the major browsers and will bring more visibility to the key pins, so let's follow suit here. This change removes the baked-in certs and defers to the platform certificate store for validating the chain, while adding a mechanism for hashing and checking the subject public key info. One of the certs in the chain must match one of the hashes for the connection to be allowed. For the interested, a fingerprint can be generated from a certificate like so: openssl x509 -in some-certificate.crt -pubkey -noout | \ openssl rsa -pubin -outform der | \ openssl dgst -sha256 -binary | \ openssl enc -base64 Public key pins are added for the existing Thawte (lastpass.com) and AddTrust (lastpass.eu) roots. Signed-off-by: Bob Copeland <[email protected]> Backported from master. Conflicts: Makefile http.c
- Loading branch information