(Updated to refer to PageSigner. The main webpage for PageSigner is here ).
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.
Meanwhile, let’s consider what the server is not trusted with:
- usernames, passwords, any user credentials
- 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
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.
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:
- Prove you received an offensive private message on your favourite message board or social network (that could put the cat among the pigeons!)
- Prove that a website retroactively changed its statement
- Prove that a website is reporting a certain financial balance to you. Why? To help with peer to peer trade? To brag? To give evidence of fraud? The list goes on..