4 ms·

This is like a version of Certificate Transparency for software. Attempts have already been made to port CT to software ("Binary Transparency"), and I like them

This is like a version of Certificate Transparency for software. Attempts have already been made to port CT to software ("Binary Transparency"), and I like them better than this approach. Specifically, you can demand a CT receipt from your downloads, proving that the existence of the download had been made public. Without that, and in this scheme, it's still possible to simply target someone with tailored malware and assume they won't bother to check hashes against one of these databases. With CT, the download client itself can automatically refuse a download that has not been publicly announced.

j_s 10y ago
Is there any accommodation for the per-user downloads implemented by Chrome, Dropbox, etc. (each with their own ways of sneaking around Authenticode verification)? https://textslashplain.com/2016/05/13/cheating-authenticode-redux/ https://textslashplain.com/2016/05/13/cheating-authenticode-...
- gruez 10y ago
  Why would they even do that? After you get a signing certificate, you can sign as many times as you want, so it's not like they're saving any money.
  - quicklyfrozen 10y ago
    Even if the installer is signed, Windows and/or your AV will warn you if it's a package that hasn't been downloaded by many other users.
andrewdavidwong 10y ago
Fair enough, but this system isn't intended for end users who, as you point out, are unlikely to bother checking the hashes of their downloads. Quoting Joanna Rutkowska: "Also, in case it wasn't clear: the primary audience for such a DB should be developers or admins (e.g. IT department in a large organization), I think. Not users. Users are always somehow fated to trust the 'last mile' vendor, and there is little feasibility in implementing any form of trust distribution for them." https://secure-os.org/pipermail/desktops/2016-November/000147.html https://secure-os.org/pipermail/desktops/2016-November/00014...
- cjbprime 10y ago
  Your quote's incorrect, in my opinion. Under CT, users are able to mistrust the issuing CA -- we start by assuming they want to give us malware (in the CT case, MITM certs) and trust them only to the extent that they are distributing publicly announced and tracked artifacts to us. This happens at the end user's computer, when their browser refuses to accept a cert with no CT announcement attached. This all happens in running Chrome browsers today. If other software (e.g. your Linux distro) similarly checked for publicly announced artifacts (e.g. an offered package upgrade) then you would be protected against targeted malware from your last mile vendor. The malware has to be either offered to everyone (ensuring detection) or no-one. I think the CT mechanism is simply better than a system that "isn't intended for end users", because a CT mechanism projects both administrators and end users.
  - andrewdavidwong 10y ago
    I don't speak for Joanna, but I interpret that quotation as saying something like: "Users are always fated to trust the 'last mile' vendor because the last mile vendor (e.g., Google Chrome), has control over what the user sees and does (i.e., sends and receives). If your Chrome browser is compromised or malicious, it can silently ignore the fact that no CT announcement is attached to a cert. In this sense, the user is fated to trust Chrome. "Moreover, there's little feasibility in implementing any form of trust distribution for them, but this is not to say that there's little feasibility in implementing a system that keeps them relatively secure. Users running a non-malicious, non-compromised instance of Chrome do not have any form of trust distribution, since they place all their trust in Chrome (though they probably don't realize it). Nonetheless, Chrome may be keeping them relatively secure as long as it's working properly."
    - cjbprime 10y ago
      Thanks, "last mile" confused me because it implies a transfer. With CT applied to software updates, I think you really could be suspicious-by-default of your software vendor. Do you have any thoughts on why codebase.db should exist, versus pushing the same hashes to a CT log and having clients check for CT announcements? Seems like CT is a clear improvement.

j_s 10y ago

Is there any accommodation for the per-user downloads implemented by Chrome, Dropbox, etc. (each with their own ways of sneaking around Authenticode verification)? https://textslashplain.com/2016/05/13/cheating-authenticode-redux/ https://textslashplain.com/2016/05/13/cheating-authenticode-...

gruez 10y ago
Why would they even do that? After you get a signing certificate, you can sign as many times as you want, so it's not like they're saving any money.
- quicklyfrozen 10y ago
  Even if the installer is signed, Windows and/or your AV will warn you if it's a package that hasn't been downloaded by many other users.

andrewdavidwong 10y ago

Fair enough, but this system isn't intended for end users who, as you point out, are unlikely to bother checking the hashes of their downloads. Quoting Joanna Rutkowska: "Also, in case it wasn't clear: the primary audience for such a DB should be developers or admins (e.g. IT department in a large organization), I think. Not users. Users are always somehow fated to trust the 'last mile' vendor, and there is little feasibility in implementing any form of trust distribution for them." https://secure-os.org/pipermail/desktops/2016-November/000147.html https://secure-os.org/pipermail/desktops/2016-November/00014...

cjbprime 10y ago
Your quote's incorrect, in my opinion. Under CT, users are able to mistrust the issuing CA -- we start by assuming they want to give us malware (in the CT case, MITM certs) and trust them only to the extent that they are distributing publicly announced and tracked artifacts to us. This happens at the end user's computer, when their browser refuses to accept a cert with no CT announcement attached. This all happens in running Chrome browsers today. If other software (e.g. your Linux distro) similarly checked for publicly announced artifacts (e.g. an offered package upgrade) then you would be protected against targeted malware from your last mile vendor. The malware has to be either offered to everyone (ensuring detection) or no-one. I think the CT mechanism is simply better than a system that "isn't intended for end users", because a CT mechanism projects both administrators and end users.
- andrewdavidwong 10y ago
  I don't speak for Joanna, but I interpret that quotation as saying something like: "Users are always fated to trust the 'last mile' vendor because the last mile vendor (e.g., Google Chrome), has control over what the user sees and does (i.e., sends and receives). If your Chrome browser is compromised or malicious, it can silently ignore the fact that no CT announcement is attached to a cert. In this sense, the user is fated to trust Chrome. "Moreover, there's little feasibility in implementing any form of trust distribution for them, but this is not to say that there's little feasibility in implementing a system that keeps them relatively secure. Users running a non-malicious, non-compromised instance of Chrome do not have any form of trust distribution, since they place all their trust in Chrome (though they probably don't realize it). Nonetheless, Chrome may be keeping them relatively secure as long as it's working properly."
  - cjbprime 10y ago
    Thanks, "last mile" confused me because it implies a transfer. With CT applied to software updates, I think you really could be suspicious-by-default of your software vendor. Do you have any thoughts on why codebase.db should exist, versus pushing the same hashes to a CT log and having clients check for CT announcements? Seems like CT is a clear improvement.