Hacker News Reader

Comment by thenewnewguy | Hacker News Reader

No they wouldn't, because this is trivially easy to MITM. The whole reason CAs exist is to verify the identity of the domain owner, because any random MITMer can claim to be yourbank.com and you can't prove it either way.

Very technically this would be slightly better because it stops passive observers, but in reality I suspect it would be worse because tons of websites would use this broken by design solution and think they were perfectly secure because encryption.

What we really need is to stop making HTTPS so hard to setup. It has gotten better in the last 5-10 years, but you still have to do this whole rigamarole with Apache2/nginx to disable weak cipher suites, setup all the right TLS parameters, etc because the default configuration is so bad. Imagine a world where I just installed an HTTP server and it asks me if I wanted to get a cert from Let's Encrypt (or any other ACME provider) and just did all the setup correctly for me.

View on HN

>Imagine a world where I just installed an HTTP server and it asks me if I wanted to get a cert from Let's Encrypt (or any other ACME provider) and just did all the setup correctly for me.

That is exactly what Caddy https://caddyserver.com/ does - except it doesn't even ask. Automatically setting up HTTPS is the default, zero-extra-configuration behaviour.

There are two aspects that are currently adressed by https: identity and privacy. What I’m proposing does indeed only solve the privacy aspect. And for some use-cases, that’s fine. Not all use-cases (e.g. your bank), and we would still have CAs for that.

Privacy is really the wrong word in my opinion. What you mean is confidentiality. This might sound like nitpicking, but private communication might mean that some attacker does not know who is talking to whom, which is not what TLS even tries to provide (anonymous communication). The term is somewhat overloaded. You can have fully encrypted communications and still give away information you intended to be private.

TLS does try to provide confidentiality and part of that is authenticating who you are talking to. Without this your communication is not at all confidential, as anyone could impersonate your intended target. A passive adversary can't read your traffic, true, but an active attacker (of for example the coffee shop dwelling variety) is not a major step up and would undermine the confidentiality aspect entirely.

Having private communication without knowing who you're talking to is not private at all. You need to first define who you want to hide the communication from (assumedly, everyone except the server in question), and then also know that you're really talking to that server and not just someone claiming to be that server.

For example, if there were a class of websites where certificates were not checked, I could configure my router to man-in-the-middle attack every connection to one of those coming from anywhere in my own network, and then re-transmit information in the clear somewhere else. To someone inside my network, their browser would report their connection as being "secure".

How does it solve the privacy aspect if I can MITM it and replay the second half of the conversation to the real party?

I want privacy with the site I'm trying to connect to including when I do so for the first time. I don't care about privacy with whomever is running a MITM attack on me since that's rather pointless.

That's what TLS 1.3 is all about. It has a very limited suite of ciphers instead of 1.2's "throw everything at a wall and see what happens".

Reply on news.ycombinator.com