Re: What I am missing

On Wed, Nov 19, 2014 at 6:35 AM, Michaela Merz <michaela.merz@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.merz@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.merz@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?