[kragen]

I think it was Snowden who made TLS the default. Let's Encrypt did great work, but basically having the NSA's spying made common knowledge (including revealing some things that were worse than we expected, like stealing the traffic between Google's data centers) created a consensus that unencrypted HTTP had to go, despite the objections of people like Roy Fielding.

[Lammy]

Ironically, the inability to cache TLS on the edge of my network makes the Internet more surveillable since everything has to pass through the Room 641As of the world and subjects us all to more network behavior analysis. The TLS-everything world leaks so much more metadata. It's more secure but less private.

[kragen]

Yes, that's a real problem. Probably moving to a content-centric networking or named-data networking system would help with it, while also creating difficulties for censorship, and IPFS and Filecoin seem to be deploying such a thing in real life as an overlay network over the internet.

[globular-toast]

You can do it if you're happy to deploy your CA to your network, can't you? Deploying CA certs sucks, though. I wish it was easier.

[Lammy]

It's one of those things that may be technically possible but that doesn't matter unless a large enough percentage of other people are doing it too. Now that everything is geared to be realtime, anything most people will want to do on a computer will have those kind of traffic patterns. Even our popular application platforms are set up to encourage this pattern. Electron being a browser engine is geared around making network connections first and foremost.

[globular-toast]

Maybe I misunderstood your point. Why do you need everybody to be doing it?

[Lammy]

Concrete example: if my friends only use Discord and I want to talk to my friends, I have to use Discord whether or not I think it's bad for me.

[kragen]

That's true of Discord, but it's not really true of deploying your own CA certs.

[inejge]

> I think it was Snowden who made TLS the default.

Snowden's revelations were a convincing argument, but I would place more weight on Google in its "we are become Evil" phase (realistically, ever since they attained escape velocity to megacorphood and search monopoly status), who strove to amass all that juicy user data and not let the ISPs or whoever else have a peek, retaining exclusivity. A competition-thwarting move with nice side benefits, that is. That's not to say that ISPs would've known to use that data effectively, but somebody might, and why not eliminate a potential threat systemically if possible?

[rusk]

Reading this it seems to me that ISPs missed a trick by not offering privacy features. These features were already baked into mobile wireless it probably wouldn’t have been a huge big deal for them to provide it. That’s what happens when you treat your business as a source of rent

[trvz]

The article claims http was kept around. My experience was, that once you setup https you just redirected http, like today.

Snowden may have been a coincidence, too. We knew encryption was better, it was just too much of a hassle for most sites.

[tialaramex]

Redirection doesn't get the job done, without at least a mechanism so that browsers reliably stop visiting the HTTP site (HSTS) and ideally an HTTPS-everywhere feature which, in turn, was not deployable for ordinary people until almost every common site they visit is HTTPS enabled and works properly.

The problem is that there are active bad guys. Redirection means when there are no bad guys or only passive bad guys, the traffic is encrypted, but bad guys just ensure the redirect sends people to their site instead.

Users who go to http://mysite.example/ would be "redirected" to https://mysite.example/ but that redirection wasn't protected so instead the active bad guy ensures they're redirected to https://scam.example/mysite/ and look, it has the padlock symbol and it says mysite in the bar, what more do you want?

Snowden was definitely a coincidence in the sense that this wasn't a pull decision. Users didn't demand this as a result of Snowden. However, Snowden is why BCP #188 (RFC 7258) aka "Pervasive Monitoring is an Attack" happened, and certainly BCP #188 helped because it was shorthand for why the arguments against encryption everywhere were bogus. One or another advocate for some group who supposedly "need" to be able to snoop on you stands up, gives a twenty minute presentation about why although they think encryption is great, they do need to er, not have encryption, the response in one sentence is "BCP 188 says don't do this". Case closed, go away.

There are always people who insist they have a legitimate need to snoop. Right now in Europe they're pulling on people's "protect the children" heart strings, but we already know - also in Europe that the very moment they get a tiny crack for this narrative in march giant corporations who demand they must snoop to ensure they get their money, and government espionage need to snoop on everybody to ensure they don't get out of line.

[jstanley]

> Users who go to http://mysite.example/ would be "redirected" to https://mysite.example/ but that redirection wasn't protected so instead the active bad guy ensures they're redirected to https://scam.example/mysite/ and look, it has the padlock symbol and it says mysite in the bar, what more do you want?

You can do better than this. You can have your mitm proxy follow the SSL redirect itself, but still present plain HTTP to the client. So the client still sees the true "mysite.example" domain in the URL bar (albeit on plain http), and the server has a good SSL session, but the attacker gets to see all of the traffic.

[ktpsns]

No, let's do a punycode attack: It "looks" like it was https://mysite.example but is not. And yet it has the green padlock.