TLSNotary – Prove you received a webpage from a server with TLS signatures(tlsnotary.org)
tlsnotary.org
TLSNotary – Prove you received a webpage from a server with TLS signatures
https://tlsnotary.org
12 comments
So, TLS promises to deliver three things: Authentication, Confidentiality, and Integrity.
Authentication means Alice knows this TLS connection is to Bob's server and (optionally, rarely used for HTTPS) Bob's server can have Alice's client prove who it is too.
Confidentiality is the obvious one, all this is encrypted, so Mallory can't tell what Alice sent to Bob or vice versa (but, from a position in the middle Mallory can see that Alice and Bob are communicating and put an upper bound on how much was sent each way)
Integrity means that Mallory also can't tamper with the messages. Even though Mallory doesn't know what they mean, in a lot of trivial encryption schemes, Mallory can tamper with it blindly. This won't work in TLS, if Mallory changes things randomly the connection just drops, and from the middle position dropping the connection was always possible anyway.
Now, back in older TLS versions it's usual for Integrity to be protected separately from Confidentiality via a MAC (Message Authentication Code). This is like a checksum, except cryptographic so that Mallory has no practical chance to guess a valid encrypted message other than the real one.
The TLSNotary scheme arranges that one party doesn't know the MAC used for their TLS session until after they've concluded the session and handed a transcript to another party. Since they didn't know the MAC they could not have faked the transcript.
This won't work in modern TLS because we don't use MACs. Instead a scheme like AES GCM is used, in which both confidentiality and integrity are protected by a single key in the same operation. This turns out to also improve the security ergonomics, it's much less tempting to do things that are a bad idea because those things are now hard whereas doing it properly is easy. However, since a single key is used, the TLSNotary scheme is not possible.
Authentication means Alice knows this TLS connection is to Bob's server and (optionally, rarely used for HTTPS) Bob's server can have Alice's client prove who it is too.
Confidentiality is the obvious one, all this is encrypted, so Mallory can't tell what Alice sent to Bob or vice versa (but, from a position in the middle Mallory can see that Alice and Bob are communicating and put an upper bound on how much was sent each way)
Integrity means that Mallory also can't tamper with the messages. Even though Mallory doesn't know what they mean, in a lot of trivial encryption schemes, Mallory can tamper with it blindly. This won't work in TLS, if Mallory changes things randomly the connection just drops, and from the middle position dropping the connection was always possible anyway.
Now, back in older TLS versions it's usual for Integrity to be protected separately from Confidentiality via a MAC (Message Authentication Code). This is like a checksum, except cryptographic so that Mallory has no practical chance to guess a valid encrypted message other than the real one.
The TLSNotary scheme arranges that one party doesn't know the MAC used for their TLS session until after they've concluded the session and handed a transcript to another party. Since they didn't know the MAC they could not have faked the transcript.
This won't work in modern TLS because we don't use MACs. Instead a scheme like AES GCM is used, in which both confidentiality and integrity are protected by a single key in the same operation. This turns out to also improve the security ergonomics, it's much less tempting to do things that are a bad idea because those things are now hard whereas doing it properly is easy. However, since a single key is used, the TLSNotary scheme is not possible.
Apparently by plugging into the handshake process the auditor can verify the session key and MAC. The idea is simple: you just save a full replay of the session and thus it can be verified to be legitimate.
In modern TLS this just doesn't work, because you generate a shared key. You can verify what you've received from the server because you know you didn't generate it, but someone else cannot verify if any content was generated by you or the server, only that it was part of an exchange between you and the server.
TLS 1.0 didn't generate a shared key?
There's other mechanisms that work with recent TLS protocols, like Deco: https://arxiv.org/abs/1909.00938
Excellent paper, thank you for sharing it.
As far as I can tell "by logging out before delivering the data, he can render any session cookies invalid" means that if you use this mechanism and forget to sign out partway through the process you're potentially handing over session cookies. This seems like a really unsafe design.
I think you hand them over regardless, the logout is to render them invalid.
I wonder how many sites neglect that part.
I wonder how many sites neglect that part.
https://www.youtube.com/watch?v=cVknXa1bg2M
Why is the video shot in Windows XP? How old is this project?
Why is the video shot in Windows XP? How old is this project?
I think you've forgotten what Windows XP looked like (it's been a while!). That is Windows 7.
Plus it says right under the video that it was uploaded in 2015. Why should do they re-do the whole video every time a new Windows version is released just so that it looks modern and fresh? If anything, I appreciate that they don't waste their time doing that when there's nothing new to show. Though in this particular case it does seem like the browser plugin might be dead (see other comments in this thread).
> UPDATE October 2020. These instructions will only work if you use an old Firefox version which was around in 2015 (e.g. v37). Additionally the website you plan notarize must support TLS 1.0 or TLS 1.1 (a rare thing in 2020). Finally, you will have to modify /src/shared/pubkeys.txt and provide pubkeys which are up-to-date. Run the auditee like this python2 ./src/auditee/tlsnotary-auditee.py
Also, the site fails hard at explaining how the hell it works. If you're in a situation where you need something like this, you understanding how it works is irrelevant. It needs to be understood and believed by the person arbitrating the dispute. I'm a sysadmin, I've read it three times, and I'm still left blinking in confusion. I can't figure out whether it's exploiting some TLS weakness, or the plugin is performing a separate fetch of the page with the user's session credentials, or what.
Can anyone explain?