Hacker News Reader

Comment by franga2000 | Hacker News Reader

franga2000

Yeah, there really needs to be a "secure, but not trusted" mode. My suggestion would be add a "trusted-only" TXT DNS entry that a browser could check when presented with an untrusted connection.

HTTP: gray broken padlock HTTPS+Cert: green padlock HTTPS+no cert: gray padlock HTTPS+no cert+trusted-only: red broken padlock

Any complaints? No? Ok, let's make it a standard! Oh wait... we're not in control of the standard, it's the world's largest cloud hosting, service and product providers. Intranets and locally-accessible embedded devices are a threat to their business model. Fuck.....

View on HN

There's no such thing as "secure, but not trusted". The security depends on the trust. That isn't just how TLS works; it's how all secure key exchanges work.

s/secure/encrypted/ ?

There’s little point in encrypting if you’re not authenticating

Which is why ssh is meaningless compared with telnet?

Obviously, SSH authenticates. But on that first connection, when it prints the "you've never seen this key before" warning? You get that you're not getting any real security on that connection, right?

That's exactly how mail works between servers though. Granted, it's about semantics, but virtually all mail servers accept TLS connections without the need to check cert validity of their respective counterparts.

Yes: encryption does not work in multi-hop SMTP email. Email is not a secure messaging system, and it is difficult to even build a novel secure messaging system on top of it.

Client-server TLS has a goal of actually thwarting adversaries. SMTP encryption is mostly about raising the costs of adversaries (I think there's plusses and minuses with this strategy; to some threshold, increasing costs for the US IC is actually helping them, organizationally, because the IC's real primary goal is budget-seeking).

That is very obviously not the case. A self-signed certificate protects data from being intercepted and read just as well as a signed one. The only thing "valid" certs protect from that self-signed certs don't is impersonation. In the case of an intranet or local embedded device, if someone can MITM your connection, you're already screwed - and either way, your are just as screwed getting MITMd with an unchecked cert as you are with no encryption. The difference is, that without any encryption, an attacker doesn't even need to MITM you - they can just sit quietly and snoop on your packets.

One of the basic jobs of a secure transport is to prevent MITM attacks. MITM attacks are the modal attack on TLS. It's not 1995 anymore. Nobody's using solsniff.c.

On the face of it, it sounds simple enough: special treatment when the IP address is an IETF-designated private IPv4 address (e.g. 192.168.x.y).

Is there some reason this wouldn't work, that I haven't thought of?

Whitelisting specific addresses makes me uncomfortable.

But I can't actually articulate why it would be bad in this instance, so maybe it's fine...

I considered that, but I think at the moment there's no concept of IP address for web certificates, it's all based on domain names as far as I know.

It doesn't mean it's not doable of course, but I could understand if it make people uneasy since it means that the same domain and the same certificate would behave differently depending on what it resolves to.

It may be an interesting solution to consider though. That would definitely make my life easier.

> there's no concept of IP address for web certificates, it's all based on domain names as far as I know

Regardless of whether you can or can't issue a certificate with a CN of an IP address, the browser doesn't receive the certificate in isolation, it receives it from an IP address, and can handle certificate validation differently depending on what it's connected to.

This may be a terrible idea for reasons I haven't considered (it probably is), but I can't think of any off head myself right now.

EDIT: this is probably terrible because someone can just stick a MITM proxy on your lan, and poison your DNS to resolve google.com to a RFC1918 address and boom.

You absolutely can get a certificate for an IP address. Clients should verify them based on the common name, and a subject alternative name has various field types including IP address.

A quick Google search shows various certificate authorities who will issue certificates for IP addresses.

Public addresses only though:

https://stackoverflow.com/questions/2043617/is-it-possible-t...

There are companies who’ve been using public IPs on their intranet for decades, however.

well, rfc1918 addresses just specify which ranges should not be advertised into the default free zone. (aka, the internet routing table). It says nothing about if a network is LAN or not.

One could totally build a network with globally routed addresses, and not announce those addresses to the rest of the world.

> "One could totally build a network with globally routed addresses, and not announce those addresses to the rest of the world."

Could, and people do; I've worked on networks where the original people must have misunderstood networking and did the equivalent of using 10.0.0.0/8, 11.0.0.0/8, 12.0.0.0/8 for internal networks, including public /8s they didn't own, so they lost access to one or two chunks of the internet - and it never seemed to cause all that many problems for them working this way (so no motivation to do a big involved risky rework-everything project). We added new private network subnets for new build things, but never swapped everything over. It'll phase out eventually I guess.

Reply on news.ycombinator.com