I stumbled into this recently for a specific project I had in mind. I thought HTTPS would prove that a given content actually came from the origin, by having its contents always signed before transfer. But actually, after the initial handshake, all communications are only secured through an agreed-upon symmetric encryption key.

This really surprised me, because non-repudiation is really important in communications, and all ingredients are available on the tech stack to make it happen.

Why wasn't it implemented? Is it purely from a performance standpoint? Is there another motivation? Is it planned to be implemented?

  • Related: crypto.stackexchange.com/questions/5455/…
    – mti2935
    Commented Dec 23, 2020 at 13:49
  • Also security.stackexchange.com/questions/143375/… and half a dozen more linked there @mti2935 Commented Dec 24, 2020 at 0:10
  • 1
    Your description isn't quite correct. Each TLS message is not only encrypted but accompanied by a secure message digest.
    – user207421
    Commented Dec 24, 2020 at 3:14
  • 9
    I'd disagree with the premise that "non-repudiation is really important in communications". Of all the properties that are commonly guaranteed via cryptographic means, non-repudiation seems to be one of the least useful ones. Can you come up with a scenario where this is actually more useful than the confidentiality/authenticity/integrity already provided by SSL? Commented Dec 24, 2020 at 6:33
  • 2
    For some discussion of why non-repudiation may not be desirable, read this posting by Matt Green about how DKIM accidentally provides non-repudiation of email messages, and why that can be a bad thing. Commented Dec 24, 2020 at 20:54

5 Answers 5


TLS is a two-party communication protocol, and HTTPS is not much more than HTTP over TLS. Its threat model considers only two participants (the client and the server) and its goal is to secure the communication against attackers who might read or modify the data that is exchanged. Non-repudiation does not fit in this threat model at all: it's about allowing a third party to verify properties of the communication, which was never a goal of TLS or HTTPS.

Your claim that “non-repudiation is really important in communications” is false. Non-repudiation is a rare property, and is often not important or even not desired. Deniability (the ability for one or both parties to deny that a particular exchange of data took place) is about as commonly desirable and achievable, and it contradicts non-repudiation. TLS guarantees neither non-repudiation nor deniability, but is compatible with both. For non-repudiation, you'll want to at least have the non-denying party sign the data to commit using an asymmetric signature scheme. For deniability, you'll want to take precautions against recording by a reliable third party. (Neither of these are enough! Both non-repudiation and deniability are complex properties.)

Furthermore, even when non-repudiation is important, it is not important in communications. It's mostly orthogonal to how communication works. Non-repudiation is fundamentally an end-to-end property: one or more entities commit to a certain piece of data. TLS is a point-to-point communication protocol, and HTTPS commonly involves multiple entities generating content on the server side.

Even end-to-end communication protocols rarely guarantee non-repudiation on their own. A signature does not guarantee non-repudiation, since it leaves open the “nuclear option” that the signing party could deliberately leak its signing key. In fact, for this reason, it's impossible to achieve general non-repudiation by purely cryptographic means (i.e. without resorting to a trusted third party). The most you can achieve is to design a protocol where the nuclear option causes so much collateral damage that the signer would not want to use it, and that's a judgement that can only be made in a specific setting.

It would be possible to modify the TLS protocol to add an asymmetric signature to every message, which would commit each party to having sent these messages, short of invoking the nuclear option. But:

  • In many cases, the client is not authenticated. So only the server would be committing to anything, not the client.
  • Depending on the protocol carried over TLS, the signature may or may not commit to anything meaningful. Often, the data exchanged includes parts that are meaningful to both sides, but not to third parties that could be interested in verifying that the exchange took place. For example, it might involve references to cached data, or references to the current state of data on the server that are not verifiable after the fact (“delete the third row”).
  • Depending on the protocol carried over TLS, the signed data might include parts that must not be revealed. Since TLS does not know anything about the data that it carries, the most it can guarantee is the authenticity of the whole exchange, or of some prefix of it. So if, for example, the communication starts with a user logging in with a password, there would be no way to authenticate subsequent data without revealing the user's password.
  • The cost of calculating and verifying the signature on every packet would be very high. Asymmetric cryptography is a lot more expensive than a MAC.
  • The amount of data to exchange would be slightly larger. (Significantly larger if it comes to post-quantum signature schemes.)

If you need non-repudiation:

  • Review your threat model carefully. Identify which party might want to lie about the data that it sent, and which party it must be accountable to.
  • Protect the data that needs to be protected. This will almost never going to be the whole communication — for example logins typically need to be excluded. Generally, there'll be one or more round-trips to determine the data, and then the server will send a signed message.
  • The signing key used for the non-repudiable data may be different from the signing key used for communication (the former belonging to the backend, the latter belongining to the frontend).
  • I disagree that TLS does not guarantee deniability. If I gave you a copy of encrypted messages and the master secret, you would have absolutely no way of knowing whether or not the message has been tampered with, since the master secret would let me compute the MAC key, modify the message contents, and recompute the digest.
    – forest
    Commented Jan 3, 2021 at 4:11

I thought HTTPS would prove that a given content actually came from the origin, by having its contents always signed before transfer.

Since "content" is sent in both directions, providing non-repudiation would require some cryptographic identity capable of signing on both sides of the communication. But TLS actually only requires some proof that the server is the expected one (to protect against man in the middle attacks). And this proof does not even need to be backed by a cryptographic identity, but can also be backed by some shared secret (i.e. PSK).

And while in most cases of TLS a certificate is used on the server side, there usually is no certificate on the client side. This means that non-repudiation could not work in both directions. Requiring some client side certificate would make the practical use of TLS much harder, since not only would each browser need to come with its own trust store as is done currently but also each user needs to have a personal certificate.

On top of this it is questionable if users would really want to have non-repudiation for everything they send. This is probably contrary to the quest for more privacy and anonymity. There is a reason protocols like PGP or S/MIME offer both encryption (including integrity) and signing (non-repudiation) separately.

In short: non-repudiation makes the protocol and the necessary infrastructure more complex and might not be even wanted in many cases. TLS therefore sticks with protecting the communication only, which is enough for most use cases of TLS. If non-repudiation is actually wanted or required (and often it is not) it can be added separately.

  • 1
    The fact content is sent in both direction is not really relevant as the protocol could simply provide non-repudiation for the side that has a certificate only. The important point is to whom the non-repudiation would be.
    – Jan Hudec
    Commented Dec 29, 2020 at 22:38

Among other reasons, I'm not prepared to say at a protocol level that there isn't a way to say to a CGI server, "echo this content". If you don't have non-repudiation, then this is a non-issue for security reasons; but if you have it at a protocol level, than this is a security breach.

If I want non-repudiation I'll use a signed-content file format, not a signed delivery protocol. X509 can sign quite a few things including zip files.


Non-repudiation is a legal property and as such cannot be "supported" by a protocol such as TLS. The property is interesting in case of disputes which ultimately must be fought before a court of law and can only be evaluated when taken the whole environment into account and the trust that is put into the environment can be shown to be warranted.

For example, if we're talking about non-repudiation in GPG then I might be liable when I ordered my company (I don't have a company.) to dump toxic chemicals in a nearby river. If I was so dump as to sign that e-mail, it might be said that it was really me that sent that e-mail. To refute this, I might show the court that my security of securing by private signing key wasn't that good and somebody else was able to send this e-mail and delete it from by sent folder.

Coming back to TLS. Let's say a service provider utilizes TLS offloading and simply stores all of the unencrypted traffic to some storage medium where only very few and trusted people have access to and who don't have any ties to the person in question. This is a record of who communicated what and when. It can be argued in a court that this is accurate.


Other answers are OK but miss an important point.

An important reason why non-repudiation cannot be imposed on HTTPS (and TLS in general) is the forward secrecy feature of TLS.

Forward secrecy and non-repudiation are mutually exclusive features.

  • Mandatory forward secrecy is a somewhat recent feature of TLS. Commented Dec 26, 2020 at 17:15
  • 1
    Forward secrecy does not make non-repudiation impossible. Forward secrecy prevents a third party from reconstructing the plaintext if both communicating parties erase temporary keys. It does not prevent one of the communicating parties from disclosing the plaintext after the fact such that the association with the ciphertext can be verified. Commented Dec 26, 2020 at 19:11
  • @Gilles'SO-stopbeingevil' Of course, one can always add features where they don't belong. Everywhere else, this will be just a bad design. In the cryptography, that's how the "heartbleed" happened.
    – fraxinus
    Commented Dec 26, 2020 at 19:51
  • @PresidentJamesK.Polk really? SSL v3.0 is not that much recent. It wasn't mandatory and wasn't widely used, but was pretty much an intended feature of the protocol.
    – fraxinus
    Commented Dec 26, 2020 at 19:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .