[jnky]

I recently had an idea to make HTTPS more secure for the average user: What if Google were to check the certificates when crawling a site, ensuring that its keys did not change in a malicious way.

Now, sites could present a different cert to Google IPs and to users. To solve this problem, the html anchor element could be augmented with the certificates fingerprint. The users browser would make note of the fingerprint and alert the user if something is off.

I think embedding information about a certs finger print or its root CA in links makes a lot of sense, as it would allow a sort of "web of trust" between linked sites.

[technion]

The most practical attack for the average MiTM is going to be the coffee shop wifi scenario. That scenario will never end up seen by Google.

On a related note, Google's crawler submits to Certificate Transparency logs any certificates it's never seen. Given you can monitor transparency logs, we have a similar situation to that you describe available to us.

[rakoo]

That's more or less what Perspectives (https://perspectives-project.org/) set out to do: a bunch of notaries would crawl websites, note their TLS cert and distribute them to whoever would want to visit the site, to have a point of comparison.

It didn't take off, mostly because of potential privacy problems and because there were not enough volunteers to make it scale properly. But the idea was sound.

[blowski]

I get the idea, but it sounds like it would make the problem of link-rot 100x worse, and the number of broken links would quickly desensitise users to the warning.

[lallysingh]

Obviously it'd be optional, and it'd only make sense for dynamically-serving systems like a web search engine.

And a multi-domain'ed serving system. Like a blog host. It could serve links to other blogs it hosts (on completely different domains) with cert hashes, and suddenly make it very hard to MITM any of the served sites without MITM'ing all of them.

[eganist]

I'm not sure how reliable this would be. E.g. an attacker with sufficient capability to launch an attack like RansomPKP (which requires a web server compromise or equivalent) would—on first glance, anyway—also be able to undermine these mitigations.

Technion's point about certificate transparency is probably the closest to solving what you're aiming for.