Sort of. You actually do need to know when a certificate is self-signed because it means the connection isn't authenticated even if it's encrypted.

But what they ought to do is to accept the self-signed certificate, show something other than the usual lock icon but do the encryption anyway, and then freak out if the certificate changes before it expires.

The point is, sometimes you just don't care about authority, you just care about the encryption.

HTTPS with self-signed certificates is better than moving plaintext over the wire, in the same way PGP is better than moving plaintext over the wire. It doesn't matter that you don't have a "trusted" peer to tell you this PGP signer is who it says it is. As long as you can trust you acquired his key in a secure way (e.g., out-of-band), it's better than the alternative.

Plus, MITM concerns over self-signed certs are moot. This vulnerability exists at the DNS level anyway.

But how do you distinguish a self-signed certificate from a MITM NSA-signed one?

NSA does not use self-signed certificates for MITM, they have access to certificate authorities to get there own certificates that show up as valid in your browser.

MITM would be unnoticeable then.

Unless you visited the site before. (like ssh). Or if the trust was provided through another channel (DNS).

If somebody can tamper with your HTTP connections on the fly, they can surely rewrite the DNS too.

maybe, maybe not they use separate paths in general so its quite a bit hard as you need to be closer to the client, or compromise more hosts. not saying it's the bulletproof solution tho. it's definitely not. its just that some services (like ssh) actually provide that feature.