Hacker News Reader

Comment by amelius | Hacker News Reader

I'm amazed that in 2015 every application has to implement its own encryption.

Why doesn't the OS let us open "encrypted sockets"?

You can't separate encryption from authentication, and the application is the only thing that can tell you what qualifies as authentication.

With IPSec you can tell the OS "open an encrypted connection to 69.231.14.52" and the OS will verify that you're actually talking to 69.231.14.52 and no-one else can read your messages. But that's not actually terribly helpful, because what you want to ensure is that only Bob can read your messages. And only the application knows who Bob is.

Ok, what am I missing?

Now: Application: Hey OS, what is example.com's IP? Okay, now give me an unencrypted connection to example.com's port 80.

Desired: Hey OS, give me an encrypted connection to example.com's port 443. (+ optional encryption params like minimum key strength)

Why can't encryption be an OS level task, exactly?

But what if you get a reply "I am example.com, here's the encrypted socket". How do you know that the entity that replied isn't in fact something that is MiTM you connection?

Same as now. What is inherently anti-OS the way we use certificates? In fact, most apps already use OS-wide root ca lists.

> Same as now.

Along similar lines, I think it's strange that I now see warnings in Chrome for SHA-1 certificates but no warnings at all for http.

And firefox happily offers to save your password when you enter it into a http login window but yells at you if you try to connect to a self signed https webpage.

Hostname-based encryption only covers a small subset of use cases. If it's a web browser then sure, hostnames have become the way of doing that (although even then, browsers are starting to display the organization name in the top left alongside the URL). But for any kind of peer-to-peer program e.g. instant messaging or file sharing, hostnames are irrelevant; you care about the identity of the person on the other end, who's probably using a home connection that may not even have a public hostname (and will in any case change rapidly). Even for something as basic as email, you'd rather encrypt to a specific person than encrypt to gmail.com.

So in short hostname-based authentication is mostly useful for web browsers - which is why it's in the web browser, not the OS.

(Also, pragmatically, existing OS-based key management is terrible - just try and use the Windows dialogues to set up an SSL client certificate. For many users the very idea that you manage your keys separately from the programs you use them in is confusing. So browsers would rather provide their own cross-platform UI for key management, even if the OS offers a "managed SSL keystore" as most OSes do)

I can't think of a network related app I ever used where hostname based auth wouldn't be a net plus. Mail, chat, web browsing, VPN, VNC, network filesystems, ... Not to say "as long as I know that it's the right host, all my encryption needs are satisfied!" Sure, sometimes you want more. But knowing I got the host matching the hostname would always help.

As to the UI: Yes, but that's precisely because it is currently unclear who is responsible. Java has its own keystore, FF has its own but Chrome doesn't, even some libraries have their own or they don't, depending on the OS. It's a mess. A mess that I don't care about, as a user.

I want a central key store that apps tap in to. When I revoke a cert for Diginotar, I don't want to have to grep every file in my entire filesystem for that string on the off chance some crazy statically linked lib installed a local cert store somewhere.

And sure, an app wants to create a special case just for itself (e.g. a client certificate only for mail), let it. But I'd like that to be the exception, not the rule.

Cert management is a mess right now, and both developers and users are duped.

> I can't think of a network related app I ever used where hostname based auth wouldn't be a net plus

You're exactly right on this – APIs need to be secure by default. Yes, I'm sure that that'd make some of the certificate management issues more pronounced but that's something we need to solve anyway; increasing the expectation that everything should be encrypted will only help.

Chrome is the one that I feel gets it the most "right" ... I just wish that some of these interfaces were easier for other applications to use the system store. Even for host-based connections alone. I also feel that DNSSEC + certs would take this farther, and away from having to trust and pay certificate authorities.

It bugs me that it costs more for a wildcard domain cert than it does to host with a VPS for a year. I'm not saying it's prohibitively expensive for hobbies using multiple certs, just the same it shouldn't be this way.

You wouldn't want to be encrypting twice or three times over - at that point there really does start to be an overhead associated with it.

> Mail

Encrypting at the host level would be actively unhelpful (e.g. it would make failover or forwarding harder) and wouldn't gain you much in the way of security. You just want to encrypt the message to the actual recipient.

> chat

Again hostname-based auth is actively unhelpful in a federated system like IRC or XMPP (you want to failover to a different host if a particular host is down), and offers minimal security in a centralized-server system.

> VPN

I think a VPN is inherently the wrong approach to security; it's trying to create a network you can trust, but networks are too big to secure.

> VNC

How often do you VNC to a box with a stable hostname? I only ever use it to connect between my (coffee shop or wherever) laptop, my (dynamic IP) home machine and my (dynamic IP) dev machine at work.

Well, that's where certificates come into play. And managing those is a perfect job for the OS.

You wouldn't want to deal with certificates and keychains and all the UI stuff that comes with it from within an application.

> You can't separate encryption from authentication

Why not?

So you are saying these are our only 2 options?

1. I don't know who you are so we can't encrypt our conversation.

2. I know who you are so we can encrypt our conversation.

Why is there not a third option?

3. I don't know who you are but we can still encrypt our conversation.

You can, it's just that you don't know if the connection is actually encrypted from you to the person/machine you're talking to, or if there's someone in the middle silently spying on you and relaying the messages between the two.

And by "someone," that doesn't necessarily mean an actual person specifically targeting you, it may just be an infected machine or router that snoops on everyone.

There is option 3, for example with a self-signed certificate. That works well for talking to your own server.

But if you're trying to reach some other site, how would you know if someone is pretending to be the site you're trying to reach? Encryption is not much use in protecting privacy, if your encrypted connection goes to an imposter. That's why authentication matters as much as encryption for surfing the web.

I wouldn't. But if I'm using an unencrypted connection I know for sure that everything is readable all along the way.

It seems to me that implicit in the argument against option 3 is the assumption that if we have a system in which encryption is not tied to authentication that the net will be filled with MITM attackers, thus effectively rendering option 3 identical to option 1.

Is that a valid assumption?

Yes. With modern tools MITM is akin to spam: almost no marginal cost, so even if it only hooks a few people, it's worth trying. Here are some examples:

http://arstechnica.com/tech-policy/2013/04/how-a-banner-ad-f...

http://gizmodo.com/gogo-is-using-man-in-the-middle-malware-t...

Keep in mind these are legitimate, professional ISPs doing this, so we're not even into criminal or state-level MITM attempts, let alone basic griefing tools like Firesheep.

So yes, it is a valid assumption that the net is filled with MITM attackers.

How would that differ from opening up a TLS connection?

It is now user space, so every app needs to reinvent the wheel. Updates to the security layer are per-app. At best, they use a good library (something we hopefully trust the OS will do, too).

It's like the OS not providing TCP but only UDP. Sure, every app can include its own TCP stack. But I'd rather the OS do it.

How does using a library qualify as reinventing the wheel? Not everything needs to be done in kernel space. User space is a lot more flexible - for instance, an application can decide to use LibreSSL instead of OpenSSL, but it can't change the IPsec implementation in the kernel.

Show me a widespread OS that doesn't have a TLS library.

Not sure what you mean. OS X has Secure Transport (https://developer.apple.com/library/mac/documentation/Securi...)

What are you missing?

Reply on news.ycombinator.com