Comment by chrisfarms | Hacker News Reader

Comment by chrisfarms | Hacker News Reader

Parent Full thread

The encryption of the transport and the verification of the identity of the server should be more disconnected.

The CA part is only to verify that the machine you are talking to is who it says it is.... in reality all this really verifies is that they filled out a form and there is probably a money trial somewhere leading to a real entity.

But I've never understood why the identity is so tied to the transport security. It would make everyone's life easier if HTTPS could be used WITHOUT identity verification (for 90% of cases this would make the world a better place)

We'd still want to purchase third-party identify verification... and browsers would still present this in the same way ("green padlocks" etc)... but even without verification every connection could be encrypted uniquely, and it would raise the bar considerably for a great number of sniffing-based issues would it not?

EDIT: I guess what I'm saying is a social issue: We've put so much effort into telling everyone that "HTTPS is totally secure", that we've left no room for a system that is "Mostly secure, unless someone has compromised the remote system/network" .... maybe it's too late to teach everyone the difference between "encrypting a letter" and "verifiying that the person you give the letter to is who they say they are"

I'm sitting here still trying to think of a way to prevent MITM attacks if you have no idea who the guy is on the other side... Maybe I need to drink more tea this early in the morning?

I guess if you did something weird like flip the protocol upside down such that all people would have "internet licenses" and enter them into the browser they're using at that moment (or better yet, lets charge each user $50/yr PER BROWSER LICENSE) and it became the sites problem to encrypt to the end users key... One way or another I think you have to verify the identity of at least one side WRT MITM?

> I'm sitting here still trying to think of a way to prevent MITM attacks if you have no idea who the guy is on the other side... Maybe I need to drink more tea this early in the morning?

It's not that you don't know who the guy is, you just don't rely on a 3rd party to tell you that. See how SSH fingerprinting works.

SSH keys work exactly like self-signed certificates. On first connection you get the "whoah, this isn't trusted, do you want to proceed" warning, and if you accept, you are not warned in the future unless the key changes.

If browsers would make it easier to "permanently accept" a self-signed certificate (right now it's usually a multi-step process with blood-red warning messages at every step) we'd have the same situation as SSH keys.

HTTPS involves multiple servers that are interchanged regularly and commonly use different keys. The keys change regularly. There'd be no way to know if the key changing is part of regular operation or a man in the middle.

Note that there's a difference between SSH fingerprints and (self-signed) SSL certificates. Multiple servers can easily share a certificate.

It would be unwise to do so. In any case, phasing out old servers and certs for new ones is common practice. Using one cert everywhere (which would mean using one set of keys everywhere, which is a horrible idea) would require more downtime for maintenance of the certificates. It's not gonna happen.

> See how SSH fingerprinting works.

It doesn't, as a MITM prevention technique, for a gullible population. It doesn't even work for non-gullible population that's been trained to always hit "Y" on first connection from a host to a new server... err... I mean first connection to a MITM who then talks to the new server for you.

There are ways to make the situation slightly harder like the extremely unpopular idea of putting SSH host keys in DNS and then securing DNS ... err .. probably securing DNS via a CA type backend.... Well even unsecured DNS holding SSH host keys is better than nothing, or at least it makes people more susceptible because they feel safer, or something like that.

The odds of encountering a MITM attack on your first connection to a new server are low.

If it does happen, then the attacker will have to keep doing it forever, or else you'll get a warning the moment you manage to connect directly to the site without the MITM.

If your first connection is direct, then you're safe from MITM forever. If your first connection is compromised, then at least you'll likely discover that fact quickly.

I think this qualifies as "works".

I think the point is that most users wouldn't notice having to press "Y" again to accept a new fingerprint.

ssh only gives you the "y/n" choice the first time you connect. If you've connected before but the key has changed, it throws up a very nasty warning and does not even give you the choice to continue. You have to manually edit your key file to remove the offending entry if you want to start using the new key.

This seems similar to the logic behind TOR entry guards: https://www.torproject.org/docs/faq#EntryGuards

So you don't prevent MITM attacks...it's still a step up from cleartext.

All this change is meant to ensure is that all HTTP/2.0 traffic is encrypted, not that it is all authenticated. For authenticated communication, we continue to have what HTTPS is today.

The main issue is retraining people to not think that "https" means "safe". That's something that browsers are already good at, however, because there is already a world of difference between the user experiences of visiting a site with a trusted cert and visiting a site with an untrusted cert.

It's not a meaningful step up from cleartext, because a passive attacker can become an active attacker with just a couple spoofed packets or control of a single DNS resolver.

That's still a step up. Now you need to be an active attacker, and not just a passive one.

The perfect is the enemy of the better.

The worse is the enemy of the better too.

It's easy to decide to avoid the worse. But deciding on the tradeoff for the better vs the perfect is much harder.

This tradeoff is easy. UI that makes unauthenticated connections easier to accept is a bad idea; UI that makes certificate pinning work better is a good idea. Suggested tradeoff: pursue good idea, avoid bad idea.

It is a meaningful step up, because the passive attack is entirely risk free for the attacker, while an active attack carries with it the risk of detection.

The practicality of enormous secret drag-net operations like the NSA has been running would decrease dramatically if TLS had been the norm rather than the exception, even with unverified certificates. You can't opportunistically MITM 100% of connections without somebody noticing.

It is a shame that cleartext connections have to be the out-of-the-box default in every web server. Security should be the default, and I think the CA mess is to blame for that not being the case.

The sane thing to do would be generating a random self-signed certificate if the administrator didn't set up any explicit certificates. That would prevent passive attacks, and can be built on top of with technologies like certificate pinning and Convergence to mitigate active attacks.

This appears to be a comment that seriously suggests removing authentication from TLS as a countermeasure to NSA surveillance.

Not entirely. I kind of agree. I think I even posted a nearly identical comment once.

It would be nice if there were two kinds of connections. Encrypted unauth and encrypted auth. That seems strictly better than offering unencrypted connections. Your browser could still display the "wide open to attack" icon for encrypted unauth if you like.

Why?!

The entire reason people think TLS should have "unauthenticated encryption" (which is in the literature kind of an oxymoron) is that they don't like the SSL CAs.

I don't like them either.

But the SSL CAs are a UI issue. Instead of dinking around with the browser UI to make worthless "unauthenticated encryption" sessions appear different, why not just build a UI for TACK, let people sign their own certificates if they want, but then pin them in browsers so those sites can rely on key continuity instead of nothing.

Five years from now, if TACK pinning becomes the norm, I think it's a safe prediction that basic TLS certificates will be free from multiple vendors. Moreover, the corruption of the CA system will matter less, because unauthorized certificates will violate pins and be detected; the CAs that issue them can be evicted.

While we're at it, why don't we just fix the UI for managing CA roots? It hasn't changed since the mid-1990s.

I am baffled by why anyone would actively promote an insecure cryptosystem as a cure for UI problems, or even as an alternative for some entirely new cryptosystem like MinimaLT.

It's just a matter of what can be done today vs tomorrow vs next year.

All of these things are simply gated on browser vendors. That's the overhead. Why would you push for a new UI for insecure connections when you could instead lobby for TACK?

Of course not! I am suggesting that connections should be encrypted by default, whether the endpoints can be authenticated or not.

> All this change is meant to ensure is that all HTTP/2.0 traffic is encrypted, not that it is all authenticated.

This is a perfect example of <strikethrough>"good enough is the enemy of good"</strikethrough> "not completely broken in every possible way is the enemy of barely good enough" that is so prevalent in web security. If we don't use this chance we have now to secure internet traffic we will continue to be completely vulnerable to rogue WiFi AP like http://www.troyhunt.com/2013/04/the-beginners-guide-to-break... and to companies as well as countries snooping their employers/citizens traffic via huge proxies for years to come.

The "guy on the other side" is the fridge you bought at the store and just installed in your house.

You want to connect to it securely, but the fridge really has no way to prove to you who it is through any kind of third-channel.

Hell, forget about fridges. It's the router you just got at Best Buy.

A fence doesn't stop someone with a ladder, but that doesn't mean fences are a bad idea.

I couldn't agree more.

It is much more secure to visit a site with a self signed certificate than to visit the site over http. And yet, browsers start flashing red when you do that. At the least, they should show red on http, yellow on self signed https, and green on trusted https.

I agree.

One actual use case that could be solved in a better way than today would be login portals where a user have to be logged in to access the Internet.

Today, this is typically solved by issuing a redirect of some kind to the client (in the future, I guess it will receive a 511).

For HTTPS, the choices are a: Dropping the packets, ensuring extra costs in the support organizations when users wonder why their internet doesn't work. b: Doing a MITM and issue a redirect to the login portal that way.

Different operators choose different solutions here. Neither choice is good. Having a way of telling the client, that yes, while the connection is still encrypted, it didn't end up at the place it expected.

Might it be possible to add to TLS so that there are some way of issuing gateway redirect? Perhaps, perhaps not. I've seen precious little action in that area.

Surely there must be a solid reason why endpoint authentication and transport encryption must be extricably combined into one program.

Personally, I would find great use for the authentication function of OpenSSH as a separate program. In other words, a program that does one thing only: it verifies an endpoint is who it says it is.

The short answer is that at the time this stuff was designed, it was assumed that a passive attack could trivially become active instead, so it was assumed that defending against passive attacks wasn't worthwhile.

Newer info about fiber splitters invalidate that assumption.

Reply on news.ycombinator.com