"Attack surface" in this case, boils down to bugs and fuck ups. "Massive" is subjective but justified in my opinion too. A message delivered via http or https is the same - one is encrypted on wire and one is not. There is a minimal cost of encryption these days. We are long past the point where a CPU gets bogged down with it.
I still contend that "everything should be encrypted" is cargo culting:
An unencrypted webby stream does not expose a browser to anything nastier than an encrypted webby stream. The eventual payload is the same, regardless of the transport. The difference is that the browser has to use vastly more code paths to do the same job of receive -> display. It has to decrypt the stream. That additional complexity introduces vastly more possibilities for bugs.
So, I think you should pick your medium with care. I do think that https is a safe transport for all messages and do routinely use it myself. I have done a risk assessment on it - I don't simply use it because everyone else says its a good idea 8)
I deliberately used the pejorative term "cargo cult" in this discussion.
> An unencrypted webby stream does not expose a browser to anything nastier than an encrypted webby stream. The eventual payload is the same, regardless of the transport.
No, my point is that an unencrypted payload is controlled by anyone on your network path (your ISP, anyone on the same open WiFi, ...), so it can be nastier than an encrypted payload. Remember that TLS provides not just encryption, but also authentication.
We are now in the realms of risk management etc. An unencrypted TCP stream still has sequence numbers - famously abusable in the past. You can still use them to be reasonably sure that your stream is untampered with, with care.
I'm talking about integrity - ie what I sent is what you received or what I requested you to send is what I received.
TLS does only provide encryption, it does not authenticate anything. You can use TLS as a wrapper for auth - to make the exchange private or you could pre-arrange a swap of public keys (certificates) via a method that is mutually agreed. That mutually agreed bit is the authentication part but it has nothing to do with TLS per se.
You click on a website link that starts with https://, most people allow their browser to use its trust store to decide whether to proceed. Increasingly, browsers are becoming opinionated about this, which is bloody annoying for IT bods.
Should you trust MS/Google/Apple/KDE/Mozilla int al to tell you who is trustworthy? No and they don't really (tell you who is trustworthy! All they do is tell you which certification authorities follow the rules. There are not too many rules and they certainly do not ensure anything as such. What you are nearly guaranteed is that if you use things like "Perfect Forward Secrecy" (which cannot be perfect, by definition) and a few other tricks ... your conversation is probably private.
Authentication is a whole new ball game as they say several thousand miles to my left and down a bit!
