On Wed, Nov 19, 2014 at 6:35 AM, Michaela Merz <michaela.m...@hermetos.com> wrote:
> Well .. it would be a "all scripts signed" or "no script signed" kind of > a deal. You can download malicious code everywhere - not only as scripts. > Signed code doesn't protect against malicious or bad code. It only > guarantees that the code is actually from the the certificate owner .. and > has not been altered without the signers consent. > On Wed, Nov 19, 2014 at 5:00 AM, Michaela Merz <michaela.m...@hermetos.com> wrote: > > it would make sense. Signed code would make script much more resistant to > manipulation and therefore would help in environments where trust and/or > security is important. > > We use script for much, much more than we did just a year or so ago. > On Wed, Nov 19, 2014 at 6:41 AM, Michaela Merz <michaela.m...@hermetos.com> wrote: > > TLS doesn't protect you against code that has been altered server side - > without the signers consent. It would alert the user, if unsigned updates > would be made available. Signing allows you to verify that an entity did produce a run of bytes, and not another entity. Entity here meaning the holder of the private key who put his signature onto that run of bytes. How do you know this entity did that? Said entity also broadcast their public key, so that the recipient can compare. TLS solves this problem somewhat by securing the delivery channel. It doesn't sign content, but via TLS it is (at least proverbially) impossible for somebody to deliver content over a channel you control. Ajax downloads still require a download link (with the bloburl) to be > displayed requiring an additional click. User clicks download .. ajax > downloads the data, creates blob url as src which the user has to click to > 'copy' the blob onto the userspace drive. Would be better to skip the final > part. Signing, technically would have an advantage where you wish to deliver content over a channel that you cannot control. Such as over WebRTC, from files, and so forth. In regard to accept: I wasn't aware of the fact that I can accept a socket > on port 80 to serve a HTTP session. You're saying I could with what's > available today? You cannot. You can however let the browser accept an incoming connection under the condition that they're browsing the same origin. The port doesn't matter as much, as WebRTC largely relegates it to an implementation detail of the channel negotiator so that two of the same origins can communicate. Suppose you get a piece of signed content, over whatever way it was delivered. Suppose also that this content you got has the ability to read all your private data, or reformat your machine. So it's basically about trust. You need to establish a secure channel of communication to obtain a public key that matches a signature, in such a way that an attackers attempt to self-sign malicious content is foiled. And you need to have a way to discover (after having established that the entity is the one who was intended and that the signature is correct), that you indeed trust that entity. These are two very old problems in cryptography, and they cannot be solved by cryptography. There are various approaches to this problem in use today: - TLS and its web of trust: The basic idea being that there is a hierarchy of signatories. It works like this. An entity provides a certificate for the connection, signing it with their private key. Since you cannot establish a connection without a public key that matches the private key, verifying the certificate is easy. This entity in turn, refers to another entity which provided the signature for that private key. They refer to another one, and so forth, until you arrive at the root. You implicitly trust root. This works, but it has some flaws. At the edge of the web, people are not allowed to self-sign, so they obtain their (pricey) key from the next tier up. But the next tier up can't go and bother the next tier up everytime they need to provide a new set of keys to the edge. So they get blanket permission to self-sign, implying that it's possible for the next tier up to establish and maintain a trust relationship to them. As is easily demonstratable, this can, and often does, go wrong, where some CA gets compromised. This is always bad news to whomever obtained a certificate from them, because now a malicious party can pass themselves off as them. - App-stores and trust royalty: This is really easy to describe, the app store you obtain something from signs the content, and you trust the app-store, and therefore you trust the content. This can, and often does go wrong, as android/iOS malware amply demonstrates. TSL cannot work perfectly, because it is built on implied trust along the chain, and this can get compromised. App-stores cannot work perfectly because the ability to review content is quickly exceeded by the flood of content. Even if app-stores where provided with the full source, they would have no time to perform a proper review, and so time and time again malware slips trough the net. You can have a technical solution for signing, and you still haven't solved any bit of how to trust a piece of content. About the only way that'd be remotely feasible is if you piggyback on an existing implementation of a trust mechanism/transport security layer, to deliver the signature. For instance, many websites that allow you to d/l an executable provide you with a checksum of the content. The idea being that if the page is served up over TLS, then you've established that the checksum is delivered by the entity, which is also supposed to deliver the content. However, this has a hidden trust model that established trust without a technical solution. It means a user assumes he trusts that website, because he arrived there on his own volition. The same cannot be said about side-channel delivered pieces of content that composit into a larger whole (like signed scripts). For instance, assume you'd have a script file (like say the twitter API). Twitter signs that file. Let's assume there's some mechanism to verify that twitter as identified by their domain name, and as trusted over their TLS can then be contacted to provide their public key, so you can verify the signature. How do you know you can trust twitter? You haven't visited their website, you might not know who they are, for you, they're just one of dozens of entities which produced the content, which combines to a whole. Would you have to visit each signatories TLS presence to establish that you are satisfied they're trustworthy?