(Updated to refer to PageSigner. The main webpage for PageSigner is here ).

(If you’re more interested in code than words, the main repo is here and oracle (server) part here . The rough technical workflow is here).

Fantasy tlsnotary

What we really want is something like this:

Browse to a website, log in, pull up the page with the juicy details.

Click a button and get a “notarized” or stamped copy of that page.

Some time later, pass that over to someone else (an auditor, or even the general public if there’s some reason to broadcast, and privacy doesn’t matter)

Simple, right? But the main version of TLSNotary doesn’t do that, for at least three reasons:

It doesn’t, and can’t, work for every single website; the most common reason is when the site is using certain kinds of dynamic content. By negotiating the TLS secrets with an auditor, you’re able to prove to the auditor that the data is valid, but not anyone else. See the previous post On Signatures for details of the issue here (repudiability). Doing it with an auditor is a cumbersome process – you need to organize to do it with them, at the same time. This is quite a lot of hassle; not enough to stop you if you really need an audit, but it matters.

Auditing != notarizing

If you look at the “delta-to-fantasy” list above, only problem #1 is baked in at the algorithm level. #2 and #3 are different – they are a consequence of insisting on the entire process only being carried out with a single counterparty – a single “auditor” agent. But this auditor agent is carrying out two separate functions:

prove that the data is honestly created

read the data (and interpret its meaning)

The beautiful thing is, you can prove that the data is not fake without reading the data, and without intercepting or reading the data even in encrypted form!

So, we introduce: the blind notary server. What does it do? It follows all the steps of the tlsnotary algorithm except the last one. It withholds the secret material needed to fabricate server traffic, and receives a sha256 hash (commitment) to the encrypted traffic, and only then releases that secret data to the auditee. At the same time, it provides a signature to the auditee confirming that that’s what happened – something like a notary stamp of the validity of the audit. The auditee then bundles it up into a file whose contents are, very crudely:

TLS secret data : Encrypted traffic from server : Notary Signature

This file is self-validating, assuming you trust the public key used to make the signatures (which is the notary server’s public key of course). It can be moved around and given to others as you like; we have created the effect of a digital signature on the html page – if the notary server is trusted to follow the rules.

The problem of trusting the notary server has been addressed by means of the use of the Amazon AWS oracle, as described here , and as coded here. Instructions are there on how to try it out.

Meanwhile, let’s consider what the server is not trusted with:

usernames, passwords, any user credentials

money

the TLS master secret (which would allow traffic decryption)

the TLS premaster secret (as above)

the HTML page

the encrypted version of the HTML page

(In case you are confused how it can not hold TLS secrets, note that it owns half of the premaster secret, which is useless without the other half, and only a hash value which is used to create the master secret, again useless on its own. It does not ever possess any of the ssl keys for the session, including the server mac key).

In fact, the only real information a user has to give to the server is the server public key of the website to be audited (and, after all it’s a public key).

Once the notary server has given you your signature, it has no more business with you. If you don’t like the audit, throw it away and do another one. Or not – the server has no knowledge or interest. The notary server’s signature means this and only this:

The user did not receive the secret material (S) to build the master secret (and therefore server mac secret) UNTIL they sent me the commitment hash (H) of the encrypted traffic for the site with pubkey N.

What is signed is (S,H,N).

Why this is useful.

This quasi-non-repudiable signature on pages could be useful in a broad context of cases. By splitting notarizing and auditing, users can simply hold audit files until they see fit to give them to another party. Any situation where a screenshot is of interest could be vastly improved by replacing it with a .audit file, whereever that works. Examples: