3 ms·

What's an alternative implementation that encrypts the data at rest and is more resilient to a compromised server?

tptacek 13y ago
A downloadable client that doesn't bootstrap its own crypto every time it runs from your server. Can I have my $1000 now? Actually: I'd prefer if you just sent it to Partners in Health; they're great.
- absherwin 13y ago
  We can argue about the merits of downloadable solutions but that isn't a flaw in this application. I'm willing to make it easy for you: You can even have the database to let you crack it without first having to break into my server. I agree with you that there are risks to browser side crypto but how are they any different from upgrading software without reevaluating the security of each upgrade? Browser-based crypto also has benefits; most users prefer using web applications to installed all else equal because it's easier.
  - tptacek 13y ago
    Because normal users don't upgrade their applications every time they run them? I feel like people have to entertain this argument every time Javascript crypto comes up, and that it's a self-evidently silly argument. Would you feel as comfortable running SSH as a Java applet delivered from a website every time you needed it as you do running /usr/bin/ssh? Of course you would not.
    - absherwin 13y ago
      How is the frequency of upgrade relevant to the security of the system? If given a new version, people tend to upgrade and I take control of your software update mechanism, how is the security risk any less? You'd presumably argue that we should have higher security standards for a software update mechanism than a web application. If that's the case, would you agree that any web application that's as secure as a software update mechanism, should be allowed to distribute JS crypto? Edit: I have no specific problem running ssh as a Java applet if I trusted the site and connection. How do you determine when you're comfortable upgrading ssh or any other security program through your package manager?
      - tptacek 13y ago
        I gave a specific example. You fled to abstraction. I think my example is illustrative. You haven't explained why it isn't. So I'm going to decline to engage with your abstractions.
        Dylan16807 13y ago
        Well honestly the main reason I don't want to run the code in your literal scenario is the phrase 'java applet'. I wouldn't be very happy with a permanent one either. I think it's fair to focus on the downloading aspect, and ignore the issues of convenience/java. Then we see that people like AnIrishDuck are perfectly happy with such a scenario.
    - AnIrishDuck 13y ago
      While I understand your point and agree mostly with what you're saying, it's worth noting that a functionally equivalent thing happens with /usr/bin/ssh on most linux systems. A remote web site is consulted (usually via plain http, not even https!) and new code is downloaded. Signatures are checked locally (using gpg, which is itself bootstrapped from trusted installation media, and can be updated at any time like any other package), and then new software is installed. The update cycle is longer, but it's still there. Under the threat model of "your source of software is compromised", no system is safe.
      - tptacek 13y ago
        So try to articulate why you wouldn't be comfortable just doing a "curl foo.com | bash" every time you SSH'd to a site. Obviously, very few people would be comfortable doing this.
        AnIrishDuck 13y ago
        Because I wouldn't trust foo.com as a source of software, in your hypothetical example. If we're being hypothetical, I would have no problem running something like: $ wget https://openssh.org/releases/openssh-blah.tar.gz https://openssh.org/releases/openssh-blah.tar.gz ; tar -xf openssh-blah.tar.gz ; make && ./bin/ssh host If such a thing were possible (and not hideously slow). I agree with what I believe is your thesis: good crypto is hard to do right and that you should be very careful with which sources of crypto software you trust. I just wanted to point out that trusting trust is a big problem in our industry, and isn't magically solved by using binaries on your local machine.
      - CodeMage 13y ago
        The software source for stuff like /usr/bin/ssh is a thing that has some serious infrastructure, well-established procedures and well-organized people. Right from the start the trustworthiness of that source is higher than average, arbitrary site. I say "arbitrary", because I assume you would want to serve this JavaScript solution from your own site, the way people do with jQuery. On the other hand, if you do decide to serve it from one central place, then you could establish similar level of trustworthiness for that source, but your solution would still be at a disadvantage. Running JavaScript is like downloading new software to your home directory on a regular basis and executing it; you don't need to compromise the software source for /usr/bin/ssh, you just need to compromise a less trustworthy bit of software and then make that bit modify the in-memory behavior of /usr/bin/ssh (because JavaScript doesn't have the kind of security the OS gives processes).
  - CodeMage 13y ago
    > most users prefer using web applications to installed all else equal because it's easier. Except that all else is clearly not equal: your solution is insecure.
aidenn0 13y ago
Also remember a "compromised server" could be DHS serves you with a warrant that forbids you from discussing the warrant.
rdl 13y ago
A signed applet/activex/etc. or browser plugin signed by a different authority, or under some kind of multi-party audit and control. There is definitely something to building "hostproof" applications. Javascript delivered from the same host isn't how to do it. The long-term solution is probably some kind of packaged thing similar to a binary, and some means of separating out who controls the server infrastructure from who controls that code. Even if it's the same organization, there's no need for the code signing key to be "live" on the Internet, so someone who compromises front end servers shouldn't be able to compromise the binaries. Browser java hasn't lived up to any of its promises, and I'm not sure about native code execution mechanisms. webcrypto might be a way to solve this general problem in the future. There is of course the bootstrapping problem when you first visit a site, but there are out of band ways to try to address that. The other option is just to give up and do mobile stuff; a mobile development framework combined with server-side development framework designed to build "hostproof" stuff would be pretty cool. You get a trusted platform, potentially can do trusted stuff server side too, have a reasonable third party for distributing updates (at least on iOS) with some level of auditing in case of a bad app being served, etc. The problem is that if you can't trust Apple, you're kind of doomed; the ideal would be a per-enterprise root of trust, where no one else has the ability to push OS/app updates, and can actually verify how the hardware works. There was some work done by NSA with Android in that direction.

A downloadable client that doesn't bootstrap its own crypto every time it runs from your server. Can I have my $1000 now? Actually: I'd prefer if you just sent it to Partners in Health; they're great.

absherwin 13y ago
We can argue about the merits of downloadable solutions but that isn't a flaw in this application. I'm willing to make it easy for you: You can even have the database to let you crack it without first having to break into my server. I agree with you that there are risks to browser side crypto but how are they any different from upgrading software without reevaluating the security of each upgrade? Browser-based crypto also has benefits; most users prefer using web applications to installed all else equal because it's easier.
- tptacek 13y ago
  Because normal users don't upgrade their applications every time they run them? I feel like people have to entertain this argument every time Javascript crypto comes up, and that it's a self-evidently silly argument. Would you feel as comfortable running SSH as a Java applet delivered from a website every time you needed it as you do running /usr/bin/ssh? Of course you would not.
  - absherwin 13y ago
    How is the frequency of upgrade relevant to the security of the system? If given a new version, people tend to upgrade and I take control of your software update mechanism, how is the security risk any less? You'd presumably argue that we should have higher security standards for a software update mechanism than a web application. If that's the case, would you agree that any web application that's as secure as a software update mechanism, should be allowed to distribute JS crypto? Edit: I have no specific problem running ssh as a Java applet if I trusted the site and connection. How do you determine when you're comfortable upgrading ssh or any other security program through your package manager?
    - tptacek 13y ago
      I gave a specific example. You fled to abstraction. I think my example is illustrative. You haven't explained why it isn't. So I'm going to decline to engage with your abstractions.
      - Dylan16807 13y ago
        Well honestly the main reason I don't want to run the code in your literal scenario is the phrase 'java applet'. I wouldn't be very happy with a permanent one either. I think it's fair to focus on the downloading aspect, and ignore the issues of convenience/java. Then we see that people like AnIrishDuck are perfectly happy with such a scenario.
  - AnIrishDuck 13y ago
    While I understand your point and agree mostly with what you're saying, it's worth noting that a functionally equivalent thing happens with /usr/bin/ssh on most linux systems. A remote web site is consulted (usually via plain http, not even https!) and new code is downloaded. Signatures are checked locally (using gpg, which is itself bootstrapped from trusted installation media, and can be updated at any time like any other package), and then new software is installed. The update cycle is longer, but it's still there. Under the threat model of "your source of software is compromised", no system is safe.
    - tptacek 13y ago
      So try to articulate why you wouldn't be comfortable just doing a "curl foo.com | bash" every time you SSH'd to a site. Obviously, very few people would be comfortable doing this.
      - AnIrishDuck 13y ago
        Because I wouldn't trust foo.com as a source of software, in your hypothetical example. If we're being hypothetical, I would have no problem running something like: $ wget https://openssh.org/releases/openssh-blah.tar.gz https://openssh.org/releases/openssh-blah.tar.gz ; tar -xf openssh-blah.tar.gz ; make && ./bin/ssh host If such a thing were possible (and not hideously slow). I agree with what I believe is your thesis: good crypto is hard to do right and that you should be very careful with which sources of crypto software you trust. I just wanted to point out that trusting trust is a big problem in our industry, and isn't magically solved by using binaries on your local machine.
    - CodeMage 13y ago
      The software source for stuff like /usr/bin/ssh is a thing that has some serious infrastructure, well-established procedures and well-organized people. Right from the start the trustworthiness of that source is higher than average, arbitrary site. I say "arbitrary", because I assume you would want to serve this JavaScript solution from your own site, the way people do with jQuery. On the other hand, if you do decide to serve it from one central place, then you could establish similar level of trustworthiness for that source, but your solution would still be at a disadvantage. Running JavaScript is like downloading new software to your home directory on a regular basis and executing it; you don't need to compromise the software source for /usr/bin/ssh, you just need to compromise a less trustworthy bit of software and then make that bit modify the in-memory behavior of /usr/bin/ssh (because JavaScript doesn't have the kind of security the OS gives processes).
- CodeMage 13y ago
  > most users prefer using web applications to installed all else equal because it's easier. Except that all else is clearly not equal: your solution is insecure.

aidenn0 13y ago

Also remember a "compromised server" could be DHS serves you with a warrant that forbids you from discussing the warrant.

rdl 13y ago

A signed applet/activex/etc. or browser plugin signed by a different authority, or under some kind of multi-party audit and control. There is definitely something to building "hostproof" applications. Javascript delivered from the same host isn't how to do it. The long-term solution is probably some kind of packaged thing similar to a binary, and some means of separating out who controls the server infrastructure from who controls that code. Even if it's the same organization, there's no need for the code signing key to be "live" on the Internet, so someone who compromises front end servers shouldn't be able to compromise the binaries. Browser java hasn't lived up to any of its promises, and I'm not sure about native code execution mechanisms. webcrypto might be a way to solve this general problem in the future. There is of course the bootstrapping problem when you first visit a site, but there are out of band ways to try to address that. The other option is just to give up and do mobile stuff; a mobile development framework combined with server-side development framework designed to build "hostproof" stuff would be pretty cool. You get a trusted platform, potentially can do trusted stuff server side too, have a reasonable third party for distributing updates (at least on iOS) with some level of auditing in case of a bad app being served, etc. The problem is that if you can't trust Apple, you're kind of doomed; the ideal would be a per-enterprise root of trust, where no one else has the ability to push OS/app updates, and can actually verify how the hardware works. There was some work done by NSA with Android in that direction.