Now: Application: Hey OS, what is example.com's IP? Okay, now give me an unencrypted connection to example.com's port 80.
Desired: Hey OS, give me an encrypted connection to example.com's port 443. (+ optional encryption params like minimum key strength)
Why can't encryption be an OS level task, exactly?
So in short hostname-based authentication is mostly useful for web browsers - which is why it's in the web browser, not the OS.
(Also, pragmatically, existing OS-based key management is terrible - just try and use the Windows dialogues to set up an SSL client certificate. For many users the very idea that you manage your keys separately from the programs you use them in is confusing. So browsers would rather provide their own cross-platform UI for key management, even if the OS offers a "managed SSL keystore" as most OSes do)
As to the UI: Yes, but that's precisely because it is currently unclear who is responsible. Java has its own keystore, FF has its own but Chrome doesn't, even some libraries have their own or they don't, depending on the OS. It's a mess. A mess that I don't care about, as a user.
I want a central key store that apps tap in to. When I revoke a cert for Diginotar, I don't want to have to grep every file in my entire filesystem for that string on the off chance some crazy statically linked lib installed a local cert store somewhere.
And sure, an app wants to create a special case just for itself (e.g. a client certificate only for mail), let it. But I'd like that to be the exception, not the rule.
Cert management is a mess right now, and both developers and users are duped.
You're exactly right on this – APIs need to be secure by default. Yes, I'm sure that that'd make some of the certificate management issues more pronounced but that's something we need to solve anyway; increasing the expectation that everything should be encrypted will only help.
It bugs me that it costs more for a wildcard domain cert than it does to host with a VPS for a year. I'm not saying it's prohibitively expensive for hobbies using multiple certs, just the same it shouldn't be this way.
Encrypting at the host level would be actively unhelpful (e.g. it would make failover or forwarding harder) and wouldn't gain you much in the way of security. You just want to encrypt the message to the actual recipient.
> chat
Again hostname-based auth is actively unhelpful in a federated system like IRC or XMPP (you want to failover to a different host if a particular host is down), and offers minimal security in a centralized-server system.
> VPN
I think a VPN is inherently the wrong approach to security; it's trying to create a network you can trust, but networks are too big to secure.
> VNC
How often do you VNC to a box with a stable hostname? I only ever use it to connect between my (coffee shop or wherever) laptop, my (dynamic IP) home machine and my (dynamic IP) dev machine at work.
Along similar lines, I think it's strange that I now see warnings in Chrome for SHA-1 certificates but no warnings at all for http.