Comment by superkuh | Hacker News Reader

Comment by superkuh | Hacker News Reader

Parent Full thread

Plain text protocols are in serious danger as the (confused) desire for TLS-only everywhere spreads with the best intentions. The problem is that the security TLS-only brings to protocols like HTTP(s) also brings with it massive centralization in cert authorities which provide single points of technical, social, and political failure.

If the TLS-everywhere people succeed in their misguided cargo-cult efforts to kill of HTTP and other plain text connections everywhere, if browsers make HTTPS only default, then the web will lose even more of it's distributed nature.

But it's not only the web (HTTP) that is under attack from the centralization of TLS, even SMTP with SMTPS might fall to it eventually. Right now you can self sign on your mailserver and it works just fine. But I imagine "privacy" advocates will want to exchange distributed security of centralized privacy there soon too.

TLS is great. I love it and it has real, important uses. But TLS only is terrible for the internet. We need plain text protocols too. HTTP+HTTPS for life.

There’s a difference between the transport and the protocol. For instance I’ve used Redis fronted by TLS in the past. Initial connection did get more tricky for sure, needing to have the certs in place to first connect.

However after the connection was established with OpenSSL I was able to run all the usual commands in plain text and read all the responses in plain text. Having transport layer encryption on the TCP connection didn’t effect the protocol itself at all.

You can talk plain text protocol through a TLS or SSL-encrypted connection, even interactively.

Example:

        { echo GET / HTTP/1.0 ; echo ; sleep 1 ; } | openssl s_client -connect www.google.com:443

Or just :

        openssl s_client -connect www.google.com:443

then type interactively GET / HTTP/1.0 then press enter twice.

Using openssl s_client -ign_eof makes piping text a bit easier because connection won't be closed prematurely (so you don't need to use sleep 1)

Mixing trust and encryption that resulted in centralized TLS was probably a design flaw. Certificate pinning in DNS is an attractive "fix", but moves the problem up a layer. But DNS is already centralized, so there's that.

> Right now you can self sign on your mailserver and it works just fine

Well .. sort of. Until you have to interact with google or ms mail servers. After an hour of wondering why your mails are getting blackholed, one starts to reconsider one's life choices.

Yeah but no. I can demonstrate the necessity for HTTPS right now. Because Comcast is my only realistic option for high speed Internet service where I live I'm stuck with them.

Because of their ridiculous data cap policy I've been getting warnings I'm approaching my cap for the month. I dared to watch Netflix and do work this month!

So if I were to go right now and access a web page via HTTP I'll get a pop up inserted into the page by Comcast telling me I'm approaching my data cap. There was a time when ISPs were inserting their own ads and tracking into pages.

Ergo, your ISP cannot be trusted to deliver data to you unmolested. Unless you've got pre-shared signing keys, like your Linux distro's package signing keys, you have little assurance that what you received is what you requested.

Arguing that TLS enforces centralization is laying it on really thick. Self signed certs are a thing and both they and expired certs must be acceptable by browsers. They can throw up errors or warnings but they can't reasonably disable them.

Also because users have to be able to import corporate/government root certs it's entirely possible to add some grass roots root certs (bad cow pun) that aren't beholden to some "establishment" set of root certs. You can also have your own grass roots DNS root servers if you really want.

But you're really just trading one trusted party for another, right? Now you don't need to trust your ISP (as much), but you do need to trust the certificate authorities.

Many ISPs have repeatedly demonstrated they are untrustworthy. Unfortunately in the US they tend to have regional monopolies. I don't have a realistic option outside of Comcast. So I have no choice but to use a shitty ISP and all of my traffic has to pass through them.

I do have a choice in trusting certificates. I can revoke trust of certificates, chains, and even root certificates. I can also choose to trust self signed certificates. But I don't have to trust my shitty ISP not to meddle in my traffic. I also don't have to trust the networks between my shitty ISP and a server. I don't need to trust those networks because I can verify a server's traffic against a chain of signing keys.

With unencrypted traffic every network between nodes is going to peak at the content and you have no way of knowing if they modified it in transit*. TLS provides encryption and verification. I don't trust my ISP at all. I don't have unlimited trust of CAs but they have less ability to compromise all of my traffic like my ISP.

* Without pre-shared signing keys.

Gemini uses TLS and it is common practice for Gemini clients to use self-signed certificates and TOFU. No dependency on centralized CAs.

TOFU seems to work pretty well for SSH. AFAIK not many people actively verify host fingerprints on first use. It doesn't protect against MITM attacks on the first connection, but I wonder if that's not a case of better being the enemy of good to some extent?

The high value targets are much more spread about with SSH than with HTTP. Finding a place where you could inject yourself between, for example, a user ssh'ing into a banking service and the banking service is going to be difficult. Just blindly MITM'ing a bunch of users at a coffee shop will probably get you little to nothing of any real value.

And because SSH is rarely used for the public to connect in to services it's a lot easier to add additional layers of security on top. Most valuable targets won't even be exposed in the first place or will have a VPN or some other barrier that would prevent the attack anyway.

From the HTTP end though, it's easy to narrow down "valuable" targets--there are like 5 main banks in my country. They're, by design, meant to be connected to by the public so there are no additional layers of security implemented. If you set up in a coffee shop for a day there's a pretty reasonable chance you'd find at least one or two people that had just bought a new device or were otherwise logging in for the first time that you could nab.

You'd also run into the issue of what to do when sites needed to update their certificates for various reasons. If the SSH host key changes it's pretty easy to communicate that out-of-band within a company to let people know to expect it. If a website's certificate changes what do we do? We end up training users to just blindly click through the "this website's certificate has changed!" warning and we're back to effectively zero protection.

> If you set up in a coffee shop for a day there's a pretty reasonable chance you'd find at least one or two people that had just bought a new device

Sure, but it's easy to protect against this - just connect to the same service via a different endpoint and check that both endpoints get the same certificate. AIUI this is how the EFF SSL observatory detects MITM attacks in the wild, and similar approaches could be used to make TOFU-to-a-popular-service a lot more resilient, at least wrt. most attacks.

I sort of thought TLS everywhere was more about encryption than authentication.

If it was only authentication then they'd be perfectly fine with unsigned certs. But they're not.

Don't worry, the day HTTP is deprecated is the day civilization is over.

Reply on news.ycombinator.com