Hacker News new | ask | show | jobs
by czarit 1030 days ago
TLS solves two problems, but was originally designed to solve three. The author seems to be annoyed that it does not solve the third problem.

TLS (or SSL, really) was designed to solve trusted authentication - that you could be sure the website that responded to your request was your bank. The idea was that a manual review from an authority would verify that the owner of certificate x was the "real" y, for some definition of x, y, real and authority.

It does not solve that problem, I agree.

It does, however, solve two other problems: The problem of message integrity - noone intercepted and changed this message between server and client; and the problem of eavesdropping - noone can read the message by observing the network traffic alone.

Now, of course, this all depends on the fact that the connection was setup correctly, and a man-in-the-middle attack that can redirect all the traffic for some domain to their own servers would possibly succeed. But that is quite a high bar! Modifying DNS or shaping network traffic in that way requires deep access, and is much, much harder than attacks with no SSL/TLS.

2 comments

Has there been any known successful MITM attack with forged certificates since the introduction of CT? I am not aware of any.
Those two other problems that it does solve could be done in a less centralized way, couldn't they? E.g., add a record to DNS that contains a public key for the domain. Clients can grab that when they are grabbing the server IP address.
That's not really any better than what we have now. In your model you need to have full trust in the DNS operator and that your DNS responses weren't MITM'd (which are still generally unencrypted!!).

In other words, you're just trading trusted CAs for trusted DNS operators.

We already have to place full trust in DNS operators—a rogue DNS operator could trivially get a LetsEncrypt cert for your domain and redirect your traffic to a different server that they control.
Sort of. Let’s Encrypt checks multiple DNS operators, so you’d need to compromise multiple from LE’s perspective.

Whereas putting the public key in DNS only requires compromising a user’s nearest DNS server. For example, in my home network I would be able to MITM any site that anyone using my DNS server, which DHCP will gladly hand out, attempts to connect to.

Edit: actually, I would be to MITM any unencrypted DNS lookup. So even if they didn’t use my DNS server, I could still alter the responses.

I didn't state it, but I was assuming that browsers would only use keys from DNS servers if they had used DNS over HTTPS to make sure they are talking to a DNS server that the user trusts.
And what if the request isn’t made via DoH (very few today are)? Do we just fallback to the existing Web PKI? If so we’d now have two systems to support until everything is migrated to DoH, which can very well be never.

Also, how do we know which certificate to use for DoH?

Ah, that makes sense! I thought you were talking about the root nameservers, I wasn't considering all the other DNS servers.
DNS is unexpected and easily modified.