4 ms·

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

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?

lokedhs 12y ago
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?
- nothrabannosir 12y ago
  Same as now. What is inherently anti-OS the way we use certificates? In fact, most apps already use OS-wide root ca lists.
  - omphalos 12y ago
    > 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.
    - leni536 12y ago
      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.
lmm 12y ago
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)
- nothrabannosir 12y ago
  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.
  - acdha 12y ago
    > 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.
  - tracker1 12y ago
    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.
  - lmm 12y ago
    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.
deleted 12y ago
[deleted]

lokedhs 12y ago

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?

nothrabannosir 12y ago
Same as now. What is inherently anti-OS the way we use certificates? In fact, most apps already use OS-wide root ca lists.
- omphalos 12y ago
  > 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.
  - leni536 12y ago
    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.

lmm 12y ago

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)

nothrabannosir 12y ago
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.
- acdha 12y ago
  > 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.
- tracker1 12y ago
  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.
- lmm 12y ago
  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.

deleted 12y ago

[deleted]