Somebody checked that in the past, yes, but that check doesn't matter for your current connection. Your browser will accept any CA signed cert as valid for the site it's for... if a hacker hacks into a low-profile CA, not even the one that verified BoA, they can MITM you every bit as easily as if they hacked BoA's actual cert authority.
The problem here is that the delegation is too broad; we're delegating verifying all websites to all CAs and assume that all CAs are absolutely trustworthy for it to work. That's ridiculous.
Chrome has a sort-of-solution built on top of this with certificate pinning where the organization gets a cert from the CA, and then gives it to chrome and claims "Only this cert is valid for our site" rather than all CA's certs...
Continuing with our example of BoA, this doesn't matter because they have not opted in [0] to that and in any case that won't apply to non-chrome requests.
"Chrome has a sort-of-solution built on top of this"
… which scales up about as far as every domain Google owns/cares about, and a few of their friends/partners/sites-that're-politically-or-business-beneficial-to-Google-to-pin.
I suspect in my 20 odd years of working with ssl protected websites, there's maybe 2 or 3 sites I've worked on that hav a hope in hell of getting into Chrome's pin list. If you're outside the US Fortune500 or any other countries Fortune100, how easy is it gonne be to get Google to pin your cert? It's nice if you're Twitter - it's _never_ gonna work for mygreatcatphotos.org.au...
It's useful, and a great thing they're doing, but as you say, it's _very much_ a sort-of-solution. Perhaps more like a very good two or three bandaid solution, directed at the problem of someone with 99% full body covered 3rd degree burns. "Here, I've got your left thumb and your right big toe covered!"
They've been pushing back against new people preloading public key pins because it's hard to make sure that someone else understands exactly what the consequences are. (Cryptocat, notably, got this wrong.)
But yes, HSTS preloading is totally open, and has been scaling as well as it's been needed.
this is a really good point. So would a good solutioon be to divy up the delegation? Though I don't know how that could work (how would you know you're on a bank website? a .bank tld?)
This is tricky, but I still don't get how decentralisation solves things, because the problem is still the same, except now it's a risk of whatever web-of-trust node you're a part of being compromised instead of a CA.
The problem here is that the delegation is too broad; we're delegating verifying all websites to all CAs and assume that all CAs are absolutely trustworthy for it to work. That's ridiculous.
Chrome has a sort-of-solution built on top of this with certificate pinning where the organization gets a cert from the CA, and then gives it to chrome and claims "Only this cert is valid for our site" rather than all CA's certs...
Continuing with our example of BoA, this doesn't matter because they have not opted in [0] to that and in any case that won't apply to non-chrome requests.
[0]: https://code.google.com/p/chromium/codesearch#chromium/src/n...