##What does it do?(Or what's this all about?)##
Think of it as a cryptographically enhanced, on-steroids version of your generic, run-of-the-mill screen capture tool; it captures a webpage, attached with the proof that it comes from a particular website - as long as said website supports SSL connections - and sends it to an auditor who will then verify that the proof matches the content of the page provided.
##Why do I want to show this to a third-party? ##
There are many usage scenarios, e.g., people routinely provide screenshots or printouts as proofs that a transaction took place, or that certain words are said by certain people at certain places/times, to an authority to decide who is telling the truth. Such arbitrations/dispute settlements trhough a third-party are really common in our daily lives. An example might be proof of funds to support a visa application, or proof of residence using utility bills to set up an account.
##Why the need for all this crypto wizardry? My [screen-capture tool/printer/Skype session] works for me!##
Cryptography can provide protection against forgery (in other words, it can be used for checking authentication and integrity of messages - see HMAC for how this is achieved in TLS/SSL). Without such protection it's quite easy for the technically capable fraudster to produce an authentic looking fake proof even in high-stakes scenarios. E.g., it may be as simple as editing a number in the html source file of a bank statement to show a false value of total transfer amount. Even screen-share auditing with Skype is not immune to simple tricks like redirecting the browser to a spoofed local page by just making a few changes to the cert database and hosts file. More advanced frauds may involve setting up fake websites. Proper use of cryptography can prevent this.
##That sounds scary, then how does your program protect me?##
Whenever a page is retrieved through an SSL connection, your browser sends an encrypted secret to the server on which the page is hosted, both the browser and the server then use the secret to create several keys, one of which is used to encrypt the communications between you and the server, while another is used to authenticate the page as being from the server. With TLSNotary, both the auditee and the auditor will be responsible for generating half of the secret, then the auditor will send the part of the secret needed by the auditee to generate the encryption key to the auditee, so that he alone knows the encryption/decryption key and nobody, including the auditor, can spy on information he shouldn't know (e.g., his password). At the same time, the auditor will get the part required to generate the aunthentication key from the auditee, so that he alone knows the authentication key, and the auditee, without the key, cannot produce a fake page which can be verified by the key, to fool the auditor.
##So there is no way the auditor can see my password?##
No, at no time does TLSNotary touch your password. In fact, it's specifically designed to not be able to touch your password at all! To make a banking session auditable, TLSNotary modifies the process of generating the SSL master secret, which is independently regenerated each time you connect to the bank, and unrelated to your password. In addition, TLSNotary only starts the auditing process after the page you want to present for auditing is fully loaded, and you click the "Audit This Page" button, which it does by receiving an instruction from a browser exetension, and initiating a session completely independent from the one established with your browser. As long as you never click this button on a page where you input your password, or record it explicitly, TLSNotary cannot know your username or password, encrypted or unencrypted.
##But are the SSL keys generated by TLSNotary weaker than the 'normal' ones?##
To make it possible to generate a secret which each party only knows a portion of, TLSNotary makes use of [RSA homomorphism] (https://en.wikipedia.org/wiki/Homomorphic_encryption#Unpadded_RSA) , which basically allows two secrets to be multiplied in their encrypted forms. However, this multiplication must be carried out with a certain number of zeros in each secret, to ensure all parts of the secrets are preserved in the key-generation process, this requirement of number of zeros reduces the entropy used in the TLS secret considerably, from 46 bytes to 21, which is split between the auditee/or. However, 21 bytes of secret still needs 2^168 attempts from an external attacker to brute-force, which is by any means impractical. To further protect the auditee from a man-in-the-middle attack by the auditor, we distribute 12 bytes of the 21 bytes to the auditee, which, given the short span of the window of attack(after the auditee receives the page the keys would be immediately expired), 12 bytes give the auditee an equivalent protection to 3DES for 16 years, which is believed by NIST to be safe until 2030. The remaining 9 bytes of randomness will be injected into the HMAC key, which gives it a effective brute-force strength against forgery of 2^72 in a few minutes, which we also believe to be adequate.
##But in that case how am I supposed to tell if the page from the server hasn't been tampered, without the authentication key?##
The auditee will in fact, get the authentication key to check the page, but the trick here is he can only do that after he commits the page cryptographically to a value, much like how the authentication scheme using the key works, the commitment is designed to be so strong that he cannot modify the content of the page to be audited after he makes the commitment.
##Great, then how should I use it?##
Thanks for taking the interest to try it out. See the How to install, User Guide and video intro.
##But why should I trust you?##
You shouldn't, you should trust math and, to whatever extent possible, code that you can read and understand. We have tried extremely hard to make sure that the technical architecture requires trust nowhere; the code is in Python and Javascript, so there are no binaries to download. The algorithm, like the code, is 100% open source and everything is accessible here on the github repo. Most importantly, there is no modification needed to your Firefox browser; TLSNotary will simply be run as an add-on in your own copy of Firefox.
##How does my tlsnotary communicate with an auditor?##
The communication is done through an IRC channel and server of your choice, which can be specified in the "Advanced" settings - the default channel is #tlsnotary on Freenode IRC, and all the traffic between the auditee/auditor is encrypted using 2048 bit RSA, so no one other than those who hold the private keys can view it. In order to facilitate such encrypted communication, the TLSNotary program will generate a public key for you before the session starts, which you will exchange with the auditor for his public key.
##OK, enough high level overview. I need the details.##
Start here. This gives the theoretical underpinnings of the TLSNotary algorithm. A heavy dose of the RFC is a prerequisite. After that, you may need to review code. The most important part is in tlsn_crypto.py and the prepare_pms step which begins the audit process in the auditee module here and process_messages in the auditor module. To understand how the auditor and auditee communicate in detail, please also read the messaging protocol specification.