> No one's saying that you should trust "blindly". Gotcha. Quick digression: I'm not a fan of the term 'trust on first use', as it can very reasonably be inter

> No one's saying that you should trust "blindly". Gotcha. Quick digression: I'm not a fan of the term 'trust on first use', as it can very reasonably be interpreted to mean exactly that. I mean, that's what is says... Wikipedia even gives it as one of its two almost antonymous definitions of the term, i.e. it can mean on first use, manually confirm whether to trust, or it can mean on first use, blindly trust. > The whole point of having a "hostile" warning when encountering a self-signed cert is protecting the user from impersonation attacks. There's a strong argument to be made that if you really want to protect the end-user from impersonation attacks, you shouldn't even give them the option of proceeding. Unfortunately, users are conditioned to click through warnings uncritically. > if you've established trust in other ways (such as by verifying the cert via an out-of-band channel, or because you set it up yourself) TOFU should be available In principle, sure, but what's the use-case here? We already have a secure, scalable, fool-proof solution to the problem: CAs. We insist upon CAs, because there's no good reason not to use them for all public-facing websites. What's the use-case here? If you want to run your own personal network, and your own personal alternative DNS scheme, you're free to set up your own personal CA for the purpose. Corporate networks do this. I see no reason to chuck out the whole concept of CAs. SSH is a different beast, as it's not intended for use by non-technical users. It's reasonable to insist on your sysadmin manually checking SSH fingerprints. Not so for non-technical users and HTTPS certs. Even in the case of SSH, CAs are a good solution if you're working at scale. To my knowledge, the only thing approaching a serious alternative to CAs, is web-of-trust, but it's not really a practical alternative.