Comment by skissane | Hacker News Reader

Comment by skissane | Hacker News Reader

Parent Full thread

I don't agree with this logic that "either you have perfect security or there's no point".

I think a lot of stuff on local LANs is still HTTP-only because trying to do TLS for local devices – even with LetsEncrypt – is a pain. Not impossible – you can't get a TLS certificate for 192.168.12.34, but you can create a public DNS entry pointing to that and then use a DNS-01 challenge to get a certificate for it. But that's enough work that heaps of people don't do it.

It also makes local LAN reliant connectivity reliant on public DNS – since you can't do https://192.168.12.34 you have to do https://device-12-34.example.com, if your Internet connection is down you might not be able to resolve device-12-34.example.com even though the device is up and accessible on your local network. Adding a local DNS server will fix that – but now that's another thing you need to make it all work.

Whereas if we had opportunistic encryption for http://, that would make local LAN passive attacks a lot harder. Yes it wouldn't stop against local LAN active attacks, but security against passive but not active attacks is still better than no security against either.

IPv6 actually resolves this. Not with Let's Encrypt (because they won't issue a cert for an IP address) or ZeroSSL (because they currently don't support issuing certs for IPv6 addresses), but it is definitely possible.

You wouldn't even have to expose the private network to the outside world. It could still be firewalled off.

Say if your prefix is 2a09:1337:8888:aa::/56 and your private prefix is 2a09:1337:8888:aaff::/64, just make sure that the router redirects all traffic from outside to the /64 to a box that listens for connections so a certificate can be issued. Of course you'd also need to be able to reach the said box from boxes within the private network (for .well_known cert requests), but it's trivial. No BGP required. Simple HTTP challenge.

Thanks for bringing up the local network scenario -- I've been skeptical of these kinds of opportunistic encryption schemes, but issuance for LAN devices is indeed a pain and seems like it would be well served by something like tcpcrypt.

At the same time: how do you foresee this interoperating securely with TLS? My first intuition is, without something even stronger than HSTS, that this would open up additional downgrade attacks against HTTPS: an attacker could do a normal HTTP downgrade and then present a TCP-ENO session that they control the key for. That's perhaps no worse than the downgrade itself, but I could see it being a source of user confusion if browsers choose to present this kind of scheme as "secure" in the UI.

> At the same time: how do you foresee this interoperating securely with TLS? My first intuition is, without something even stronger than HSTS, that this would open up additional downgrade attacks against HTTPS: an attacker could do a normal HTTP downgrade and then present a TCP-ENO session that they control the key for. That's perhaps no worse than the downgrade itself, but I could see it being a source of user confusion if browsers choose to present this kind of scheme as "secure" in the UI.

The obvious solution to that problem is - don’t show it in the UI by default.

For sophisticated users, have a config setting they can turn on which will show some kind of icon (not the padlock, a different one). For unsophisticated users, make it invisible.

Invisible protection against passive attacks is still better than no protection against passive attacks. But passive-vs-active is beyond the understanding of non-technical users, so for them keep it invisible.

What scenarios do you imagine where someone is willing to do a passive attack but not an active attack on the local lan? Local lan seems like the easiest place to do active attacks.

I agree that perfect can be the enemy of good, but i also think its important to do things that stop actual attacks. Things that make attacks just mildly more difficult are pointless since the attacks are going to be scripted anyways.

I'd think that a cache of known keys (trust on first use), synchronized across devices using browser sync, would be quite effective at protecting against MITM attacks as long as your first access to a LAN server (on any computer you have) is safe. Additionally there are orders of magnitude less attackers to a computer on a LAN than an Internet-facing machine. In fact, unless I have untrusted boxes on my network or targeted attacks, I actually feel safe hosting HTTP services (and I'm doing so right now, more or less safely), and if someone is performing targeted attacks on my network they could just break in and clone my hard drives without having to bother MITMing my connections (I value the ability to access my data across dual-boots more than I value disk encryption through Bitlocker or Linux-specific methods).

> I'd think that a cache of known keys (trust on first use), synchronized across devices using browser sync, would be quite effective at protecting against MITM attacks

How do you distinguish between a host you have seen before that has a mismatched key vs a totally new host which you have never seen before.

I guess it depends on how you are discovering these resources in the first place, but traditional answers like IP address are much less workable on the local network.

If I buy a new computer, I’m expecting an untrusted key message the first time I SSH to it. Whereas, if suddenly I got that message with an existing box, I’d start investigating. How would trust-on-first-use for HTTP on local network be any different from SSH on local network?

Reply on news.ycombinator.com