Public information versus private information
A lot of information out there in the web is inherently public: news, articles, wikipedia, resources, images, video, ... anything that isn't personal or private to the people who author or own it. Encrypting readable public information is mostly a pointless exercise. What would a casual observer hope to learn from monitoring information "on the wire" that is already readily available at their own request if they so choose?
Content isn't a concern, so what else? Having a record that you visited a certain site? That information will be known and recorded already anyway, in several locations, so monitoring your traffic in that case won't be needed either. If this is a concern, then you should employ some more advanced and better techniques to deal with untrusted local networks than SSL (which won't protect you from your visits being known to a local observer). But that doesn't really have much at all to do with browsing security, but rather networking security as a whole. Of course you wouldn't want to use plaintext traffic on untrusted networks, but would that be an issue with web traffic? Nope. It would be an issue with an untrusted network being... well... untrusted. Solutions include VPN, TOR and secure tunnels to trusted gateways.
Private information should, indeed, always be sent encrypted. People's e-mail addresses, personal data, login credentials, CC numbers; all that shouldn't be sent "in the clear" if at all possible. This is where encryption is prudent and should always be required. Common sense should apply what is public and what is private information, and the end-user can always make a choice to make private information public, as well.
"But someone might block/alter/inject stuff into public information if received unencrypted"
Absolutely! But providing Proof of Concept and having a practical application for such things are quite different things.
Keep in mind that there is no practical use for this kind of behavior, and it is not trivial to do and/or requires an investment of some sort.
block/alter: this would fall under censorship. There are plenty of ways to combat censorship if that is what you're suffering from, but none have anything to do with the need for encryption. Even encryption by itself won't prevent censorship; ISPs control your connection and traffic, including what your browser is presented with when trying to connect to an https server - the same way an https filtering, locally installed internet security suite can lie about the security and origin of your connection, an ISP can do this too - and most users wouldn't even be aware that anything was wrong.
inject: this, too, isn't trivial in modern browsers (including Pale Moon). A lot of safeguards are in place for cross-origin attacks and code injection, making it rather unfeasible to do on any practical scale. Even if done, what would be the practical use for it? Tracking? That would be done much more easily server-side. Stealing private/personal information? Not possible since public content won't contain such information...
The problem with traffic
Now, let's have a look at the potential impact of encrypting everything. Since SSL means end-to-end encryption, a few very essential mechanisms at work to keep the internet running smoothly will become unusable:
- Network Caching: because each secure connection is encrypted in a different way, there is no way for encrypted data to be cached anywhere along the way. Caching (storing a copy in an intermediate location to be served to multiple clients) is an essential mechanism to keep the traffic volume flowing through the internet in check. If caching would become pointless or unusable, the internet as a whole would likely completely grind to a halt in a very short time because of traffic congestion.
- Client-side caching: Caching in browsers more often than not has to be switched off or prevented for SSL-received data to be trusted by the browser. Data stored in local cached web content (disk cache) is usually not trusted because it can potentially be altered outside of the browser. This means that websites received over SSL can't be efficiently cached in your browser, and you end up re-downloading pages and elements in those pages over and over for each visit to the site.
- Compression: unencrypted text/html and similar documents, by their very nature, compress really well. Compression for transport is used a lot to reduce the raw traffic volume that has to be served by servers and transported by backbones. Conversely, encrypted traffic is very much like a random bitstream; it won't compress at all or extremely little. Encrypting data, in other words, makes compression unusable. This will have a similar effect to not being able to cache anything, and will compound with it.
CDNs these days are smart enough to provide encrypted traffic to end-users, by employing their own valid certificates for the domain(s) they serve from that certificate. This will allow them to somewhat tackle the caching issues because they can cache content on the "cloud edge" before delivering it over SSL to end clients. However, this still doesn't tackle the client-side caching issue or compression issue, and introduces a new problem of its own: as an end client, you are explicitly trusting the CDN, which becomes a centralized location for not just public, but also private information! Your secure connection will no longer be from end to end, but from end to the cloud edge. Beyond that, your connection becomes unknown and if you want to apply strict security rules, you shouldn't use it.
After all: the CDN becomes a man in the middle over SSL, who will have access to your traffic in an unencrypted state. See below for a potentially bad scenario in that case.
What if: this were actually going to happen?
If the entire internet were to switch any and all traffic to encrypted traffic, including file downloads and public information, then what would be the new scenario? Here's my opinion:
Most likely the situation would be one where:
- All traffic will have to be served through CDNs if congestion is to be prevented. Direct traffic would be slow, if at all possible.
- There would be the realistic potential of a segregation between "local nets" and "backbone traffic". You would no longer be able to connect to a server on the other side of the globe if direct traffic is prevented to avoid backbone congestion.
- CDNs (as mentioned above) would become a requirement for any and all web server if they planned to have a global presence (to prevent too slow traffic, or in the worst case of a traffic segregation prevent from being completely unreachable). CDNs would become a controlling force, that everyone has to place their trust in - classic https server connections would no longer be a thing.
- Building on the previous points, where would the protection of privacy be left in that situation? Nowhere, because CDNs would have full access to unencrypted data, for any controlling power that be to demand. Your net win for using SSL in the first place would be absolutely zero; no, in fact, it would be worse than what we have now, because what is currently actually secure over SSL, is no longer an option in that future scenario.
So, this is why I think that enforcing SSL for everything, especially public data, is both folly and setting ourselves up for a big fall down the line. I heartily say "no thank you" to this.
Maybe I'm playing devil's advocate just slightly in my last section, but that is exactly what proponents of "SSL always and everywhere" do all the time when promoting it. Only fair that I return the approach in kind
I'm all for giving people the convenient option of having encrypted public website traffic, as a choice, to limit easy monitoring of exactly what public content is being requested without having to use a different network security method on untrusted (open, public, non-switched) networks (like airport WiFi etc. although I would strongly suggest VPNs for that), but enforcing it blindly (everywhere, also on trusted networks and direct ISP connections) is really not something that should be done, IMHO. Especially things like file downloads should not be served over https - after all, if the web page containing the link to the download is fully trusted, then the actual download will be legitimate and easily verifiable by e.g. posted or automatically checked hash on the trusted web page.
As such, http://www.palemoon.org, for example, is https enabled (but not enforced). So is this forum, albeit with automatic switching to https when logging in because of the personal nature of logged-in traffic (potential private messages, restricted boards, account information, etc.).
