3 ms·

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 da

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.

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.