4

Public-key pinning is a proposal that allows sites to pin their keys in the browser to protect against Man In The Middle attacks that try to forge a site's key. See

Internet Engineering Task Force (IETF)'s RFC 7469

My questions are:

How does the browser checks the keys? is it by using cookie? cache? lists? database? Can you clarify implementation details?

Assuming every website adopted this technique and pinned its public-key, the list will become extremely long. How can the browser checks the key in the white-list with high performance? What possible techniques are there to do this?

  • If I'm understanding your question properly, it boils down to "How can software store and efficiently query large amounts of data? Does anyone know how (closed source) browsers do this?" I'm not convinced this is a security question. Also, since this is an internal implementation detail, each browser may do it differently. Can you clarify? – Mike Ounsworth Nov 18 '17 at 18:26
0

There are two kinds of HTTP Public Key Pinning, static HPKP and dynamic HPKP.

Static HPKP

For Google Chrome at least, static HPKP involves a list of websites and their public keys actually hardcoded in a json file distributed with all Chrome builds. Firefox keeps it in a header file with a large struct containing the websites and pinned keys. This is similar to HSTS preloading, but tends to involve only higher profile sites, so you can't submit your own. This list is not huge, so it's easy to query rapidly. If it were to include particularly many sites, it would not scale.

Dynamic HPKP

This is similar to HSTS. A server sends an HTTP header containing the pin directive along with a fingerprint and a backup fingerprint. Like HSTS, it also encodes the duration for which this will be valid. After getting the fingerprint, the browser will only connect to the website if it matches, until the expiry is up. This is stored in memory or on disk, and at most contains only the website you've visited which use dynamic HPKP. Assuming CA compromise, HPKP effectively provides a strong TOFU (Trust On First Use) guarantee on top of TLS.

The actual implementation is probably not relevant. For static HPKP, I imagine Firefox simply loops over the struct to find matches, and Chrome uses its internal json parser to find matches. For dynamic HPKP, it's probably some kind of list, whether a linked list or something faster and lighter like some kind of tree, I don't know. Either way, it would not be a significant bottleneck compared to the rest of the complex operations a browser needs to go through to perform a proper TLS handshake.

You underestimate the performance of a well-optimized hash tree or radix tree. :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.