I understand that SSL/TLS provides confidentiality and integrity.
But does it provide non-repudiation? I read in one book it does not. But I wonder why? What does it mean?
Can you clarify this point please, preferably with references.
I only recently learned of the existence of a new project. Some guys from the university of Zürich are working on something called "TLS-N" which is dedicated to bringing non-repudiation to TLS. There is no RFC that I know of yet. But they have a white paper. I'm not sure when/if we'll ever see this in the wild. But it's an interesting idea. See: https://tls-n.org
Also mentioned in their paper are some earlier attempts at bringing non-repudiation to TLS called TLS sign and TLS Evidence. Both attempts seem to have died a long time ago.
When Alice tells Bob "Let's kill the president!" and Bob goes to tell the police, then Alice can always say: "I never said that." So Alice just repudiated the previous statement.
And in regular TLS there is no way for Bob to prove by himself that Alice has in fact repudiated her earlier statement.
So no, regular TLS does NOT provide non-repudiation. So your book was right.
Now why is that? Asymmetric crypto allows you to provide proof of authorship by using Cryptographic Signatures. This WOULD in fact give non-repudiation. Then it would be straight forward to verify Yep, that really WAS signed with Alice's private key. And there is no getting out of that mathematic fact. (Of course then Alice could say: "But my key was stolen!" but there's no denying that her key was used to sign that particular message.)
So if in fact crypto signatures were used for regular TLS packets then they would be non-repudiatable. But signatures are NOT used for the regular TLS packet, so we don't have non-repudiation either.
Instead what is used to prove to the other side, My message has NOT been changed along the way is something called a MAC, a Message Authentication Code. MAC-functions work like this: You drop in two inputs and you get one output. One input is a secret MAC-key, the other input is the message that you want to protect. And what falls out is like a two-dozen byte hex-string, called a MAC Value. That string is sent along with the encrypted message. The recipient then feeds the same to inputs into the MAC function again and only accepts the decoded message if the MAC Value matches.
But since Alice and Bob both know the secret-MAC-key either one of them can generate MAC-values for whatever message they like. A MACed message says NOTHING about authorship of either Alice or Bob.
So if Bob goes and tells Charlie: Here's something evil Alice said!, then Alice can rightfully say: You could have written that your self!.
And thus: No non-repuditiation.
But: If there is a trusted third party (Alice's employer Charlie maybe) that has a network dump of the entire conversation between Alice and Bob then Alice will be in trouble. Regardless of any non-repudiation properties of TLS. Because Charlie vouches for the authenticity of the original network dump and Bob provides the key to decrypt the conversation. Of course Alice could still say Charlie is in on this! I'm being framed! but she's basically lost then.
TLS does not provide non-repudiation.
TLS is a transport layer protocol, that helps to protect the data that flows from one point to another. You can authenticate hosts with certificates or even a user with a client certificate.
However, non-repudiation means you can prove that a specific person received a message or is the author of a message. This always involves some kind of digital signature, which that person has to create using a secret (password, or key).
You can create such a digital signature with the same certificates you use for TLS authentication, but TLS itself does not provide any means for realizing non-repudiation of messages.
You could loosly say that non-repudiation is a layer 8 protocol somehow, where a person has to interact in order to prove that they read or authored something.
