5 ms·
As a practical question: what is the expected capacity of the preload stores of browsers? Hundreds of thousands, millions or much more domains? Because at some
by t0mas88 10y ago
As a practical question: what is the expected capacity of the preload stores of browsers? Hundreds of thousands, millions or much more domains? Because at some point it seems like everyone with moderately high security requirements may want to have their certificates pinned / preloaded.
- konklone 10y agoI think that's an open question. Right now, it's not the millions, that'd be too much to bundle with browsers. But browsers may well change their delivery mechanism for preload information to allow this to scale higher. In any case, .gov won't add much to the load -- right now there are all of 5,500 .gov domains, and the rate of adding/removal is on the order of dozens every month at most.
- dragonwriter 10y ago> right now there are all of 5,500 .gov domains Is that just domains from which web content is hosted, or just second level domains regardless of whether web content is hosted? Because I can't imagine that there are only 5,500 total .gov domains.
- konklone 10y agoSecond level domains. There are waayyyyy more subdomains, as you note. You can see some information and estimates on this here: https://18f.gsa.gov/2017/01/04/tracking-the-us-governments-progress-on-moving-https/ https://18f.gsa.gov/2017/01/04/tracking-the-us-governments-p... We (18F, me) personally measured at least 26,000 (though some of these are used as redirects or are just error pages, etc.).
- deleted 10y ago[deleted]
- foota 10y agoSeems like you could use a bloom filter to store whether a domain has a pinned cert, and then use an api provided by the browser to remotely fetch the pinned cert. This has privacy implications, but does step around the storage. Chrome does something similar for CRL, but bloom filters fit that use case better.
- nitrogen 10y agoIIRC DuckDuckGo might do something like that for search suggestions. For slightly improved privacy, lots of unrelated hosts can be grouped into blocks (maybe grouped by probability of access to make it harder to infer which domain from the block is the likely target).
- tedunangst 10y agoMy browser's disk footprint is already over 100MB. What's another X MB? The ironic thing is we're reinventing the CA system, only now each browser is its own authority, exactly the problem the CA system was trying to solve.
- hackuser 10y ago> My browser's disk footprint is already over 100MB. What's another X MB? Don't forget mobile and other platforms, where resources are more constrained.
- konklone 10y agoI wouldn't say this is reinventing the CA system. You don't need to trust any particular browser here. The effect is that web services must offer a secure HTTPS connection, using the existing CA system (or an enterprise CA, if their user base is truly all-enterprise), no matter what browser is being used.
- hrjet 10y ago> You don't need to trust any particular browser here. You do need to trust that the particular browser you are using supports preloaded list, and is using the latest updated version of the list, and is not missing any entries!
- konklone 10y agoWhat you're trusting the browser for there is the extra protection that preloading provides, but that's not the whole benefit here. The larger benefit is that it makes it infeasible for services to neglect to support HTTPS. So, even if your browser's preload list is busted, the site will be guaranteed to support HTTPS because of this effort, which you'll still benefit from.
- hrjet 10y agoAh ok. I think I see what you are saying now. As long as a sizeable portion of browsers support a fresh version of the preloaded list, there is sufficient customer feedback to push the servers to only support https. Right?